目次

• まえがき

第1章　プロジェクトリーダーになるということ

• • プロジェクトの構成要素／中小規模プロジェクトの課題／中小規模プロジェクトのメリット／中小規模プロジェクトの成功のポイント／プロジェクトリーダーの役割と留意点

第2章　ズレない仕様策定

• 一　顧客がＩＴ（情報技術）に関して素人である。仕様策定をどう進めていけばよいか？
  • 仕様策定プロジェクトチームを発足／【組織形態】
• 二　顧客がＩＴに精通している。仕様策定をどう進めていけばよいか？
  • 仕様策定しながら“できる”“できない”を交渉／【原価管理】
• 三　顧客のシステム化の目的に具体性がない
  • 期待される効果と解決すべき業務上の課題／【SWOT分析】【ベンチマーク】
• 四　顧客から断片的な要求事項らしきメモや関連する資料を渡されたが，どのように整理していけばよいのだろうか？
  • 資料をファイリングして“見える化”／重要な資料のみ詳細に／不明点・疑問点はあらゆる手段を使って／【ナレッジマネジメント】
• 五　顧客との打ち合わせをどうやって進めればよいのか？
  • レビュー形式のコミュニケーション／キーワードだけを走り書き／バカにされることを恐れず／【面接調査法】
• 六　課題の効果的で適切な解決策を見出すにはどうしたらよいか？
  • 課題に付随する条件や制限事項を調整／“定性的”に予測／解決の方向性／「リスク削減」対象の技術的解決策／【リスクマネジメント】【XPのテストファースト】
• 七　システム化後の業務手順を策定し，エンドユーザに説明するにはどうすればよいか？
  • 誰が，何の作業を，どこで実施するのか／どんな順番で実施するのか／【CRUDマトリックス】【データ指向アプローチ】
• 八　使いやすい画面仕様とするには，どのような点に配慮して仕様策定したらよいか？
  • 必要な時に必要な情報／顧客の反応／【プロトタイピング】
• 九　複数のベンダと協力して全体のシステムを構築する必要がある。どのような関係でシステム化を図ればよいか？
  • システム連携を疎結合／責任分担／【バッチ処理】【インターネット標準プロトコル】【Webサービス】【SOA】
• 十　情報セキュリティ対策は，何をどこまで考えればよいか？
  • 既存技術の活用／トランザクションセキュリティ対策／【情報セキュリティ技術】【暗号技術】【電子書名】

第3章　ヌケないシステム設計

• 一　仕様からシステムに求められる機能を漏れなく定義するには，どんな点について考えればよいか？
  • 「機能性」「信頼性」「使用性」「効率性」「保守性」「移植性」別の機能／【ソフトウェア品質特性】
• 二　ソフトウェアに関する機能が膨大，かつ複雑で，具体的にソフトウェアで何の処理をどうやって実施すべきか考えがまとまらない
  • ソフトウェアの内外で扱われるデータ／データの関係／データに対する操作／【命題論理】【述語論理】【オブジェクト指向アプローチ】
• 三　機能やデータをシステムのソフトウェア構造として反映するには，どうすればよいのか？
  • コスト制限／「高さ」「横」「縦」の３次元構造／縦の構造の雛形（スケルトン）／【構造化手法】【データ抽象化プログラミング】
• 四　性能を確保するために，ソフトウェアで設計すべきことは何か？
  • サブシステム単位のトラフィック／【待ち行列理論】
• 五　システムの信頼性を確保するのには，具体的に何をすればよいか？
  • データを守る／メンテナンス処理／復旧時間を短縮／【フォールトトレランス】【フェールソフト】【フェールセーフ】【フォールトアボイダンス】【フールプルーフ】【信頼性理論】
• 六　「拡張性」「効率性」「保守性」を備えたＲＤＢのテーブル構造を定義するためには，どうすればよいか？
  • コード体系／正規化レベル／トランザクション系のテーブル／【RDB】【正規化】

第4章　コケないマネジメント

• 一　仕様が不明にもかかわらず，計画を策定せざるを得ない
  • 前提条件と制限事項を明記した暫定版の計画／計画のメンテナンス／【フィージビリティスタディ】【損益計算書（P/L）】
• 二　プロジェクトの目的は，おきまりの品質確保（Q），コスト削減（C），納期厳守（D）でよいのだろうか？
  • 開発テーマ／業績ではなく“実績”／実績を形として残す／【マグレガーのXY理論】【特許出願】
• 三　QCDをすべて満足するには，どうしたらよいか？
  • QCD間のトレードオフ／納期を絶対値に／理解できないマネジメント手法／【総合技術監理】【満足化原理】
• 四　プロジェクトで実施すべき開発項目を漏れなく抽出するには，どうすればよいか？
  • “タテ”と“ヨコ”に細分化／システム設計以降の開発項目／【WBS】【PPP】
• 五　開発工数を見積もる必要があるが，どのような手順で算出すればよいか？
  • 全体工数をボトムアップ／優先順位別に工数集計／顧客に最初に提示する見積もり／【見積もり技法】【限界利益】
• 六　開発プロセスは，おきまりの開発工程を順番に並べるだけでよいのか？
  • 仕様策定とシステム設計を統合／プログラム設計はプログラミングに統合／単体テストはせずに／プログラム設計以降の開発項目／最初のステップで動作するコアを作る／開発項目の特性／作業の平準化／落し所を見極めて／【シナジー（相乗効果）】【ウォータフォールモデル】【インクリメンタルモデル】【CMMのプロセステーラーリング】
• 七　要員が多いほどプロジェクトの成功確率が高くなると考えてよいのか？
  • 少数精鋭／プログラマを成長させる／【職務拡大】【職務拡充】【バーナードのリーダーシップ論】
• 八　経験の浅い要員に開発項目を割り当てたいが大丈夫だろうか？
  • やって見せてマネさせる／最初から教育工数を見積もる／適正を見極める／【コーチング】【ピアレビュー】【XPのペアプログラミング】
• 九　社内要員が不足しているため外部委託を前提にプロジェクト体制を考える必要がある。どんな点に配慮すればよいか？
  • 外部委託先の選定／委託範囲の限定／外部委託先との相互信頼関係／【システム監査基準の外部委託】【CPM】【トレンドチャート】
• 十　発生する遅延に対して，どう対処すればよいのか？
  • 納期までの時間／発生した問題には即刻対応／遅延が発生している担当者の負荷／外部委託先担当分／【ブルックスの法則】

• 参考文献
• あとがき