IT開発プロジェクトと建築土木

もうIT関連の仕事に携わって２０年ぐらいになるが、関係したプロジェクトは成功も失敗もある。自分自身がPMとして失敗してしまったプロジェクトもあるし、さまざまな担当して担当タスクを失敗してしまったこともあるし、自分は失敗しなかったがプロジェクトとしては、失敗だったこともある。

ちなみに自分の中では、当初のシステムの目標に対し、期間、予算、機能（品質）が+30%の幅の中に収まることと考えている。（甘い見方かもしれないが）

ITプロジェクトを推進するにあたって、例えば「ビルを立てる」といった建築土木のプロジェクトの進め方との関連を意識したりしてきた。

ITプロジェクトと建築土木の考え方の間には類似点があると考えていた。

1. ものすごくざっくりというと作業工程が計画〜設計〜実装（建築土木ではなんと表現するのだろう）と工程の進み方が似ていると考えていた。※アジャイル開発においても基本これは変わらないと考えている。進め方の粒度の違いだけ。
2. 何十〜何千という見知らぬ人間が集まって目標を完遂する。各工程でスペシャリストが集まり、ものを作り上げていく。釘を打つ人と壁紙を貼る人の間のコミュニケーションはどのようにとっていくのだろうとか。
3. 予算、工期、品質の目標がある。

建築に失敗したビルというのは聞かないが、（実はあるのか？？）、失敗したITプロジェクトはごろごろある。なぜなんだろうと考えた結果、計画局面の決定ぐあいが違うのでは？と思い至った。大きなビルならモックアップをつくって検証すると聞いたことがある。また設計図など共通認識を持つための情報ツールがもう枯れた技術となっていて実装時に迷うことがないのでは？（記法なども統一されているだろうし、A社の設計図は、全然別のB社が完全に読み取れるはず）

とするとITプロジェクトにおいても

1. 計画、設計局面において、できるだけ決定できることは細かく決定しておくこと。
2. 決定したことの共通理解を関係者がもつこと。また理解のための共通言語（設計図に相当するもの）もつこと。
3. 上記とも関係するが、共通理解のためのイメージ合わせのためプロトタイプを利用すること（モックアップに相当。プロトタイプの再利用など考えず使い捨てにしたほうが良いと思う）

実装より計画を！（アジャイル宣言に反している気がしますが。。）

に重点をおくと現状が改善されるように思った。通常のウォーターフォール開発では計画〜要件定義までに予算の２割も使えば多いほうだが、（計画には１割も使っていないのでは？）これを少なくとも３割程度までUPすると後半の手戻りも少なくより成功に近づくのではと考えた。