ソフトウェアファクトリパターンを試す
Trying the Software Factory Pattern (lethain.com)
要約
AIエコシステムにおける新しい開発パターンの急速な進化に対応するため、著者は「ソフトウェアファクトリパターン」の導入を試みています。これは、プロジェクトの目標定義、測定指標、タスク管理システム（Linear）などを監査し、必要に応じてそれらを整備・更新しながら、エージェントが自律的に目標達成に向けて進捗する仕組みです。このパターンは、プロジェクトの全体像を把握し、見落としがちな状態を認識するのに役立ち、複数のツールやシステムが連携することでその効果が最大化されると述べています。
全文翻訳
ソフトウェアファクトリパターンを試す。
2026年のAIエコシステムにおける興味深い課題の1つは、新しい効果的なパターンが私の吸収できるよりも速く登場することです。いくつかを見つけて仕事に戻ると、1ヶ月後にさらに4つか5つを見逃していたことに気づくでしょう。今年のImprintの採用サイクルは、おおよそ以下のようでした。
- 1月：すべてのエンジニアに毎日Claude Codeを使わせる
- 3月：よし、他の全員にも毎日Claude CodeまたはClaude Coworkを使わせよう
- 4月：ローカル開発はチェックアウトとワークツリーモデルでボトルネックになっている。代わりに、各リポジトリの独立したチェックアウトを持つ約10個のローカルワークスペースを作成し、リポジトリレベルではなくワークスペースレベルで動作させ、フロントエンド、バックエンド、インフラストラクチャ、データモノレポを横断するクロスリポジトリプルリクエストを生成できるようにする
- 6月：おや、エージェント駆動開発は、Jiraよりも可視性が高く、権限の複雑さが少ない共通のタスク管理システムがないことで大きく制約されている。そこで、会社全体をLinearに移行し、Jiraを完全に停止しよう
- 7月：うわー、これでこれらのチケットすべてに可視性が得られたが、多くは些細なものだ。しかし、ローカル開発でそれらを管理するのはスケールしない。そこで、内部的に「Agent Fleet」と呼ぶオーケストレーションされたハーネスを展開しよう。これはStripeのMinionsに似ている。
私にとっての最新の課題は、ソフトウェアファクトリパターンをどのように採用するかを理解することでした。（軽い調査の後、この用語の特定のAIコンテキストにおける起源を特定するのは少し厄介ですが、おそらく2026年2月のJustin McCarthyによるSoftware Factories And The Agentic Momentが元になっていると思います。）
ソフトウェアファクトリパターンとは、広範な目標に対してループし、その目標に向けた進捗を推進するためにハーネスに依存することです。私たちの最初の実装はかなり基本的です。
-
Linearプロジェクトを読み込み、そのプロジェクトの目標定義を以下の次元で監査することから始めるエージェントスキル
/linear-project-loop：- プロジェクトの目標、それらの目標がどのように測定されるか、および一般的なアプローチを説明するNotionのRFC
- それらの目標に対する進捗を測定するDatadogダッシュボードまたはSnowflakeクエリ
これらが欠落している場合、またはLinearプロジェクト全体が欠落している場合、欠落しているツールを作成するためにあなたと反復します。
-
次に、プロジェクトのメトリクスと課題の状態を確認します。新しい作業が特定された場合、それらの課題をプロジェクトに追加します。移動した課題の状態を更新します。
-
プロジェクトの現在の状態に基づいて、ブロックされていないタスクに取り組みます。これは、プルリクエストを作成する、プルリクエストを更新する、レビューを依頼する、明確化の質問をするなどであることがよくあります。
-
タスクが完了すると、プロジェクトの説明が最新であれば、次のタスクに取り組みます。説明がしばらく更新されていない場合は、最初のステップからループを再実行します。
現在、これをローカルハーネスでローカルに実行していますが、十分に機能しているため、この動作を、ワンオフタスクを実行するために割り当てるのと同じオーケストレーションされたハーネスで駆動するように移行することを予期しています。
私がファクトリパターンで特に気に入っているのは、私がローカルで作業していた方法と非常に似ている一方で、プロジェクトの目標に関して私が誤って状態の一部を自分で抱え込んでいた場所を認識させることです。私はすでにエージェントに特定のLinearプロジェクトの反復処理を依頼していましたが、それらは正しい方向に向かっているかどうか、または必要なタスクが欠けているかどうかを評価する能力がありませんでした。今ではそれができるようになりました。これが私にとって非常に役立ったもう1つの場所は、リリース後のプロジェクトを確認することです。たとえば、今年の初めにパスキーの実装をリリースしましたが、数ヶ月間その進捗を確認していませんでした。採用の急増やエラー率の上昇に気づかないかもしれませんが、より頻度の低いリリース後のモードでファクトリを実行すれば、すぐにそれを検出できます。
私にとって興味深い最後の考えは、これらのすべてのピースが、他のピースを持っている場合にのみ、どの程度まで積み重なるかということです。たとえば、このファクトリパターンは、目標追跡を管理するためにDatadog MCPとSnowflakeへのアクセスが必要ですが、Linearが会社の作業の単一のステートソースであること、およびラップトップから独立して作業を実行できるオーケストレーションされたハーネスに依存していることにも依存しています。これほど多くの移行に追いつくことは、魅力的な業界の瞬間です。