現場から上がってきた声を、そのまま仕様書に落とす。
言われたとおりに作る。
それなのに、出来上がった機能は使われず、仕様はどこかで矛盾している。
逆に、現場の声を軽んじれば、本当の痛みを取りこぼす。
どちらの失敗も、同じ一点から来ている。
「要望」と「要求」と「要件」を、区別せずに扱っていることだ。
三つは、抽象度も、責任を負う人も違う。
その違いを押さえると、なぜ両方の失敗が起きるのかが見えてくる。
三層構造とその関係
要望・要求・要件の役割分担
三つの区別は、抽象度と責任の所在で決まる。
- 要望（Wants）は現場の声。未整理で、矛盾を含んでいて構わない。主語は、業務の現場にいる人だ
- 要求（Requirements）は、要望を分析・構造化し、ビジネス判断を加えたもの。意思決定を伴う宣言で、責任は発注側にある
- 要件（Specifications）は、要求を実現するためにシステムが満たすべき条件。検証可能な形で書かれ、責任は開発側にある
流れは、「要望（現場の声）→ 要求（ビジネス判断）→ 要件（技術的な約束）」だ。
冒頭の二つの失敗も、ここに位置づけられる。
要望をそのまま要件として扱えば、矛盾した仕様や使われない機能が生まれる。
要望を軽視すれば、現場の本当の痛みを取りこぼす。
どちらも、層を飛ばしたことの代償だ。
三者の関係はN:N
やっかいなのは、三者が1:1で並んでいないことだ。
関係はN:Nで、しかも変換の方向で性質が違う。
要望から要求への変換は、N:1になりやすい。
別々の要望を分析すると、同じ要求に収束することがある。
逆に、一つの要望が複数の要求に割れることもある。
要求から要件への変換は1:Nが基本だが、一つの要件が複数の要求を同時に満たすこともある。
このN:Nを放っておくと、「仕様変更の影響範囲が読めない」事態になる。
かといって、完全に管理しようとすると更新が止まって破綻する。
だから、必要なときに辿れる程度に繋がりを残す、という割り切りが要る。
目的と手段、期待と合意
要求と要件は「目的と手段」の関係だ。
だが、それだけで見ると、一つ大事なものを見落とす。
要件には、手段であると同時に「約束」としての性格がある。
要件として定義された瞬間、それは開発側とビジネス側の合意事項になる。
変更にはプロセスが要る。
論理的な関係（WHYとHOW）の上に、社会的な関係（信頼と責任）が乗ってくる。
だから、要件は軽々しく書き換えられない。
アジャイルでの扱いと生成AIの役割
スクラムでの対応関係
この三層は、ウォーターフォールの遺物に見えるかもしれない。
だが、アジャイルでも消えない。
表現と扱い方が変わるだけだ。
- 要望は、生の声・フィードバックとして変わらず存在する
- 要求は、PBIやユーザーストーリーとして段階的に詳細化される
- 要件は、受け入れ基準としてスプリントごとに合意・検証される
本質的な違いは、順番の踏み方にある。
ウォーターフォールが「順に確定させる」のに対し、アジャイルは「三層を短いサイクルで何度も行き来する」。
仮説検証型だから、要件を満たした結果「そもそも要求が間違っていた」と気づくことすら、前提に組み込まれている。
なお、PBIの受け入れ基準は、スクラムガイド上は必須ではない。
ガイドが定めるのはPBIの「説明・順序・見積もり・価値」とDoDの存在だけだ。
受け入れ基準は、「認識を揃えるための道具」として扱うのが実態に合う。
POがリードするが「全部やる」ではない
スクラムでは、三層の変換をPOがリードするのが自然だ。
ただし、POが全部やる、という意味ではない。
要望の収集と要求への変換は、「何を作るか、なぜ作るか」の判断で、POの責務だ。
要求から受け入れ基準への変換は、POと開発チームの協働になる。
リファインメントでの対話の質が、そのままプロダクトの質を決める。
問題が顕在化するのは、技術的知識がないPOの場合だ。
建前上は「何を作るか」と「どう作るか」は分離される。
だが、実際の意思決定は、そう綺麗には分かれない。
ここで効くのが、決める人と、決めるための情報を持っている人は別でいい、という整理だ。
危ないのは、二つの極端だ。
技術がわからないPOが、相談せずに決めてしまう。
逆に、技術的に難しいと言われるたびに、POが引き下がる。
どちらも、判断と情報を一人に背負わせようとする発想から起きている。
生成AIで効率化される部分と残るボトルネック
この三層に沿って見ると、生成AIの効きどころが、きれいに分かれる。
効率化されやすいのは、情報の整理・構造化・表現の工程だ。
散在する要望からのパターン抽出、要件定義書への変換、矛盾や抜け漏れの検出。
大量のテキストを読んで構造化する作業は、生成AIの得意領域だ。
一方で、ボトルネックとして残るものが二つある。
- 要望から要求への判断。どの要望を採用し、どう優先順位をつけるかは、ビジネスの文脈・組織の力学・将来の戦略を踏まえた意思決定になる
- 要望の引き出しそのもの。まだ言語化されていない業務の痛みや暗黙の前提を掘り起こすには、観察・対話・信頼関係が要る
生成AIは「すでに言葉になったもの」の処理を加速する。だが、「まだ言葉になっていないもの」を言葉にする工程と、「言葉になったものの中から何を選ぶか」という判断は、人間のボトルネックとして残る。
持続可能な運用のための実践
整理し続けるコストにどう向き合うか
ここまでは「整理する」話だった。
だが、現場で本当に重いのは、「整理し続ける」ことのコストだ。
N:Nの関係を完全に管理しようとすると、更新が止まり、破綻する。
道具立てとしては、三つの方向がある。
- バックログ管理ツールのリレーション機能で、繋がりを構造として持つ
- PBI本文に出自を一行だけ書き込み、最低限の追跡を残す
- 生成AIで、必要なときに関係を再構成する。常時管理は諦める
全方向を管理しようとして更新が止まるより、「うちのチームでは、この方向の追跡がいちばん痛みを防ぐ」と一つ決めて、そこだけ確実にやる。
そのほうが、結局は長く続く。
Issue管理とADRで追跡を残す
具体的な手段としては、GitHub ProjectsのSub Issue機能を使う構成が扱いやすい。
- 要望を親Issueにし、そこから生まれる要求をSub Issueとして紐づける
- 1:Nの関係が、そのまま構造として表現できる
- N:Nの問題（複数の要望に跨がる要求）は、主たる要望の下にSub Issueとして置き、他の要望は本文内のリンクで対処する
- 親Issueが要望、Sub Issueが要求、という構造自体が種別の役割を果たすので、カスタムフィールドの「種別」は要らなくなる
ビューも使い分けられる。
親Issueでグルーピングすれば要望単位の進捗が見え、Sub Issueだけフィルタすればバックログとして使える。
このIssue管理と、ADR（Architecture Decision Record）は、矛盾しない。
役割の境界を引けば共存できる。
Issueは「何を実現するか」を管理する場所で、状態が変わる（Open→Closed）。生きている仕事の追跡だ。
ADRは「なぜそう決めたか」を記録する場所で、基本的に状態は変わらない。決定時点のスナップショットだ。
運用としては、Issue側に「該当ADRに基づいて方針決定済み」とだけ書き、判断の詳細はADRへ委ねる。
ADRを書くべきかは、要求との対応関係ではなく、「判断の重さ」で決める。
横の広がり、つまり複数の要求に影響する判断か。
縦の深さ、つまり一つの要求でも選択肢間のトレードオフが重いか。
「半年後に別の人が見て、なぜこうなっているのかと疑問に思うか」が、実用的な目安になる。
優先度判断と矛盾への対処
最後に、いちばん歪みやすい優先度と矛盾の話をする。
MoSCoW法的な分類（Must / Should / Nice to have / No need）は、要望の段階ではやらない。
「誰にとってのMustか」が曖昧になり、声の大きい人に引っ張られるからだ。
優先度は、要求の段階でビジネス判断としてつけるほうが、歪みが少ない。
要望段階でざっと整理したいなら、Must/Shouldではなく、事実ベースの軸を使う。
頻度の高さ、影響の大きさ、緊急性の有無。
優先度は判断、頻度や影響度は観察。観察は先にやっても安全だが、判断を早くやりすぎると後で覆しにくくなる。
矛盾への対処も、順番が肝心だ。
要望に矛盾があるとき、いきなりステークホルダーを集めるのは悪手だ。
まずPOが、矛盾の構造を可視化する。
表面的に矛盾して見えるものが、掘り下げると実は矛盾していないこともある。
そのうえで、選択肢とトレードオフを整理して諮るか、POが決め切る。
合議に頼りすぎると妥協案に流れるので、決め切る選択肢は必ず残しておく。
外のユーザー間の矛盾と、内のステークホルダー間の矛盾では、対処が違う。
ユーザーインタビューから出る矛盾はPOが判断するもので、ユーザー同士を集めて調整する性質のものではない。
社内ステークホルダー間の矛盾は、POが構造を整理したうえで合意形成を促す。
矛盾の構造を整理する作業は、生成AIが得意な領域だ。
だが、どちらを取るかの判断は、最後まで人間に残る。
要望・要求・要件を三層に分けることは、突きつめれば、この一線を引くための作業だった。
情報の整理は、仕組みやAIにいくらでも預けられる。
何を選ぶかという判断だけは、最後に誰かが引き受けるしかない。
そして、引き受ける人が決まっているチームほど、たぶん整理は破綻せずに回り続ける。