情シスの定石～失敗事例から学ぶシステム企画・開発・保守・運用のポイント～
情シスの定石 ～失敗事例から学ぶシステム企画・開発・保守・運用のポイント～
技術評論社
著者：石黒直樹、解夏
はじめに
ご注意
第1章 情シスが抱える課題と本書の役割
1.1 情報システム部の現状
［現場の課題①］情シスにノウハウが蓄積しない
［現場の課題②］IT人材の育成が難しい
［現場の課題③］人材不足（ひとり情シスや部署兼務の常態化）
［現場の課題④］システムの複雑化
1.2 課題に対する本書の役割
1.2.1 本書から得られること
1.2.2 対象読者
1.2.3 課題解決のための本書の「コンセプト」
1.3 本書の構成
1.3.1 全体構成
1.3.2 各章の構成
1.3.3 要因について
1.3.4 登場人物について
第2章 企画
2.1「企画」とは
2.1.1 鳥瞰図における位置付けと内容
2.2 サービス企画
2.2.1 サービス企画の活動内容
2.2.2 サービス企画作成のポイント
2.2.3 特に重要な社外要因・社内要因
2.2.4 失敗事例：経営戦略と方向性が異なり、企画になかなかOKが出ず
2.3 システム企画
2.3.1 システム企画の活動内容
2.3.2 システム企画作成のポイント
2.3.3 特に重要な社外要因・社内要因
2.3.4 失敗事例：IT資産を有効活用できず、運用コストが倍以上に！
2.4 RFP
2.4.1 RFP作成の活動内容
2.4.2 RFP作成のポイント
2.4.3 特に重要な社外要因・社内要因
2.4.4 失敗事例：RFPのレビュー先部署の選定が十分でなく、重要な要求漏れから大問題に発展！
2.5 提案書評価・契約
2.5.1 提案書評価・契約の活動内容
2.5.2 提案書評価・契約のポイント
2.5.3 特に重要な社外要因・社内要因
2.5.4 失敗事例：開発ベンダにプログラムを再利用、販売されてしまった！
2.6 サービス評価
2.6.1 サービス評価の活動内容
2.6.2 サービス評価のポイント
2.6.3 特に重要な社外要因・社内要因
2.6.4 失敗事例：既存システム置き換えでサービス利用を選択したが、作業量が多く業務が成り立たない！
2.7 この章のまとめ
第3章 システム開発
3.1「システム開発」とは
3.1.1 鳥瞰図における位置付けと内容
3.2 プロジェクト計画
3.2.1 プロジェクト計画の活動内容
3.2.2 プロジェクト計画書作成のポイント
3.2.3 特に重要な社外要因・社内要因
3.2.4 失敗事例：リリースタイミングを細分化しすぎた結果、コスト増、品質も低下！
3.3 要件定義
3.3.1 要件定義の活動内容
3.3.2 要件定義作成時・レビュー時のポイント
3.3.3 特に重要な社外要因・社内要因
3.3.4 失敗事例：「現行と同様」では、現行を知らない開発ベンダが要件を設計に落とし込めない！
3.3.5 失敗事例：非機能要件が具体的に定義されていない！総合テストで開発ベンダと揉める事態に
3.4 設計（基本設計・詳細設計）
3.4.1 設計（基本設計・詳細設計）の活動内容
3.4.2 設計（基本設計・詳細設計）のレビューポイント
3.4.3 特に重要な社外要因・社内要因
3.4.4 失敗事例：項目の整合性が取れておらず、統一性のない設計に！
3.5 開発・ベンダテスト
3.5.1 開発・ベンダテストの活動内容
3.5.2 開発・ベンダテストのレビューポイント
3.5.3 特に重要な社外要因・社内要因
3.5.4 失敗事例：コード規約に準拠せず構築してしまい、保守で大混乱！
3.5.5 失敗事例：単体テストで検出すべきバグが結合テストで大量に！スケジュールは大幅に遅延
3.6 ユーザ受け入れテスト
3.6.1 ユーザ受け入れテストの活動内容
3.6.2 ユーザ受け入れテストのポイント
3.6.3 特に重要な社外要因・社内要因
3.6.4 失敗事例：重要機能の確認を後回しにした結果、バグ改修が稼働に間に合わず！
3.7 業務トレーニング
3.7.1 業務トレーニングの活動内容
3.7.2 業務トレーニングのポイント
3.7.3 特に重要な社外要因・社内要因
3.7.4 失敗事例：説明する順番や内容に不備があり、社内説明会が炎上！
3.8 移行リハーサル・移行本番
3.8.1 移行リハーサル・移行本番の活動内容
3.8.2 移行リハーサル・移行本番のポイント
3.8.3 特に重要な社外要因・社内要因
3.8.4 失敗事例：コンティンジェンシープランが未設定！障害復旧に時間がかかり業務影響が発生
3.9 この章のまとめ
第4章 サービス導入
4.1「サービス導入」とは
4.1.1 鳥瞰図における位置付けと内容
4.2 プロジェクト計画
4.3 サービス導入設計
4.3.1 サービス導入設計の活動内容
4.3.2 サービス導入設計のポイント
4.3.3 特に重要な社外要因・社内要因
4.3.4 失敗事例：バックアップレベルが社内ルールに達しておらず、追加システム開発が発生！
4.4 サービス設定・確認
4.4.1 サービス設定・確認の活動内容
4.4.2 サービス設定のポイント
4.4.3 特に重要な社外要因・社内要因
4.4.4 失敗事例：計算方法が異なるため、算出結果が以前と変わってしまった！
4.5 業務トレーニング
4.5.1 業務トレーニングの活動内容
4.5.2 業務トレーニングのポイント
4.5.3 特に重要な社外要因・社内要因
4.5.4 失敗事例：大人数で業務トレーニングを開始したところ、サービスにアクセスできず！
4.6 移行リハーサル・移行本番
4.6.1 移行リハーサル・移行本番の活動内容
4.6.2 移行リハーサル・移行本番のポイント
4.6.3 特に重要な社外要因・社内要因
4.6.4 失敗事例：データクリーニング範囲に漏れが！テストデータが残ったまま業務開始
4.6.5 失敗事例：データ移行が終わらない！しばらくの間業務が煩雑に
4.7 この章のまとめ
第5章 保守
5.1「 保守」とは
5.1.1 鳥瞰図における位置付けと内容
5.2 保守の全体設計
5.2.1 保守の全体設計の活動内容
5.2.2 保守の全体設計のポイント
5.2.3 特に重要な社外要因・社内要因
5.2.4 失敗事例：保守で更新すべきドキュメントが明確化されていない！
5.3 保守契約の締結
5.3.1 保守契約の締結の活動内容
5.3.2 保守契約の締結のポイント
5.3.3 特に重要な社外要因・社内要因
5.3.4 失敗事例：保守契約における営業日の定義が曖昧で障害対応をしてもらえず！
5.4 優先順位付け・案件実施
5.4.1 優先順位付け・案件実施の活動内容
5.4.2 優先順位付け・案件実施のポイント
5.4.3 特に重要な社外要因・社内要因
5.4.4 失敗事例：実施案件の管理不足から並行開発に失敗！障害多発となる事態に
5.4.5 失敗事例：ガラパゴス化した独自の保守開発により後任にしわ寄せが！
5.5 評価・改善
5.5.1 評価・改善の活動内容
5.5.2 評価・改善のポイント
5.5.3 特に重要な社外要因・社内要因
5.5.4 失敗事例：人材不足により保守品質が悪化！障害が多発してしまった
5.6 この章のまとめ
第6章 運用
6.1「運用」とは
6.1.1 鳥瞰図における位置付けと内容
6.2 運用計画
6.2.1 運用計画の活動内容
6.2.2 運用計画作成のポイント
6.2.3 特に重要な社外要因・社内要因
6.2.4 失敗事例：運用受け入れの説明ができておらず、揉めに揉めて残業の日々！
6.3 イベント管理
6.3.1 イベント管理の代表的な管理対象
6.3.2 イベント管理のポイント
6.3.3 特に重要な社外要因・社内要因
6.3.4 失敗事例：接続先システムのサービス停止を把握しておらず、システムエラーが多発！
6.4 システム管理
6.4.1 システム管理の代表的な管理対象
6.4.2 システム管理のポイント
6.4.3 特に重要な社外要因・社内要因
6.4.4 失敗事例：ハードウェアの延長保守を把握しておらず、コスト不足に！
6.5 障害対応
6.5.1 障害対応の活動内容
6.5.2 障害対応のポイント
6.5.3 特に重要な社外要因・社内要因
6.5.4 失敗事例：安易に再実行した結果、データ不整合による二次障害が発生！
6.6 評価・改善
6.6.1 評価・改善の活動内容
6.6.2 評価・改善のポイント
6.6.3 特に重要な社外要因・社内要因
6.6.4 失敗事例：評価に使えないファクトばかり！ファクト収集のための改修が発生
6.7 この章のまとめ
第7章 廃止
7 1「廃止」とは
7.1.1 鳥瞰図における位置付けと内容
7.2 プロジェクト計画
7.3 廃止設計
7.3.1 廃止設計の活動内容
7.3.2 廃止設計のポイント
7.3.3 特に重要な社外要因・社内要因
7.3.4 失敗事例：いつの間にかデータ利用が開始されており、システム廃止とともにトラブル発生！
7.4 廃止実施
7.4.1 廃止実施の活動内容
7.4.2 廃止実施のポイント
7.4.3 特に重要な社外要因・社内要因
7.4.4 失敗事例：外部サービスへの依頼が上手くいかず、無関係の他社に影響発生！
7.5 この章のまとめ
第8章 マネジメント
8.1「マネジメント」とは
8.1.1 鳥瞰図における位置付けと内容
8.2 マネジメントの基本
8.2.1 マネジメントの基本とは
8.3 各工程の「計画時」に検討すべきこと［Plan］
8.3.1 検討すべきことは何か
8.3.2 各工程の「計画時」に注意すべきポイント
8.3.3 特に重要な社外要因・社内要因
8.3.4 失敗事例：クローズしたと思った課題が再燃！
8.4 各工程の「実行時」に確認すべきこと［Do］
8.4.1 確認すべきことは何か
8.4.2 各工程の「実行時」に注意すべきポイント
8.4.3 特に重要な社外要因・社内要因
8.4.4 失敗事例：開発ベンダをツメすぎた！最低限の対応しかされず品質の悪いシステムに
8.5 各工程の「評価時」に確認すべきこと［Check］
8.5.1 評価すべきことは何か
8.5.2 各工程の「評価時」に注意すべきポイント
8.5.3 特に重要な社外要因・社内要因
8.5.4 失敗事例：前工程の良くない部分が改善されず、次の工程に持ち越された！
8.6 各工程の「改善時」に検討すべきこと［Action］
8.6.1 改善すべきことは何か
8.6.2 各工程の「改善時」に注意すべきポイント
8.6.3 特に重要な社外要因・社内要因
8.6.4 失敗事例：他案件での改善が共有されず、保守案件で同じミスが発生！
8.7 この章のまとめ
Appendix 役に立つフレームワーク
KPT法
SMART
5W2H
重要度と緊急度のマトリックス
参考文献
おわりに
執筆者プロフィール
索引