要件定義の落とし穴

「詳細に気がつく」ことは、本当に良いことか

ヒアリングの場で、こんな経験をしたことはないでしょうか。顧客が「業務をもっと楽にしたい」と話しているそばから、頭の中では「じゃあ、こういう画面を作って、こんなボタンを配置して」と、具体的な機能のイメージや、テーブルレイアウトを、考え始める。

これは、SEであれば誰にでも起こることです。正直に言うと、私自身、若い頃にこれを問題として意識したことはありませんでした。むしろ当時は、細部にすぐ気づき、具体的な画面や帳票のイメージをすぐに描けることが、優れたSEの証だと思っていました。

実際、多くのSEには、抽象的なまま考え続けることが苦手で、つい具体化したがる傾向があります。これは、ある意味で当然のことでもあります。最終的に画面や帳票に落とし込む段階では、細部への気づきが欠かせません。詳細に気がつけるということ自体は、SEにとって重要な能力です。

しかし、その能力を発揮するタイミングが、要件定義の早すぎる段階に来てしまうと、話が変わってきます。顧客の話を聞きながら、すでに頭の中では画面のレイアウトを考え始めている。悪気があるわけではありません。むしろ、真面目に「どう実現するか」を考えているからこそ、起きることです。しかし、この「機能への焦り」が、要件定義の質を大きく損なうことがあります。

今回は、SEが機能に焦ることで、何を見失ってしまうのかを整理します。

なぜ、機能を考えたくなるのか

まず、なぜSEは、機能のことを考えたくなってしまうのでしょうか。これは、決して怠慢や浅慮からくるものではありません。先ほど触れたとおり、細部への気づきは、SEにとって本来、価値のある能力です。

SEという職業は、最終的に「動くシステムを作る」ことがゴールです。顧客の話を聞いている間も、頭のどこかで「これをシステムでどう実現するか」を考えるのは、職業的な習性と言ってもよいものです。第2回でお伝えしたとおり、SEには要求を要件に翻訳する役割が求められます。翻訳しようとする意識が強いほど、具体的な実装のイメージに、思考が飛躍しやすくなるのです。

また、機能を考えることは、抽象的な要求を扱うことに比べて、心理的に楽だという側面もあります。「業務を楽にしたい」という漠然とした要求を、そのまま扱い続けるのは、落ち着かないものです。「ログイン画面を作って、一覧画面を作って」という具体的な機能に落とし込んだ瞬間、頭の中が整理されたような感覚になります。この「分かった気になる」感覚が、機能への焦りを加速させます。

焦って機能を考えたくなるのは、当然のことです。しかし、そこに注力してしまうと、大きな問題が生じます。

全体感が、失われる

機能に焦ることで、最も大きく失われるのが「全体感」です。

第2回でお伝えしたとおり、要件定義には要望・要求・要件という3つの段階があります。「業務を楽にしたい」という要望が、「月次レポートを自動化したい」という要求になり、それが「毎月末日23時に、売上データを集計してPDF出力する」という要件になっていく。

このプロセスを丁寧に踏むことで、要求全体を俯瞰した上で、最適な実現方法を選べます。しかし、機能に焦ってしまうと、このプロセスを飛び越えて、いきなり「要件」、それも特定の機能というレベルの話に飛んでしまいます。

たとえば、「月次レポートを自動化したい」という要求を聞いた瞬間に、「では、PDFを自動生成する機能を作りましょう」と考え始めたとします。しかし、この要求の背景には、複数の要因が存在するかもしれません。「そもそも月次でなくてもいいのか」「PDFである必要があるのか」「自動生成ではなく、手動でも確認できる仕組みのほうが安心なのではないか」——こうした、より広い選択肢を検討する余地が、機能に焦った瞬間に失われてしまいます。

機能というのは、要求を満たすための、数ある解決策のひとつにすぎません。しかし、SEが早い段階で特定の機能をイメージしてしまうと、その機能が「唯一の正解」であるかのように、思考が固定されてしまいます。これが、全体感を見失うということです。

個別最適に、陥ってしまう

全体感を見失った結果、何が起きるでしょうか。個別最適への傾倒です。

ヒアリングの中で、複数の要求が次々と出てくることがあります。それぞれの要求に対して、SEがその都度、機能レベルで考えてしまうと、要求ごとにバラバラの機能が積み上がっていきます。

たとえば、「月次レポートを自動化したい」という要求には、レポート自動生成機能を。「承認フローを整理したい」という要求には、承認機能を。「外出先からもデータを確認したい」という要求には、モバイル対応の閲覧機能を——というように、要求ごとに機能を割り当てていく発想です。

一見、丁寧に対応しているように見えます。しかし、これらの機能を後から俯瞰してみると、それぞれが独立して作られており、機能同士の連携が考慮されていない、ということが起こりがちです。承認フローの機能と、レポート機能が、実は密接に関わっているにもかかわらず、別々の要求として、別々の機能として処理されてしまっていた、というケースです。

第6回でお伝えした「一貫性」という品質特性を思い出してください。個々の要件は正しく見えても、全体として整合性が取れているかどうかは、別の問いです。機能に焦ってひとつひとつの要求に対処していくと、この一貫性が損なわれやすくなります。

システム全体として見たときに、機能の重複や、機能間の矛盾、あるいは「本来ひとつの機能で済むはずが、3つの別々の機能に分かれてしまった」という非効率が生まれるのは、多くの場合、この個別最適の積み重ねが原因です。

顧客が「機能」で話してきたときも、同じ危険がある

ここまでは、SE自身が機能に焦るケースについてお伝えしてきました。しかし、もうひとつ注意すべきパターンがあります。顧客側から、機能レベルの話が出てくるケースです。

顧客は、要求のヒアリングで、要求だけを整理して話してくれるとは限りません。現状の業務を説明しながら、「今のシステムは、ここが使いにくくて」と既存システムへの不満をこぼしたり、「こういう機能があれば」と、話の流れの中で自然に機能について言及してきたりすることがあります。これは、顧客が意図的に要望をまとめて伝えているわけではなく、会話の中で自然に出てくるものです。

「この画面に、検索ボタンを追加してほしい」「一覧に、CSV出力の機能をつけてほしい」——顧客が、すでに機能という形で要望を伝えてくることは、決して珍しくありません。顧客も、日々システムを使う立場として、「こういう機能があれば便利だろう」というイメージを、自然に持っています。

このとき、SEがその機能要望を、そのまま鵜呑みにして実装してしまうと、SE自身が焦って機能を考えてしまうのと、まったく同じ問題が起こります。

「検索ボタンを追加してほしい」という要望の背景には、「必要な情報を、素早く見つけたい」という要求があるはずです。もしかすると、検索機能よりも、そもそもの一覧の並び順を工夫したり、よく使う項目を上部に固定表示したりするほうが、根本的な解決になるかもしれません。しかし、顧客から出てきた「検索ボタン」という機能の言葉を、そのまま受け取ってしまうと、こうした代替案を検討する機会が失われます。

第2回でお伝えしたとおり、SEの役割は、顧客の言葉を鵜呑みにすることではなく、その裏にある要求を掘り起こすことです。これは、顧客が要望・要求のレベルで話しているときだけでなく、顧客がすでに機能レベルで話しているときにも、同じように当てはまります。むしろ、顧客が具体的な機能を口にしているときのほうが、「もう答えが出ている」という錯覚が生まれやすく、その裏にある要求を掘り起こす作業が、省略されやすいという危険があります。

焦らないためには、どうすればいいか

では、機能への焦りを抑えるためには、どうすればよいでしょうか。

ひとつは、機能のアイデアが浮かんだら、いったんメモに留めておく、という方法です。

頭に浮かんだ機能のイメージを、その場で否定する必要はありません。しかし、それをすぐに「これが答えだ」と確定させるのではなく、「こういう案もある」というメモとして、いったん脇に置いておきます。ヒアリングが一通り終わり、要求全体が見えてきた段階で、改めてそのメモを見返し、本当にその機能が最適な解決策かどうかを検討します。

もうひとつは、「なぜ」を問い直す習慣を持つことです。

第9回でお伝えした質問力の話を思い出してください。「なぜ、その機能が欲しいのですか」という問いは、SE自身の中でも、常に自問自答すべきものです。顧客が「検索ボタンが欲しい」と言ったとき、あるいは自分自身が「この機能を作ろう」と思いついたとき、「なぜ、それが必要なのか」を一度立ち止まって考える習慣が、機能への焦りを抑えるブレーキになります。

さらに、複数の要求が出そろうまで、機能の話を保留するという判断も有効です。

ひとつの要求が出てきた時点で、すぐに機能を決めてしまうのではなく、ヒアリングを重ねて、他の要求との関係性が見えてから、機能を検討する。これにより、個別最適ではなく、全体を俯瞰した機能設計がしやすくなります。

焦らないことは、遅らせることではない

ここで、誤解しないでいただきたいことがあります。「焦らない」ということは、「機能を考えるのを、いつまでも先延ばしにする」という意味ではありません。

最終的には、要件を機能というレベルまで具体化する必要があります。要件定義のゴールは、動くシステムを作ることであり、いつまでも抽象的な要求のレベルに留まっていては、プロジェクトは前に進みません。

重要なのは、順序です。要求を十分に理解し、全体像が見えた上で機能を検討するのと、要求を聞いた瞬間に機能を決めてしまうのとでは、同じ「機能を考える」という行為でも、その結果はまったく異なります。

焦らないというのは、立ち止まって考える時間を、意図的に確保するということです。頭に浮かんだ機能のアイデアを、いったん脇に置いて、「本当にこれでいいのか」を確認する、その一呼吸の余裕こそが、全体感を見失わないための鍵になります。

まとめ

SEが機能に焦ってしまうのは、職業的な習性であり、自然なことです。詳細に気がつける能力そのものは、SEにとって価値のあるものです。しかし、そこに注力するタイミングを誤ると、要求全体を俯瞰する視点が失われ、個別最適に陥りやすくなります。

これは、SE自身が先回りして機能を考えてしまうケースだけでなく、顧客がすでに機能レベルで要望を伝えてきたケースにも当てはまります。「検索ボタンが欲しい」という言葉をそのまま受け取るのではなく、その裏にある要求を掘り起こす作業を省略しないことが重要です。

機能のアイデアが浮かんだらいったんメモに留める、「なぜ」を問い直す習慣を持つ、複数の要求が出そろうまで機能の検討を保留する——こうした工夫が、焦りを抑えるための具体的な手段になります。焦らないことは、機能を考えないことではなく、考えるタイミングと順序を意識することです。