MSOL社員ブログ

これまで何人かの優れたＰＭの下で働いてきた。
優れたＰＭは、失敗をしない。いかに難易度が高いと目されるプロジェクトであっても、である。

しかし、どのようなプロジェクトでも、成功させることができるわけではないようだ。
やはり、それぞれに得意分野というものがある。

彼らは、自分では成功させることができないプロジェクトをたくみに嗅ぎ分ける。
そして、そのようなプロジェクトに関わろうとしない。
決して無責任なわけではない。むしろプロフェッショナルとしての責任があるがゆえに関わろうとしないのだ。

そうして優れたＰＭは、着々と成功の実績を積み上げる。実績があるから良い仕事が集まり、良い仕事があるから、良いメンバーが集まる。
良いメンバーがいればプロジェクトは成功する。

ＰＭの実績こそが、プロジェクト成功の最大の条件なのかもしれない。

プロジェクト管理の重要性がシステム開発の現場に理解され、様々なプロジェクト管理手法が導入されつつあるにも関わらず、失敗するプロジェクトが後を絶たない。プロジェクト管理がきちんと行われているように思えるにも関わらず、ITプロジェクトが失敗するのは一体何故なのか？その原因には、次の2つがあると感じている。

１．「何のために作るのか」「何を作るのか」というシステム化要件（Why,What)が曖昧なまま、「どのように作るのか」という開発作業（How)をベンダーに委託してしまう。
２．システム化要件に沿って、ベンダーの成果物がきちんと作られているかどうかを発注者が確認しきれていない。
本来、「成果物の要件を明確にすること」「成果物の検証をすること」は発注者の責任である。しかし、システム開発経験の乏しい発注者にこのような要求することには無理がある。

システム開発と何かと類似点の多い建設の世界において、設計と施工の分離という考え方がある。工事を発注する施工会社とは別に、建築事務所に設計と施工監理を委託するという考え方である。建築事務所は、建築主の要望・意図を確認し、それを設計図面におとす。その設計図面に基づき、施工会社の工事内容を逐一チェックする。このことを施工監理という。ちなみに施工監理は、施工管理とは異なる別の概念である。施工管理は、いわゆる現場監督のことであり、一般的なプロジェクトマネジメントの概念に近い。

私はITプロジェクトにおいても、この建築事務所に相当する主体・機能が必要であると考えている。つまり発注者の要望や意図をシステム化要件として図面(モデル）に置き換えて整理し、その図面(モデル）を用いてベンダーに開発内容を伝え、図面(モデル)と照らして彼らの開発内容をチェックするという役割である。自然言語で書かれた要件定義書では、様々な解釈が可能であるためにどうしても曖昧さが残る。要件の曖昧さを排除するためには、建築の世界と同様、図面(モデル）を使って要件を整理することが不可欠である。

そのためには、ソフトウェア工学に精通した、いわゆるITアーキテクトが、発注者の立ち位置で要件定義やベンダー成果物の監理をドライブする必要がある。そしてその役目を担うのはPMOであり、PMOをアウトソーシングする理由の一つになり得ると私は思う。