HN 日本語サマリー

← 一覧へ戻る
AI・機械学習

ソフトウェアファクトリパターンを試す

Trying the Software Factory Pattern (lethain.com)

42 pointsby gpi25 コメント

要約

AIエコシステムにおける新しい開発パターンの急速な進化に対応するため、著者は「ソフトウェアファクトリパターン」の導入を試みています。これは、プロジェクトの目標定義、測定指標、タスク管理システム(Linear)などを監査し、必要に応じてそれらを整備・更新しながら、エージェントが自律的に目標達成に向けて進捗する仕組みです。このパターンは、プロジェクトの全体像を把握し、見落としがちな状態を認識するのに役立ち、複数のツールやシステムが連携することでその効果が最大化されると述べています。

全文翻訳

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