「完璧な要件定義」は幻想？システム開発がうまくいく会社の共通点とは

ファンブリューの金井です。

これまで数多くのシステム開発プロジェクトに関わる中で、痛感してきたことがあります。
それは――完璧な要件定義など存在しないという事実です。

「しっかり要件を固めてから発注しないと失敗する」
「見積もりをもらうには、細かく仕様を詰める必要がある」

こうした“常識”が、実は多くのシステム開発を苦しめています。
なぜなら、本当に必要なシステムは、実際に作って・動かしてみて、初めて見えてくるものだからです。

なぜ「最初に決めた要件」が使われなくなるのか

私たちにご相談いただくお客様の多くが、システム開発自体が初めてというわけではありません。
すでに何かしらのツールを使っていたり、過去に開発経験があったりする方も少なくありません。

それでも、共通して起こるのがこんな現象です。

• 「当初の要件に入っていた機能の半分が、実際は使われていない」
• 「作ってみたら、業務フローの前提がそもそも違っていた」
• 「現場の声を取り入れたら、やりたいことが変わってしまった」

これは決して、準備不足や計画の甘さのせいではありません。

むしろ、お客様の多くはご自身の業務について、言語化されていない“暗黙知”が多すぎるのです。
そのため、どれだけ丁寧にヒアリングしても、「いざ使ってみると違った」ということが普通に起こります。

要件定義は“計画”ではなく“仮説”と捉えるべき

私たちファンブリューでは、要件定義を「開発前に完璧に決め切るフェーズ」とは考えていません。
むしろ、「現時点で立てられる“業務理解にもとづく仮説”」として設計し、そこからブラッシュアップしていくプロセスそのものを開発と捉えています。

この考え方を取り入れている企業様は、例外なく開発後の満足度が高く、長くシステムを活用してくださっています。

ケーススタディ：業務理解を深めながら育てた“現場主導型”のシステム

ある建設関連企業様の例をご紹介します。

「現場の工程管理が紙と電話に依存していて、進捗確認が大変」
ということで、Webベースの工程管理システムを構築したいとご相談いただきました。

最初のご要望では、日次スケジュールの入力、現場ごとの進捗状況の一覧、通知機能など、盛りだくさんの機能が並んでいました。

しかし、実際に現場のリーダー層や事務方の方と何度も打ち合わせを重ねてみると――
本当に困っていたのは、「現場から事務所への作業終了報告が遅れること」だと判明しました。

そこで、私たちはいったん要件を絞り、「スマホで作業終了を1タップで報告できる仕組み」を優先的に構築。
他の機能は後回しにして、まずは“現場で動かせる”ミニマムなシステムとしてリリースしました。

結果として、

• 報告遅延は9割減
• 事務所からの確認電話もほぼ不要に
• その他の機能も「必要に応じて追加」で対応し、開発コストを段階的に最適化

「最初に全部作らず、実際の業務にあわせて“育てて”いったことで、現場もストレスなく使えた」と、今でも継続して運用いただいています。

---

業務は止まらない。だからこそ、“変わる前提”の開発を企業活動は常に変化しています。

• 人が入れ替わり
• 商材が変わり
• お客様のニーズも変わる

当然、システムに求められる役割も日々変化していきます。

にもかかわらず、「一度決めた要件のままで5年使う前提」で開発する――
これはどう考えても、現実に即していません。

だから私たちは、こうした変化を前提にした“進化型の開発モデル”を提案しています。

「予算が決まっているから変更できない」は本当？

ここでよく聞かれるのが、「でも、社内予算はもう決まってるんですよね…」という声です。

確かに、日本企業の多くでは「前年度中に仕様と見積を確定し、固定された開発予算を確保する」文化が根強く残っています。

しかし――

「決まっている予算内で、どう優先度を設計し、どう段階的にリリースするか」

この視点があれば、柔軟性はぐっと高まります。

私たちは、「どうすればこの予算で一番効果が出るか？」を常に考えながら、要件の“段階的リリース”や“後方優先順位設計”をご提案しています。

予算に合わせて最大限の成果を出す。
この“現実と戦略のバランス”こそが、私たちの真骨頂です。

成功する開発には「会話」が必要不可欠

どんなに素晴らしい社内資料やRFP（提案依頼書）があっても、
私たちが本当に知りたいのは「その業務の裏にある、肌感覚」です。

• どこがめんどくさいのか
• 誰がいつ詰まるのか
• 何にストレスを感じているのか

こうした感覚は、実際に話して、掘って、想像して、再確認して、ようやく見えてくるものです。

ファンブリューでは、要件を押し付けるのではなく、お客様と一緒に考え、一緒に組み立てていくスタイルを大切にしています。

まとめ：「まずは、作りながら考える」が一番うまくいく

• 完璧な要件定義にこだわるより、「仮説として始める」ほうが、成功に近づける
• 実際に動かすことで、初めて“使えるかどうか”がわかる
• 変化する業務には、変化できるシステムが必要
• 予算が決まっていても、優先順位設計で“効果重視”の開発は可能
• 会話と想像力が、システム成功の最大の武器になる