MSOL社員ブログ

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

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

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

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

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

最近、友人のアメリカ転勤イベントの幹事や、
友人の結婚式二次会の幹事を任されることがありました。

これまでも飲み会の幹事役を任されることがありましたが、
マネジメントソリューションズに入社したこともあってか、
こういったイベントの準備といった幹事業も
一つのプロジェクトと見立てて管理できるのでは？と思い、
プロジェクト管理の手法を導入して検証してみることに。

実際にWBSを作成して、スケジュールをメンバー間で共有し、
作業の役割分担、コミュニケーションルールを決定。
ゴールに向かってメンバーで作業を進めていきました。
大げさですが、途中発生した問題についても
課題一覧にまとめて共有したこともあります。

周りのメンバーは、プロジェクト管理について知識がない人ばかりで、
スタート時は、なかなか想いが伝わらないところありましたが、
ToDoリストを”やること一覧”等、メンバーに分かりやすい言葉に置き換えることで、
徐々にプロジェクト管理の大切さを浸透させることに成功しました。

途中色々アクシデントが発生しましたが、
きっちり管理してきたこともあって、イベントは無事成功。
笑顔でアメリカに送り出すことができました。

結婚式二次会の準備は今まさに継続対応中ですが、
こちらも無事成功を収めることができたらと思います。

こんにちは、亀井です。

みなさんは、仕事をする上で議事録やメモを作ることはありますか？

会議での議事録など、その場に参加している人が記録を残すことはとても大切です。

議事録は、会議の記録を残すだけでなく、その場にいなかった人にも会議の内容を伝えるための手段だと思います。

内容を正確に伝えるのはもちろん、誰が、何を、いつまでに、どうやってなど、会議の場にいなかった人にもわかるように、言葉を足して記載する必要があると思います。

会議で話した内容をそのまま記載するのではなく、体系的にまとめ記述することで、会議での検討事項や決定事項を共有できる資料になります。

議事録やメモを作成する場合は、チームメンバみんなが理解できるかという視点で見直してみると、より理解しやすい議事録になるのではないでしょうか。

最近議事メモを確認する機会も増え、時間をかけすぎずに、わかりやすい議事録を作成することが大切だなと今まで以上に思うようになりました。

商売柄、プロジェクトについて考える事が多い。

現在担当しているプロジェクトについてはもちろんであるが、最近気になるのが「プロジェクトの成功（の基準）」についてである。

---

プロジェクトにはPMO(project management office)として携わる。

プロジェクトの初期フェーズから参画することもあれば、テストフェーズ等の終盤フェーズからの参画もある。そのため、まず最初に確認するのが「プロジェクト計画書」である。

「プロジェクト計画書」が存在しており、それから充分な情報が得られる事は残念ながらまだ少ない。ましてプロジェクトの成功の判断となるような明確な基準、例えば、

• Q(quality：品質)

• C(cost：費用)

• D(delivery：納期)

• S(scope：範囲)

について、それぞれの規約や基準、また制約や前提等の条件が定義されており、関係性（優先順位等）が明示されるケースは稀有である。

---

翻って、「プロジェクトの成功率」で検索すると30%前後の数値が表示されたサイトが多数ヒットする。判定の基準はやはりQCDによる定量評価が多いようだが、一つでも基準を下回ると失敗とカウントされるようだ。

！！！

QCDの定量的な基準を一つも下回らないプロジェクトが30%も存在する？（基準は妥当なのだろうか？）

また、同業の知人には、
「今までプロジェクトで失敗したことがない」
という人も少なからずいる。
あえて基準を問わなかったが、羨ましい(おめでたい?!)プロジェクトである。

---

「QCDによる定量評価」and/or「定性的（恣意的）感想」だけによるプロジェクト成功判断があまり大きい意味を持つとは思えないし、その他の明確な解はまだないが、

プロジェクトに関わる人に、
「今回のプロジェクトの成功は何だと思いますか？」
と質問した際、プロジェクト計画書に記載されない多種多様な回答があり、いずれもPMOとして大きな気づきとなり今後のプロジェクト運営に役立った事だけは間違いない。