この記事の目的

この記事は、生成AIが普及し始めた2024年において、
statelessすなわち「状態を持たない」というエンジニアリングの概念を、
エンジニアの組織設計にも適用することで、
より高い開発効率を目指そうというものだ。
エンジニア組織を持つ経営者にこそこの可能性を伝えたいと考えている。

インターネットサービスでのstateless

まず手始めに、一般的に言われるstatelessという概念から説明していく。
この単語がよく使われるのは
インターネットサービスのアーキテクチャ(構成)の話であるから、
それについて説明していく。

statelessというのは「状態を持たない」という意味である。
インターネットサービスではサーバーは状態を持たないなど言われる。
これはどういう意味なのだろうか。

素朴に考えると、状態持つよね？

LINEでもGoogleでも、サーバーは自分の情報を返してくれる。
これは、サーバーが自分の情報という状態を持っているからだ。

なのに「サーバーが状態を持たない」のはどうしてなのか、と気になるだろう。
情報は状態とは違うのかな、なんて考えるかもしれない（情報はここでは状態と考えて良い）。

中継地点は状態を持たない

実は、やりとりしているサーバー自体は、自分の情報を持っていない。
状態は、その奥にあるデータベースという場所に格納されている。
サーバーは、データベースの状態をユーザーに伝える中継地点だ。

たくさん処理したいからstatelessにする

LINEでもGoogleでも、
中継地点となるサーバーを増やしたほうが、
たくさんのアクセスを処理できる。
サーバーを増やすためには、それぞれが状態を持たないこと(stateless)が必須だ。

基本的に、各アクセスに対し、中継地点となるサーバーはランダムに割り当てられる。
それぞれのサーバーが状態を持ってしまっていたら、不都合なことが起きる。
例えば、サーバーAは僕の情報を持っているが、
サーバーBは持っていないというとき、
ランダムにサーバーが割り当てられると、
僕の情報がちゃんと得られるかどうかは運になる。
だから、どのサーバーも中継地点としての役割に徹して、
情報自体はデータベースに問い合わせるようにしているのだ。

ということでstatelessとは

「たくさん処理したいから、中継地点には状態を持たないようにしよう」
という考えのこと。
たくさん処理できる仕組みのことを、
「スケーラブルな設計」とか
「スケーラビリティ」と表現したりする。

statelessな開発組織？

ここからが本題である。
開発組織が状態を持つ・持たないというのは何か。

それは「エンジニアが、その開発プロジェクトの詳細を知っている・知らないということだ。

だからstatelessな開発組織というのは、
「エンジニアが、その開発プロジェクトの詳細を知らない」ということだ。

素朴に考えると、知るべきだよね？

エンジニアは開発プロジェクトの詳細を知るべき？
その通りだ。
むしろ、開発プロジェクトに配置されたら真っ先にすることが、
そのプロジェクトの概要、詳細を把握することであるべきである。

把握は一日にして成らず

どのプロジェクトにも、
その概要、詳細を把握することを目的としたドキュメントが書かれている。
通常、それは膨大な量だ。
一度に全部読んでも忘れてしまうし、重要な箇所がわからないから入ってこない。
だから、プロジェクトの詳細をちゃんと把握できるのは、
実際に手を動かして体に馴染んできてからということになる。

生成AIが把握を助ける

これら大量のドキュメントから、
必要な箇所を必要なタイミングで引用して教えてくれると、業務が捗る。
そんな都合のいいツールがあればよいのだが。

はい、まさに。
実に幸運なことに、2024年我々は、生成AIという武器を手にしているのだ。
生成AIは自然言語もプログラミング言語もくまなく読み込むことができ、
問い合わせや回答も人間との対話のような自然な受け答えで行うことができる。
このように生成AIを用いれば、プロジェクトの把握時間を短縮することができる。

Cursor

特に現在、生成AIを前提とした開発ツールがある。
おすすめなのはCursorだ。
これは生成AIを前提としたエディタで、プロジェクトのコードや文書全体を読んで、
それをもとに変更を提案してくれる。

Cursorについては、とりあえず下の動画などが解説しているようだ。

（タイトルだけ見て雑に貼り付けただけなので内容は保証していない)

statelessで人員のスケーラビリティを確保

生成AIはプロジェクト把握時間を短縮化した。

つまり、
エンジニアが、そのプロジェクトの詳細を知らない状態で配属になっても(=stateless)、
生成AIを活用することですぐにプロジェクトを把握して、
業務を実施することが可能なのではないか、ということだ。

これが「statelessな開発組織」の意味するところだ。

属人化 = 中継地点にのみ状態があること

属人化とは、知識・ノウハウが企業に明文化されず
特定の個人の脳だけに留まっている状態を指す。

まさにこれは、中継地点のみに状態があることを指し、
インターネットサービスの例と同様に、スケーラビリティの妨げになる。

すなわち、新たにエンジニアを配属したときに、
そのエンジニアは、特定の個人にのみ溜まっている知識を知らないがゆえに、
開発できない、また開発効率が落ちる、ということがあるのだ。

暗黙知は残る問題

とはいえ、すべてをドキュメント化することは不可能だ。
特に、活発に開発が行われている現場ほど、ドキュメントが追いつかないのは世の常だ。
むしろ古いドキュメントや技術的負債があることは、
逆にビジネス価値が高い開発であることを示しているという言説もあるぐらいだ。

ということで、ドキュメント化されない暗黙知が一部の開発者の脳にとどまる問題は
どうしても生じてしまう。

生成AIがコードから暗黙知を読み取る

この問題も、生成AIなら解決可能と考える。
生成AIは、コード全体から「意図」や「慣習」といった
暗黙知に相当する言語化されないものを読み取ることができる。

例えば、実現方法が複数あるやり方のうち、
何を採用しがちであるか、とか、
変数と呼ばれる名前の付け方の規則とか、
リストに記載する順番の規則とか。

そういった言外のルールも生成AIなら読み取ってくれるのだ。

ということでstatelessな開発組織とは

開発人員の自由な増減を実現可能にするために、
生成AIにドキュメントやコードを読ませることで、
新規に配属となったエンジニアにも容易に開発が進められるような状態のこと。

statelessの対比

	インターネットサービス	開発組織
状態とは	情報	プロジェクトに関する知識
状態格納場所	データベース	ドキュメント、コード
中継地点	Webサーバー	エンジニア
中継地点に状態があると	一貫した値を返せない	属人化問題
statelessにする目的	処理のスケーラビリティ	開発のスケーラビリティ
statelessに必要な技術	(諸説ありそう)	生成AI

どちらもスケーラビリティのために、

状態を一箇所にまとめた構造にしていることと、
中継地点のみに状態がないようにすることが特徴なのだ。

本当に目指せるのか

ここに書いた「statelessな開発組織」はあくまで理想的な状態だ。

実際には、やはり長期にそのプロジェクト全体を理解するシニアエンジニアは
引き続き欠かせないものだろう。

だが、そのシニアエンジニアは、上の表でいうと
もはや中継地点ではなく、状態格納場所としての役割ではないか。

そう考えると、生成AIを駆使すれば、
「状態格納場所」がボトルネックにならない限りにおいて、
中継地点を増やすことはできるのではないか。

実際にやってみている

ちょうど今、我々株式会社CureAppではこれをモデルとした開発体制が始動した。

(社内でstateless開発組織だー！とか言っているわけではない。この概念は私がカッコつけて命名したにすぎない。社内では、横断開発組織と言ってる)

複数のプロジェクトを複数のエンジニアで幅広く扱う体制だ。
これによって、プロジェクト間での繁閑に柔軟に対応することができる。

来年の今頃は、現実のstateless開発組織運用論を語れるようになっていることを願う。