インタビュー
Jeremy Freeman, Allstacksの共同創設者兼CTO – インタビューシリーズ
Jeremy Freeman、Allstacksの共同創設者兼CTOは、ソフトウェアエンジニア、テクノロジーアーキテクト、起業家であり、キャリアはソフトウェア開発、ハードウェアエンジニアリング、マシンラーニング、製品イノベーションにわたる。2017年にAllstacksを共同創設して以来、彼は会社のコアプラットフォームのアーキテクチャと開発を主導し、予測分析とAI駆動の予測を通じてソフトウェアデリバリーマネジメントを変革してきた。Allstacks以前は、Ravioli LabsとCertiRxでリーダーシップ役割を果たし、ソフトウェアエンジニアリング、研究、反対象テクノロジー、製品開発に携わっていた。彼のキャリアの初期には、スタートアップ、企業テクノロジー企業、アカデミアを渡り歩き、ウェイク・テクニカル・コミュニティ・カレッジでウェブ開発を教えるなど、幅広い経験を積んだ。彼の技術的背景は、組み込みシステム、ハードウェア設計、大規模ソフトウェアプラットフォーム、マシンラーニング、エンジニアリングリーダーシップにわたり、データ駆動型製品を構築するためのユニークな視点を提供している。
Allstacksは、ソフトウェアエンジニアリングインテリジェンスとバリューストリームマネジメントプラットフォームであり、組織がソフトウェア開発の予測可能性と効率性を向上させるのに役立つ。プラットフォームは、プロジェクトマネジメント、ソースコントロール、デプロイスシステムなど、ソフトウェア開発ライフサイクル全体で使用されるツールからのデータを統合し、AIとマシンラーニングを適用してリスクを特定し、デリバリ成果を予測し、実行可能な洞察を表面化する。エンジニアリングと製品リーダーにプロジェクトヘルス、チームパフォーマンス、開発トレンドに関する可視性を提供することで、Allstacksは組織がより情報に基づいた決定を下し、デリバリ不確実性を軽減し、エンジニアリング努力をビジネス目標に適合させることができる。同社のテクノロジーは、直感に基づく計画を超えて、リアルタイムの運用データを利用してソフトウェアデリバリパフォーマンスと戦略的実行を向上させることを目的として設計されている。
あなたは、機械学習をソフトウェア開発データに適用する研究およびエンジニアリングチームをリードするというユニークな経歴を持ち、2017年にAllstacksを共同創設しました。最終的に会社を構築することを決めたのは、どのような具体的なギャップや反復的な問題があなたに観察されたのでしょうか。
Allstacksを開始したとき、私たちは最初に多くの時間を顧客発見に費やしました。顧客ごとに一貫したパターンが現れました。会社ごとに大量のデータがありながらも、実際に何が起こっているのかがわからないという問題が存在していました。ソフトウェアのデリバリーは、部屋にいる最も賢い人たちがいても予測できないものでした。その問題は解決されていませんでした。
すぐに明らかになったのは、この問題が報告問題や統合問題ではなく、関係性の問題であるということだった。何かがリスクにあるかどうかを判断するには、作業アイテムがブランチに接続されている方法、ブランチがPRに接続されている方法、PRがスプリント目標に接続されている方法、スプリント目標がビジネスイニシアチブに接続されている方法を知る必要がある。標準ツールチェーンでは、デフォルトでそのグラフは存在しません。グラフを構築する必要があります。そして、グラフをうまく構築することは本質的に推論問題であり、そこで機械学習の背景が直接役に立ちます。
私たちの目標は最初から、個々の開発者の特定の機能の速度を上げることではありませんでした。全体の組織を改善することであり、エンジニアリング努力をビジネス成果に合わせる方法を見つけることでした。エンジニアリング努力をビジネスに真正に奉仕させる方法を見つけるには、データ関係をよりよく理解する必要があります。そうした質問が、私たちが行ったほぼすべての製品決定を推進してきました。
Allstacksは、ソフトウェア開発ライフサイクル全体にわたるデータを分析しています。デリバリリスクを早期に特定する上で、どのような種類のシグナルまたはパターンが最も予測的であると思われますか。
私は、単一のメトリクスセットが良いものと悪いものを予測するのではなく、さまざまなフェーズや組織タイプに応じたパターンがあると考えています。私がより役に立つと考えるのは、エンジニアリング組織が改善の季節を経験することを認識することです。この月はデータベースパフォーマンスです。次の月はチーム間のコミュニケーションです。次に、「なぜPRを閉じることができないのか」ということです。次に、観測可能性です。エンジニアリングリーダーとして、あなたは診断、監視、ノイズの多い多くのシグナルに浸り込んでいます。
役に立つのは、実際に見ている問題から始めることです。もし「あなたは去年よりも少ないことをデリバリーしているように感じる」のような質問をしているなら、それが正しい出発点です。その後、私は3種類のメトリクスが必要だと考えています。まず、問題が実在するかどうかを判断する方法（たとえば、開発者ごとのPR数の時間経過）；二番目に、どのような変更を加え、それらをどのように追跡しているか（たとえば、AI PRレビューアーの採用）；三番目に、問題がビジネスにとってどれほど重要か。直感的に、コードを20パーセント少なく出荷しているように感じるかもしれませんが、実際の話は、QAが今3倍の時間を要している可能性があるということです。問題を正しく解決しているかどうかを判断するには、3つのレンズが必要です。
あなたはヘルスケア、エネルギー、テクノロジーなどの業界で働いてきました。ソフトウェアデリバリーの課題はこれらのセクター間でどのように異なり、Allstacksプラットフォームはどのように形作られましたか。
私は、非純粋なテクノロジー部門での経験を大いに評価しています。SaaS企業では、ソフトウェア自体が目標であるという考えに陥りやすいです。ソフトウェアを直接販売していないビジネスでは、役割はより明確になります。テクノロジーはビジネスをサポートするために存在します。私はしばしば、ビジネスが可能であれば、自分と関わることなくすべてを同じ速度で達成できる選択肢を選ぶだろうと冗談を言います。
その視点は実際に役に立ちます。テクノロジー業界で何をしているのかを文脈化し、多くのテクノロジー論争をその場に戻します。ビジネスは、PythonやGoを使用するかどうかには興味がありません。コードの書き直しにサイクルを費やすことは、実際のリターンがある場所ではありません。
すべての業界で一貫して存在するのは、断片化問題です。業界に関係なく、すべてのエンジニアリング組織には、接続された組織がない多数のツールに散在するデータがあります。詳細は異なります。規制された業界では、計画サイクルが長く、要件の曖昧さに対する耐性が低いため、間違ったものを構築するコストが高くなります。高速度のテクノロジー企業は、隠れた負債をより速く蓄積します。しかし、根本的な故障モードは同じです。チームは何が配信されたかを伝えることができます。何がスリップしたか、どれだけのコストがかかったか、問題が発生する前にリスクがどこにあったかを追跡することはできません。那がAllstacksを構築した方法を形作ったものです。
AIがコーディング自体を加速しながら、他の場所で弱点を露呈するという物語が成長しています。要件、計画、仕様の準備が実際のボトルネックになる理由は何ですか。
私たちはこれを毎日見ています。良いエージェントとその周りの堅固なハーネスがあれば、アイデア、時には顧客の口から直接、数時間でプロダクションまで進むことができます。
その変化が重要なのは、フィードバックループの変化です。コピロットスタイルのツールでは、人間が各提案のループ内にあります。AIが補完を提供し、すぐに受け入れるか拒否することができます。間違っている場合は、すぐに気付きます。悪い提案の爆発半径は1行のコードです。エージェントコーディングは違います。エージェントに目標を与え、作業を分解して実行し、動作するモジュールを提供します。人間がその出力を確認しますが、各ステップではありません。仕様が間違っている場合、エージェントは間違った仕様に基づいて全体の実装を構築し、レビュー時に気付きます。
それは純粋なプラスの側面のように聞こえます。以前のラグタイムが実際に何をしていたのかを認識しないと、ラグタイムが実際の目的を果たしていたことを認識しないと、そこまでではありません。ラグタイムは、賢い人々がレビュー、計画、テスト、アイデアを通じてより優れたシステムを生み出すために、複数のラウンドを実行する時間を提供しました。
現在の誘惑は、すべてを省略してそれをスキップすることです。しかし、エージェントとハーネスはまだフルSDLCに準備ができていません。速度は実際のものです。以前のより遅いステップで発生していた品質ゲートキーピングは、まだ置き換えられていません。那がギャップです。
多くの組織はまだ、時代遅れのメトリクスを使用して生産性を測定しています。AI駆動の開発環境における生産性について、リーダーが基本的に間違っていることは何ですか。
人々は私たちがAllstacksを開始して以来、このトピックについてかなり成熟しています。測定は、実際に重要なものに移行しており、フレームワークはより洗練されてきました。AIはすべてを覆い隠します。
従来のソフトウェア開発は、開発者がビジネスと基礎となるテクノロジーの要件を満たすコードを書く速度によって基本的に制限されていました。そのコストはゼロに近づいています。私たちが向かっているのは、個々の開発者がエージェントのマネージャーであるというものです。そのモデルでは、トークン生成数や開発者時間数に基づくものではなく、別の基盤を持つ生産性の測定方法が必要です。
現在のメトリクスの危険性の1つは、それが実際に起こっていることを隠すことです。シニアエンジニアはAIツールを使用して優位性を蓄積しています。コードベースのコンテキストと、エージェントの出力をステアし、失敗をキャッチするための判断を持っています。キャリアの初期段階のエンジニアは同じコード量を生成しますが、評価できない出力を監査するのにより多くの時間を費やします。集約的な速度は良好かもしれません。シニアエンジニアとジュニアエンジニアの間のギャップは、標準ダッシュボードのどこにも表示されません。最初に尋ねるべき質問は、「どれほど速くなったか」ではなく、「最初から正しかったものが何パーセントだったか」です。
私たちはまだ、正しい測定モデルの業界コンセンサスを持っていませんが、出力の品質とリワーク率、ただし、スループットと採用のみを追跡するのではなく、チームは他のチームよりも優位性を獲得するでしょう。
あなたのプラットフォームは、プロジェクトマネジメントシステムやコードリポジトリなどのツールからのデータを接続します。データソースを統一することはどれほど重要ですか。組織がそうしない場合に何が起こりますか。
Allstacksは、この分野で成功しています。コンテキストグラフを構築し始めたのは、顧客が実際に尋ねている質問に答えるために、すべてのデータを接続する必要があることを認識したからです。
その接続が存在しない場合、エンジニアリングデータに作用するAIは、画像の一部しか見ることができません。プロジェクトマネジメントシステム内のものを分析できます。コードリポジトリ内のものを分析できます。ツール間のブロックされた依存関係に遡ってデリバリ延期を追跡することはできません。なぜなら、その関係はデータ層に存在しないからです。最善の分析が得られるか、自信を持って間違った推奨が行われるか、ガベージインプット、ガベージアウト、モデル品質によって解決されません。最も優れたモデルを生のAPI統合の上に配置していても、データが関係をエンコードしない限り、問題の実際の原因を見逃すことになります。
その接続は基盤です。それが私たちを最初の市場に出現することができた理由です。まだ複製されていない機能です。
AIエージェントが開発ワークフローに組み込まれるにつれて、準備が整っているエンジニアリング組織とそうでない組織はどのように異なりますか。
実際には、それはあまり異なりません。サマーインターンを迎えるのと同じです。強力な自動テストスイート、堅固なドキュメント、成熟したCI/CDパイプライン、エージェントをチームに追加するときと同じガードレールが必要です。
重要なのは、エージェントのルール、エージェントのファイルを定期的に戻って確認することです。最初のパスをしっかり行うことができますが、エージェントの出力をステアし、悪いデフォルトをトレーニングする方法を忘れることは簡単です。たとえば、コミットの前にテストを実行するようにエージェントに指示することは、人間のリマインダーを必要としません。
エンジニアリングリーダーに提案する診断質問は1つです。前のスプリントでエージェントが何を生成したか、どの出力がそのまま受け入れられたか、どの出力が修正されたか、修正努力が集中していたかを私に教えてください。そうであれば、改善するための計器を持っています。そうでない場合は、感覚で飛行しています。
あなたはエンジニアリング作業をビジネス成果と一致させることの重要性を強調しています。組織は実用的かつ測定可能な方法でそのギャップを埋めることができますか。
私は2つの主な失敗モードを見てきました。1つは、エンジニアリングチームを製品にペアリングしていない会社です。多くのチーム構造はレガシーであり、長い間存在しています。1つのチームは3つの異なる製品の1つの部分を所有しているかもしれませんが、別のチームは4つすべてを所有しているかもしれません。エンジニアリング投資は基本的にヘッドカウントに依存しており、チームが製品に一致していない場合、ビジネス期待と現実が乖離していることがわかりにくくなります。
2つ目の失敗モードは、ビジネスに不可視なすべてのエンジニアリング作業を考慮していないことです。ビジネスに不可視なエンジニアリング作業の大きなカテゴリがあります。私の好きな例は、パッケージを更新しておくことです。非技術的なビジネスリーダーは、価値やなぜ継続的に行われているのかを理解するのに苦労することがあります。しかし、投資カテゴリを説明することはできます。そう説明することで、ビジネスリーダーが評価できるトレードオフを示すことができます。
もし販売リーダーが、npmパッケージの更新と取引を終了するための機能のどちらかを選択することを求められたら、機能は常に勝ちます。しかし、「SOCコンプライアンスから外れるか、機能を出荷するか」と説明することで、ビジネスリーダーが評価できる2つのトレードオフを提示することができます。その再構成は全てのゲームです。顧客は、R&D資本化レポートの時間を2/3以上削減することができました。自動的な作業分類によって、手動ではなく、レポートの時間を削減することができました。メカニズムは同じです。接続されたデータは、相関するスプレッドシートを置き換えます。
あなたはハンドソンのエンジニアリングとウェブ開発の教師としての経歴を持っています。AIがコーディングの作業量を増やすにつれて、開発者の役割はどのように進化すると思いますか。
正直に言えば、心配しています。ただ、私は賢い人々がそれを解決することを信じています。
私の心配は実際のものです。新入社員は、コーディングエージェントのない世界でコーディングしたことがない状態で就職市場に参入することになります。教育はそれに追いついていますか。ツールは迅速に進化していますが、高等教育は常にそれに追いついていません。私が注目しているもう1つの変化は、シニアエンジニアとシニア製品担当者の境界が薄れることです。新しいモデルの中で最も成功した実践者は、製品思考に深く投資しているエンジニアです。
価値があるものは、判断力です。問題をエージェントが解決できるように正確に定義する能力、解決策が正しいかどうかを評価する能力、エージェントの出力の微妙な失敗をキャッチする能力です。シニアエンジニアは優位性を蓄積します。エージェントの出力をステアし、どの出力を信頼できるかを知っています。心配は、キャリアの初期段階にある人々のためです。従来の方法で判断力を構築する方法は、コードを多く書き、間違いから学ぶことでした。そのフィードバックループは、業界がまだ完全に理解していない方法で変化しています。
しかし、歴史はある程度の安心感を与えてくれます。コンパイラがアセンブリ開発者を仕事から追い出すだろうと信じていた人々の相当な集団がありました。技術の変化は予測どおりに起こりました。コンパイラに従わなかった開発者に何が起こったのでしょうか。次の10年間で、開発者の総数は増加しました。多くのアセンブリプログラマーは新しい言語を学び、基礎知識のおかげで優れました。私はそのようなパターンが再び発生すると思います。
今後3〜5年を見据えて、AIはソフトウェア開発ライフサイクルをどのように変え、企業はどのような競争上の優位性を得ることができるでしょうか。
私たちは、以前には見られなかった機能アームズレースを見ることになるでしょう。構築するコストがゼロに近づくにつれて、企業、さらには大企業は、新しい制約に直面することになるでしょう。顧客のフィードバックを収集し、品質の高いものを大量に構築し続けることができるかどうかです。
起こらなければならない変化は、構築されるものの基準が上がる必要があるということです。現在のほとんどのエンジニアリング組織では、単純な制約があります。5つのトップ優先事項があり、2つしか出荷されません。エージェントを使用すると、比率が反転します。5つのトップ、10の次のもの、20の「もしも」のリストがあり、100を出荷することができます。最後の65が、悪く考えられ、悪く実行されていないものでないようにする方法を見つけることができなかった場合、質問は何ですか。
私が3〜5年間でかなり自信を持っている2つのことがあります。1つは、エンジニアリングAIの競争上の優位性がモデル品質ではなく、コンテキストの深さと幅から来ることです。モデルはテーブルステークスになります。すべてのツールに有能なモデルが存在します。リーディングプラットフォームを区別するのは、組織の理解の深さです。リポジトリ、チーム構造、デリバリ履歴、デプロイパターンです。システムを知っているツールは、知らないツールとは根本的に異なる回答を生成します。2つ目は、反応からプロアクティブへの移行です。今日のツールは質問されたときに回答します。数年以内に、リーディングツールは継続的に観察し、質問する前にリスクを表面化します。コンテキストレイヤーを構築している組織は、優位性を蓄積しています。次の世代のツールは、品質の問題を解決する必要があります。最初にそれを解決する組織は、実際の優位性を獲得することになります。
素晴らしいインタビュー、詳しく知りたい読者はAllstacksを訪問してください。
