E FACTORY GUYSがシステム開発のYESマンにならない4つの理由

システム開発の話を進めていると、当初の構想よりも機能が増えていくことがあります。

現場からは「この作業も楽にしたい」という意見が出る。別の部署からは「こちらのデータも連携したい」という要望が加わる。さらに、将来の事業展開を考えて、「今は使わなくても、いずれ必要になるかもしれない機能も入れておきたい」という話が出てくる。一つひとつを見れば、どれももっともな要望です。

しかし、それらをすべて盛り込めば、本当に良いシステムになるのでしょうか。私たちEFGは、必ずしもそうではないと考えています。システム開発会社の役割は、お客様から挙がった要望を、そのまますべて形にすることだけではありません。お客様が実現したい目的を理解し、そのために本当に必要なものを一緒に見極めることも、重要な仕事の一つです。

CHECK POINTS：この記事のポイント

要望が増えるほど、費用や期間だけでなく、操作や保守も複雑になる
EFGは「欲しい機能」の奥にある「解決したいこと」から確認する
機能を一方的に削るのではなく、理由と代替案を示して一緒に判断する
お客様の予算を、本当に必要な部分へ使うことを優先する

システムの構想は、自然に大きくなっていく

新しいシステムを作るとなれば、期待が膨らむのは当然です。

「せっかく作るなら、これもできるようにしたい」「後から追加するより、最初から入れておいたほうがいいのではないか」「他社のシステムにある機能だから、自社にも必要かもしれない」。こうした意見が出ること自体は、決して悪いことではありません。さまざまな立場の人から意見を集めることで、最初には見えていなかった課題が見つかることもあります。

一方で、要望が増えるたびに、開発費用と開発期間も増えていきます。機能同士の関係が複雑になれば、設計やテストに必要な時間も増えます。画面に多くの操作を詰め込めば、現場の人にとって使いにくいシステムになる可能性もあります。完成後には、追加した機能を保守していく費用も必要です。

⚠️ 注意

特に注意したいのが、「将来使うかもしれない」という理由だけで機能を増やすことです。実際に必要になる頃には、事業の状況や業務の流れが変わっているかもしれません。

今の段階で想像した将来に合わせて大きな機能を作っても、結局ほとんど使われないことがあります。大切なのは、要望を出さないことではありません。出てきた要望を一度すべて受け止めたうえで、今、本当に必要なものを整理することです。

「欲しい機能」と「解決したいこと」は分けて考える

お客様から「この機能が欲しい」と聞いたとき、EFGはそのまま見積もりに加えるのではなく、まず理由を確認します。

誰が使う機能なのか。どのような場面で使うのか。どれくらいの頻度で使うのか。その機能がないことで、現在どのような問題が起きているのか。こうしたことを一つずつ伺っていくと、お客様が求めているのは、その機能自体ではなく、機能によって得られる結果だと分かることがあります。

たとえば、複雑な管理機能を希望されていても、実際の目的が「確認漏れを防ぎたい」ということであれば、もっとシンプルな仕組みで解決できるかもしれません。新しい画面を追加しなくても、既存の画面に必要な情報を表示すれば足りる場合もあります。システムで自動化するより、現在の運用を少し変えたほうが、費用を抑えながら柔軟に対応できることもあります。

また、必要性はあるものの、最初の開発ですぐに作る必要はない機能もあります。まずは事業の中心となる機能だけで運用を始め、実際の利用状況を見てから追加する。そのほうが、本当に必要な形を見極めやすく、最初から大きく作るよりも無駄を減らせます。

「心で見なければ、ものごとはよく見えない。大切なものは、目には見えない。」 — アントワーヌ・ド・サン＝テグジュペリ『星の王子さま』

これはシステム開発について語られた言葉ではありません。しかし、良いシステムを考えるときにも通じます。目に見えるのは「欲しい機能」ですが、その奥には「解決したいこと」があります。検討すべきなのは「その機能を作れるか」だけではなく、「その機能を作ることが、お客様の目的に対して最も良い方法なのか」ということです。

比較項目	要望をそのまま機能にする場合	目的から考え直す場合
確認すること	どのような機能を作るか	何を解決したいのか
選択肢	希望された機能を実装する	実装、簡素化、運用変更、後から追加などを比較する
予算の使い方	要望の数に応じて費用が増える	必要性の高い部分へ優先的に配分する
目指す結果	要望どおりの機能がそろう	実際の業務に合うシステムになる

EFGは、一方的に機能を削ることはありません

もちろん、開発会社の判断だけで「これは不要です」と機能を削るわけではありません。お客様から出てきた要望には、それぞれ理由があります。その背景を理解しないまま否定してしまえば、本当に必要なものまで見落としてしまいます。

だからこそ弊社では、要望を受け止めてから、次の流れでお客様と一緒に整理します。

STEP.1 要望の背景まで聞く
欲しい機能だけでなく、誰が、いつ、何のために使うのかを確認します。
STEP.2 費用と効果を整理する
開発費用や期間、利用頻度、完成後の保守まで含めて、その機能を作る意味を考えます。
STEP.3 代替案を示す
より簡単な機能、運用による対応、後からの追加など、同じ目的を実現できる選択肢を提示します。
STEP.4 納得したうえで決める
判断の理由を説明し、お客様自身が比較・納得したうえで、開発する範囲を決めます。

「この機能を作ると、これだけの費用と期間が必要になります」「目的がこちらであれば、もっとシンプルな方法でも実現できます」「今すぐ作るのではなく、実際の運用を確認してから追加する方法もあります」。このように、判断の理由と選択肢を示しながら話し合います。

重要なのは、開発会社が勝手に決めることではなく、お客様自身が比較し、納得したうえで決められることです。最終的に、費用がかかっても必要だと判断する機能もあります。反対に、目的をあらためて確認した結果、「そこまで作らなくても十分だった」と分かる機能もあります。

当初の上限予算から約40％抑えて開発を始めたケース

あるお客様から、新しいシステムを開発したいというご相談をいただいたことがあります。社内ではすでにさまざまな構想があり、特に上長の方からは、将来の展開も見据えた多くの機能案が挙がっていました。

構想としては魅力的でしたが、すべてを最初から実装すると、現在の業務や利用規模に対してシステムが大きくなりすぎる可能性がありました。費用も相応に膨らみます。

そこでEFGは、最初から案を否定するのではなく、要件定義の中で一つずつ目的を確認していきました。その機能は、誰がどのような場面で使うのか。現在、どの程度の課題があるのか。別の方法で同じ目的を達成できないか。最初から必要なのか、それとも運用を始めてから追加してもよいのか。

確認した内容をもとに、よりシンプルな方法で実現できるものについては代替案を提示しました。お客様にも一つずつ判断の理由を説明し、「それなら、この形で十分だ」「この機能は今すぐ必要ではない」と納得していただきながら、開発する範囲を整えていきました。

📘 結果

最終的には、当初想定されていた上限予算より約40％抑えた規模で開発をスタートしました。単に予算に合わせて機能を削ったのではなく、実現したい目的を残しながら、その時点のお客様に必要な形へ整えた結果です。

※守秘義務のため、案件を特定できないよう一部の情報を一般化しています。

機能が多ければ、開発会社の売上は増える

率直に言えば、作る機能が増えれば、開発会社の売上も増えます。お客様から出された要望をすべて受け入れ、そのまま見積もりを作るほうが、話は早いかもしれません。

しかし、使われない機能や、もっと簡単な方法で解決できる機能まで作ることが、お客様にとって良い提案だとは考えていません。

開発時の費用だけではありません。システムは完成後も、保守や改修を続けていくものです。機能が増えれば、それだけ管理する範囲も広がります。最初に必要以上に大きなシステムを作ると、その負担は完成後も残り続けます。

だからEFGは、「作れます」という回答だけで終わらせず、「本当にこの形で作るのがよいでしょうか」と考えます。お客様の予算を、使われない可能性のある機能に割くのではなく、本当に必要な部分へ使う。あるいは、将来必要になったときのために残しておく。そのほうが、お客様の事業にとって意味のある選択になることがあります。

📌 EFGが大切にしていること

自社の売上を増やすために、無駄なものを作る提案はしない。限られた予算を、お客様にとって本当に必要な部分へ使うことを優先します。