先日、SNSで「Webサイトなんて要件定義が終われば、あとは1ヶ月くらいでサクッと作れるでしょ？」と経営層に言われた時、現場のPMやエンジニアはどう打ち返すべきか？というテーマで発信したところ、現場の最前線で戦うプロフェッショナルからリアルな声をいただきました。
- 「サクッと終わらせるには、今から 30 分以内に全ての原稿や素材を出せるんですか？と言いたい」
- 「大体、頼む人は要件定義ができないと思う。Webに限らず」
- 「WBSとディレクトリマップを提示しますかね...。各1ページずつ作りこむとなると工数もかかるのは普通のこと。ご自身の製品商品と比較して、例えば車を一から作ると1 ヶ月でできるか？と問いたい」
どれも現場の痛みを映し出した、あまりにも真っ当な意見です。
しかし、その中でハッとさせられる、ひとつのコメントがありました。
「なんで、打ち返す前提なんだろう」
非常に鋭い視点です。
私たちはなぜ、非エンジニアからの「サクッと作って」という要求に対して、反射的に身構え、感情的に打ち返そうとしてしまうのか。
それは、 「上流の仕様がガタガタなままAIにコードを吐かせたら、内部がスパゲッティコード（技術的負債）になり、最終的に自分がデスマーチを迎える」 ことを、本能的に知っているからです。
AI時代に私たちが向き合うべき相手は、無理解な経営層でも、コードの生産速度でもありません。
「不完全な仕様のまま、AIにコードを量産させてしまう構造のバグ」 です。
本記事では、感情論で「打ち返す」のをやめ、ツールやコードの細部に依存しない 「仕様書の構造化」と「AIによる概念レビュー」というシンプルな引き算の仕組み を使って、仕様の破綻をシステマチックに検知・ブロックするプロセスの設計思想を考えてみたいと思います。
1. 「要件定義できない人」と「AI」が繋がったときの恐怖
「頼む人は要件定義ができない」というコメントは、生成AI全盛の今、最も恐ろしい真実を突いています。
現在のLLM（大規模言語モデル）は、指示された関数単体をそれっぽく書くのは天才的に得意です。しかし、仕様書に未定義の「穴（エッジケースの考慮漏れや、データ構造の矛盾）」がある場合、AIはそれを 「それっぽいコード」で勝手に埋めて出力してしまいます。
これがコードレビューをすり抜け、本番環境でデータ整合性エラーを引き起こす。
つまり、問題の根源は「AIの能力」ではなく、 「AIに渡す前の仕様書の解像度が低いこと」 にあります。
「だったら1 ヶ月でできるハリボテを作ればいいか」と諦めるのは簡単ですが、それではエンジニアとしての市場価値は下がる一方です。
必要なのは、人間が 1 行ずつコードレビューで消耗する前に、 「この仕様書（要件）に対して、この変更コードは本当に整合性が取れているか？」 をAI自身に「審判」として検証させ、構造を満たさないプルリクエストを自動で検知・ブロックする仕組み（品質ゲート）です。
2. 解決アプローチ：仕様とコードを紐付ける「構造化ゲート」
設計思想は、シンプルにいきましょう。
特定のツールや複雑なコードを増やす（足し算）のではなく、開発プロセスの中に「境界線（引き算）」を明確にするだけです。
-
仕様書の一元化
要件定義や仕様は必ずリポジトリ内のテキスト（Markdown等）に集約し、仕様が変わるたびに「コードと同時に」ここを更新することを絶対ルールとする。
-
変更点の抽出
開発者がシステムに変更を加えた際、自動化されたパイプラインを通じて、「最新の仕様書」と「実装の変更差分（diff）」という構造的に重要な 2 点だけを取り出す。
-
AIによる整合性チェック
LLMに対し、この「仕様の定義」と「実装の変更点」をダイレクトに比較させ、仕様の穴・実装者の勝手な解釈・過剰なコードの足し算を検知させる。
ここで重要なのは、技術の細部ではなく 「構造の整合性」 をAIに見せるという設計です。
3. 実装案：AIに「審判」をさせるための構造チェック観点
実際の現場において、AIに渡すのは複雑なプログラムコードではありません。
「仕様と実装の整合性を客観的に判断するための、明確なチェックリスト（構造的観点）」 です。
具体的には、CI（継続的インテグレーション）プロセスの中で、AIに以下のような「観点」をインプットして審判を行わせます。
■ AIに定義する構造的チェック観点
-
【隠れた仕様変更の検知】
仕様書に記述されていない、実装者の勝手な憶測やハルシネーションによる独自の挙動が、コード側に含まれていないか。
-
【必須要件の網羅性チェック】
仕様書で必須とされている例外処理やエッジケースが、実装の都合によってコード側でスキップ（放置）されていないか。
-
【過剰な足し算の排除】
既存の共通コンポーネントやモジュールで代替できるロジックであるにもかかわらず、AIが独自の関数を無駄に量産（密結合化）していないか。
AIはこれらの観点に基づき、「仕様と実装のズレ」をコンマ数秒で検知し、自動的にレビューをブロックして開発者に具体的なフィードバックを返します。
ここで大事なのは、プロンプトの細かな記述テクニックではなく、「どのような構造적モノサシをAIに持たせるか」 というプロセスの設計ではないでしょうか。
4. 「打ち返す」から「構造で対話する」へ
この引き算の仕組みを開発プロセスに組み込んだことで、現場には以下のような劇的な変化が生まれました。
① 仕様の曖昧さが“自動的に”表面化する
AIに丸投げして作られた「仕様書を無視したオレオレコード」が、人間の手を煩わせる前にCIの段階で自動的に弾かれます。これにより、人間同士が感情でぶつかったり、レビューで消耗したりする必要がなくなりました。
② 「打ち返す」から「構造で対話する」文化の醸成
「なんで打ち返す前提なんだろう」という冒頭の問いに対する、これがエンジニア側の本質的なアンサーです。
感情的に要求を突っぱねる（打ち返す）必要はありません。AIが「仕様のこの部分が曖昧なため、コード側でハルシネーション（勝手な実装）が発生しています」と冷徹に指摘してくれるため、エンジニアはビジネス側に対し、「AIを使っても、仕様のバグのせいで自動化ゲートを通過できません。まずはここのロジックを一緒に整理させてください」 と、客観的なデータをベースにして、チームを守るための「建設的な対話」ができるようになりました。
5. ものづくりに想いを込めている人ほど、いま「仕様を決める側」を目指してほしい
ただ言われた通りにコードの文字数を増やすだけの「足し算のプログラミング」は、これからの時代、AIに代替されていくでしょう。
しかし、システム全体の構造を見つめ、不必要なコードや無駄な依存関係を削ぎ落とする「引き算のアーキテクチャ設計」は、どれだけAIが進化しても、人間のエンジニアにしかできない領域です。
そして今、開発現場で本当に求められているのは、AIを使いこなす技術以上に、「そもそも、何を、なぜ作るのか」という仕様を適切に決められる人です。
もしあなたが、AIを使った「サクッと開発」の丸投げに強い違和感や憤りを感じているなら、それはあなたが 「ものづくりに対して、誰よりも強い想いとリスペクトを持っている」 という何よりの証拠です。
自分が愛する「ものづくり」の現場が、不完全な仕様とAIの自動生成によって泥沼の負債に沈んでいくのを、ただ手をこまねいて見ている必要はありません。
ひとつのキャリアの選択肢として、 「仕様を決める側＝PM（プロジェクトマネージャー）」 を目指してみませんか？
「作業者」の殻を破り、仕様を決める打席に立つ。
それこそが、AIにあなたの想いを奪われないための、確実な生存戦略の一つです。
6. 私たちの取り組み
本記事でご紹介した「ドキュメントと実装の歪みを削ぎ落とし、現場の自浄作用を高める設計思想」は、私たちが大規模な受託開発や現場の再生で実践している 「引き算のマネジメント」 の考え方に基づいています。
私たちは、人が大切にされ、エンジニアが本来の価値を発揮できる自走組織への転換を支援しています。
より具体的な「現場の仕組み化」の事例や、チームの自律性を高めるコンピテンシー育成に興味のある方は、ぜひ私たちの寺領領域を覗いてみてください。
エンジニアが使い捨てられず、プロとしての誇りを持って「現場の夜明け」を迎えられる仕組みを、共に創っていきましょう。
