システム（ソフトウェア）開発の不思議

1. 何故、近年は失敗プロジェクトが多いのか？

2. 何故、プロジェクトが大規模化するのか？（ビッグバンは有効だったか？？？）

3. システムの本質（真の狙い）は何か？　誰のためのシステムか？

4. 誰がシステム化のリスクを負うのか？

1970年代：

1. 自社保有リソースを前提にシステム化計画を立案

2. 自社内システム要員が中心のプロジェクト

   • • プロジェクト・リーダー

     • 適用業務SE

     • プログラマー

3. 業務分析、システム化（適用業務）計画立案、システムデザイン、プログラミング、テスト、導入支援を一人多役でチーム運営

4. 利用部門（ユーザー）との協業でシステム導入

1990年以降：

• 1. 外部リソース頼みの計画立案

  2. 専門家によるプロジェクト運営（分業化）

     • • プロジェクト・マネジャー（PMO)

       • 業務コンサルタント

       • システム・アーキテクト

       • DBデザイナー＆アドミニストレーター

       • プログラマー

       • テスター

       • ヘルプデスク

  3. 利用部門不在のシステム導入

     • • 丸投げで、ベストプラクティスのシステム化

       • 利用者の情報リテラシーに合ったシステム???

1. 同様なプロジェクト管理手法を利用しながら、何故成功率が異なるのか？

2. 実績あるプロジェクト管理手法が機能しない真の原因は？

   • • 建設プロジェクトとの決定的な違い。

ー進捗が目で見えるか？見えないか？（作業途中で是正が効くか？）

ー誰が作業しても同等な結果を得られる個々の作業の標準化がなされているか？

3. 上記の課題を解決しなければ、どんなに洗練された管理手法を採用しようともシステム構築プロジェクトの管理は個人の能力に従属したKKDにならざるをえない。

1. 常に議論されるトップダウン・アプローチとボトムアップ・アプローチ

   • • ウォーターフォール型開発はトップダウン・アプローチ

     • アジャイル開発はボトムアップ・アプローチ

     • 現実路線はハイブリッドでは？？？

ー従って計画/仕様設計はウォーターフォールと変わらない。

ー製造はイタラティブなアジャイル開発

2. アジャイル開発手法は、従来のウォーターフォール型開発と全く相
   容れないと言う考えは誤り

   • • 設計〜製造～テスト/納品の流れはどちらの手法でも同様だが、製造工程の『見える化』はアジャイル開発を利用しなければ、実現不可能である。

1. 『見える化』するための技術（手法）

   1. • タスクボード(作業ログの保管）

      • ペアプログラミング（ペアの頻繁な組み換え）

      • バーンダウンチャート（働く、機能するプログラム）

2. 擦り合わせのための技術（手法）

   1. • 短期間でのイタラティブ(反復での)開発

      • 頻繁なコミュニケーション(確認＆検証）と働くプログラム（見える化）