ITプロジェクトはなぜ失敗するのか|失敗の多くは、作る前のプランニングで決まる

社内でITプロジェクトを進めているものの、なかなかうまくいかないと感じている方に向けた記事です。結論から言うと、ITプロジェクトの失敗の多くは、エンジニアの腕ではなく、作り始める前に「何を作るか」を整理しきれていないことが原因です。この記事では、発注する側がつまずく点と、IT企画の力を上げる方法を説明します。

ITプロジェクトは、なぜ失敗するのか

私の経験では、失敗の主な原因は、発注する側の準備不足でした。私はこれまで、次の3つの立場でITプロジェクトに関わってきました。

• 受託開発を請けた開発会社として
• プロジェクトの支援を請けたコンサルタント・PMOとして
• 事業会社でプロジェクトを運営する側として

この3つの立場のどれでも、エンジニアがプロジェクトの失敗を引き起こしたケースはありませんでした。システムに求めることを整理しきれていない、どう整理すればプロジェクトを前に進められるか分からない。そういう状態に陥った発注側の準備不足が、主な原因でした。

JUASの調査でも、予定どおりの工期・予算で終わったプロジェクトの割合と、品質に満足したプロジェクトの割合は、この10年で下がる傾向にあります。

発注する側は、何につまずくのか

一番多いのは、プログラムを作ってもらうときの「頼み方」が分からないことです。事業会社の立場になってみて、改めて衝撃を受けた点でした。

ITが本業でない会社には、エンジニアがいないのが当たり前です。プログラムを作るよう頼まれた経験もないので、頼み方が分からないのは自然なことです。その結果、「こういうものが欲しい」という要求のまま発注され、作り始めてから「思っていたものと違う」が起きます。

要求と要件の違いについては、「RFPを出しても見積もりがばらつくのはなぜか」で詳しく説明しています。

IT企画の力は、どうすれば上がるのか

エンジニアが適切な情報を出しながら、ビジネス側と議論を重ねると上がっていきます。

「これはできる」「これは難しいが、こうすればできる」という情報をエンジニアから受け取ると、ビジネス側に判断の基準ができていきます。最初は頼み方が分からなかった人も、議論を重ねるうちにシステムの作りのイメージが湧き、「こんなことはできないの?」というアイデアを出せるようになります。

その過程で大事なのは、専門用語を使わずに、システムの中を流れるデータをどうしたいのかを詰めていくことです。画面の見た目より先に、どんな情報を、誰が、いつ、どう使うのかを決めると、議論がかみ合います。

実際の現場では

事業会社でプロジェクトを運営していたとき、まさにこの議論を重ねました。

• 「その伝え方では、何がしたいのか分からない」
• 「欲しいと言っているけれど、言うほど使わないのでは」
• 「そこを変えるには、こちらも変える必要がある。こういう形ではだめか」

こうしたやり取りを続けるうちに、社内のIT企画の力が上がり、ビジネス側から具体的なアイデアが出てくるようになりました。この経験から、IT企画の力は、エンジニアが適切な情報を出せば上がっていくものだと考えるようになりました。

今の当社の進め方も、この経験の延長にあります。PMを含むチームで要件定義から参画し、業務の流れと作業を調べ、必要な機能を洗い出し、画面の試作品を現場の方に操作してもらって確かめてから要件を固めます。詳しくは、開発支援(PM・PMO)と、要求の整理から要件定義までの進め方(AI開発)のページで紹介しています。

プロダクトマネージャーの役割を、どう考えるか

プロダクト開発の参考書として知られる『Inspired: 顧客の心を捉える製品の創り方』に、次の一節があります。

覚えておいてほしい。価値のある、使いやすい、実現可能な製品として作られるべき何かをプロダクトマネージャーから与えられなければ、どんなにエンジニアリング部門が優秀でも意味はない、ということに。

何を作るべきかを決める人がいなければ、どんなに優秀なエンジニアがいても、成果にはつながりません。社内にその役割を担う人がいないなら、外部のPMと一緒に進めるのが現実的です。

まとめ

• ITプロジェクトの失敗の多くは、作り始める前に何を作るかを整理しきれていないことが原因
• 発注する側が一番つまずくのは、「頼み方」が分からないこと
• IT企画の力は、エンジニアが適切な情報を出しながら議論を重ねると上がっていく

社内にPMがいない状態で外注を進める方法は、「社内にPMがいない会社のシステム開発外注ガイド」にまとめています。