あるところからこんな相談を受けた。システム開発プロジェクトを進めてきたが、開発元があてにならないという。納期遅延であり、かつ完成の目処さえ立っていない。このままずるずると引きずるわけにもいかず、損失を覚悟でプロジェクトを打ち切りたいが、それなりに開発元へ損害賠償も考えたいというのである。
　
　いわゆる、失敗プロジェクトの後始末である。
　
　このプロジェクトの話を伺ってみると、失敗の原因は、当然のことだが双方にあると考えている。
　
　開発元の要因：見積もりの甘さ、スキル不足、管理能力不足。つまり、全てがＮＧである。理想を追っかけたか、現実を知らなかったか、そのギャップがこの結果を生み出している。最大の要因は、確かに開発元にありそうだ。
　
　発注元の要因：開発元の見積もりを鵜呑みにして、リスクとして対策を採らなかった。開発元のスキルを見抜けなかった。プロジェクトの進め方で、会話にならず主張の言い合いになってしまいまとまらなかった。
　
　こんなことって、多かれ少なかれ、どこにでもあるプロジェクトの姿ではないかと思うのである。
　
　発注元と発注先の１対１の関係でのプロジェクトは、この様相を呈している。うまくいけばよいが、ギャップが生じた場合にそれを埋められない傾向がでるのである。
　
　主張の言い合いをまとめるのは、非常に難しいことなのである。発注元は発注先をその手のプロフェッショナルだと勘違いしていることも大きな要因。営業トークをそのまま聞き入ってしまっては、こんな事態になってしまう。見抜く力が必要なのだが、本業ではないＩＴ分野の力量を見抜くことは素人では無理だろう。
　
　そこで、ビジネスの三角関係を提案している。プロジェクト管理を第三者といして立てて、全体最適を進めていく。
　
　発注先のけん制にもなるし、相談相手にもある。発注元にすれば、自社内であたりないＩＴノウハウや情報、経験、プロジェクト管理をアウトソーシングすることで獲得できる。結果的には、費用もスケジュールも想定内に納まる可能性が高まるのである。
　
　このビジネスモデルを弊社では、ＭａａＳ（Management as a Service）と定義して、プロジェクト管理を必要な場面、必要なとき、必要な量だけ提供するサービスを展開している。このキーワードが、今回の相談につながったようだ。　
　
　社内外の視点を持って、発注元の懐の中に入り込んでのアドバイスやプロジェクト管理は、誰にでもできることではない。まさに経験と修羅場をくぐってきた経験数によるノウハウがものを言う。
　
　今回も、崩壊プロジェクトに入り、情報や責任を整理し、お互いの損失を軽減しながらの決着を試みている。
　
　このＭａａＳ。ご興味ある方は、ぜひご連絡ください。
　
ＳＦＪソリューションズ株式会社
http://www.search-firm.jp/sfjs/