いや、それはソフトウェアファクトリーではない — ライアン・クック（WorkOS）

하이라이트

• AIによるコード生成量やPR数などの出力指標は、ソフトウェアファクトリーが実際のエンジニアリング成果や組織価値に貢献しているかを覆い隠すリスクがある

• WorkOSはソフトウェアファクトリーの価値をコード出力ではなく、機能デリバリーの加速や複雑な機能開発の迅速化といった成果（アウトカム）の指標で測定している

• 「TARS」システムはSlack、Linear、GitHubと連携し、コード生成だけでなく依存関係を持つチケットの進行やプロジェクトの進捗追跡を自律的に行う

• 自社構築のMCPゲートウェイ「コンテキストエンジン」を導入し、Snowflakeの製品利用データや開発ツールの使用方法をエージェントに提供することで社内全体のデータアクセスを効率化している

• 製品の安定性を保つため、障害発生率や復旧時間（MTTR）を計測し、外部サービスに依存せず自社インフラ上でサンドボックス環境を所有・改善するアプローチをとっている

타임라인

1. 00:00 - 03:11

   アウトプット指向の指標が抱える問題点

   多くの企業がソフトウェアファクトリーの導入において、生成されたPRの数やコードの移行量といったアウトプットの数値を強調している。しかし、これらの数値は全体のPR量が増えたことを示すだけであり、実際にプロダクトの価値向上につながっているかの判断を難しくする。開発チームの成果を加速させ、複雑な機能を迅速に届けることこそが投資に対する適切な評価軸となる。

   • PRの作成数やAI生成コードの割合といった指標は、開発プロセスの実質的な健全性を反映していない
   • 専任チームを投入する価値を証明するには、単なるコード出力ではなく成果（アウトカム）の計測が必要である
   • ソフトウェアファクトリーの理想型は、各エンジニアに専用の小さな開発チームを提供する状態である
2. 03:11 - 06:26

   プロセス自動化の柱「TARS」と「Horizon」の構造

   単一のサンドボックスでコードモデルを動かす従来の手法では、エンジニアがローカルでAIツールを使う以上の成果は出ない。そこでWorkOSは、開発プロセスそのものを組み込んだ二つのシステムを構築した。TARSはLinear上の依存関係を識別して完了チケットから次のタスクへ自律的に移行し、進捗に伴う計画の不備まで再評価して修正する。

   • 単にクラウド上でコードを生成するだけでは開発効率の指数関数的な向上は得られない
   • TARSはSlack、Linear、GitHubのWebhookを購読し、プロジェクトの進捗と依存チケットを自律的に追跡する
   • Horizonはインフラのオーケストレーションを担い、MCPゲートウェイの前段で機能する
3. 06:26 - 12:00

   仕様書作成とタスク分解の自動化プロセス

   プロダクトマネージャーが存在しないWorkOSでは、エンジニアがPRD（ハルトップ）を作成し、競合分析や初期デザイン、マイルストーンを標準化している。このドキュメント作成作業をPMエージェントが支援し、白紙から執筆するハードルを補う。レビューと承認を経て生成されたタスクや仕様情報は、DevonやローカルのClaude Codeなどの外部ツールにもMCPを介して供給される。

   • 「PMエージェント」が概要メモからPRD（ハルトップドキュメント）のドラフトを作成する
   • ドキュメントの承認状態をWebhookで検知し、自律的に実装チケットへの細分化を開始する
   • エージェントが提供するコンテキストは、DevonやClaude Codeなどの異なる開発ツール間現場でも共有できる
4. 12:00 - 14:06

   「コンテキストエンジン」としてのMCPゲートウェイ活用

   独自構築したMCPゲートウェイ「コンテキストエンジン」は、社内システムのデータ構造や操作手順に関するシステムプロンプトを管理する。データレイクであるSnowflakeと接続することで、エージェントは指示に応じた適切なテーブルクエリを実行できる。開発作業にとどまらず、社内チームがSlack経由でデータ分析を行う際にも強力なレバレッジとなっている。

   • 社内MCPゲートウェイは全社システムと接続し、ツールの利用手順や文脈をエージェントに提供する
   • Snowflake内のプロダクト利用状況データとセマンティックテーブルをエージェントからクエリ可能にしている
   • 開発エージェント用に作成したMCPサーバーが、Slackを経由した社内データ分析の基盤としても機能している
5. 14:06 - 18:39

   インフラ自社所有と自己改善型ファクトリーの展望

   Slackからのバグ報告やサポートリクエストの初期対応にTARSを活用し、コードベースを参照した原因特定を行っている。さらに、自前のサンドボックスインフラと組織全体の文脈を保持するメモリ層を構築することで、システムの安定性指標（障害発生率や復旧時間）を監視している。インフラ内部の動作データを蓄積・学習させることで、時代遅れになった指示（スキル）の特定やファクトリー自体の自己改善を進めている。

   • バグの一次トリアージやPRの作成、顧客サポートの一次対応をTARSで自動化している
   • 外部のサンドボックスサービスから脱却し、自前インフラでセッション情報とメモリ層を管理する
   • インフラデータの計測により、組織に必要なスキルの変化やAIツールの精度向上を継続的に行う