最近読んだ本の中にコリン・S・グレイの「現代の戦略」という本がある。
内容としてはクラウゼヴィッツの「戦争論」をベースに、「過去から現代までの戦争には共通かつ不変の原則や諸要素がある」とするもので軍事寄りの内容のもの。
その中で「戦略の下に戦術が存在しているのであり、戦術の下に戦略が存在するのではない」という言がある。
戦術はあくまで手段であり戦略があったうえで選択されるべきものとする考えで、個人的にはかなり考えが近いものだった。
この話が何に関係しているのかというと、昨今話題によく出るLLMとチーム開発も似たようなところがあるのではないかと思ったことがきっかけにある。
昨今ではLLMによって「ゲームが変わった」とか「もうITエンジニアはいらない」というような声も出ているが、実際のところそれは「戦術レベルでの変革」であり「戦略レベルでの変革」ではないだろう。
というのもチーム開発自体の原則というものはLLMの登場によって変わっていないと思えるからだ。
チーム開発(アジャイルにしろ、ウォーターフォールにしろ)では仕様や要件を詰めたりする必要はあるし、人同士のコミュニケーションの問題などもある。つまりLLMで解決できることばかりではない。
またTDDやタスクの見積もり、スクラムのようなチーム全体の動き方に影響を与えるような戦略レベルでの原則のようなもに関してもLLMはカバーできていない。
それにLLMが得意とするのは「入力に対して、それらしい回答を返すこと」であったり、「参考になるコードベースに対して、それらしいコードを書きこむ」などだ。
その出力結果が精度が高いためそのまま利用できることが多いが、必ず使えるというものでもない。
そういったことを考えるとLLMはあくまで戦術レベルでの手段でしかなく、戦略レベルで見ると影響はあまりないと思えてくる。
ただ例外的にコールウェルの「小戦争」やグレイの「現代の戦略」でも言及されているように非対称戦のツールとして使われる場合に関してはLLMは戦略レベルでの影響を持つ可能性はある。
グレイは「現代の戦略」の中で「特殊部隊による工作などにより敵対国家の崩壊というシナリオはありうるかもしれないが、常にうまくいくわけではない」という旨の事を書いていたと思う。
近い事例としてはベトナム戦争を引き合いに出しており、ゲリラ戦で先頭を長引かせ厭戦気分を引き出すということを紹介していたと思う。
これに似たケースとしては「個人開発でのLLM利用により、欲しいツールを作成する」などがそれにあたると思う。
「LLMを使い、少人数で一気に開発を進めることでアウトカムを出す」ということは確かにできる。それによって
だが、結果としてその後の運用や保守、機能拡張といった先々のことまで考えが及んでいない場合は単なる負債となるのではないかと思う。
そういった意味では戦略的見地からLLMを使い、その後をどうしていくのかについて思案する必要があると思う。
またそのことからLLMは戦術でしかないのだろうとも思う。
ただLLMに触れずにいるというのも新しい戦術を学ばないということになるので塩梅を見つつ、触れるべきなんだろう。
ただ戦術レベルでの成果を積み重ねても戦略レベルでの成果とはならないと思う。
なので、戦略と戦術どちらもを学び、それを活かせるようにするのがこれからは必要になるのではないかと思う。
また戦略的な視点と戦術的な視点とを持って、意識して使い分けていくのが今後は大事になるのかなとも思う。