今回は、システム開発プロジェクトの失敗の原因について探ります。
最大の失敗は、「要件定義」の失敗といわれていますが、なぜ要件定義が失敗になるのか？
実際にプロジェクトマネージャをやっていると、要件定義の失敗よりは、開発そのものをコントロールすることに失敗することの方が多いという感覚があります。
その違いはどこにあるのか、なぜ要件定義が失敗といわれ続けるのか、その謎に迫ります。
システム開発プロジェクトの失敗の過半数は要件検討、その本当の意味とは
プロジェクト失敗の原因の過半数は要件検討
システム開発のプロジェクトが失敗するのは、要件検討がうまくいかないケースが多いというのは、３０年前から同じように言われ続けています。
プロジェクトが掲げる目標-つまり、システムが立ち上がって思い通りの効果が得られなかったときがプロジェクトの失敗になります。
プロジェクトのオーナーからしたら、「プロジェクトが目的からずれて目標がまるで達成できなかったとき」が最大の失敗なのです。
そのため、効果がないのは、「要件定義が失敗」、ということに焦点があてられるわけです。
ということは、そこを成功させるためには、プロジェクトの企画や、経営課題をどう解決していくかという領域にもなってきて、そこはシステムアナリストやビジネスアナリストの領域になってきます。
プロジェクトの失敗の過半数が要件検討だから、要件検討のやり方を学べばプロマネ力があがる、というのは実は短絡的で本質はそこにはないのです。
ユースケース図の書き方を学んでも、要件検討を確実に進められるわけではないのです。
要件定義の本質
要件定義とは、お客様のプロジェクトで実現したいシステムを定義すること。
プロジェクトが本当に目指しているもの＝プロジェクトのオーナーが本当に達成したいと願っていること
それを実現させるために必要なスキルは、要件検討で何をやればいいか、要件検討して定義するタスクの内容ではなくて、問題の本質をどうとらえて、プロジェクトの目標をどのように描くかというスキルになってきます。
お客様が狙っている問題課題をとらえ、方向性を見極め、開発するシステムをその方向に導くことが大切になります。
目的にずれがなく、最終的な目標を引き出し、その目標に対して今回のシステムで達成可能な目標を設定すること、そこが重要なポイントになります。
システム開発を発注する側の作業になるかもしれませんが、要件検討では、その前の企画・構想を今回開発するシステムで本当に達成できるのかを常に考えながら、お客様の要望にあったシステム化が重要になってきます。
その部分を抜きにして、技術的な要件検討の成果物-業務フロー、データフロー、ユースケース図-の書き方や、要件検討タスク一覧をみても、プロジェクトの失敗はなくなりません。
お客様に画面イメージを出してもらって、どのボタンを押したら何をするかということを定義するのも、確かに要件検討の中では実施するかもしれません。
システムをレスポンスよく稼働させるために、不要なデータを消しましょうと決めて、削除用のバッチを提案・開発する方向にもっていくのも、確かに要件検討の中では実施します。
しかし、そうやってスケジュール通りに、リリースしたシステムの中には、ほぼ障害もなく立ち上がったプロジェクトだったとしても実は失敗プロジェクトとなるものが存在するのです。
表面的な要件検討をやった結果まねいたこと
自分がまだ駆け出しのプロマネだった時のことです。
自分がマネジメントした最初のプロジェクトでは四苦八苦したので、そこから学んだことを活かしながら確実なマネジメントでプロジェクトを成功させようと気負ってました。
スケジュールを立案して、それを守るために管理・コントロールを厳しくしたのです。
要件検討は、画面を決めて動作を決めてというのをどんどん進めました。
「決めてくれないと計画に遅れがでます」とお客様に迫り、時間が少ない中で無理に決めてもらいました。
画面の設計も開発も、順調に進みます。
前もって課題もつぶしながら、プロジェクトも順調に進み、リスクをみて２週間ほど前倒しで進みました。
最後の方は余裕もでてきて、当時としては珍しく、プロジェクトメンバー全員がほぼ残業なし、年休消化もできた記憶があります。
システムをリリースした後の品質面でも問題なく、大きな障害もなく、プロジェクトは大成功に思えました。
「こんなことはできないのですか？」
「できません、要件書に書いてありませんので」
「それができないと、このシステムの意味がないのですが・・・」
「そこまで対応すると、根本的な大改修になるので、今回の開発費用と同じくらいの費用がかかってしまいます」
「そうですか・・・」
そのシステム、リリース後もほぼ使われず、半年で消えることになりました。
プロジェクト単体としては、納期・品質・コスト面で全く問題なく、大成功のプロジェクトだったかもしれませんが、お客様としては失敗プロジェクトでしかありません。
そこで開発したシステムがその後使われなかったこともあり、次の開発は別会社への発注となり、システム開発会社としてもマイナスになっています。
まだ、２０代だった頃の苦い思い出です。
プロジェクトマネージャとして実施すること
プロジェクトが失敗する大きな原因のひとつが、要件定義の失敗にあります。
要件定義で大切なことは、そのシステム要件でお客様が狙った効果を得られるようになっているか、にあります。
狙った効果を得られるようにするために、プロジェクトマネージャとしては何をすればいいか？
「開発するシステムの狙いをメンバー全員で何度も共有・理解することです」
常にその原点に立ち返り、要件定義ではその要件が本当に、狙った方向に向かっているのかを意識して、違った方向のものは実現しないようにすることが大切です。
要件が決まった後の外部仕様・外部設計を決めていく中でも同じで、常にシステムの目的に立ち返り、方向がずれていないかを意識すること、プロジェクトマネージャーとして情報の展開、共有、意識付けをしっかりやること。
それをすることで、できあがったシステムがすぐに使われなくなるというリスクは格段に減ります。
プロジェクトをマネジメントしてしっかり進められるようになったとしても、そもそも作っているものが目的からずれていたら、そのプロジェクトは失敗になります。
プロジェクトマネージャーとしては、常にお客様視点を忘れずに、システム開発に携わりたいものです。
今回の話はここまで。
最後までお読みいただき、ありがとうございました。
