システム開発を発注するとき、多くの担当者は「要件定義」を、自分たちが要望を伝えて、システム会社がそれを形にする作業だとイメージしています。つまり、発注側が指示を出し、受注側がそれを受け取って進める、一方通行のやり取りです。

しかし、この認識のまま要件定義を進めると、高い確率でプロジェクトはうまくいきません。私たちEFGが要件定義で最も大切にしているのは、「二人三脚」であるという姿勢です。発注側から要望を受け取って終わりではなく、こちらから何度も質問し、時には発注側も気づいていなかった業務の実態を一緒に掘り起こしていく。そういう共同作業として要件定義を捉えています。

この記事では、EFGが実際にどのように要件定義を進めているのか、なぜそこまで徹底的に対話するのかを、正直にお伝えします。良いことばかりではありません。お客様側にも一定の負荷がかかる、という事実も含めてお話しします。

業務を「同じ解像度」で理解するまで話す

要件定義で私たちが目指しているのは、お客様の業務を、お客様自身と同じ解像度で理解することです。

「同じ解像度」というのが重要です。システム会社が業務の大枠を把握しただけで設計に進んでしまうと、細部のズレが後から必ず表面化します。逆に言えば、細部まで理解できていれば、お客様が明示的に言葉にしていない要望まで汲み取ったシステムを作ることができます。

この解像度に到達するために必要なのは、資料を一度読むことでも、ヒアリングシートに答えてもらうことでもありません。実際の業務の流れ、例外処理、現場の人が「当たり前すぎて説明しなかったこと」まで、繰り返し質問して掘り下げていくプロセスです。

これは、発注側の説明が足りないという話ではありません。むしろ逆で、日々その業務をこなしている担当者ほど、細かい例外処理やイレギュラー対応は「わざわざ言うまでもない当たり前のこと」になっています。当たり前すぎて、説明の必要性にすら気づいていない。だからこそ、私たちの側から一つひとつ具体的に問いかけて、言葉にしていただく必要があるのです。

実際の対話はこんな感じです

たとえば、ある企業から「在庫管理をシステム化したい」というご相談をいただいたとします。最初のヒアリングでは、こんなやり取りになることがよくあります。

この時点で、最初の「在庫数をリアルタイムで見えるようにしたい」という要望の裏に、「店舗間での在庫融通という、正式なルールになっていない業務フローが存在する」という事実が見えてきます。

さらに私たちは、ここで終わりにしません。

このように、最初の要望をきっかけに、業務の中に埋もれていた「非公式な運用」を一つずつ言語化していきます。もしここを掘り下げずに設計を進めていたら、完成したシステムは「エクセルより見やすいだけの、実態に合わないシステム」になり、結局は現場が独自にエクセル管理を続けてしまう、という結果になっていたはずです。

なぜここまで聞くのか

理由はシンプルです。曖昧なまま進めた要件は、必ず後工程で歪みとなって表面化するからです。

設計やプログラミングが始まってから「実はこういう例外がありまして」という話が出てくると、手戻りが発生します。手戻りは、単に時間とコストがかかるだけでなく、スケジュールの遅延、追加費用の発生、そして何より、お客様と開発チームの信頼関係を損なう原因になります。

たとえば、先ほどの在庫管理の例で言えば、もし「店舗間での在庫融通」という運用に気づかないまま開発を進めていたらどうなるでしょうか。テスト段階になって初めて、お客様から「あれ、店舗から借りた分はどう扱うんですか」と聞かれ、そこから慌てて仕様を追加することになります。すでに設計・実装が進んだ段階での仕様追加は、ゼロから作るよりもずっと手間がかかり、他の機能との整合性を取り直す作業まで発生します。私たちが過去に対応してきた炎上案件の多くも、突き詰めれば「最初の要件定義で聞き切れていなかったこと」が原因でした。

だからこそ、私たちは要件定義の段階で、時間をかけてでも「本当にこれで全部ですか」「こういうケースはどうなりますか」と、しつこいくらいに質問を重ねます。

正直に言います。お客様側にも負荷がかかります

ここまで読んでいただくと分かる通り、この進め方は発注側にとって決して楽ではありません。

何度もヒアリングの時間を取っていただく必要がありますし、「当たり前すぎて説明していなかった業務ルール」を言語化する作業は、思っている以上に骨が折れます。担当者お一人では答えられない質問が出てきて、社内の別の部署に確認していただくことも珍しくありません。

正直、「もっと手早くやってほしい」と感じられることもあると思います。ですが、ここで手を抜いてしまうと、その負荷は形を変えて、開発の後半かリリース後に、より大きくなって戻ってきます。私たちが二人三脚という言葉を使うのは、この負荷を発注側だけに押し付けず、私たちも一緒に業務を理解する努力をする、という意味です。一方的にヒアリングシートを埋めさせるやり方とは違う、というのが私たちのこだわりです。

それでもこのやり方を貫く理由

要件定義にかける時間は、一見遠回りに見えます。しかし、実際には最大のコスト削減になります。

設計・開発が始まってからの手戻りは、要件定義段階での確認作業よりもずっと高くつきます。時間だけでなく、追加の見積もり、スケジュールの再調整、社内での説明対応など、目に見えないコストが次々と発生します。要件定義の段階で1時間かけて確認しておけば済んだはずのことが、開発終盤で発覚すると、その何倍もの時間とコストをかけて修正することになる。これは決して大げさな話ではなく、私たちが数多くのプロジェクトで実際に見てきたことです。

要件定義に十分な時間と労力をかけることは、プロジェクト全体で見れば、最も費用対効果の高い投資なのです。私たちがここまで対話にこだわるのは、きれいごとではなく、これまでの経験から導き出した、地に足のついた結論です。

「二人三脚」という言葉には、もう一つ意味があります。それは、走るペースを合わせる、ということです。片方だけが速く走ろうとしても転んでしまいますし、片方だけに歩調を任せていても前に進みません。要件定義とは、発注側とシステム会社が、お互いのペースと理解度をすり合わせながら、同じゴールに向かって進んでいく作業です。私たちがこの姿勢を大切にしているのは、それが結果的に、お客様にとって一番遠回りに見えて、一番の近道になるからです。

よくある質問