要件定義で つまずかないための 「対話の設計」。

システム開発でトラブルが起きたとき、その原因をたどっていくと、ほとんどが同じ一点に行き着きます。「最初に握ったはずの内容が、お互いの頭の中で違っていた」。プログラムのバグでも、技術力の不足でもありません。要件定義という、いちばん最初の“対話”が噛み合っていなかった——これが、納品物が想像と違ってしまう最大の理由です。

厄介なのは、このすれ違いが当事者には見えないことです。発注側は「ちゃんと伝えた」と思い、開発側は「ちゃんと聞いた」と思っている。両者とも誠実なのに、できあがったものは食い違う。本記事では、なぜ要件はすれ違うのか、その溝をどう設計された対話で埋めていくのかを、私たちの現場経験を交えて具体的にお伝えします。

仕様の食い違いは「対話のすれ違い」から

要件のすれ違いには、立場ごとに典型的な“思い込み”があります。発注側に多いのは「言わなくても分かるはず」。毎日その業務をしているからこそ、当たり前すぎる前提や例外処理は、わざわざ口に出すまでもないと感じてしまう。一方の開発側に多いのは「聞かなくても作れるはず」。これまでの経験から、似た案件のパターンに当てはめて“きっとこうだろう”と先回りしてしまう。

どちらも仕事ができる人ほど陥りやすい、というのがこの問題の難しさです。経験が前提を省略させ、自信が確認を飛ばさせる。結果として、現場の例外や繁忙期の特殊な運用といった“言葉にされなかった要件”がそっくり抜け落ち、検収の段階になって初めて「これでは使えない」と判明します。すでに作り込んだ後では、手戻りのコストは何倍にも膨らんでいます。

なぜ「聞いたつもり」で進んでしまうのか

要件定義の打ち合わせは、たいてい和やかに進みます。発注側が業務を説明し、開発側がうなずく。お互いに気持ちよく合意できたように感じます。ところが、この“スムーズさ”こそが落とし穴です。同じ言葉を使っていても、その言葉が指す中身は人によって違うからです。よくあるすれ違いには、次のようなものがあります。

• 「承認」と言っても、誰が・どの順番で・差し戻しはどうするかが食い違う
• 「在庫」「顧客」など同じ言葉が、部署ごとに別の意味で使われている
• 「だいたいで」「いい感じに」が、具体像を共有しないまま流れていく
• 正常系ばかり語られ、エラー時や例外時の振る舞いが決まっていない

これらは、言葉の表面では合意できているように見えるため、その場では問題として浮かび上がりません。だからこそ、対話を“なんとなく”ではなく意図的に設計する必要があります。確認すべきことを確認しきる仕組みを、最初から打ち合わせの中に組み込んでおくのです。

— Note

「要件定義とは、仕様を“聞き出す”作業ではありません。
お互いの頭の中の像を、同じ一枚の絵にそろえる作業です。」

溝を埋める「対話の設計」3原則

すれ違いを防ぐ対話は、話し手のセンスや相性に頼るものではありません。あらかじめ設計しておける“型”があります。私たちが要件定義の現場で大切にしている原則は、大きく3つです。

PRINCIPLE 01
「なぜ」から聞き、「何を」で終わらせない

発注側が口にする要望は、多くの場合“解決策”の形をしています。「ボタンを増やしてほしい」「この画面を分けたい」。ですが、その裏には必ず「本当はこうしたい」という目的があります。私たちはまず「それは、どんな困りごとを解決するためですか」と背景を尋ねます。目的にさかのぼると、提案された解決策より良い手段が見つかることも珍しくありません。手段の合意より先に、目的の合意を取ることが対話の土台になります。

PRINCIPLE 02
言葉を、その場で“見える形”に変換する

言葉だけの合意は、解釈の余地を残します。そこで、聞いた内容をその場で画面のラフや業務の流れ図に描き起こし、相手に見せて確かめます。「つまり、こういうことですか」と図で問い返すと、発注側は「いや、ここは違う」と具体的に指摘できます。頭の中のイメージは、目に見える形になって初めて差分が分かる。可視化は、すれ違いを“その場で”発見するための最も確実な手段です。

PRINCIPLE 03
「言いにくいこと」を引き出す問いを置く

本当に重要な要件は、たいてい例外やイレギュラーの中に隠れています。「月末だけ違う処理をしている」「特定の取引先だけ別扱い」——こうした話は、聞かれなければ出てきません。そこで私たちは「うまくいかないときは、どうしていますか」「例外的に扱う相手はいますか」と、あえて裏側を尋ねる問いを用意します。正常系より異常系を先に握ることが、後の大きな手戻りを防ぎます。

「合意したこと」を、形にして残す

対話で像をそろえても、それを記録に残さなければ、時間とともにまた解釈はずれていきます。大切なのは、決まったことを誰が見ても同じに読める形で残すこと。私たちは打ち合わせのたびに、次の3点を必ず文書化して共有します。

• 決まったこと（合意した仕様と、その目的・背景）
• 決まっていないこと（次回までに確認・判断する宿題と担当）
• あえて今回はやらないこと（スコープ外として線を引いた範囲）

とりわけ三つ目の「やらないこと」を明文化しておくのが効きます。何を作るかと同じくらい、何を作らないかを握っておくことで、開発の途中で要望がじわじわ膨らむ“スコープのにじみ”を防げます。合意は記憶ではなく記録に置く。これが、後から「言った・言わない」で揺れないための保険になります。

対話の設計は、伴走できる相手と

とはいえ、ここまでの対話を発注側だけで設計するのは簡単ではありません。自社の業務に詳しいからこそ、何が“言わなくても分かるはず”の前提なのか、自分では気づけないからです。だからこそ、業務と技術の両方を行き来しながら問いを立てられる相手の存在が効いてきます。私たち d-studio は、北九州を拠点に、この要件定義の段階からお客様と一緒に対話を組み立ててきました。

私たちが大切にしているのは、仕様書を早く埋めることではなく、お客様自身も気づいていなかった本当の要件を一緒に掘り起こすことです。図に描いて確かめ、例外を尋ね、決めたことを記録に残す。この地道な往復のなかでこそ、後から揺れない土台ができあがります。立派な仕様書を急いで作るより、お互いの像がそろった一枚の絵を持つほうが、結果として開発はずっと速く、確かに進みます。

「要件をうまくまとめられる自信がない」「過去に仕様の食い違いで苦労した」——そう感じておられるなら、まずはその不安をそのままお聞かせください。何を作るかが固まっていない構想段階のご相談こそ、私たちがいちばんお役に立てる場面です。あなたの会社の“まだ言葉になっていない要件”を、一緒に形にさせてください。