前エントリではITアーキテクトについて書いたのですが、僕が考えるITアーキテクトの作業として重要なものが「プロジェクト・ビジョン」です。
建築のビジョンは完成物が主
建築業界の建築家というと、クライアントの示したビジネス・ビジョンに対して、それを実現する建物のビジョンやコンセプトを定義するというものです。もちろん、それが建設できなくてはいけませんから建築学や物理学に基づいたチェックは行われています。
とはいえクライアントが重視するのは建築過程ではなく完成物です。それは「言うからにはちゃんと建つだろう」という最低限の約束が成立しているからです。もちろん建築業界も遅延や不良品と無縁ではありませんが、歴史的に見てびっくりするほど問題ではないでしょう。
システム開発のビジョンは"過程"が重要
一方でシステム開発では先ほどの「最低限の約束」が守られることが少ないため、びっくりする問題になっています（成功率は2003年の日経システム調べて26%。顧客満足度で図れば20%以下ではないでしょうか）。
そこでIT業界ではシステム・ビジョンだけでなく、プロジェクト・ビジョンが必要となります。
システム・ビジョンとは、完成物であるシステムが「ビジネスをどうやって実現するか」ということです。一方のプロジェクト・ビジョンは「どうやってそのシステムを作るのか」ということです。
プロジェクトの進め方、体制、開発方法というもので、具体的には以下のような感じでしょうか。
実装をどう行うのか：実装はどこで、だれが？仕様確認体制はどうする？詳細仕様は誰が？現場からのフォードバックをどうやって共有する？受け入れテストの規模は？何チームで開発される？実装期間はどれくらいにする？
体制をどうするのか：外注は使う？何社？それぞれのスキルは？管理はどうする？ステークホルダーはだれ？決定者は誰？
ともかく、こうしたもろもろというやつです。加えてこれらの項目が"失敗しないようにどうする？"、"失敗したらどうする？"ということも考慮しなくてはいけません。
プロジェクト・ビジョンに技術的な実行力を
こうしたプロジェクト・ビジョンというのは、PMが決めるべきではないのか？と感じられるかもしれません。しかし、次の理由で従来型PMでは難しいのです。
1.開発をうまく進めるためには、実装をうまく進めなくてはいけない
2.実装の最大リスクは属人性と情報劣化
3.これを抑制するためには規約（含パターン化など）が重要
4.でも、紙の規約は守れない
5.規約をソフトウェア化することが重要
6.それがアーキテクチャであり開発フレームワーク
つまり6を詳しく理解しないままプロジェクト・ビジョンを描いても、実行性のないビジョンにしからないのです。それに技術的知識がないと、そもそも問題に気づけないということもあるでしょう。
もちろんPMと（に）協力して決定するというのでも良いでしょう。重要なのはビジョンを具現化するためのロジカルでコード化された手札を持っているかということです。根性や気合では、スプーンは曲げられてもプロジェクトは曲がりません（手の届く範囲では奇跡がおこるかもしれないの意ｗ）。
ロジカルなプロジェクト運営を
「そりゃ、失敗するわな」というプロジェクトの話をよく聞きます。でもプロジェクトの失敗要因なんかよく聞く話ばっかり。そういう起こりうることを事前にちゃんとロジカルに考えておけば、まず墜落することはないと思います（軟着陸はしかたなし）。
大人なんだからロジカルに実行力のあるプロジェクト運営をすればいいのにと思う今日この頃（でも大人の方がそういうことができないとも思ったりして）。
じゃ、その具体的な手法はなんですかというわけですが、また、そのうちｗ
