中嶋です。
今回はIT投資マネジメントから話がそれてしまいますが、プロジェクトの失敗についての自分なりの考察を書いてみようと思います。
先日、こんな記事がITproで掲載されていました。
ITpro：なぜプロジェクトマネジメントは機能しないのか
「プロジェクトの成功率は3割にも満たない」と言われ続けていますが、こういった記事を見ると、如何にプロジェクトを成功させることが困難であるかを改めて感じます。昔と違って、マネジメント系の教育も充実していますし、プロジェクトマネジメントやPMPといったマネジメント系の資格取得者も増えているというのに何故改善しないんでしょう？
色々な理由があってプロジェクトは失敗してしまうわけですが、根本原因は以下２つではないかと私は考えています。
１．スコープが定義出来ていない
２．プロジェクトの振り返りをしっかり行っていない
以下で、それぞれについて意見を述べたいと思います。
１．スコープが定義出来ていない
これは、見積が甘かったという声を取り上げたものです。要件（機能・非機能）、要員、コスト・・・色々あるとは思いますが、いずれもスコープが正しく定義出来なかったから起こる事象です。
では、スコープは要件定義段階で明確に定義出来るものなのでしょうか？答えはNoだと思います。ITプロジェクトの成果物が目に見えないという性質上、最終的なイメージを付けづらいからです。そのため、後から後から要望が増え収集がつかなくなったり、そもそも思っていたものと違うものが出来上がって使われないといった事態に陥ってしまいます。
個人的には「大枠のスコープを定義」して、後はお客様との認識ギャップを減らす取り組みを続けたり、発生する可能性のある変更を予め洗い出して共有しておくことが効果的だと思います。
前者は、プロト開発やイテレーション開発、簡単なところではお客様とのコミュニケーションを増やすといったことが考えられます。少しずつ成果物が見えてくれば、お客様のイメージもより具体的になりますし、コミュニケーションを増やすだけでも認識ギャップは大幅に減らせます。特に開発フェーズ等、請負期間中は移行やユーザーテスト、ユーザー教育の話が中心となってしまい、機能イメージの共有等を行わないことが多いように感じますので、やってみる価値は大いにあると思います。
後者は、リスクマネジメントの実践です。マネジメントは実践しているといっても、リスクマネジメントを正しく実践しているプロジェクトは少ないのではないでしょうか？実際リスク一覧を作っているといっても、書いている内容が具体化されていなかったり、洗い出して満足してしまって運用されていないプロジェクトが多いように感じます。まだ実践されていないのであれば、フェーズの開始終了時点だけでも有識者を集めて、リスク検討してみてはいかがでしょうか？
２．プロジェクトの振り返りをしっかり行っていない
プロジェクトの振り返りを行うことは、ナレッジの共有という意味でも非常に有効であると考えています。冒頭で挙げた記事を引用すると、
プロジェクトとは、
「やったことがないことを何が起こるか分からないのに、計画して、
予定通りのモノ（コト）を、期限までつくる（終らせる）こと」
とあるように、分からないことに挑戦することでもあります。プロジェクト推進期間中に、何事も起きないプロジェクトは皆無です。であれば、過去に苦労した情報は貴重で価値のある情報なのですが、あまり共有・活用されない傾向にあります。
それもそのはずで、振り返りはプロジェクト期間外（終了後）に行われることが多く、実践したとしても主要メンバーが別プロジェクトに参画してしまい、なかなか本質を突いた振り返りが出来ていないからです。
これを防ぐためにも、フェーズの切れ目で振り返りを行うことをオススメします。私の参画していたプロジェクトではありませんが、フェーズの切れ目で振り返りを行い、プロジェクトの終了後に総合的な振り返りを行うことで、本質を突いた意見や改善提案が多く挙がっていたように感じます。言いづらいことを言いやすくしてもらうために、匿名性で問題点・改善点を挙げてもらうといったプロジェクトもありました。とにかく後に続く貴重な情報を吸い上げられる仕組みを作ることが大切です。
振り返りの後は、整理した内容をノウハウとして一元管理する仕組みを作り、簡単に検索・閲覧出来る仕組みがあると良いですね。集めたナレッジを分析した結果、同じような問題にぶつかったプロジェクトが多ければ、プロジェクト参画者で集まって分科会を開き、改善策を深掘りするのも良いでしょう。
長々と書いてしまいましたが、今回はこの辺で。少しでも多くのプロジェクトが成功するよう、またメンバーが楽しくプロジェクトを進めることが出来るよう、自分自身も精進していけたらと思います。
0 コメント:
コメントを投稿