5B-2　委任を仕様にする：要件定義と受け入れ基準

※もともと有料教材でしたが、今はすべて無料で読めます。経緯はこちら→https://note.com/bonnno420/n/n226b8551ab12

外注から上がってきた成果物に「思ってたのと違う」と言いかけて、ふと自分の発注書を読み返したら、曖昧なのはこちらだった——あの気まずさ、ありませんか。

相手の腕の問題ではありません。「期待値を仕様に変換する」工程が、抜けていただけです。

答えは、設計にあります。

ソフトウェア開発が何十年もかけて磨いてきた答えがあります——要件定義。「もっと売上を見たい」という要望を、「誰が・何を・なぜ」のユーザーストーリーと「何ができたら完成か」の受け入れ基準に変換してから任せる。この技術は、人への外注でもAIへの委任でも同じに機能します。

委任が大きくなるほど、口頭の依頼では事故が起きます。ソフトウェア開発の世界は、この問題と何十年も格闘してきました。その蓄積が要件定義——そしてこれは、AI時代の個人が再発見すべきスキルです。

出発点は、要望と要件の区別です。要望は「もっと売上が見えるようにしたい」という願い。要件は「営業担当者が、日次で、商品別の売上を、スマホで確認できること」という、実現すべき条件の記述です。プロジェクトの失敗の多くは、要望を要件に変換しないまま作り始めることで起きます。これは第3A部 3-1で学んだ「問題と課題の区別」、第3B部 3-14の「曖昧な指示の翻訳」の、組織版にあたります。

要件を書く現代的な型がユーザーストーリーです。「〔誰〕として、〔何〕をしたい。なぜなら〔理由〕」——「営業担当者として、外出先で日次売上を確認したい。なぜなら顧客との会話で最新数字を使いたいから」。主語と理由を置くことで、第3B部 3-19で扱った利用現場の証拠を要件へ戻しやすくなります。そしてストーリーには必ず受け入れ基準を添えます。「何ができたら完成か」の検証可能なリスト——「スマホで3タップ以内に表示される」「前日分が朝9時までに反映される」。2-18で学んだとおり、これは委任4本柱の②を業界が磨き上げた形です。

もう一つ忘れがちなのが非機能要件——機能ではなく品質や制約の条件です。速度、セキュリティ、使いやすさ、予算。「動くけど遅い」「できたけど危ない」は、非機能要件の定義漏れから生まれます。プロンプトで言えば制約設計（2-9・ネガティブ指定）に相当します。

そして仕上げがベースライン化と変更管理です。合意した要件は「ここまで確定」と固定し（5A-6のベースライン化）、以後の変更は「何を・なぜ・どんな影響と引き換えに」を明示して合意し直す。これがないと、要望が際限なく染み込んで、完成が永遠に逃げていきます。

この一式は、人への外注でも、AIエージェントへの委任でも、まったく同じに機能します。委任とは、期待値を仕様に変換する作業——書ける人だけが、大きな仕事を安全に任せられます。

保存版・委任を仕様にする

• 要望（願い）を要件（実現条件）に変換してから任せる

• ユーザーストーリー（誰が・何を・なぜ）＋受け入れ基準（何ができたら完成か）

• 非機能要件（品質・制約）の漏れが「動くけどダメ」を生む。合意はベースライン化する

これで冒頭の"思ってたのと違う"が消えます。

【2026年時点の一例】 ユーザーストーリーと受け入れ基準はソフトウェア開発で標準の書式です。AIへの応用先は、Deep Researchへの依頼文やエージェントの指示書がそのまま該当します。名称は数年で入れ替わりますが、本文の原理は変わりません。

やってみよう: いま任せたい仕事を1つ、「ユーザーストーリー1文＋受け入れ基準3つ」の形式で書いてみましょう。書けない部分が、事故の予定地です。変換はこのプロンプトでも。

📍 番号や読む順に迷ったら講座マップへ。目的別ルートと全84レクチャーの対応表があります。