Agentic Codingが台頭し、AIがコードを書くのが当たり前になりつつある昨今、ITエンジニアの在り方も変化を迫られているように思う。
次の時代に適応する働き方として注目を集めているワークスタイルはやはり「フォワードデプロイドエンジニア（FDE）」だろう。その定義は多岐にわたるが、ざっくり言えば「顧客に深く入り込んで、ニーズに沿ったソリューションを提案し、業務的、技術的にデプロイをやり切るエンジニア」といったところだろうか。組織のコンテクストやプロセスは多様であるため、テクノロジーをそれぞれに最適化して導入する役回りが重要になってくるというのは疑いのないことと思う。(その仕事が新しいものなのかはともかくとして)
しかしながら、逆張り癖のある私は、別の方向性のワークスタイルを考えていて、意識的に取り組んでみている。市場や技術コミュニティの中に繰り返し現れる課題のパターンを見つけて、それをもとに新しい解法を作る。既存の仕組みの組み合わせで解けるならそれを示すし、既存の部品で足りなければ作る。成果物はブログ記事のこともあれば、OSSへの提案のこともあれば、自社サービスへの実装もあり得るだろう。
名前をつけるとしたら、「リバースデプロイドエンジニア」とでも言ったところだろうか。
- リバースデプロイドエンジニアは何をするか
- リバースデプロイドエンジニアは成果物の形式を予断しない
- リバースデプロイドエンジニアとOSS
- リバースデプロイドエンジニアは公開によって検証する
- リバースデプロイドエンジニアとAI
- リバースデプロイドエンジニアが機能する条件
- リバースデプロイドエンジニアの経済的持続性
- まとめ
リバースデプロイドエンジニアは何をするか
リバースデプロイドエンジニアは、複数の企業、コミュニティ、技術領域にまたがって繰り返し発生している問題のパターンを見つける。その問題の技術的な解法を考案し、作って社会に向けて公開する。ここで「作る」は、既存のツールの組み合わせ方を示すことから、まだ存在しないものを新たに設計・実装することまでを含む。
Palantirが確立したフォワードデプロイドエンジニアが、プロダクトを携えて顧客のもとへ出向く「身内→社会」の動きだとすれば、リバースデプロイドエンジニアはその逆で「社会→身内→社会」の動きをする。ここで「身内」は自分自身や自組織を、「社会」は市場やコミュニティを指す。社会から課題を引き受け、身内の中で構造化し、解法を社会に返す。そして、解法を公開する過程で得られるフィードバックや新たな接点が、次の課題の発見に繋がるのだ。
リバースデプロイドエンジニアは成果物の形式を予断しない
リバースデプロイドエンジニアの成果物は固定されない。既存のツールの組み合わせを示すブログ記事かもしれない。サンプルコードやリファレンスアーキテクチャかもしれない。OSSプロジェクトへの提案や実装かもしれない。自社サービスへの機能提案かもしれない。
課題の性質が成果物の形を決めるのであって、逆ではない。より正確に言えば、課題をどの抽象度で切り取るかが成果物の形を決める。同じ課題でも、個別の現場に寄せれば顧客向けのコンサルティングになるし、高く抽象化すれば汎用ライブラリになる。この抽象度の選択自体が、リバースデプロイドエンジニアの判断が難しい部分かもしれない。
技術職は通常、成果物の形式で定義される。コードを書く人、アーキテクチャを設計する人、コンテンツを作る人。リバースデプロイドエンジニアは、ある月はブログ記事を書き、次の月はIssueを書き、その次は開発をする。どの月も同じ思考プロセスの出力であるにもかかわらず、成果物だけを見ると異なる職種の仕事に見える。
そのため、リバースデプロイドエンジニアは職種というよりも姿勢に近い。FDEが組織の中に定義されるロールであるのに対し、こちらは行動原理に近い。両者は完全な対比というよりも、FDEという動きの方向性を逆転させたらどうなるか、という思考実験から生まれた概念だ。ソリューションアーキテクトやデベロッパーアドボケイトの活動と重なる部分も多い。この姿勢を特徴づけるのは、課題を自分で見つけ、パターンとして構造化し、そこから解法を作り出すという一連の思考プロセスだ。課題の構造化は、それ自体が目的ではなく、何を作るべきかを見定めるための工程にある。構造化された課題認識があるからこそ、既存のパターンの適用で済む場面と、新しいものを作るべき場面の判断ができる。
リバースデプロイドエンジニアとOSS
OSSは、身内と社会の中間にある場だと思う。自組織の中でも完全な外でもなく、コミュニティという緩い共同体の中で課題の共有とフィードバックが継続的に行われる。この性質が、リバースデプロイドエンジニアの活動と噛み合う。
まず、OSSの世界では、コミュニティのニーズや課題を自発的に見つけて解く動きが評価される傾向がある。Issueが立つ前に問題を構造化して提案を出す、複数プロジェクトにまたがるペインポイントを抽象化してライブラリにする。こうした動きを受け入れる土壌がある。
次に、OSSへの貢献はコードだけではない。問題の言語化、設計の提案、既存ツールの組み合わせ方のドキュメント。成果物の形式が固定されないリバースデプロイドエンジニアの特徴と噛み合う。
そして、OSSに成果物を公開することは、後述する二つの機能を同時に果たす。コミュニティからのフィードバックを通じて自分の課題認識を検証する場になると同時に、公開されたコードや設計文書がAIの学習データやエージェントの参照情報として蓄積されていく。公開すること自体が、検証とリファレンス供給の両方に繋がる。
リバースデプロイドエンジニアは公開によって検証する
課題のパターンを見つけ、構造化し、解法を作るという一連の工程には、自分の観測範囲の偏りに引きずられるリスクがある。複数の現場で繰り返し発生していると自分が認識している課題が、実は自分の視野の偏りに過ぎない可能性を、誰が指摘するのだろうか。
ここで、成果物を公開すること自体が検証プロセスとして機能する。OSSに提案を出せばコミュニティからレビューが来る。ブログに書けば反応がある。公開を前提とすることで外部の目が入り、課題認識の妥当性や解法の方向性に対するフィードバックが得られる。
ただし、これは能動的にフィードバックを受けに行く姿勢がなければ機能しない。公開して終わりではなく、反応を読み、自分の認識を修正する意思が要る。リバースデプロイドエンジニアにとって、コミュニティとの接点は成果物の配布経路であると同時に、自分の判断を補正する仕組みでもある。
リバースデプロイドエンジニアとAI
AIはリバースデプロイドエンジニアの実践を加速する。課題の調査、設計の検証、プロトタイプの構築、ドキュメントの執筆といった各工程の摩擦をAIが下げたことで、課題の発見から解法の公開までの一連の流れを、従来より速く、広い範囲で回せるようになった。
一方で、逆方向の関係もあるのではないか。AIが良い出力を出すためには、リファレンスが要る。
LLMは学習データやコンテキストとして与えられた情報をもとに出力を生成する。新しい技術やアプローチが記事やコード、設計文書として世に出ることで、それがAIの学習データやエージェントの参照情報になる。リバースデプロイドエンジニアが課題パターンを構造化し、解法を公開する行為は、結果としてAIが参照できるリファレンスを社会に追加する行為でもある。
私はここ数年、Icebergの発信に力を入れてきた。多くのブログやプレゼンを通じて技術情報を発信してきたし、Icebergの専門書の執筆もした。私はGeminiやGPT, Claude, Perplexityなど様々なツールを2023年頃から触っているが、AIたちがIcebergについて話すことは、ここ数年で格段に正しくなった。昔はHive形式のテーブルとの区別がついていないなど、誤った出力が多々見られたが、今では基本的な情報であれば特別なコンテクストを与えなくても正しく答えられるようになってきている。(まだ怪しい部分も多いが...) これは世界中の多くのIcebergコミュニティの人々による発信の成果の賜物であり、自分もその一部に貢献してきたと信じている。
これは既存の技術を発信してリファレンスにした例だが、まだ存在しないアプローチを作って公開することも、同じ構造でAIのリファレンスを拡張する。そして後者にこそ、より大きな意味があるのではないかと考えている。
Redis開発者であるantirezは最近の記事（Don't fall into the anti-AI hype）で、AIによってプログラミングが根本的に変わったことと、その受け止めを語っている。私はこの記事の内容の大部分に同意する。
in general, it is now clear that for most projects, writing the code yourself is no longer sensible, if not to have fun.
参考訳：大半のプロジェクトにおいて、楽しみのためでなければ、自分でコードを書くことはもはや合理的ではない。これは今やはっきりしている。
How do I feel, about all the code I wrote that was ingested by LLMs? I feel great to be part of that, because I see this as a continuation of what I tried to do all my life: democratizing code, systems, knowledge.
参考訳：自分が書いたコードがLLMに取り込まれたことについてどう感じるか？その一部であることを誇りに思う。これは自分が生涯をかけてやろうとしてきたこと――コード、システム、知識の民主化――の延長だと思うからだ。
But what was the fire inside you, when you coded till night to see your project working? It was building. And now you can build more and better, if you find your way to use AI effectively. The fun is still there, untouched.
参考訳：夜通しコードを書いて、プロジェクトが動くのを見届けたときの、あの内なる火は何だったのか？それは「作る」ことだった。そして今、AIを効果的に使う方法を見つければ、もっと多く、もっと良く作れる。楽しさは変わらず、そこにある。
一方で、この記事についたコメントの中に、考えさせられる指摘があった。LLMは本質的に既存の知識の「平均」を出力するエンジンであり、全員が同じオラクルを使えば、ソフトウェアは均質的な「十分に良い」ものの集合になり、「革新的」なものは生まれにくくなるのではないか、という批判だ。
- The Innovation Plateau LLMs are, by definition, engines of the "average." They predict the next token based on the consensus of existing human knowledge. If the entire industry moves toward prompting instead of manual tinkering, we risk an "Innovation Plateau." True breakthroughs—like the unique architecture of Redis itself—often come from a human deviating from the "sensible" path. If we all use the same oracle, our software will become a homogenous soup of "good enough," but rarely "revolutionary."
参考訳：イノベーションの停滞。LLMは定義上、「平均」を生成するエンジンだ。既存の人間の知識の合意に基づいて次のトークンを予測する。業界全体が手作業の試行錯誤からプロンプトへ移行すれば、「イノベーションの停滞」に陥るリスクがある。真のブレイクスルー――Redis自体のユニークなアーキテクチャのような――は、「合理的な」道から逸れた人間から生まれることが多い。全員が同じオラクルを使えば、ソフトウェアは「十分に良い」ものの均質なスープになり、「革新的」なものはめったに生まれなくなるだろう。
この批判には一面の真理があると思う。そしてだからこそ、AIが既存のパターンを高速に適用できるようになるほど、既存のパターンの外に出る動きの価値は相対的に上がると言える。新しいアプローチを試み、それを記事やコードとして公開し、AIが参照できる形にすること。課題の構造化をもとに新しいものを作り、それを公開するというリバースデプロイドエンジニアの動きは、この方向に位置している。
自分自身の取り組みとしては、Icebergの発信を続ける中でOpenSearchコミュニティとの接点が生まれ、そこから新たな課題が見えてきた。Icebergベースのレイクハウスが普及する一方で、AI活用の広がりとともに全文検索やベクトル検索への需要も高まっていることから、レイクハウスのデータに対してこれらの検索機能を簡単に接続できる仕組みが要ると考え、OpenSearchのData PrepperにIceberg CDCソースプラグインのRFCを出してみている。
リバースデプロイドエンジニアが機能する条件
リバースデプロイドエンジニアは万能ではない。機能する領域とそうでない領域がある。
リバースデプロイドエンジニアが機能するのは、課題の構造が複雑で、既存のアプローチでは十分に解けない場合だ。それは複数の技術領域にまたがる課題かもしれないし、特定の分野の中で深い専門性や新しい発想が求められる課題かもしれない。いずれにせよ、課題を正確に定義し直すこと自体に労力が要る領域で、この姿勢は機能する。
解法の形式が事前に確定しない場合も向いている。既存のツールの組み合わせで済むのか、新しいコンポーネントが必要なのか、ドキュメントで十分なのかが、課題を掘り下げるまでわからない。こうした状況では、成果物の形式に紐づいた分業が機能しにくい。
また、課題が一つの組織に閉じず、複数の現場で繰り返し発生している場合。パターンとして汎化して公開することで、対応コストの総量を下げられる領域だ。
一方、リバースデプロイドエンジニアが機能しないのは、問題が明確に定義されていて分業のオーバーヘッドが小さい場合。確定した仕様の高品質な実装が求められる場合や、物理的なスケールが必要な場合も同様だ。
また、課題の発見から解法の公開まで広い範囲をカバーする以上、同時に扱えるテーマの数は限られる。取り組むテーマの選択が決定的に重要になる。
リバースデプロイドエンジニアの経済的持続性
リバースデプロイドエンジニアに対して「誰が対価を払うのか」は難しい問いかもしれない。
成果物が自社プロダクトの市場への提案や、改善であれば、通常の報酬構造の中で成り立つ。市場の課題パターンを見つけて自社サービスの使い方や機能に落とし込む動きは、企業にとって直接的な価値がある。
しかし、成果物がより汎化されたコンセプトを示すブログ記事やOSSコントリビューションなど、公共財として公開されるものである場合は、直接の対価は発生しにくい。ただし、プラットフォーム企業がエコシステム拡大の一環として評価する場合や、OSSでの実績が採用市場やコンサルティングの文脈で換金可能な資本として蓄積されるケースもある。
この姿勢が経済的に成り立つかどうかは、姿勢そのものの問題というよりも、成果物がどこに向かうかによる。自社プロダクトに向かえば通常の雇用で成り立つし、公共財に向かえば間接的な回収経路が必要になる。多くの場合はその混合だろう。後者の経路は、技術的な信用の蓄積があるほど機能しやすいものと思われる。
まとめ
AIは既存のパターンを高速に適用できるが、その外に出るには人間が新しいリファレンスを示す必要がある。課題のパターンを見つけ、構造化し、そこから新しい解法を作って公開する動きは、AIの生産性を享受する側であると同時に、AIが参照する知識を供給する側でもある。
フォワードデプロイドエンジニアは今後ますます必要とされていくだろう。顧客の現場で課題とプロダクトのギャップを埋める仕事の価値は変わらない。一方で、その逆方向、社会から課題を引き受け、解法を社会に返すというワークスタイルにも活路があるのではないかと思っている。当面はそれを模索してみるつもりだ。
