要求は誰のものか

要求は唯一システムの話をしない層であり、主語はユーザーや発注者である。 では発注者がいない案件では、この層はどうなるのか。

顧客が存在しない開発は珍しくない。自社プロダクト、社内ツール、技術的負債の解消、 そして受注前の提案。これらに共通する問いを扱う。

結論から言えば、要求工程がなくなることはない。要求を出す主体と、その身分が変わる。 そして身分の違いのほうが、主体の違いよりも本質的である。

顧客がいないことと、要求がないことは違う

要求層に座る者がいなければ、その席は空くのではない。誰かが座る。 明示的に座らなければ、要求は消えるのではなく暗黙化する。

暗黙化した要求は、誰にも見えない形で誰かの頭の中にあり、 検証されないまま以降の全層の前提になる。 後から「なぜこの機能があるのか」と問われても、答えられる者がいない。

これは越境パターン #1（要求に解決策が書かれている）の変形である。 あちらは要求の位置に解決策が座る問題だった。 こちらは要求の位置に誰も座らないまま作業が進む問題である。

要求には身分がある

主体を並べる前に、より重要な区別を立てる。要求には2つの身分がある。

身分内容根拠検証状態
合意事項発注者や責任者と確認済みの要求相手の意思済み
仮説観察や推論から立てた要求観察・調査・類似事例未

同じ文面でも、身分が違えば扱いが違う。 合意事項は動かすのに再合意が要るが、仮説は反証されたら差し替えてよい。 逆に、仮説を合意事項として扱うと、検証されていないものが最上位の権威を持つ。

文書には、どちらの身分かを明記する。 書き分けがなければ、読み手は区別できない。

主体と身分の対応

案件の型要求の主体検証者初期の身分
受託発注者発注者・ユーザー合意事項
提案（受注前）提案する側未確定仮説
自社プロダクトプロダクトオーナー・事業責任者見込みユーザー・市場仮説
社内ツール業務部門実際に使う人合意事項
技術的負債の解消開発組織自身保守する人・運用する人仮説

受託と社内ツールだけが、最初から合意事項として始まる。 残りは仮説から始まり、どこかの時点で身分が変わるか、変わらないまま進む。

仮説であることの帰結

要求が仮説の身分にあるとき、受託とは異なる困難が生じる。 受託より容易なのではなく、異なる注意を要する。

根拠の明示が必須になる

合意事項の根拠は相手の意思であり、それ以上さかのぼれない。 仮説の根拠は観察や推論であり、示せるし、示さなければならない。

根拠を書く実利は、外れたときに根拠だけ差し替えられることにある。 根拠のない仮説は、否定されたら丸ごと捨てるしかない。

検証者が仮想になる

「見込みユーザー」は実在しても、目の前にいない。 受入テストに相当する検証が、リリース後の反応まで先送りされる。

受託であれば要求の誤りは受入テストで露見する。 仮説から始まる案件では、露見する場が構造的に後ろにずれる。

要求と要件の主体が同一人物になる

受託では要求（発注者）と要件（発注者＋開発者）で主体が変わるため、 層の境界が自然に守られる。誰かに説明する必要が、境界を維持する外圧になっている。

自社プロダクトや技術的負債の解消では、自分で要求を立てて自分で要件を書く。 外圧がないため、層の混同が起きても指摘されない。

成功基準を自分で決められてしまう

発注者がいれば「30分にしたい」は交渉相手のいる数字である。 自分で決めるなら、達成できそうな数字に無意識に寄る。

さらに悪いことに、未達のときも誰も気づかない。 越境パターン #10（設計上の制約が要求の目標を書き換える）が、 検証者不在のまま進行する。

技術的負債の解消では、解決策が要求の位置に座りやすい

この型で特に頻度が高い。

前者は解決策であり、要求ではない。 解決策を要求の位置に置くと、いつ終わったのかを誰も判定できなくなる。 リファクタリングに完了はないが、原因特定1時間には完了がある。

身分が変わる瞬間

仮説から始まった要求は、どこかで合意事項に変わる。 この遷移が起きる瞬間を意識しないと、仮説が身分を偽ったまま残る。

提案が受注に変わるとき

提案において、要求は特殊な位置にある。要求そのものが提案の中身だからである。

通常の開発では要求は与件であり、それを満たす手段を考える。 提案では「あなたの課題はこれではないか」という要求の提示が、提案の価値の中心にある。 手段だけを示す提案は、要求の当てが外れた時点で全体が無効になる。

そして提案時点の要求は、誰にも検証されていない。 提案先の担当者はまだ検証者ではない。提案が通って初めて発注者になる。

受注後にやるべきことは決まっている。

  1. 提案書の要求を発注者と確認し、合意事項として立て直す
  2. 提案の制約と要求の制約を分ける。「予算枠のために削った」と「そもそも要らない」は別
  3. 提案書に載せた画面を仕様から切り離す。あれは説明のための絵であり、仕様ではない

これを飛ばすと、検証されていない仮説が要求という最上位の権威をまとって固定される。 提案書は相手を説得するための文書であり、 通すために強めに書かれた成功基準が混じっていることがある。 それが要求として居座れば、達成不能な目標を抱えたまま開発が始まる。

提案書と要求定義書を同じ文書にしない。 片方は仮説、片方は合意であり、性質が違う。 同じ文書にすると、いつ仮説が合意に変わったのかが誰にも分からなくなる。

プロトタイプが評価されるとき

自社プロダクトでは、プロトタイプ（仕様・実装）が先行して要求が後から明確になる逆流が起きる。 これは健全な進み方である。

ただし「なぜ工程として必要なのか」で述べたとおり、 崩れているのは順序であって、判断ではない。 触ってもらった結果を受けて、要求を仮説から合意事項に変える工程が後ろに必ず要る。

その工程がなければ、プロトタイプが要求の代わりに居座る。 動いているものは説得力を持つため、 「これが欲しかったものか」を問い直す機会が失われやすい。

立て直しを飛ばした場合

いずれの遷移でも、飛ばしたときに起きることは同じである。 検証されていないものが、検証済みの顔をして最上位に固定される。

これは「コードから何が読めるか」で述べた逆算の罠と同型である。 あちらはコードから要求を推測して文書化する話だった。 こちらは提案書やプロトタイプの前提を、確認せずに要求として流用する話である。

いずれも、要求の検証者は発注者やユーザーであって、 コードでも提案書でもプロトタイプでもない。

判定の問い

要求層に誰か座っているかを確かめるには、次を問う。

これが完成したとき、それが成功だったと判定するのは誰か。

答えられなければ、要求の席が空いている。 答えが「自分」でも構わない。空欄であることが問題である。

続けて、書かれている要求それぞれについて問う。

この要求は合意事項か、仮説か。

仮説であれば、根拠が書かれているか。いつ合意に変えるのかが決まっているか。 どちらも答えられないなら、その要求は身分を偽っている。

まとめ

この判断は誰が検証するのか。 問いは変わらない。 要求においては、まずその席に誰が座っているかを確かめることから始まる。