今年の初め、私たち 8090 のチームは、ある大規模組織の請求エンジンを解体しました。それは 1,800 万行の COBOL とアセンブリで構成されており、私たちのエンジニアの一部が生まれる前から蓄積され続けていたものでした。もはや誰も完全には理解していませんでしたが、私たちのソフトウェアファクトリーを活用して、40 日間で 10 万以上の平易な英語のルールにリバースエンジニアリングしました。その作業を終えたとき、なぜ「ソフトウェアファクトリー」という言葉が突然他の誰もが使うようになったのか、その理由がわかりました。
この概念は、企業が求めていながら得られていない、ある種の産業的信頼性を暗示するため、流用されています。ソフトウェアファクトリーには 50 年の歴史があり、その唯一の特徴は、企業がこれまで以上に必要としているもの、つまり「アウトプットを保証する生産システム」です。これは、個人を強化するものの、システム全体をより混沌とさせている、広範なツール群に対する高まる不満とは対照的です。
「ファクトリー」という言葉は、ほとんどの人が思っているより古い
日立は 1969 年に「ソフトウェア工場」を開設しました。これは文字通りの工場で、統計的品質管理のもとでソフトウェアが生産され、欠陥率は 1,000 行あたりで測定され、標準化されたプロセスと、アウトプット品質に責任を持つ管理チームが存在しました。東芝、NEC、富士通も続き、1970 年代から 1980 年代にかけて、これらの日本のソフトウェア工場は、これまでに書かれた中で最も信頼性の高いコードの一部を出荷しました。それらが生み出したシステムは、銀行、鉄道、電力インフラを数十年にわたって動かしました。
2004 年には、マイクロソフトの 2 人のアーキテクトが『Software Factories』という本を出版し、ソフトウェアは自動車のように、実証済みのコンポーネントから、反復可能な生産ラインで、バリエーションは後からのヒロイズムで修正するのではなく、事前の設計で制御されるべきだと主張しました。現在、米空軍はソフトウェアファクトリーを運用しています。Kessel Run は国防総省向けのミッションソフトウェアを構築・運用しており、そのソフトウェアが壊れた場合、彼らが責任を負います。
60 年にわたって、この AI の波が来るまでは、一貫して一つのことが変わっていませんでした。工場は、どんなに優れていても、単なるツールや生産性向上のためのハックではありませんでした。工場とは、インプットを受け取り、完成品を生産し、その品質に責任を持つ生産システムでした。言い換えれば、フォードはあなたにレンチと部品を売って「幸運を祈る」とは言いませんでした。フォードは車を売り、その車が故障した場合、フォードはリコールしました。なぜなら、それを生産したのはフォードの工場だからです。
それが基準であり、現代のソフトウェアファクトリーもそれに準拠すべきだと私は主張します。
5 つのテスト
ソフトウェアファクトリーは 5 つのテストをクリアする必要があります。どれか一つでも欠ければ、それは別のものです。その別のものとは、おそらく開発者ツールであり、便利ではありますが、異なる責任を持つ異なる製品です。
テスト 1：工場はビジネス上の意図から始まる。 工場へのインプットは、ビジネスが必要とするもの、つまりビジネスの言葉で表現された要件、ルール、規制上の制約、望ましい成果です。もしインプットが、エンジニアが別のエンジニアのために書いた Jira チケットであれば、それは既存のプロセスに取り付けられたパワーツールに過ぎません。工場の要点は、顧客が製品を説明し、工場が生産方法を考えることです。
テスト 2：工場は継続的な変化のもとで整合性を維持する。 これは最も難しいテストであり、AI ツール市場のほとんど誰も話題にしないものです。なぜなら、彼らの製品がそれを悪化させているからです。
新しいコードを書くことは、エンタープライズソフトウェアにおいて決してボトルネックではありませんでした。ボトルネックは、実際のシステムが毎週数十人によって変更されることです。すべての変更は、システムが崩れる機会です。要件はドキュメントから乖離し、ドキュメントはコードから乖離し、コードはテストから乖離します。その乖離を 20 年間放置すれば、冒頭で説明した請求エンジンが出来上がります。誰も全体を理解していない 1,800 万行、年率 5～8% で上昇するベンダーとの保守契約、そして、恐れずに自社のソフトウェアを変更できなくなる組織。
現実には、コード生成は乖離を加速させます。もしあなたのエージェントが、同期が取れていない仕様に対して 10 倍のコードを生成すれば、前例のない速度で乖離を誘発することになります。1,800 万行の問題は手作業で 40 年かけて構築されましたが、ガバナンスのないエージェント群はこれを数年で構築するでしょう。
機能するソフトウェアファクトリーは、意図、仕様、コード、テスト、本番動作を、単一の統制されたオブジェクトとして同期させ続けます。要件を変更すればコードも変更されます。コードをホットフィックスすれば要件も更新されます。ベンダーに、このループが実際のシステムで閉じていることを示してもらいましょう。もしそれができなければ、彼らはコード生成を販売しているのです。それは有用ではありますが、別のものです。
テスト 3：工場は特定の個人に依存せずに動作する。 ツールは、それを使う人が優れている場合にのみ優れています。同じコーディングエージェントを 2 人のエンジニアに渡すと、誰がプロンプトを書くか、誰が差分をレビューするか、誰がミスを見つけるかによって、まったく異なるアウトプットが得られます。そのばらつきはツールでは許容されます。しかし、生産システムでは失格です。工場は、誰がシフトに入っているかに関係なく、予測可能な速度と品質で生産すべきです。まさにそれが、日立の統計的制御が保証するように設計されたものです。品質はオペレーターの特性ではなく、ラインの特性として。
工場がこれを達成する方法は、知識が個人ではなくシステムに蓄積されることです。人が入社すると、工場はそれまでに学んだすべてをその人に渡します。人が去っても、何も失われません。ほとんどのエンタープライズソフトウェアはこのテストを壊滅的に失敗します。請求エンジンが判読不能になる理由は、コードが悪いからではありません。コードの理解が人の中にあり、長年にわたって人が入れ替わるからです。その知識がシステムによって決して捕捉されなければ、システムは徐々にブラックボックスになります。
明確にしておきますが、これは人が重要ではないとか、工場に説明責任が不要だという意味ではありません。工場には常に、アウトプットに対して責任を負う特定の人物がいます。ただ、その人物が代替不可能であることに依存してはいけないのです。機能するためにヒーローを必要とするシステムには、説明責任も工場もありません。そこにあるのはヒーローであり、ヒーローはいつか新たな冒険に出かけます。
テスト 4：すべてのアウトプット単位にトレーサビリティがある。 実際の工場では、すべての部品に「ロット番号」があります。何かが故障した場合、生産ラインを遡って、バッチ、機械、シフトまで追跡します。規制業界はソフトウェアにまさにこれを要求しており、それが AI コーディングツールの導入が最も遅れている理由です。「モデルが書いた」というのは、監査人が受け入れる回答ではありません。ソフトウェアファクトリーは、生産自体の副産物として監査証跡を生成します。このルールは この要件 に基づき、この人物 によって承認され、この変更 で実装され、このテスト で検証され、この時間 にデプロイされました。出所は生産ラインに組み込まれていなければならず、後から書かれたドキュメントはカウントされません。
テスト 5：完成品に対して誰かが責任を負う。 これこそが、ソフトウェアファクトリーと開発者ツールを分けるテストです。なぜなら、ほとんどのツールベンダーがこのテストを満たすことを望まないからです。
工場は、自らが責任を持つ製品を出荷します。請求エンジンが請求額を誤って計算したとき、トレーディングシステムが誤った数値を生成したとき、製造検証が不良部品を承認したとき、特定の人物がそれに対して責任を負い、修正し、コストを負担します。私はこれまで多くの AI ツールの契約書を読んできましたが、知的財産権のセクションは何ページにもわたる一方で、説明責任のセクションは通常 1 文であり、その内容は「アウトプットは 現状有姿 で提供され、検証はお客様の責任です」というものです。これは工場としては完全に失格です。
当社のお客様の 1 つである上場健康保険会社は、支払い請求ルールを決定論的な事前フィルターに変換し、従量課金ベンダーに回される請求を 80% 以上削減し、4 年間で 2,000 万ドル以上のコストを回避しました。このような数字は、作業を請け負う側が結果に対して責任を負う場合にのみ達成されます。
ファクトリーではないもの
テストを適用すれば、自らをファクトリーと呼ぶ多くのものは、実際には別のものであることがわかります。
コーディングエージェントは、どんなに優れていてもツールです。エンジニアリングタスクをインプットとして受け取り、コードをアウトプットとして生成し、検証と説明責任のすべてを顧客のエンジニアに転嫁します。それをエージェント群と呼んでも、この事実は変わりません。
エージェントオーケストレーションダッシュボードは、監視ツールです。エージェントの作業を監視しやすくします。
ベンチマークは、ツールの測定ハーネスです。高いスコアは、ベンチマークタスクにおいてツールが優れていることを示します。しかし、人間とエージェントの混成チームによる継続的な変更が 2 年続いた後にシステムが整合性を維持できるかどうかを教えてくれるわけではありません。
なぜ今、定義が重要なのか
ソフトウェアを生産するコストは急落しています。そして、生産コストが急落すると、価値はアウトプットを保証できる者に移行します。これはこれまでのあらゆる産業化プロセスで起こったことであり、AI でも再び起こるでしょう。
「ファクトリー」という言葉に飛びついているスタートアップは、これを本能的に理解しています。しかし、多くのスタートアップは、産業的な生産の信頼性を求める一方で、その信頼性を生み出した責任を受け入れようとしていません。
ですから、デモやベンチマークは無視して、すべてのソフトウェアファクトリーに一つの質問をしましょう。システムが本番で壊れたとき、誰が電話を受けるのですか？
ソフトウェアファクトリーの場合、答えは「私たちが受けます」でなければなりません。
