「仕様を書けるエンジニア」がAI時代の開発速度を決める

こんにちは、大平です。

AIでコードを書く速度が上がるほど、開発組織の別のボトルネックが目立つようになりました。 それは、何を作るのか、どこまでできたら完了なのか、誰が未決事項を決めるのかを言葉にする工程です。 実装をAIへ渡せても、事業固有の業務ルールや許容できるリスクまでAIに決めてもらうことはできません。

僕が重要だと考えているのは、長い仕様書を作れる人ではありません。 必要なのは 曖昧な要求を、実装と検証ができる判断単位へ変換できる人です。 この記事では、仕様に何を書くべきか、どの粒度なら使えるのか、組織に型を入れるならどの順序で進めるかを具体化します。

実装が速くなるほど、曖昧さがボトルネックになる

実装力が不要になるわけではありません。 設計の妥当性を判断し、生成されたコードを読み、障害時に原因を切り分ける力は引き続き必要ですが、コードを入力する作業はAIが担えます。

その結果、要求が固まるまでの待ち時間、レビューで前提が覆る手戻り、受け入れ時に初めて見つかる業務ルールの抜けが、相対的に大きな遅延要因になります。 GoogleのDORA 2025レポートは、AIを組織の強みと弱みを増幅する存在として整理しています。 仕様が曖昧な組織では、その曖昧さを抱えたまま成果物が速く増える、と捉えるのが安全です。

だから、AI時代の開発速度は「一日に何行書けるか」だけでは決まりません。 実装を始める前に、決めるべきことを発見し、決められる人へ返す速度が効いてきます。 この考え方を開発プロセスとして整理したものがSDD（仕様駆動開発）です。

仕様は「長い文章」ではなく、判断の境界線である

ここでいう仕様は、画面項目を網羅した分厚い文書と同義ではありません。 実装者やAIが勝手に補ってよい範囲と、事業側の判断を仰ぐべき範囲を分ける情報です。

最低限、仕様には次の問いへの答えが必要です。

• 目的：誰の、どの業務上の問題を解決するのか
• 対象外：今回は何を解決しないのか
• 業務ルール：計算、状態遷移、締め、取消、権限をどう扱うのか
• 例外：データがない、重複する、途中で失敗する場合にどうなるのか
• 受け入れ条件：どの観察可能な結果をもって完了とするのか
• 品質と運用：性能、可用性、セキュリティ、監査、移行、復旧のうち何が必要か
• 未決事項：何が決まっておらず、誰がいつ判断するのか

重要なのは、すべてを最初から確定したように見せないことです。 未決事項を空欄のまま隠すより、「決定者は事業責任者」「この判断が終わるまで実装対象外」と明記した方が、AIも外注先も安全に止まれます。 よい仕様は、答えの集積であると同時に、未決事項の所在図でもあります。

仕様は三つの層に分けると抜けを見つけやすい

仕様を一枚の文章として書くと、事業判断と技術判断が混ざります。 僕は、少なくとも「事業」「振る舞い」「品質と運用」の三層に分けて考えるのがよいと思っています。

三層を分ける利点は、誰が決めるべきかが見えることです。 たとえば、集計方式を事業側が決めるのは自然ですが、データ取得方式やキャッシュ戦略まで経営会議で決める必要はありません。 反対に、エンジニアが実装しやすさを理由に、返品や締め日の扱いを独断で決めるべきでもありません。

受け入れ条件は「確認方法」まで書く

受け入れ条件は「正しく表示されること」「問題なく動くこと」では足りません。 誰が、どの前提で、何をしたとき、何を観察できれば合格なのかを書きます。

たとえば、「経理担当者が確定前の対象月を選ぶと、取消済み取引を除き、一部返金を反映した売上合計が表示される」という条件なら、利用者、状態、操作、計算ルール、期待結果が含まれます。 ここに「権限のない利用者には確定操作を表示しない」「集計に失敗した場合は前回値を確定値として扱わない」といった条件を足すと、権限と異常系も検証できます。

受け入れ条件を読んだ人がテスト方法を想像できなければ、まだ曖昧です。 一方で、すべての内部実装を指定する必要はありません。 API名やクラス名まで固定せず、外から観察できる振る舞いと、破ってはいけない制約を中心にします。

受け入れ条件からテストケースを作り、AIが実装後に検証できるようにすると、完了判定を人の印象だけに頼らずに済みます。 自動テストを含む検証基盤の重要性は、「動けばいい」運用は半年もたないでも詳しく扱っています。

非機能要件は「全部」ではなく、事故の大きいものから選ぶ

非機能要件を網羅しようとすると、仕様は維持できないほど重くなります。 必要なのは、対象機能で外したときの損失が大きい項目を選ぶことです。

次の観点で、該当するものだけを仕様へ置きます。

• 性能：最大想定データ量、同時利用、処理時間の許容範囲は何か
• 可用性と復旧：失敗時に再実行できるか、途中結果をどう扱うか、どこまで戻せればよいか
• 権限：閲覧、作成、変更、承認、取消を誰に許すか
• 監査：誰が、いつ、何を変更したかを後から説明する必要があるか
• セキュリティ：入力検証、認証、認可、秘密情報、外部通信について守る基準は何か
• データ：移行、保持、削除、個人情報、タイムゾーン、丸め規則をどう扱うか
• 運用：監視する事象、通知先、問い合わせ時に必要な情報は何か

セキュリティ要件は「安全にする」の一文で済ませず、検証項目へ落とす必要があります。 NISTのSecure Software Development Frameworkは、セキュアな設計、コードのレビューと分析、実行コードのテスト、リリース後の脆弱性対応を、ソフトウェア開発へ組み込む実践として整理しています。 Webアプリケーションで具体的な確認項目が必要なら、OWASP Application Security Verification Standardを要求と検証の基準にできます。

「月次レポートを追加して」では何が決まっていないのか

「月次レポートを追加して」という依頼から、AIはそれらしい画面や集計処理を作れます。 しかし、画面が動くことと、月次業務が成立することは別です。

実装前に、少なくとも次の判断が必要です。

• 対象は経営者、経理担当、各部門長のうち誰か
• 月の境界はどのタイムゾーンで判定するか
• 売上日は注文日、決済日、出荷日、入金日のどれか
• 取消、全額返金、一部返金、翌月訂正をどの月へ反映するか
• 集計値を誰が確定でき、確定後に誰が再計算できるか
• 元データの変更と集計結果の変更を監査できる必要があるか
• 集計失敗、データ欠損、重複計上をどのように検知して知らせるか
• 過去の帳票との一致を、どのデータで確認するか

これらは、プログラミング言語の知識だけでは決まりません。 会計や契約、社内運用に関わるものは、事業責任者や業務担当者の判断が必要です。 仕様を書けるエンジニアは、答えを勝手に作りません。 役割は 実装前に必要な問いを見つけ、決定者が答えられる形へ整えることです。

使える仕様かどうかは、粒度で判断する

仕様は細かいほどよいわけではありません。 実務で使いやすい目安は、「一つの利用目的と、一つの受け入れ判断を扱う単位」になっていることです。 独立してリリース可否を判断できる機能が複数入っているなら、仕様を分けます。

粗すぎる仕様には、次の兆候があります。

• 「適切に」「必要に応じて」「高速に」「分かりやすく」など、判定者によって意味が変わる言葉が多い
• 利用者が一人に定まらず、異なる権限や目的が一つに混ざっている
• 正常系だけがあり、権限不足、データなし、重複、失敗時の扱いがない
• 完了条件が画面の存在や実装作業の終了になっている
• 未決事項があるのに、仮定なのか決定済みなのか区別されていない

細かすぎる仕様にも兆候があります。

• 技術選定前からクラス名、関数名、ライブラリ名を固定している
• 実装コードを読めば分かる内部手順を、別の文章で重複管理している

AIへ大量の資料を渡せば精度が上がるとは限りません。 Anthropicのコンテキストエンジニアリングに関する公式ガイドも、有限なコンテキストから高い信号を持つ最小限の情報集合を見つけることを重視しています。 社内での実践方法はコンテキストエンジニアリングの解説にもまとめています。 仕様の品質は文字数ではなく、判断に必要な情報の密度で見るべきです。

よくある失敗は「書かないこと」以外にもある

一つ目は、仕様が実装指示書になってしまうことです。 最初から技術や内部構造を固定すると、より安全で単純な実装案をAIやエンジニアが提案できません。 事業が決める「何を満たすか」と、開発が決める「どう満たすか」を分けます。

二つ目は、正常系だけを書いて完成とすることです。 業務システムで手戻りになりやすいのは、権限不足、取消、重複、締め後の訂正、外部サービス停止といった境界条件です。 過去の障害や問い合わせを見て、頻出する例外から仕様へ戻します。

三つ目は、用語の定義を省くことです。 「売上」「会員」「解約」「有効」のような日常語ほど、部署や画面によって意味が違います。 一つの仕様の中で使う意味を短く定義し、既存のマスタや規程が正なら参照先を示します。

四つ目は、すべてを必須要件として並べることです。 優先順位がないと、納期やコストに制約が出たときに、実装者が重要度を推測することになります。 必須、推奨、対象外を分け、何を守るために何を諦められるかを決めます。

五つ目は、AIに仕様の作成まで任せ、人間が承認しないことです。 AIは質問、矛盾候補、テストケースの案を出せますが、事業上の正しさや損失の許容範囲は決められません。 AIが整えた文書ほど完成品に見えるため、決定者、根拠、未決事項を人間が確認する工程が必要です。

六つ目は、実装中に判明した事実を仕様へ戻さないことです。 仕様とコードが食い違ったとき、常にコードを正とすると、次回のAIも古い前提を読みます。 仕様変更なのか実装不備なのかを判定し、変更理由と一緒に更新します。

仕様を書ける人は、経営と開発の翻訳者になる

経営は投資の成果とリスクを見て、事業部門は顧客価値と業務ルールを知り、開発は実現可能性と保守コストを判断します。 仕様を書けるエンジニアは、この三者の答えを一つの文書へ集める翻訳者です。

ただし、すべての責任をその人へ集めてはいけません。 役割は次のように分けると運用しやすくなります。

若手は担当範囲の前提と完了条件を言語化し、ベテランは暗黙知をチームやAIが再利用できる形へ外出しします。 PMだけに仕様を書かせるのではなく、各エンジニアが問いを立て、責任者が判断する分担へ変えることが重要です。

AIは仕様の「決定者」ではなく「査読者」として使う

AIは仕様を書く力を代替するより、仕様の査読を補助する用途で使うと安定します。 たとえば、次の仕事は任せやすい領域です。

• 曖昧な言葉、未定義の用語、矛盾している条件を指摘する
• 正常系から、権限不足、データなし、重複、失敗時の質問を作る
• 受け入れ条件からテストケース候補を作る
• 仕様、実装計画、タスク、テストの間に抜けがないかを比較する
• 変更前後の差分から、影響を受ける利用者や運用を列挙する

最終承認は人間が行います。 この分担をワークフローとして導入したい場合は、GitHub Spec Kitの仕組みが参考になります。

組織に仕様を書く型を入れる打ち手の順序

最初にやるのは、新しいテンプレートの配布ではありません。 直近の手戻り、障害、受け入れ差し戻しを集め、「実装前に何が決まっていれば防げたか」を分類します。 自社で実際に抜けた判断から始めると、仕様が形式的な書類になりにくくなります。

次に、業務ルールと例外がある一つの機能を選び、最小のひな型を試します。 目的、対象外、利用者、用語、正常系、例外、受け入れ条件、必要な非機能要件、未決事項と決定者があれば十分です。 すべての欄を必須にせず、「該当なし」を許しつつ、空欄との違いを明確にします。

そのうえで、実装開始の条件を決めます。 重大な未決事項に決定者が付いていること、受け入れ条件が観察可能であること、権限とデータの扱いが確認されていることを、レビューの入口に置きます。 仕様を完璧にするためのゲートではなく、危険な推測を実装へ流さないためのゲートです。

最後に、レビューで繰り返し聞かれた質問だけをひな型へ追加し、使われなかった欄は削ります。 仕様作成にかかった時間だけでなく、仕様不足による手戻り、実装開始後の受け入れ条件変更、確認待ち、障害や問い合わせの変化を見ます。 文書量が増えたかではなく、意思決定と検証が早くなったかで型を評価します。

AIへ渡す前のチェックリスト

• 解決する業務と利用者を一文で説明できるか
• 今回の対象外を明記したか
• 用語、計算、状態、締め、取消の意味を関係者で共有したか
• 正常系だけでなく、権限不足、データなし、重複、失敗時を書いたか
• 受け入れ条件が外から観察できる結果になっているか
• 性能、権限、監査、移行、復旧のうち、損失が大きいものを選んだか
• 仮定、決定済み、未決事項を区別したか
• 未決事項ごとに決定者を置いたか
• 仕様変更の理由をコードと同じ変更履歴から追えるか
• AIが補った箇所を人間が承認したか

すべてにチェックが付くまで実装を止める、という意味ではありません。 付かない項目を認識し、そのリスクを誰が引き受けるかを決めてから進むための一覧です。

仕様を書く人が、開発の速度を決める

• 実装が速くなるほど、曖昧さを決める力の価値が上がる：AIが増やす速度を、正しい方向へ向ける必要があります
• 仕様は三層で考える：事業、振る舞い、品質と運用を分けると、決定者と抜けが見えます
• 受け入れ条件は観察可能にする：完了を印象ではなく、振る舞いと検証結果で判断します
• 未決事項を隠さない：AIに推測させず、決定者へ返せる状態を作ります
• 型は手戻りから作る：長い標準文書ではなく、自社で繰り返す判断の抜けを減らします

「月次レポート」の六文字では、月次業務は動きません。 一方で、分厚い仕様書を作ること自体も事業成果ではありません。 何を決めれば安全に実装へ進めるかを書ける人を中核に置くことが、AIと人間の速度をそろえる組織設計になります。