曖昧性とのたたかい ～体験的プロジェクトマネジメント論～

第1章　システムビジネスと受注

1.1　システムビジネスの流れと特徴
システムビジネスの流れ
システムビジネスの特徴

1.2　システムの受注
顧客要求事項のより正確な把握
顧客予算の事前把握/顧客予算の見積り
顧客予算に合わせたシステムの提案
納期に無理はないか
検収条件に無理はないか
戦略的受注のための戦略
避けたい防衛的受注
身の丈にあった受注

第2章　見積り

2.1　見積りの重要性と難しさ
見積り条件、見積仕様書
適切な見積りとは
プロポーザルは見積仕様書である
安易な見積りの怖さ

2.2　見積りミスの防止
段階的見積り、段階的契約の提案
作るよりつなぐ―見積り対象の削減
仕様の膨張を抑える見積り条件
見積り周辺の注意事項

2.3　見積り能力向上のために
失敗事例
成功事例

コラム　「思考停止」症候群

第3章　スコープの明確化

3.1　受注条件の明確化とシステム仕様の確定
受注条件の明確化、再確認
システム仕様の確定
システム仕様膨張の抑制
仕様が膨らんでしまったときの対処
契約の見直し

第4章　プロジェクト計画

4.1　プロジェクト工程計画
工程設計
極力詳細に矛盾なく
工程進捗度の事前定義
最悪事態を想定した準備
顧客との工程表合意

4.2　プロジェクト共通設計基準の整備
ドキュメント体系、ドキュメント作成基準
共通設計基準
共通データ仕様書の管理
プログラムライブラリ管理
用語集

4.3　プロジェクト工程計画の円滑推進
統括部隊の設置
キックオフミーティング―工程計画の周知徹底

第5章　基本設計

5.1　美しい設計
設計基本思想の明確化宣言
データ仕様の設計重視
単純明快性の追求
一様性の追求
階層性の追求
対称性の意識
良い名前は幸せの始まり
美しい解を求める
美しさを感じる心

5.2　混乱の少ない設計
部隊の力量にあわせた設計方式の選択
部品化、共通化、オブジェクト指向の落とし穴
目標コストを定め、それに合わせた設計を心がける
仕様変更に強い設計
戦略的プロトタイピング

5.3　後工程を考慮した設計
バグが見つかりやすい設計
テストしやすい設計
失敗時の逃げ道を考えた設計

5.4　信頼性を考慮した設計
最大許容ダウン時間はよく見極めよう
システムを極力止めないようにしよう
長時間ダウン防止策を考えよう
蟻穴に注意
暗黙知の重要性

5.5　処理能力を考慮した設計
スループットとレスポンス
前より長くは待てない
レスポンスタイムは仕様拡大防止の砦にもなる
トラフィック特性の把握
ポジティブフィードバック型システムに注意
待時式か即時式か
1日は24時間しかない
処理能力限界の予兆をつかむ仕掛けの準備
社会変化に着目

5.6　運用しやすい設計
運用を阻害する3大特病
運用負荷の平準化―特意日の少ない設計
運用ミスの低減
異常時の運用負荷の軽減
運用環境変化の警告

5.7　拡張性がある設計

5.8　保守を考慮した設計

第6章　システム開発

6.1　プロジェクト進捗管理
進捗度の把握
レビューによる質的進捗度評価
顧客との定例会議の決定
スケジュール遅れへの対処
納期と稼働開始

コラム　真の事実とファクトファインディング

6.2　コスト管理
目標原価はマネージャーの約束、指示、意志
コスト管理の中心は人件費管理
原価（人件費）が増えないプロジェクトこそあぶない
原価予想とタイムリーな申告

6.3　仕様変更管理
仕様変更要求の管理
仕様変更に予算の裏づけを
稼働前後の修正変更は絶対禁止
変更管理システムの活用

6.4　要員管理、組織管理
要員配置
組織編成
要員のモラル管理
プロジェクト内での教育
ローテーション

6.5　コミュニケーション管理
情報の発信と受信
指示
報告
折衝

6.6　外注管理
外注契約の形態
外注会社の選定
外注先体制の確認
発注仕様書の整備
外注管理の実際
海外発注（オフショア開発）

6.7　品質管理
テスト組織の確立とテスト方式の設計
品質と問題点の早期把握
より完璧なテストへの挑戦
品質管理部（検査部）との連携
テスト効率向上のために
稼働開始可否の判定

6.8　その他のリスク
動かないコンピュータも色々
動いているコンピュータを止めないために
止まったコンピュータを早く動かすために
機密管理
安全管理
輸出管理

6.9　終結
検収と要員引き上げ
プロジェクト反省会

第7章　顧客との信頼関係の構築

7.1　顧客にも同じ船に乗ってもらうために
顧客折衝
真の顧客を見つける
顧客第一主義
顧客との業務分担
顧客側プロジェクト体制の確立

結びに代えて

何をおいても実態把握（ファクトファインディング）
システムの必要最低限の機能を選び直す
絞り込んだ機能について対策工程を設定する
窓口責任者の設定
前向きに粘り強く、泥沼をかき分けて（Mudding through）
転んでもただでは起きない

補論　マルス 105プロジェクトから学ぶ

A.1　マルス 105の誕生の経緯

A.2　事故に学ぶ知恵
マルス 103の後始末とマルス 105への反映

A.3　ドキュメントこそプロジェクト展開の基礎
業務機能仕様書の充実
データ仕様書、インターフェース仕様書の充実

A.4　マルス工程表の設計
ファイル管理系の優先
機能の優先順位を明確に意識
問題点早期発見のためのレビュー
準備作業の事前検討

A.5　顧客と同じ船に安全に乗る

A.6　信頼性と保守性を支える「美しい設計」
外部からの入力はすべてMSGET（メッセージゲット）で受ける
ディメンションを減らす
論理のデータ化
ロジックとデータの分離
プログラム間連絡方式の統一

A.7　見逃しバグの早期摘出のために
設計上の工夫
要員配置の工夫
テストの工夫
地道なテスト

お問い合わせ

内容についてのお問い合わせは、正誤表、追加情報をご確認後に、お送りいただくようお願いいたします。

正誤表、追加情報に掲載されていない書籍内容へのお問い合わせや
その他書籍に関するお問い合わせは、書籍のお問い合わせフォームからお送りください。

利用許諾に関するお問い合わせ

本書の書影（表紙画像）をご利用になりたい場合は書影許諾申請フォームから申請をお願いいたします。
書影（表紙画像）以外のご利用については、こちらからお問い合わせください。