目次
第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 導入効果は定期的に点検しないと得られない
- 巻末資料