先日、社内でAIでの開発技法の話をしていた際に
ふと、懐かしい概念を思いだした
GAPS²(gaps of GAPS)というやつだ
要はシステム開発の失敗要因を、ステークホルダー間の知識のズレとして4分類したものが GAPSなのだが
もう、２０年前の話なので知らない人の方が多分、多いから軽く説明しておく
GAPS of GAPSとは何か
うまくいっていないプロジェクトを「理想と現実にギャップがある」で済ませると、性質の違うズレが混ざったままになり、打つ手が当たらない。GAPSは、関係者の間で食い違っている対象を四つに分けたものである。
- Goal Gap：目的のズレ。何のためのプロジェクトかについて、関係者の認識が食い違っている
- Activity Gap：活動のズレ。目的には合意していても、工数を使っている作業がその目的に効いていない
- Process Gap：手順のズレ。関係者それぞれの進め方が噛み合っていない
- Skill Gap：技能のズレ。計画が前提とする技能と、実際に作業する人が持っている技能が食い違っている
四つは並立した診断項目ではない。上のズレが次のズレを生む。何のためかが揃わなければ工数の使い方も揃わず、何を作るかが揺れていれば進め方は各組織の都合だけで決まり、進め方が決まらなければ必要な技能も特定できない。あるズレを埋める手が、別の層に新しいズレを持ち込むこともある。ギャップを埋める行為がまたギャップを生む、この入れ子を GAPS of GAPS と呼ぶ。
実装が速くなったいまのほうが、この見方の使い道は増えている。理由は後半で扱う。先に、四つのズレが実際にどう現れるかを見る。
例として、社内の受発注システムを刷新するプロジェクトを取る。四つの層それぞれについて、以前はそのズレがどう表面化していたかと、コーディングエージェントを入れたあと何が起きるかを対にして書く。対にするのは、変わったのがズレの有無ではなく、ズレの見え方だからである。
目的のズレ
Goal Gap は、そのプロジェクトが何のためにあるのかについて、関係者の認識が食い違っている状態を指す。
キックオフでは全員が「受発注システムの刷新」で合意した。合意したのは言葉であって、目的ではない。経営は運用コストを下げたい。利用部門は、いまの業務のやり方を変えずに処理を速くしたい。開発は、保守が限界に来た基盤を作り直したい。
以前は、このズレが優先順位を決める場で表面化した。作れる量に限りがあったので、何を作って何を諦めるかを決めなければならず、そこで目的の違いが衝突した。衝突は決定を遅らせる。遅れは困るが、同時に、目的がズレていることを教える信号でもあった。
作れる量の制約がなくなると、この衝突が起きない。利用部門は自分たちで生成AIを使って必要なツールを作り、開発は開発で基盤の作り直しを進め、経営は報告される進捗の数字を見る。誰も諦めないので、誰とも対立しない。半年後、似た機能を持つ業務ツールが十数個並び、どれも誰かの目的には合っていて、全体としては統合できない状態になる。
要件定義は遅れなかった。遅れという症状が出ないまま、目的のズレが動くコードとして実体化した。仕様書の分量も問題にならない。生成させれば厚い仕様書が短時間で揃うので、合意したという感触だけが強くなる。
このズレは、成功したときに何が変わっているかを関係者に別々に書いてもらうと出てくる。同じ会議に出ていた三人が、いまも違う文章を書く。
活動のズレ
Activity Gap は、目的には合意していても、実際に投じられている工数がその目的に効いていない状態を指す。
目的を「利用部門の業務時間の削減」で揃えたとする。4か月目に、消化したタスクを目的に照らして分類してみた。工数の6割が、現行画面の見た目と操作感を再現する作業に使われていた。
以前、この種の要望は工数の制約が削っていた。現行の帳票を1画面ずつ再現したいという要望に対して、それは3人月かかるので今回は見送りましょう、という会話が成立した。目的に効かない作業を落としていたのは、判断力である前に、単純に余裕のなさだった。
生成が速くなると、その削る力が働かない。1画面あたり一晩でできるなら、断る理由を説明するほうが面倒になる。要望はそのまま実装され、テストも生成され、カバレッジの数字も悪くない。バーンダウンは以前よりきれいに下がる。
こうして、現行業務の忠実な写しが、以前より短い期間で完成する。利用部門の業務時間は削減されない。進捗の指標はすべて健全なので、リリース後に効果を問われるまで、この状態は誰の目にも問題として映らない。
完了したタスクを目的に紐づけ、紐づかないものの割合を数えると見える。速く作れるようになったチームほど、この割合は上がりやすい。
手順のズレ
Process Gap は、関係者それぞれの進め方が噛み合っていない状態を指す。
以前の構図はこうだった。開発は2週間スプリント、利用部門の受入確認は月末、仕様変更の承認は月次の会議体。この三つはそれぞれの組織にとって合理的で、どこにも怠慢はない。それでも、2週間で作ったものへのフィードバックが返るのは3週間後から7週間後になり、手戻りは常に3スプリント分の大きさで発生した。
コーディングエージェントを入れて変わったのは、この三つのうち一つだけである。生成の周期は1日以下になった。受入確認は月末のままで、承認会議も月次のままだ。周期の比が、以前の1対1.5から、1対20以上に開いた。
差が開くと、確認を待つ分量も同じ比率で増える。現実には、手戻りが起きる前にレビューが破綻する。週に数千行の変更が上がり、読める人が2人しかいなければ、実質的な確認は行われない。
その結果として残るのは、動いてはいるが、書いた人も読んだ人もいないコードである。障害が起きたとき、調査は生成した当人にも他の誰にもできない。振り返りでは「レビュー体制が追いつかなかった」と要約される。実際に起きていたのは、周期の違う三つの手順のうち一つだけを20倍に加速して、直列につないだままにしたことによる破綻である。
作ってから、それでよいと確認されるまでの実測時間を測ると見える。その時間が生成の周期より長い限り、確認されていない分量は増え続ける。
技能のズレ
Skill Gap は、計画が前提としている技能と、実際に作業する人が持っている技能の食い違いを指す。四つのなかで、コーディングエージェントの影響がもっとも大きいのがこの層である。
旧システムからのデータ移行スクリプトを例に取る。以前の見積もりは2人週で、旧データの構造と、そこに溜まった例外的なレコードの由来を知っている人が書くことを前提にしていた。その前提を満たさない要員が割り当てられると、5人週かかり、超過として表面化した。
いまは1日で書ける。生成されたスクリプトは動く。10年前の運用で入った特殊な区分コードを、エージェントは知らないので、素直に変換して通す。移行は完了し、見積もりは超過せず、テストも通る。受注履歴の一部が欠落していることが判明するのは、半年後の監査である。
書く技能のズレは、たしかに埋まった。代わりに現れたのは、出てきたものを評価する技能のズレである。計画が置くべき前提は、旧データの由来を知る人が書くことから、旧データの由来を知る人が結果を確かめることに変わっている。前提が入れ替わったことを明示しない限り、この層のズレは超過としても遅延としても現れず、リリース後に事故として現れる。
症状が出ないまま進む失敗
四つの例には、共通する形がある。
以前は、上流のズレが下流の症状として必ず現れた。決定が遅れる、手戻りが増える、見積もりを超過する。遅れて現れるとはいえ、症状はズレの存在を教えていた。うまくいかなさが、検出装置として働いていた。
コーディングエージェントは、そのうまくいかなさを局所的に解消する。決定は遅れず、実装は間に合い、見積もりは超過しない。ズレは残ったまま、警報だけが止まる。症状から遡ってズレに辿り着く従来のやり方が使えなくなり、四つの層を直接見に行く必要が出てくる。古い見方が、いまのほうが要るというのはこの意味である。
入れ子の構造も、同じ理由で見えにくくなる。確認が追いつかないので、レビュー自体をエージェントに任せることにしたとする。指摘の量は増え、形式的な不備は減る。ただし、何のために作っているかを知らないレビュアーが増えただけなので、目的に効かない実装は目的に効かないまま、より整った形で通過する。手順の詰まりは解消し、目的のズレは一段見えにくくなる。
エージェントはどの層の当事者か
四つのうち、エージェントが技能を肩代わりするのは Skill Gap である。だからといって、残る三つが人間だけの食い違いだということにはならない。
ここまで四つのズレを、関係者の間の食い違いとして定義してきた。その定義に従えば、作業を担う側にエージェントが入った時点で、エージェントは四つすべての片側に立つ当事者になる。何のために作るのかを渡していなければ、指示どおり動いて目的に効かないものが出てくる。やるべき作業を取り違えたまま生成すれば、速く作った分だけ大きな手戻りになる。人間の開発者との間に起きていた Goal Gap と Activity Gap が、相手を変えてそのまま再現する。
違うのは、ズレが表に出る経路である。人間の開発者は、渡された指示に違和感があれば手が止まった。止まること自体が、ズレを知らせる信号だった。エージェントも疑問は返すが、渡した文脈の外にあるものは疑問にすらならない。現場の雑談や、画面を見たときの座りの悪さといった、指示の外から入ってくる情報がないからだ。業務理解の欠落は、止まらないまま出力に反映される。
手順のズレも同じ形で残る。できましたという報告と、実際にできていることの差は、関係者の間で状況が共有されていない状態そのものである。報告が速いぶん、差に気づくのはかえって遅れる。
逆向きにも働く。エージェントは上流のズレを埋める側に回ることもできる。既存のコードから現行の業務ロジックを取り出して文書にする。要件の曖昧な箇所を質問の形で並べる。暗黙の前提を書き出させる。どれも Goal Gap と Activity Gap を縮める作業で、人手でやるには割に合わなかったものだ。
正確に言うとこうなる。エージェントが縮めるのは実装の技能のズレで、代わりに評価の技能のズレが出る。残る三つは消えず、しかも人間だけの問題でもなくなった。当事者が一つ増えた分、食い違いの生まれる場所は増えている。そのうえ速さによって増幅される。ズレたまま作れる量が増え、ズレたまま完成する確率が上がるからだ。
Skill Gap を埋めるために打った手が、他の層に新しいズレを持ち込んでいる。エージェントの導入そのものが、入れ子の構造の一例になっている。
作る速さは上がった。何のために作るかの合意を作る速さは、上がっていない。
AI開発での用い方
分類できただけでは、まだ用いていない。
コーディングエージェントを入れた開発でこの枠を使う場所は、振り返りではない。生成を頼む直前である。いま頼もうとしている作業が、どの層のズレを埋め、どの層に新しいズレを開くかを先に決める。
いちばん多いのは、Skill Gap だけを埋めにいく用い方である。書けないものを書けるようにする。それは正しい。ただし、書く技能のズレが埋まると、評価の技能のズレと、確認が追いつかない手順のズレが同時に開く。入れ子は誤用の結果ではない。下の層に正しく使った結果として起きる。
だから、生成の速さを下の層の埋め方にだけ使わない。何のための実装かを揃える、目的に効かない作業を落とす、確認の周期を生成の周期に合わせる。上の層が開いたまま下だけを埋めると、ズレは完成品として固定される。
では、その決め方を指示文に書いておけば、ズレは起きないのか。
プロンプトでは消えない
起きないようにはできない。
プロンプトが運ぶのは、人間がすでに持っている答えだけである。関係者の目的が揃っていなければ、指示はどちらか一方の目的を、より速く実装する。確認の周期が生成に追いついていなければ、丁寧な指示を増やしても周期の比は開いたままである。評価できる人がいなければ、知らない前提を丁寧に書けと頼んでも、渡されていないものは素直に変換される。
指示でできるのは、ズレを消すことではない。欠けた層を推測で埋めて完成させるのを、拒否させることである。
成功したときに何が変わっているかを指示へ書き、自分の言葉で言い返せなければ実装しない。頼んだ作業が目的に紐づかなければ、速くできる理由だけでは受けない。確認していないことと、評価できないことを、「できた」より先に出す。四つのうち一つでも欠けていれば、下の層を埋めない。
Gaps が起きないプロンプトを目指すこと自体が、入れ子の一例になる。整った指示は合意した感触を強め、ズレた目的をよりきれいな完成品にする。プロンプトで支えるのは予防ではなく、止まって見えることである。
進行中に、その欠けを確かめる順序が次である。
進行中に点検する順序
上の層から順に、次の問いに答えられるかを確かめる。
- このプロジェクトが成功したとき何が変わっているかを、関係者が別々に書いて一致するか
- 直近1か月に完了したタスクのうち、その目的に紐づくものがどれだけあるか
- 生成してから、それでよいと確認されるまでの実測時間が、生成の周期に見合っているか
- 生成されたものを評価できる人が、評価すべき対象ごとにいるか。いないなら、その対象を生成に任せてよいか
答えは、生成を頼むときの指示に入っていなければ、渡していないほうのズレとして再現する。一つでも答えられないものがあれば、下の層を調べる前にそこを埋める。下から埋めても、上がズレていれば、埋めた分はまた別の形でズレる。
かつては、これらの問いに答えなくても、プロジェクトが失敗という形で答えを教えてくれた。いまは、失敗が起きないまま、成果だけが出ない状態が続く。四つの層を自分から見に行くことが、以前より必要になっている。
