委任戦術で AI 時代に対処する
ソフトウェア開発における課題の解が他の分野にすでにあるのでは？軍事編。
戦場の霧🔗
軍事の文脈で、情報の不完全性や、情報を更新する必要のある状況を指して言うらしい。
クラウゼヴィッツが提唱しているので約 200 年前にはあった概念。
戦における判断をする場合、ざっと次の情報が必要となる。
- 戦場
- 地形
- 移動経路
- 天候
- その他状況
- 敵状
- 戦力
- 布陣
- 意図
- 戦略目標と言っても良いかもしれない
クラウゼヴィッツの時代にはこれらは斥候など出して獲得したり、前線からの伝達によってはじめてわかるものだった。
現在は衛星写真やドローンなどによってこれらはリアルタイムでわかるし、情報をつなぎ合わせて判断するコストも低くなっているようだ。が、逆にセンサー群をだまして誤った情報を与えるなど、技術とその使いこなしによって敵方にとっての情報の不完全性を作り出す方向に発展しているらしい。
ソフトウェア開発においてよく議論される、見積もりにおける不確実性コーンは情報の不完全性がプロジェクト進行に伴って解決されていくことを示している。まさに戦場の霧が広い、もしくは濃いために正確な判断ができない状況が、接敵によって様々な情報を得ることで霧が晴れていくのに対応する。本質的な複雑性はやってみてわかることが多いし、本番での多様な状況は Observability ツールによって可視化されたりしている。
委任戦術🔗
時代が降って、戦場の広域化によって中央による状況把握がそもそもできなくなる、つまり戦場の霧が広がると、実行部隊それぞれに判断の裁量を持たせるしかない、となる。
これを委任戦術や訓令戦術と呼ぶ。大モルトケによって提唱された概念が第一次世界大戦前後で Auftragstaktik という語にまとめられたらしい。が、いろんな意味を一語にまとめすぎて訳が難しい言葉のようで、様々な訳語がある。
訓令というのは大枠の命令のことで、達成すべき目標やその理由、任務が全体の中で果たす役割を指す。これらの伝達までをしっかりとやったあと、実行は現場に委任する、というものだ。こうすることで任務の大切さがわかる上に、想定外の状況が起きたときに目標に照らして動き方を変えられる。
古くから戦場ではこういったことがなされてきた場面もあったはずだが、大モルトケによって戦術として明文化されたのが 1869 年なので、 150 年ちょっと前。意外と新しい。
ソフトウェアエンジニアに対してマイクロマネジメントがスケールしないのと同じで、いまこういう課題があって、こういうことがやりたくて、というあたりを共有したら設計から悩んでもらう、ということと対応する。
意図共有のオペレーション化🔗
現在の軍では意図の明文化が MUST として制度化され、オペレーションとして定義されているらしい。 5 paragraph order というのが有名。
- Situation
- Mission
- Execution
- Administration / Logistics
- Command / Signal
Commander’s Intent 、つまり指揮官の意図がきちんとテンプレに入っている。
また、これらはすべて揃わないと不備となる、というのが仕組みとして優れているところ。意図の外部化を個人の意志力に依存させない。
最近話題の Intent debt 解消のために意図を記載したドキュメントを整備するのはまさにここらへん。
ドクトリン🔗
5 paragraph order で細かいところまで伝えきれるかと言うとそうではなく、事前にその組織における用語や判断基準、考え方などが共有されているからこれで十分ということになっている。コミュニケーションのためのプロトコルや判断基準を事前にみんな学んでいる。ある程度までは同じ結論に達するし、速度が優先される場合は非常に合理的なやりかた。
ソフトウェア開発でもチームによって判断軸が異なる。テストのないコードはマージしないとか、中央集権的に処理するか、ワーカーで分散するかのどちらを選ぶかなどなど。 ADR などで明文化されるようになってきたところでもある。
参謀制度🔗
こうなると「どう意図を定めるか？」が重要になる。全部それで決まるわけなので。意図の定め方を仕組み化したものが参謀制度。
すべてを指揮官がやるとなると膨大な量の情報をさばきながら大局的な判断をしなければならないので、実質不可能。情報分析や作戦立案などを専門スキルとして身につけた人間も一緒に作戦を立てることで、こういった課題に対処しているのが参謀制度らしい。
参謀は作戦立案、指揮官はどの作戦でいくかの決定。こうすると役割が違うので認知リソースの使い方が異なる。また、ひとりで考えて決断するよりも多様な視点を織り込むことができる。
各ツールの最新の流れを知っていたり、 Observability ツールが示すスコアがどういう意味を持つのか読み解き判断できるなどは専門性だ。異なる専門家がひとつのプロジェクトで目標達成のために議論するというのがまさに参謀制度にあたる。要求がこれならこう設計するよね、アルゴリズムはあれを使うよね、といったあたりを議論によって高めていくが、決定は意思決定者がひとりでやる。
AI 時代への応用🔗
tech lead はメンバーとのチーム目標の共有を徹底し、動き方は任せる。同様にメンバーは coding agent に意図を伝え、課題を解いていく。二段階で委任が走っている。
個人レベルで必要なこと🔗
いままでは委任される側だったメンバーが、委任するスキルを習得しなければならなくなったことが一番の変化だと思う。
意図を適切に coding agent に伝える必要がある。最低限、最終的に欲しいアウトプットとその理由は言語化できるようになったほうがいいだろう。
チームレベルで考えるべきこと🔗
意図が共有できているアクターの数がそのまま戦力となる。ここでのアクターとはエンジニア / coding agent のいずれか。
この文脈ではドクトリンの明文化、つまり組織やチーム共通の CLAUDE.md / AGENTS.md や Agent Skills などのコスパが非常に良い。配布にはまだ様々な課題があるが、ぜひ取り組むとよいだろう。
また、委任戦術の成功に必要なのは次の 2 つ。
- 目的の保持
- 状況認識
これらは相互依存になっている。目的が不明確であれば何を認識すべきかわからず、状況認識できていなければ目的の妥当かどうかわからない。目的の保持は入念なオンボーディングでなんとかなるが、後者はかなりの部分で経験がものを言う。
経験値という希少リソースをどう割り振るかが作戦立案時の観点として重要かもしれない。 tech lead は誰にどういうタスクをお願いするか、メンバーは coding agent に委任する部分と自分で学ぶ部分を切り分けるなど。
今後に期待だが🔗
意図が明文化されていれば未来の coding agent が最低限のメンテナンスはやってくれるかもしれない。というか Opus が並列で C compiler を実装したという実績もあるので、きちんと意図を示せていれば実行するタイミングによって、そのとき最も効率的なシステムを組んでくれる可能性もある。ただし、 C compiler の仕様は複雑すぎて意図よりもう一段細かい命令と解釈したほうが良い気がする。
これらが実現すると、チームという実行単位を保持する必要性が薄れてくる。が、現時点でわからない以上、まだ両にらみで動くべきところだと思っている。しばらくはチームメンバーと議論しながらバス係数とチーム練度向上に努めつつ、 coding agent の使い方に習熟するべき、ということだ。