「いい感じに直して」をそのまま実装しない：曖昧な依頼を検証できる仕事に変える【第2回】

「いい感じに直しておいて」と頼まれ、3時間かけて丁寧に作り、見せた瞬間に「あ、そうじゃなくて」と言われる。この記事を読み終えると、曖昧な依頼を「終わったと言える条件」が付いた仕事に翻訳し、手戻りの前に認識を合わせられるようになります。ジュニアエンジニア向け開発フロー入門シリーズ（全8回）の第2回です。

🎯 テーマの主役：「受け入れ条件」——到着を判定できる目的地

今回の主役は受け入れ条件（Acceptance Criteria）です。一言で言えば、受け入れ条件とは「この状態になったら、この仕事は終わり」と第三者が判定できる形で書いた条件です。

日常の例えで言うなら、目的地の住所です。「南の方にある公園ね」と言われて出発したとします。歩けど歩けど、公園らしきものが見えません。「南の方」は方向であって、到着したかどうかを判定できないのです。「○○駅の3番出口を出て、線路沿いを200メートル、改札のない入口」まで聞けば、たどり着けるかどうかは別として、着いたかどうかは誰でも判定できます。受け入れ条件は、この「住所」にあたります。

第1回で、開発フローは8つの関門を通ることを確認しました。今回掘るのは、最初の2つの関門である「課題」と「要件」です。この2つが通っていないと、後ろの6つの関門はすべて無駄になります。設計も実装もレビューもテストも、「何を満たせばよいか」が決まっていなければ、正しいかどうかを判定できないからです。

この関門を通せるようになると、次の3つができるようになります。第一に、曖昧な依頼から「終わりの条件」を引き出せること。第二に、作業を「動く単位」で分割できること。第三に、「間に合いません」を、言い訳ではなく情報として伝えられることです。3つ目は特に重要です。受け入れ条件とタスクの大きさが分かっていると、「この条件のうち、ここまでは今週できます。この条件は来週になります」と、選択肢として伝えられます。

動機：なぜ「言われた通りにした」が通らないのか

ジュニアエンジニアが最初にぶつかる壁は、技術的な難しさよりも「依頼の曖昧さ」かもしれません。先輩から「この画面、たまにエラーが出るから直しておいて」と言われる。あなたはコードを読み、たしかに気になる箇所を見つけ、直します。報告すると「うーん、そうじゃなくて、エラーが出るのはここじゃなくて……」となる。

このとき、あなたの技術力は何も問題ありません。問題は依頼の中に「終わりの条件」が入っていなかったことです。「たまに」「エラーが出る」「直す」——この3つはすべて、判定できない言葉です。たまにとは何回に1回か。どのエラーか。直すとは、エラーが出ないことか、出ても影響が小さいことか、原因を特定することか。

ここで大切なのは、依頼した先輩も悪くないという点です。先輩は「たまにエラーが出る」という現象しか見ておらず、その奥にある原因や期待する結果を、まだ言葉にしていないだけです。これは能力の問題ではなく、開発の仕事が本質的に持つ不確実性です。だからこそ、開発フローには「課題」と「要件」という関門が置かれています。曖昧なまま進めるのではなく、進める前に曖昧さを減らす場所として置かれているのです。

この記事の仮説はこうです。依頼の質は、依頼する側の能力ではなく、受け取る側の質問で決まる。もしこれが正しければ、「いい感じに直して」と言われても、こちらから判定可能な条件を引き出すことで、手戻りのほとんどを防げるはずです。

🔍 検証①：依頼のどこが「判定不能」なのか

まず、依頼のどこが曖昧なのかを分解します。1つの依頼には、少なくとも次の5つの情報が含まれているべきです。これは第1回の関門1〜2の出口条件を、依頼の形にしたものです。

「いい感じに直して」という依頼を、この5要素で採点するとこうなります。目的＝不明。対象＝不明。完了条件＝不明。制約＝不明。期限＝不明。5つすべてが空です。この状態で実装を始めるのは、住所を聞かずに南へ歩き始めるのと同じです。

1行目から4行目への変化で、追加されたのは技術情報ではありません。「月に数回」「再現テストを追加」「他の画面は触らない」——すべて、判定のための情報です。曖昧さを減らす仕事は、技術力ではなく質問力の仕事です。

🔍 検証②：受け入れ条件の書き方——「〜のとき、〜となる」

「終わりの条件」を書く、と言うと身構えるかもしれません。しかし形式は決まっていて、「〜のとき、〜となる」の1行で足ります。これは振る舞いを書く形式として広く使われているもので、Given-When-Then（前提・操作・期待）とも呼ばれます。

先ほどの保存エラーの例なら、受け入れ条件は次のようになります。

• 条件1：登録フォームでメールアドレスを空のまま保存ボタンを押すと、「メールアドレスを入力してください」と表示され、保存処理は実行されない
• 条件2：同じメールアドレスが既に登録されている場合、「このメールアドレスは登録済みです」と表示され、既存データは変更されない
• 条件3：正常な入力で保存すると、完了メッセージが表示され、一覧に新しい行が追加される

この3行の良さは、そのままテストになることです。実際、受け入れ条件はテストケースの原型になります（第6回で扱います）。逆に言えば、テストに書き直せない条件は、まだ受け入れ条件になっていません。これが判定のコツです。

書き直すコツは3つです。第一に、形容詞を数値か行動に変える（「速く」→「1秒以内」）。第二に、主語と操作を明示する（「使いやすく」→「3回の操作で」）。第三に、複数の条件に分ける（1行に2つ以上のことを書かない）。1つの条件が長くなったら、それは2つの仕事が混ざっているサインです。

🔍 検証③：タスクの切り方——「動く単位」で縦に切る

受け入れ条件ができたら、次は作業を分割します。ここで多くのジュニアエンジニアがつまずきます。分割の仕方を間違えると、最後の1日まで何も動かないという状態になります。

典型的な間違った切り方は、技術の層で切るやり方です。たとえば「ユーザー検索機能」を作るとき、①データベースのテーブルを作る、②データ取得のAPIを作る、③検索画面を作る、④結合テストをする——この4つに分ける。一見、きれいに見えます。ところがこの切り方では、①も②も③も単体では動きません。「できました」と報告できる瞬間が、最後の④まで来ません。そして④で初めて「そもそも検索対象の項目が足りない」といった根本的な問題に気づきます。

正しい切り方は、利用者に見える単位で縦に切るやり方です。たとえば「名前の一部で検索できる」→「部署で絞り込める」→「検索結果を並べ替えられる」というふうに、1つずつ動く形で切ります。最初の1つは、テーブル作成から画面まで含みますが、見た目は小さくても端から端まで動きます。

ただし、横に切る切り方が常に悪いわけではありません。設計の検討段階では、層ごとに全体を見渡す必要があります。問題は、それを「タスク」として登録してしまうことです。「DBのテーブルを作る」は、作業の一部ではあっても、単体で完了報告できるタスクではありません。「テーブルを作り、名前検索が画面から動くところまで」が1つのタスクです。

この切り方は「水平スライスではなく垂直スライス」と呼ばれ、アジャイル開発では基本とされています。垂直に切ると、各タスクの終わりに必ず「動くもの」と「確認できるもの」があるので、第1回で見た関門（レビュー・テスト）も各タスクで通せます。

🔍 検証④：見積もりと約束は違う

関門2の出口条件には「期限」も含まれます。ここで必要になるのが見積もりです。そして、見積もりについて最も多い誤解が、「見積もり＝約束」だという思い込みです。

見積もりは、いま持っている情報で立てた予測です。だから、情報が増えれば変わります。引っ越しの見積もりを思い出してください。部屋の広さと荷物の量を聞いて出した金額と、当日に「ピアノがありました」と分かった後の金額は変わります。見積もりが変わったのは、嘘をついたからではなく、情報が増えたからです。

重要なのは、見積もりを出すときに「何を前提にしたか」を一緒に出すことです。たとえば「この3つの受け入れ条件を満たすのに3日」と言うとき、「既存のデータ構造をそのまま使えることを前提に」と添えます。この前提が崩れたら、見積もりも変わるという合意が生まれます。前提を添えずに数字だけを出すと、その数字だけが独り歩きして約束に変わります。

不確実性が高いときの定石は、調査タスクを先に切ることです。「見積もりが出せない」と正直に言うのは、実は専門家の正しい振る舞いです。代わりに「半日かけて調べます。その結果で判断しましょう」と、調査に期限を付けて提案します（これをタイムボックスと呼びます）。調査の結果は「実装できそう／できなそう／別の方法がある」の3択で報告できるので、依頼側も次の判断ができます。

🔍 検証⑤：チームの「完了の定義」と個人の「終わりました」は違う

ここまでの受け入れ条件は、個々のタスクの話でした。それとは別に、チーム全体で「完了（Done）」の定義を決めていることがあります。たとえば「テストが通り、レビューを受け、ドキュメントを更新し、監視に登録されたら完了」といったものです。これは個人の「コードを書き終えた」とは別の水準です。

なぜこの定義が必要かというと、個人の「終わりました」とチームの「出せる状態」にはギャップがあるからです。コードが書けても、テストがなければ壊れたことに気づけず、レビューがなければ盲点が残り、監視がなければ出した後に気づけません。第1回で見た関門の考え方そのものです。

自分のタスクが「終わった」と思ったら、チームの完了の定義に照らして、残りは何かを確認する。これを習慣にすると、「もう終わったはずなのに何でまだ作業があるの」という混乱が消えます。チームに完了の定義がない場合は、先輩に「このタスクは、何がそろったら完了ですか」と聞くのが良い質問です。これは依頼の確認と同時に、チームの暗黙のルールを学ぶ機会になります。

結果：依頼を受けてから動き出すまでの5ステップ

ここまでの検証を、実際の行動に落とします。依頼を受けたら、次の5ステップの順で進めます。所要時間は、合わせて10分程度です。この10分が、3日の手戻りを防ぎます。

この5ステップで最も価値が高いのはステップ3です。完了条件を自分で書いて見せる——これができると、会話が「作ってから確認」から「確認してから作る」に変わります。しかも、あなたが書いた条件が間違っていた場合、依頼者は間違いを指摘する形で正しい条件を言いやすくなります。「そうじゃない、こうしてほしい」は、ゼロから説明するよりずっと楽なのです。

ステップ3で作る条件は、箇条書き3〜5行で十分です。フォーマットは次の3つのどれかで書けば、チームの文化に合わせやすいでしょう。

考察：聞き返すのは失礼ではなく、仕事の一部である

ここからは、検証では扱いきれなかった解釈を述べます。私の考えでは、ジュニアエンジニアが最も損をするパターンは、「聞き返すと仕事ができないと思われる」と恐れて、曖昧なまま進めることです。この恐れは、入社1〜2年目に特に強く働きます。

しかし、開発の仕事の本質は、不確実性を減らすことです。要件が最初から明確な現場はほとんどありません。プロのエンジニアは、曖昧な依頼から質問で輪郭を引き出すという技術を使います。これは「分からないことを聞く」のではなく、「依頼の中の未決定事項を特定する」という能動的な作業です。だから、聞き方にも工夫が要ります。「どうすればいいですか」と丸投げするのではなく、「私はAだと思います。理由はこうです。合っていますか」と選択肢を添えて確認するのが、最速で正確な方法です。この形なら、依頼者は「はい」か「違う、Bだ」を答えるだけで済みます。

これはAIへの指示にも、そのまま当てはまります。生成AIに「いい感じに直して」と頼むと、それらしいが的外れな結果が返ってきます。受け入れ条件を書ける人は、AIへの指示も上手くなります。逆に、AIの出力を検証できないのは、自分が受け入れ条件を持っていないからです。第1回で述べた「実装が安くなると、要件と検証の比重が上がる」という変化は、この能力の価値を相対的に高めます。

📌 注目ポイント

• 曖昧な依頼の本質は「言葉が曖昧」なのではなく、「終わりを判定できない」こと
• 依頼に必要な5要素は目的・対象・完了条件・制約・期限。5つすべてが空の依頼は、実装を始めてはいけない
• 受け入れ条件は「〜のとき、〜となる」の1行で書ける。テストに書き直せない条件は、まだ条件になっていない
• タスクは動く単位で縦に切る。層で切ると、最後まで何も動かない
• 見積もりは予測であり、前提と一緒に出す。前提が崩れたら再見積もりする
• 個人の「終わりました」とチームの「完了」は別の水準。定義を確認する
• 聞き返しは失礼ではない。選択肢を添えた確認が、最速で正確な方法

💡 活用事例：手術室で生まれた「報告の型」——SBAR

曖昧な依頼を構造化するという課題は、実は医療の現場で最も真剣に取り組まれてきた問題です。そこで生まれたのがSBARというコミュニケーションの型です。

SBARは、次の4つの頭文字です。S（Situation：状況）「いま何が起きているか」。B（Background：背景）「これまでの経緯・前提は何か」。A（Assessment：評価）「私はこう考えている」。R（Recommendation：提案）「こうしてほしい」。

なぜ医療でこれが必要になったのか。患者の急変を医師に伝えるとき、「なんか様子がおかしいです」と言われても、医師は何を優先すべきか判断できません。「患者Aさん（S）、術後2日目で発熱と頻脈（B）、感染の可能性があると考える（A）、抗生剤の指示と診察をお願いしたい（R）」——これなら、受け取った側が即座に判断できます。

SBARは元々、米海軍の原子力潜水艦での報告手法が由来とされ、1990年代に医療機関へ導入されました。カイザーパーマネンテなどの医療機関が導入し、患者安全の改善に寄与したと報告されています（WHOの患者安全の文書や、米国医療研究品質局AHRQの患者安全の資料でも取り上げられています）。導入効果は施設や測定方法によって幅がありますが、「報告の型を決めると、伝達の失敗が減る」という方向の結果が複数報告されています。

この型は、開発の現場にそのまま持ち込めます。先輩への報告を「なんかエラーが出ます」ではなく、「状況：保存時に500エラーが月に数回出ている。背景：先週のリリース以降。評価：データの重複が原因と考えている。提案：再現テストを追加して原因を特定したい」と伝える。受け入れ条件の確認は、依頼の方向でSBARを使っているとも言えます（状況＝対象、背景＝目的、評価＝完了条件の案、提案＝次のアクション）。

ちなみに、この「型」の効果は万能ではありません。形だけなぞると、中身のない報告が上手になるだけです。型の目的は、相手が判断できる材料を漏れなく並べることにあります。

✅ 要点まとめ

• 曖昧な依頼には目的・対象・完了条件・制約・期限の5要素が欠けている。まずどれが欠けているかを特定する
• 受け入れ条件は「〜のとき、〜となる」の形で書く。形容詞は数値か行動に置き換える
• テストに書き直せない条件は受け入れ条件ではない。これが最も実用的な判定基準
• タスクは縦に切る。各タスクの終わりに「動くもの」と「確認できるもの」を残す
• 見積もりは前提付きで出す。「3日（前提：既存構造を使う場合）」の形
• 見積もりが出せないときは、タイムボックス付きの調査タスクを提案する
• チームの「完了」の定義を確認し、個人の「終わりました」と区別する
• 依頼を受けたら10分で5ステップ。特に「完了条件を仮で書いて見せる」が効く

🚀 取り込み方：明日から使う3段階

今日（5分でできること）：いま自分が持っているタスクを1つ選び、「〜のとき、〜となる」の形式で受け入れ条件を3行書いてみてください。書けない場合は、どこが分かっていないかが分かります。書けたら、チケットやタスク管理ツールの説明欄に貼り付けます。GitHub Issues、Jira、Backlog、Notion、どこでも構いません。

今週（小さく試す）：次の依頼を受けたとき、ステップ3（完了条件の仮案を見せる）を1回だけ実行してください。「この3つができたら完了という理解で合っていますか」と確認するだけです。相手の反応を観察し、認識のずれが何件見つかったかを数えてみてください。ずれが見つかるほど、あなたは手戻りを防いだことになります。

今月（定着させる）：自分のタスクを縦に切る練習をしてください。大きなタスクを1つ選び、「利用者に見える単位」で3〜5個に分解します。分解した各タスクに「この終わりに何が動くか」を1行書きます。書けない分解は、まだ横に切れているサインです。あわせて、チームに「完了の定義」が明文化されているか確認し、なければ先輩に1回聞いてみてください。その答えは、チームの暗黙のルールを知る最短の道です。

🔥 ハマりポイント

その1：「聞けば分かる」と考える
「分からないことは聞こう」は正しいのですが、依頼した側も答えを持っていないことが多々あります。「どうすればいいですか」と聞くと、相手もその場で考え始め、その場の思いつきが仕様になってしまう危険があります。これを避けるには、選択肢を持って行くことです。「A案とB案があります。私はAが良いと思いますが、どちらでしょうか。決めるための情報は◯◯です」——この形なら、相手は判断に集中でき、答えがぶれません。

症状：質問したのに、後で「やっぱり違う」と言われる。原因：その場の思いつきで答えが決まっている。対処：選択肢と判断材料をセットで持参する。決まらない場合は決める期限と人を確認する。

その2：「受け入れ条件を書くと重くなる」と考える
受け入れ条件と聞いて、分厚い仕様書を想像すると身構えます。しかし必要なのは3〜5行の箇条書きです。長い仕様書が必要になるのは、条件が多すぎるか、条件が決まっていないからです。条件が多すぎる場合は、タスクの分割を疑ってください（1つのタスクの条件が10行を超えたら、それは複数の仕事です）。

症状：仕様書を書くのに時間がかかり、実装が遅れる。原因：条件が多すぎる（＝分割不足）。対処：条件が3〜5行に収まるまでタスクを分ける。

その3：「見積もり」を「約束」として出す
「3日でできます」とだけ言うと、その3日が約束に変換されます。前提が崩れて4日かかったとき、あなたは約束を破ったことになります。前提を添えて出すだけで、この構造が変わります。「3日（前提：既存のデータ構造をそのまま使えること）」。前提が崩れたら、見積もりの更新を提案するのが正しい振る舞いです。

症状：見積もりが常に外れ、信用を失う。原因：不確実性を織り込まず、前提も添えていない。対処：幅（2〜4日）＋前提＋「調査後に更新します」の3点セットで出す。

その4：タスクを「作業」で分けてしまう
「調べる」「直す」「テストする」という分け方は、作業手順であってタスクではありません。この分け方だと、どの時点でも「動くもの」がなく、進捗も測れません。「◯◯ができる」という状態で分けてください。

症状：毎日の報告が「今日も調べました」になる。原因：作業で分けている。対処：「いま何ができるようになったか」を報告の単位にする。

🔄 代替技術との比較：依頼の受け取り方

依頼の受け取り方には、大きく3つの態度があります。どれが正しいかではなく、状況に応じて選ぶものですが、ジュニアエンジニアには手順化された受け取り方を強くおすすめします。

補足として、契約形態によっても正しい態度は変わります。請負契約で仕様が契約に含まれる場合、仕様の変更は契約変更です。この場合は「手順化して受け取る」の中でも、変更の記録を丁寧に残す必要があります（この記録が後の第3回の設計判断の記録にもつながります）。一方、同じチームで継続的に開発する場合（準委任・自社サービス）、受け入れ条件の確認はそのまま日々の会話になります。

また、依頼の形式にも選択肢があります。口頭、チャット、チケット、ドキュメント。口頭は最も速いが最も消えやすく、チケットは残るが書く手間がかかります。迷ったら、「決定と完了条件はチケットに残し、相談は口頭で」という使い分けが実務的です。第4回で扱うGitのコミットメッセージも、この「意図の記録」の一種です。

📅 今後の展望：AI時代に「要件を書く力」が再評価される

この記事で扱った「受け入れ条件を書く」という技術は、生成AIの普及によって重要性が下がるどころか、上がっています。理由は単純です。AIは、指示された条件を満たすことには長けていますが、条件そのものの妥当性は判断できません。

2023年以降、AIコーディングツールの性能は急速に向上し、実装・テスト生成・リファクタリングの多くが自動化されつつあります。その結果、人間の仕事として残るのは「何を満たすべきかを定義すること」と「定義通りかを検証すること」です。これはまさに、この第2回で扱った関門1〜2の仕事です。

もう1つの潮流は、受け入れ条件の自動検証です。受け入れ条件を「〜のとき、〜となる」という形式的な記述（Gherkin記法など）で書くと、それをテストコードとして自動実行できる仕組みがあります（Cucumberなどのツール群。振る舞い駆動開発＝BDDと呼ばれます）。すべての条件を自動化する必要はありませんが、書いた条件がそのまま検証に使えるという考え方は、AI時代の開発と相性が良い方向です。

さらに、AIに仕事を任せる場合も構造は同じです。「いい感じに直して」とAIに頼めば、それらしいが的外れな結果が返ります。目的・対象・完了条件・制約を与える——この5要素は、人間にもAIにも共通する「仕事の渡し方」の形式です。第1回で述べた「たすきの中身」は、人間だけでなくAIに対しても必要になります。

まとめ

この記事を読んだあなたは、次に「いい感じに直して」と言われたとき、そのまま実装を始める代わりに、3行の受け入れ条件を書いて見せるようになります。そして、書けない条件があるときは、それが質問すべき点だと分かります。

曖昧な依頼は、あなたの敵ではありません。仕事の始まりはいつも曖昧で、それを具体化するのがエンジニアの仕事です。「言われた通りにしました」ではなく「この条件を満たす形にしました」と言えることが、プロの仕事の証になります。

第3回では、関門3の「設計」を掘ります。受け入れ条件が決まった後、実装の前に何を決め、何を決めないでおくのか。「設計書を書け」と言われて何を書けばよいか分からない、という状態を解消します。

参考文献

1. Mike Cohn, “User Stories Applied: For Agile Software Development”, Addison-Wesley, 2004（ユーザーストーリーと受け入れ条件） — https://www.mountaingoatsoftware.com/books/user-stories-applied
2. Bill Wake, “INVEST in Good Stories, and SMART Tasks”, 2003（良いストーリーの6条件） — https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
3. Mike Cohn, “Agile Estimating and Planning”, Prentice Hall, 2005（見積もりと計画） — https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning
4. Cucumber, “Gherkin Reference”（受け入れ条件の形式的記述） — https://cucumber.io/docs/gherkin/reference/
5. ISO/IEC/IEEE 29148:2018, “Systems and software engineering — Life cycle processes — Requirements engineering”（要求の品質特性） — https://www.iso.org/standard/72089.html
6. Institute for Healthcare Improvement (IHI), “SBAR Tool: Situation-Background-Assessment-Recommendation” — https://www.ihi.org/resources/tools/sbar-tool-situation-background-assessment-recommendation
7. Agency for Healthcare Research and Quality (AHRQ), “TeamSTEPPS: SBAR Communication” — https://www.ahrq.gov/teamstepps/index.html
8. World Health Organization, “Patient Safety Solutions: Communication During Patient Hand-Overs”, 2007 — https://www.who.int/
9. Bill Bryar, Colin Carr, “Working Backwards: Insights, Stories, and Secrets from Inside Amazon”, St. Martin’s Press, 2021（作る前にプレスリリースを書く） — https://www.stmartins.com/
10. Taiichi Ohno, “Toyota Production System: Beyond Large-Scale Production”, Productivity Press, 1988（「なぜ」を繰り返す問い方の原典） — https://www.routledge.com/
11. Jeff Patton, “User Story Mapping”, O’Reilly Media, 2014（タスクの縦割りと優先順位） — https://www.oreilly.com/
12. Google, “Google’s Engineering Practices documentation”（変更の小ささと説明責任） — https://google.github.io/eng-practices/
13. Alistair Cockburn, “Writing Effective Use Cases”, Addison-Wesley, 2000（利用者視点の振る舞い記述） — https://www.oreilly.com/
14. Daniel Kahneman, “Thinking, Fast and Slow”, Farrar, Straus and Giroux, 2011（見積もりに生じる認知バイアスの背景） — https://us.macmillan.com/
15. Bent Flyvbjerg, Dan Gardner, “How Big Things Get Done”, Currency, 2023（大規模プロジェクトの見積もり誤差の実証研究） — https://www.penguinrandomhouse.com/
16. 情報処理推進機構（IPA）, 「ソフトウェア開発データ白書」 — https://www.ipa.go.jp/