発注側の責任

コンサル

前回（８月７日）は包括フレームワークの狙いを私が理解した範囲で示した。

このフレームワークの重要な考え方として、発注側もシステム開発、特に仕様に責任をもつというところにある。

これは当たり前と言えば当たり前のように聞こえるが実際には発注側の責任が明確になることは少ない。

家を建てるときに施主にとって住みやすい家は、家造りにどれだけ施主が関わるかで決まる。

同じようにシステム開発でも利用するユーザが何処までシステム開発に関わるかで出来が違ってくる。

しかし、既存システムがある場合はユーザの参画は非常に難しい。

ユーザにしてみると以下のような意識が働く

　・既存のシステムとほぼ同じような機能なのになぜ打ち合わせが必要になるのか
　・既存のシステムは現在の担当者が関わる前からあったので仕様は理解していない
　・年々人が減ってきて一人当たりの仕事量が増えているので打ち合わせの時間が取れない
　　〜〜

などなど　このような中で発注側が仕様に責任をもつというのはなかなか難しい。

一方ユーザ企業においてシステム開発に責任を持つのは情報システム部門である。　

大きな組織の情報システム部門は長年保守や改訂などが主要な仕事であり、新規のシステムを再構築することに慣れていない。

システムを企画し要件を決め開発に持って行く一連の流れを経験している担当者は少ない。

昔多くのシステムを開発してきた技術者はほぼ管理職になっており、現場に関わることは無くなっている。
同時に現在の技術にはキャッチアップできていない。

同時に２０代、３０代の情報システム部員でプロジェクトの最初から最後までの一連の作業に関与したことのある人はあまりいない。

従ってプロジェクトに時間の経過と共に起こる様々なことが分かっていない。

従って、情報システム部門が大きなプロジェクトを推進していくのは難しい。

そこでPMOが登場する。

最近の大規模開発ではPMOがおかれることが多くなっているのはこのような状況も原因である。

しかし、PMOが本当に力を発揮するためには、そのプロジェクトに関わる情報システム部門の責任者が最終的な責任を持たなくてはPMOは力は発揮できません。
単純なスケジュール管理ではなく問題解決のための様々な決断が求められるからです。
実際にはこれが一番実現していないことなのです。

ユーザの参画と発注側（発注者の情報システム部門）が責任を持つことはシステム開発成功への鍵です。

これが実現出来るとプロジェクトは非常に安定します。

逆にこれが不完全な場合はプロジェクトは最初から混乱しだします。