情シス・IT担当者［必携］システム発注から導入までを成功させる90の鉄則

書籍の概要

この本の概要

本書は，IT担当者，情報システム部門に向けた，システム発注から導入までのノウハウ集です。

なぜシステムの発注～導入には失敗がつきまとうのでしょうか。

筆者は，「失敗の原因はユーザー企業の力量不足」と喝破します。

ユーザー企業は，少なからず何らかのシステム導入を経験しているものです。
であれば，経験はノウハウとして蓄積されているはずです。
しかし，プロジェクトは失敗してしまいます。
ノウハウに体系的なまとまりがないからです。

本書には，ITコンサルタントという立場だからこそ知りえた筆者のノウハウが詰まっています。

こんな方におすすめ

  • 情報システム部門の方，IT担当者
  • システム導入案件を任されたユーザー企業の担当者，責任者

この書籍に関連する記事があります！

御社のITプロジェクトが今後ますます重要になるワケ
最近，ヤマト運輸の動向が日本中の注目を集めていました。

目次

第1章　システムの企画提案～ITベンダー選定までのルール

  • 1-1　ITプロジェクトを社内横断的に立ち上げる
    • RULE 01　ITプロジェクトで自社を加速させる
    • RULE 02　ITプロジェクトは人選が運命を決める
    • RULE 03　オーナーの立ち位置がプロジェクトの成否を分かつ
    • RULE 04　役割分担表はまず上流工程のみ定義する
  • 1-2　適切な企画でプロジェクトの成功レールを敷く
    • RULE 05　企画がダメだと全てダメになる
    • RULE 06　企画書の目次はこう作る
    • RULE 07　全社目線でシステム導入の目的を設定する
    • RULE 08　システム導入の背景・目的・効果はこう考える
    • RULE 09　システムの効果は全ての数値化を試みる
    • RULE 10　要求機能一覧でブレない自社の基準を作る
    • RULE 11　要求機能一覧はこう作る
    • RULE 12　システム関連図で森を描く
    • RULE 13　パッケージ導入は選定が全て
    • RULE 14　パッケージ導入スケジュールはこう作る
    • RULE 15　スクラッチ開発は総合力が問われる
    • RULE 16　スクラッチ開発スケジュールはこう作る
    • RULE 17　クラウドは事業面や業務面から相性を判断する
    • RULE 18　クラウドでIT部門の負担を軽減する
    • RULE 19　基幹システムは全体計画に従い導入する
  • 1-3　自社に最適なITベンダーを見つけるためにRFPを活用する
    • RULE 20　RFPは最適なパートナーを選ぶ手段である
    • RULE 21　RFP未完成でベンダーに声をかけない
    • RULE 22　RFPの自社フォーマットを確立する
    • RULE 23　RFPの目次はこう作る
    • RULE 24　RFP本編はこう作る
    • RULE 25　RFP本編で注意すべきこと
    • RULE 26　RFP別紙で自社の業務内容を柔軟に伝える
    • RULE 27　業務フローで自社の説明責任を果たす
    • RULE 28　業務フローは自社で整理する
    • RULE 29　業務イベント図で業務をシンプルに表す
    • RULE 30　社内合意していないRFPは無意味
  • 1-4　ITベンダーは客観的かつ公正なプロセスで選ぶ
    • RULE 31　ITベンダーと会う前に評価基準を作っておく
    • RULE 32　選定方針に従いベンダー評価シートを作成する
    • RULE 33　ベンダーの実績を軽視しない
    • RULE 34　あらゆる手段を駆使してRFP発行先を見極める
    • RULE 35　ベンダーの提案を主体的に検証する
    • RULE 36　パッケージは「ノンカスタマイズ」を目指す
    • RULE 37　「アップルtoアップル」で完成させる
    • RULE 38　選定会議で会社としての結論を出す
  • 1-5　ITベンダーとの契約書でトラブルを未然に防ぐ
    • RULE 39　著作権は必ず自社に帰属させる
    • RULE 40　瑕疵担保責任期間は1年を基準とする
    • RULE 41　多段階契約は自社に不利となる

第2章　プロジェクト立ち上げ～要件定義までのルール

  • 2-1　プロジェクト計画でベンダーとの良好な関係の枠組みを作る
    • RULE 42　プロジェクト計画書で共同作業の方向を定める
    • RULE 43　ベンダーWBSとは別に社内WBSを作る
    • RULE 44　社内WBSは全て自社タスクで構成する
  • 2-2　システム要件を俯瞰し導入効果を最大化する
    • RULE 45　要求機能一覧をベンダーと精査していく
    • RULE 46　現行帳票は全て廃止するつもりで見直す
    • RULE 47　システム間連携は自社の連携力が問われる
    • RULE 48　システム間連携で注意すべきこと
    • RULE 49　自社でデータの手加工運用を前提としない
  • 2-3　自社の課題解決力で進捗を加速させる
    • RULE 50　自社の課題管理表の方こそ重要
    • RULE 51　課題管理表はこう作る
    • RULE 52　課題管理は進捗を聞くだけでは意味がない
  • 2-4　マスターデータは自社の生死を分かつ
    • RULE 53　マスターデータの手入力は最後の手段とする
    • RULE 54　マスターデータは全件テストする

第3章　ユーザー受入テスト～システム検収までのルール

  • 3-1　システム検証の前にプロジェクト計画の仕切り直しをする
    • RULE 55　下流工程の役割分担表で仕切り直しをする
    • RULE 56　本物の管理者かどうかはWBSの扱いでわかる
    • RULE 57　管理者も仕様から逃げない
  • 3-2　納品されたシステムを自社責任で徹底的に検証する
    • RULE 58　受入テストをカオスにしないために
    • RULE 59　受入テストは4種類で計画する
    • RULE 60　機能確認テスト項目書はこう作る
    • RULE 61　システム間連携テスト項目書はこう作る
    • RULE 62　シナリオテスト項目書はこう作る
    • RULE 63　シナリオテストはコーディネートするもの
    • RULE 64　現新比較テストは全件で行ってこそ意味がある
    • RULE 65　現新比較テストをExcelで行う方法
    • RULE 66　合わない理由を徹底的にトレースする
    • RULE 67　検収を遅らせるとLose-Loseになる
  • 3-3　システム障害を主体的に管理することで致命傷を防ぐ
    • RULE 68　受入テストの障害管理表は自社が管理する
    • RULE 69　障害管理表はこう作る
    • RULE 70　障害管理表のボールが止まっていないか
  • 3-4　ITベンダーへのアプローチを工夫し品質を引き上げる
    • RULE 71　事前にベンダーテスト結果を確認する
    • RULE 72　スクラッチ開発は品質報告書を要求する
    • RULE 73　その遅延は本当にベンダーのせいか

第4章　ユーザー教育～システム本稼働までのルール

  • 4-1　マニュアルを作成し混乱と不満を最小限に抑える
    • RULE 74　マニュアルは2種類ある
    • RULE 75　マニュアルは誰が作るのか
    • RULE 76　業務マニュアルは大勢で作らない
  • 4-2　システムを実際に使うユーザーを味方につける
    • RULE 77　説明会で良いイメージを持ってもらう
    • RULE 78　業務説明が先，システム操作が後
    • RULE 79　システム操作説明会のリハーサルは必ず行う
  • 4-3　新システムの稼働判定会議を開催し全社的に判断する
    • RULE 80　システム稼働判定は自社主導で必ず行う
    • RULE 81　稼働判定表はこう作る
    • RULE 82　並行稼働後の稼働判定表はこう作る
    • RULE 83　稼働判定はプロジェクトマネージャーの責任で進める
  • 4-4　万全な準備で本番稼働を迎える
    • RULE 84　初回稼働時は考えうる全てのチェックを行う
    • RULE 85　本番障害は軽率な対応を行わない
    • RULE 86　社内原因の本番障害は再発防止を考える

第5章　システム運用／保守のルール

  • 5-1　システムの開発体制から保守体制へスムーズに引き継ぐ
    • RULE 87　社内引き継ぎの前に体制を明確にする
    • RULE 88　保守メンバーを交えて課題をたな卸しする
    • RULE 89　ベンダーと積み残しの最終確認を行う
  • 5-2　システムの導入効果を最大限に引き出す
    • RULE 90　導入効果は定期的に点検しないと得られない
  • 巻末資料