トップ ／ コラム ／ システム開発が失敗する理由

システム開発が失敗する5つの理由と、発注側ができる対策

「お金も時間もかけたのに、思っていたものと違うシステムができあがった」「途中で話がかみ合わなくなり、結局使われなかった」。システム開発の失敗は、決して珍しい話ではありません。このページでは、システム開発が失敗しやすい5つの理由と、社内にエンジニアがいない発注側でもできる対策を整理します。

そもそも「システム開発の失敗」とは

システム開発の失敗というと、「納期に間に合わなかった」「予算を大きく超えた」といった場面を思い浮かべるかもしれません。もちろんそれも失敗ですが、発注する側にとってもっと深刻なのは、次のようなケースです。

• 完成したものの、現場で使われない
• 作りたかったものと、できあがったものがずれている
• 修正や追加を重ねるうちに、いつまでも完成しない

こうした失敗の多くは、技術の問題というよりも、「何を作るか」を発注側と開発側で共有しきれていないことから起こります。つまり、発注側にも打てる手があるということです。

システム開発が失敗する5つの理由

現場でよく見られるのは、次の5つのパターンです。どれも特別なことではなく、進め方を少し変えるだけで避けやすくなります。

• 作りたいものが言葉になっていない

  「業務を楽にしたい」という思いのままでは、開発側は何を作ればよいか判断できません。

• 発注側と開発側で「言葉」が違う

  同じ単語を、お互いが違う意味で受け取ったまま話が進んでいきます。

• 最初から全部を作ろうとする

  機能を詰め込むほど、費用も期間も確認すべきことも増えていきます。

• 完成するまで実物を確認できない

  文章の仕様書だけでやりとりすると、画面を見るのは完成間近になります。

• 現場の業務が反映されていない

  実際に使う人の運用や例外処理が、要件から抜け落ちてしまいます。

理由1：作りたいものが言葉になっていない

「業務をもっと楽にしたい」「会員の管理をきちんとしたい」。発注の出発点は、たいていこうした思いです。しかし、この段階のままでは開発側は何を作ればよいか判断できません。開発を進めるには、「誰が」「どの画面で」「何をするのか」といった具体的な形に落とし込む必要があります。

この落とし込みの作業が、いわゆる要件定義です。従来のやり方では、要件定義の中身を発注側がまとめることを求められがちです。しかし、社内にエンジニアがいなければ、何をどこまで書けばよいのか分からないのが普通です。

理由2：発注側と開発側で「言葉」が違う

同じ「会員」という言葉でも、発注側は「会費を払っている人」を思い浮かべ、開発側は「データベースに登録されている人」と受け取る——こうした小さなずれが積み重なると、完成品は思っていたものから離れていきます。

開発側の専門用語で説明された資料に「はい」と答えたものの、実は内容をよく理解できていなかった、という話もよく聞かれます。

理由3：最初から全部を作ろうとする

せっかく作るなら、あれもこれも入れたい。そう考えるのは自然なことです。しかし、機能を詰め込むほど、費用も期間も膨らみ、確認すべきことも増えていきます。結果として、本当に必要な機能の完成が遅れてしまうことがあります。

理由4：完成するまで実物を確認できない

文章の仕様書だけでやりとりを進めると、画面を実際に見るのは完成間近になってから、ということが起こりがちです。その段階で「思っていたのと違う」と気づいても、大きく作り直すには費用も時間もかかります。

理由5：現場の業務が反映されていない

システムを使うのは、日々その業務を担当している現場の人です。ところが、打ち合わせに参加するのが決裁する立場の人だけだと、現場の細かな運用や例外的な処理が抜け落ちてしまいます。完成後に「この処理ができない」と分かり、結局は手作業が残る、ということにもなりかねません。

「要件定義ができない」ときの考え方

「要件定義ができない」と悩む発注担当者の方は少なくありません。しかし、発想を変えると、要件定義を発注側がゼロから書く必要はないとも言えます。

要件は、すでに手元の資料にある

多くの組織には、業務のルールや流れを表す資料がすでにあります。

これらを材料にして、ヒアリングで足りない部分を補えば、要件の大部分は組み立てられます。大切なのは、発注側が書類を作ることではなく、業務のことを話せることです。

「丸投げ」と「任せる」は違う

要件定義を依頼先に任せる場合でも、発注側が関わらなくてよいわけではありません。任せるのは「要件を文書にまとめる作業」であって、「何を実現したいか」を決めるのは発注側です。ヒアリングに時間を割き、途中の確認に参加することで、ずれは大きく減らせます。役割の線引きは、要件定義を発注側で抱え込まない進め方でも詳しく整理しています。

発注前に確認したいチェックリスト

依頼先を選ぶ前に、次の点を確認しておくと安心です。

• 業務の困りごとを、自分たちの言葉で説明できるか
• 「必ず必要な機能」と「あると便利な機能」を分けたか
• 既存システム・規程・調査データなど、渡せる資料を洗い出したか
• 現場の担当者がヒアリングに参加できるか
• 依頼先は、専門用語ではなく業務の言葉で説明してくれるか
• 完成前に、画面イメージや試作品を確認する機会があるか
• 発注側に求められる作業（資料作成など）の範囲が明確か

見積書の読み方そのものに不安がある場合は、システム開発の見積もりの読み方もあわせてご覧ください。

pegの進め方：話すだけで、作りたいものが形になる

pegは、発注側にエンジニアがいなくても、ヒアリングと既存の資料だけで要件を形にし、完成まで導くことを大切にしています。これまでに、次のような案件に取り組んできました。

• 日本眼科医会：約3億円規模の会員管理システムの置き換え（材料：既存システム＋ヒアリング）
• ドローン操縦士協会：技能証明の講習・実技時間管理システム（材料：ヒアリング＋事務規程）
• 官公庁：予防接種の保護者不安を軽減するLINE AIチャット（材料：調査データ＋ヒアリング）

いずれも、発注側で要件定義書を新たに作ることなく進めた事例です。「何から話せばいいか分からない」という段階でも、まずはご相談ください。古くなったシステムの置き換えを検討中の方は、老朽化した業務システムの置き換え費用を抑える進め方、社内にIT担当者を置きにくい企業の方は中小企業向けのご案内もご覧いただけます。ほかの事例は導入事例一覧にまとめています。

よくあるご質問