完璧な成果物でも顧客に伝わらない理由
1つ目の違和感は、顧客への「伝わり方」に関するものだ。「設計書が残っていない既存システムのリバース案件で、自社テンプレートをもとにソースコードから設計書をAIで生成していました。AIは、クラス名やメソッド名、ソースの根拠まで網羅された完璧な設計書を出力し、自信を持ってお客様へ提出しましたが、『どこを確認すればよいか、わからない』という困惑の声が返ってきたのです。」と伊達氏は振り返る。
失敗の原因は正確さの欠如ではなく、顧客との関心領域のミスマッチにあった。 AIが出力したのはクラス名やメソッド名など、技術的精度の根拠となる「作り手の情報」であったのに対し、顧客が確認したかったのは業務が正しく成立するかという「受け手の情報（業務サマリーや画面イメージ）」だったのだ。
「正確に書くことと、伝わるように書くことは別問題でした。同じ仕様書でも読者が違えば必要な情報は変わります。誰に向けて書くかは人間が決め、読者ごとの書き分けをAIに担わせる。これが1つ目の気づきでした」と伊達氏は語る。
従来、顧客との対話の中で掴んできた「相手が何を重視して承認するか」というプロセスを、AIのスピードを優先して省いてしまったことが本質的な原因であった。
AIの回答によって探求を止める部下
2つ目の違和感は、部下の「判断」に関するものだ。伊達氏は「AIから『現在のインプットでは実装できません』といった応答が返ってきた際に、それ以上の探求をやめてしまう現場メンバーが増えていました」と語る。
しかし、AIの「できない」は不可能を意味するわけではない。プロンプトの構成や入力情報を工夫し、成功事例をインプットすることで突破できるケースは多い。「AIの『できない』はAIの限界ではなく、こちらの問いの限界です。結果はAIが出せても、なぜその結果になったのかという背景とゴールを握るのが人間の役割です」と伊達氏は強調する。
やりがいを失った現場にあえて組み込んだ「人間のゲート」
3つ目の違和感は、同期からの「やりがい」に対する問いだ。AI駆動開発の設計当初、伊達氏は「作業をAIに任せ、人間はレビューや受け入れテストに専念する」という合理的な役割分担を策定していた。しかし、効率重視の分担により、人間の業務は「AIが出した成果物をひたすら確認する作業」へと化した。「AIのアウトプットを確認するだけの作業は、誰が楽しいのか」という同期からの一言に、伊達氏はハッとさせられたという。
「効率を追い求めるあまり、自ら考える余白を奪っていたのです」と伊達氏は明かす。
そこで、人間が問いを立て、AIがその作業を支え、最終的な意思決定と探索を人間が行う形へ分担を見直した。試行錯誤やアイデアを練るプロセスを人間に戻すことで、仕事への手応えとやりがいを取り戻していくこととなった。
顧客に「伝わらない」、AIの「できない」で立ち止まる、確認作業に「やりがいを感じない」という3つの違和感。一見すると発生場所も対象もバラバラに見えたこれらの問題だが、根本にある原因は一つだった。
「3つとも、根っこはすべて同じでした。それは『自分自身が深く考えることをやめてしまっていた』ということです。AIの利便性に流され、思考の主導権を手放していたことこそが、すべての違和感の正体でした」
この気づきを得た伊達氏は、GitHub ActionsとClaude Codeで構築した全自動パイプラインの工程内に、あえて人間が立ち止まって思考を巡らせる「ゲート（深く考える場）」を明示的に組み込んだ。顧客に伝わる文脈になっているか、AIの「できない」の裏にある背景を考えているか、人間に判断と探索の余白が残されているかを確認するためだ。
AIが担う「作業の正確さ」と、人間が担う「深い思考と判断力」を融合させることこそが、AI時代における理想的な分業の姿であると導き出した。
