AIがルールを変えつつある中、すべてのエンジニアリングリーダーが次のような同じ疑問の答えを出そうとしています。エンジニアリングチームをどのように組織すべきか。基盤モデルが進化し続ける中、組織はどこに投資すべきか。許容できない運用リスクを招くことなく、エンジニアリングのベロシティをどのように向上させるか。AI拡張型組織とAIネイティブな組織の違いは何か。
AIネイティブなエンジニアリング組織を構築するための確立されたプレイブックはなく、エンジニアリングリーダーが学んだことをオープンに比較する機会もほとんどありません。このような対話は個々の企業内にとどまることが多く、競争のプレッシャーや急速に進化するテクノロジーの影響を受けています。
何千もの組織がデータおよびAI戦略を構築するプラットフォームとして、Snowflakeはこのような対話の場を設ける独自の立場にあります。CTO Circleは、エンジニアリングリーダーが、同じ変革に取り組む同業者から学び、これまでの前提を問い直すための信頼できるフォーラムを提供するために設立されました。サンフランシスコで開催されたSnowflake Summit 2026の期間中に行われたこの初開催のイベントには、金融サービス、電気通信、小売、テクノロジーなど、さまざまな業界から350名以上のCTOが集まり、実践的な教訓を交換しました。
議論は、コーディングアシスタントやモデルの選択にとどまりませんでした。エンジニアリング組織がどのように再設計されているか、本番環境で何が機能しているか、そして長期的な競争優位性を生み出すためにリーダーがどこに投資しているかに焦点が当てられました。議論は、AIネイティブなエンジニアリング組織を構築する意味を定義する次の3つのテーマに収束しました。それは、本番環境でのAIの使用、ベロシティとリスクのバランス、そしてAIに向けたエンジニアリングチームの設計です。
本番環境におけるAI：破綻するものとスケールするもの
多くの組織は、既存のエンジニアリングワークフローにコーディングアシスタントを導入することからAIのジャーニーを始めます。開発者はコードを少し早く書けるようになり、ドキュメントの作成も容易になります。これらの改善は有意義ですが、基盤となるエンジニアリングシステムはほとんど変わりません。
SnowflakeのEngineering担当SVPであるVivek Raghunathanは、AIの導入についてもっと広く考えるようリーダーたちに促しました。Vivekは、AIネイティブなエンジニアリング組織の構築は、経営哲学の転換から始まると主張しました。Snowflakeは、開発者の生産性をエンジニアリングや文化の問題として捉えるのではなく、1つのプロダクトとして扱い始めました。
「開発者を顧客のように扱ったらどうなるか。」この問いが、Snowflake自身のエンジニアリング変革へのアプローチの基盤となりました。チームは、リーダーシップがエンジニアのニーズを把握していると思い込むのではなく、顧客向けプロダクトの構築に使用するのと同じプロダクト管理の原則を適用しました。
開発者にインタビューして作業が遅れる箇所を理解し、ソフトウェア開発ライフサイクル全体における摩擦のポイントをマッピングしました。その後、チームはベースラインとなるメトリクスを確立し、すべての変更の影響を測定するための実験を行いました。このアプローチは、経営陣の明確なスポンサーシップとボトムアップの導入を組み合わせたものでした。これにより、リーダーが期待する働き方ではなく、エンジニアの実際の働き方が改善に反映されるようになりました。
その結果は測定可能なものでした。18か月で、Snowflakeは社内開発者のネットプロモータースコアを30ポイント以上向上させました。その結果、この期間内に満足している開発者と不満を持つ開発者の比率は4対1になりました。さらに重要なことに、この改善により、ソフトウェアをより効率的に提供し、AI機能の進化に伴ってより迅速に適応できるエンジニアリング組織が実現しました。
Vivekはまた、導入だけでは有意義な生産性の向上を促進するには不十分であると説明しました。高いレバレッジは、使用の深さと、大規模なツールの真の習熟から生まれます。Snowflakeでは、そのジャーニーは3つの段階を経て進化してきました。
- 導入：開発者が日々の業務でAIツールを使用する方法を学ぶことから始まる
- 習熟：エンジニアが、常により良い結果を生み出す再現可能なワークフローを発見することで発展する
- 最適化：これらのワークフローが、すべてのエンジニアが恩恵を受けられる組織的な知識になったときに発生する
その一例が、Snowflake社内で開発されたエンジニアリング設計パターンのコレクションです。 初期のAI導入者は、プロンプト技術、計画手法、デバッグアプローチを実験しました。時間の経過とともに、組織は常により良い結果をもたらすパターンを文書化し、エンジニアリング全体で利用できるようにしました。
すべての開発者が同じAIツールにアクセスできましたが、実証済みのワークフローを使用するエンジニアは、ツールの導入初期段階にとどまっているエンジニアよりも常に優れた成果を上げました。競争優位性は、単に別のAIアシスタントを導入することからではなく、成功した働き方を組織化することから生まれました。
このようにワークフローを重視することは、組織がソフトウェア開発そのものについてどのように考えるかを変えることにもなります。AIによってアイデアを機能するソフトウェアに変換するために必要な労力が軽減されるにつれて、誰もがビルダーになります。プロダクトマネージャーは新しいエクスペリエンスのプロトタイプを作成し、デザイナーはコードで直接コンセプトを検証し、ドメインエキスパートは他のペルソナのためにガードレールを追加できます。チームは、プレゼンテーションやドキュメントを通じてアイデアを議論する代わりに、機能するソフトウェアを構築することでそれらを検証できます。コードは、仮説をテストするための最も速い方法になりつつあります。
『The Algorithm』の著者であるJon McNeill氏は、何十年にもわたってエンジニアリング組織を形成してきた前提を再考するようリーダーに促すことで、このテーマをさらに掘り下げました。 企業はテクノロジーから着手し、それを適用する場所を探すことが多すぎます。Jon氏は、成功している組織はその方程式を逆転させていると主張しました。最も重要な少数のビジネス上の制約を特定することから始め、それらの問題を解決することを中心にエンジニアリングシステムを再設計するのです。組織がAIを本番環境に移行するにつれて、成功の尺度は、誰が最も多くのコードを生成するか、または最も多くのトークンを消費するかではなく、誰が最もシンプルで、最も速く、最も効果的なエンジニアリングシステムを構築するかに移っていくでしょう。おそらく、より興味深いリーダーボードは、最も多くのAIコードを生成したり、最も多くのトークンを消費したりするエンジニアで構成されるのではなく、アイデアから本番環境までの間で不要なステップを最も多く排除したエンジニアが含まれるものになるでしょう。
ベロシティの最大化とリスクの抑制
AIがソフトウェア開発ライフサイクル全体に組み込まれるようになるにつれて、エンジニアリングリーダーは2つ目の課題に直面します。開発ベロシティが向上するたびに、信頼性の高いシステムと運用規律の必要性も高まります。最も速く動いている組織は、その両方を可能にするアーキテクチャに投資しています。
Snowflakeのオブザーバビリティビジネスユニット担当ゼネラルマネージャーであるJeremy Burtonは、AIが新たなフェーズに入ったと主張しました。初期段階の実験は本番環境へのデプロイへと移行しつつあり、組織は単発的な技術的成功ではなく、測定可能なビジネス価値を実証することがますます求められています。同時に、AIはまったく新しい運用上の課題をもたらします。AIエージェントはより多くのテレメトリを生成し、より多くのシステムと対話し、ますます複雑化する環境全体に分散された情報を使用して意思決定を行います。 これにより、オブザーバビリティの役割は、インフラストラクチャの監視から、AIシステムが確実に動作するために必要なコンテキストの提供へと変化します。
Jeremyは、より優れたモデルには単により優れたデータが必要であるという、エンタープライズAIにおける最も一般的な前提の1つに異議を唱えました。実際には、AIの有効性はアクセスできるコンテキストに依存します。そのコンテキストは、生のテレメトリをはるかに超えて広がっています。これには、データが何を意味するかを説明するセマンティクス、オントロジーやナレッジグラフを通じて捉えられた関係性、およびシステムを接続するビジネスコンテキストが含まれます。同様に重要なのは、そのコンテキストにどのようにアクセスするかです。AIエージェントが情報を確実に取得してそれに基づいて行動するには、API、CLI、Model Context Protocol（MCP）などの標準化されたインターフェースが必要ですが、エンジニアにはデータをドリルダウンしてAIが生成したインサイトを検証するための直感的な方法が必要です。
豊富なコンテキストとオープンなアクセスを組み合わせることで、切断されたテレメトリは、人間とAIの両方が効果的に推論し、問題をより迅速に調査し、より良い意思決定を行うことができる環境へと変わります。ログ、メトリクス、トレース、運用データ、およびビジネスコンテキストを切断されたシステム全体に保存し続ける組織では、AIが本番環境について正確に推論することが困難になります。代わりに、エンジニアリングテレメトリは、システム間の関係性を理解してクエリできる共通の基盤内に存在するデータとして扱う必要があります。
NetflixのEngineering担当ManagerであるAditya Gaur氏は、自動化された根本原因分析に関する同社の取り組みを通じて、これが実際にどのようなものかを示しました。このプロジェクトはAIイニシアチブとして説明されることが多いものの、その成功はAIそのものよりもデータアーキテクチャに大きく依存していたとAditya氏は説明しました。
AIエージェントを導入する何年も前に、Netflixはシステム全体で断片化されたテレメトリを接続し、オントロジーとナレッジグラフを通じて運用上の関係性をモデリングし、共有コンテキストレイヤーを作成することに投資していました。AIが導入される頃には、その基盤はすでに存在していました。AIエージェントは、切断されたログやダッシュボード全体を検索するのではなく、構造化された運用ナレッジに基づいて推論し、インシデント調査中にはるかに意味のある仮説を生成することができました。
HexのCTOであるCaitlin Colgrove氏は、異なる視点からベロシティにアプローチしました。同氏は、AI時代において速く動くことの意味を再考するようリーダーに促しました。組織には、部分的にAIネイティブである余裕はありません。最終的には、チームがプロダクトを構築し、意思決定を行い、AIを日常業務に組み込む方法を再構築することで、全面的にコミットしなければならない時点に到達します。同氏はこれを「退路を断つ」ことだと表現しました。AIは、ビジネスの運営方法の基盤にならなければなりません。
Hexは当初、生成AIの登場に対応するために、専用のAIプロダクトチームを設立しました。このアプローチは有用な機能を提供した一方で、組織的なボトルネックも生み出しました。Hexは最終的に、中央集権的なAI組織を解散し、すべてのプロダクトチームに責任を分散させました。現在、Hexがプロダクトを迅速に提供し、プロダクト全体にAI機能を組み込んでいるのは、顧客の課題に最も近いエンジニアがオーナーシップを持っているためです。
BarclaysのManaging DirectorであるChris Kozlowski氏は、エンタープライズの視点を議論にもたらし、スピードはガバナンスと信頼が伴って初めて価値を生み出すと強調しました。規制の厳しい環境では、エンジニアリングチームにはイノベーションと制御のどちらかを選択する余裕はありません。
DialpadのEngineering担当SVPであるCorey Burke氏と、project44のEngineering担当VPであるArun Rajamanickam氏は、AIがソフトウェア開発のペースをどのように変えているかについて説明しました。 AIエージェントが機能の大部分を独立して実装できるようになるにつれて、エンジニアがコードの記述に費やす時間は減り、意図の定義、複数のエージェントのオーケストレーション、および結果の検証により多くの時間を費やすようになります。
ベロシティを最大化するには、信頼性を損なうことなくチームが迅速に実験できるエンジニアリングプラットフォームを構築する必要があることを、彼らは強調しました。AIは、顧客の課題を特定してからソリューションを検証するまでの道のりを短縮しますが、それはチームが自信を持って反復できるインフラストラクチャ、共有コンテキスト、運用規律を備えている場合に限られます。
AIに向けたエンジニアリングチームの設計
AIがソフトウェアの構築方法を変えるのであれば、エンジニアリング組織の設計方法も必然的に変わります。それには、新しいチーム構造、新しいリーダーシップモデル、そしてエンジニアがどこで最大の価値を生み出すかについての異なる理解が求められます。
Cerebras SystemsのEVPであるQi Jin氏は、前世代のソフトウェア開発に最適化された組織が、多くの場合、AI導入の最大の障壁になっていると指摘しました。確立されたプロセスや組織の境界は、実証済みの働き方をスケールさせるために設計されたものであり、破壊的なテクノロジーに継続的に適応するためのものではありません。したがって、AIの導入を成功させるには、単に新しいツールを導入する以上のことが必要です。テクノロジーの進化に合わせてチームが新しい機能を迅速に取り入れられるよう、リーダーはオペレーティングモデルを再考する必要があります。
Qi氏は、この変革を「Code Yellow」という概念を通じて説明しました。これは、緊急性を持ち、顧客の課題に焦点を当てて組織の変革を推進するためのフレームワークです。彼の視点は、「有事のマネージャー」に関する自身のエッセイで書かれている、より広範なリーダーシップ哲学と共鳴しています。その中で彼は、急速な破壊的変化の時代には、既存のプロセスを最適化するよりも、意思決定を簡素化し、断固として行動し、確立された規範に進んで挑戦するリーダーが求められると主張しています。
Capital OneのCloud Platforms, Resilience Engineering and Enterprise Architecture担当Managing Vice PresidentであるParvez Naqvi氏は、こうした組織の変化がエンジニア自身の役割をどのように再構築しているかについて詳しく説明しました。AIによって実装が劇的に高速化するにつれ、エンジニアリングの価値は、AIが単独では下せない意思決定へとシフトしています。現在、ソフトウェアデリバリーの主な制約には、計画、アーキテクチャ設計、エンジニアリングの判断が含まれます。
AIが開発ベロシティを劇的に向上させるにつれて、手作業で書かれたコードを中心に発展してきた従来のレビュープロセスは破綻し始めます。シニアエンジニアは、技術的な方向性を定義し、アーキテクチャのパターンを確立することで、ますますレバレッジを生み出すようになっています。また、彼らはシステム設計への関与を深め、エンジニアとAIエージェントの双方がより良い意思決定を行えるようなコンテキストを提供するようになっています。
この進化はまた、開発者プラットフォームとエンジニアリングインフラストラクチャの重要性を高めます。内部ツールやデプロイシステムは、運用の負担を軽減し、チームが反復作業の管理ではなくレジリエンスの高いシステムの設計に集中できるようにするため、戦略的資産となります。より多くのプロダクトマネージャー、デザイナー、ドメインエキスパートがソフトウェア作成に直接貢献するようになるにつれ、エンジニアリング組織は単なるコードの生産者ではなく、品質、アーキテクチャ、オペレーショナルエクセレンスの管理者としての役割を強めています。
CodeRabbitのCEOであるHarjot Gill氏は、AIが開発者体験を根本的にどのように変えているかを共有しました。AIが実装作業の多くを担うようになるにつれ、エンジニアがアイデアをコードに変換する時間は減り、意図の定義、トレードオフの評価、システム設計の形成により多くの時間を費やすようになります。AIを活用したレビューは、エンジニアリングチームが正確性、セキュリティ、保守性を損なうことなくペースを維持するのに役立ちます。
CursorのCOOであるJordan Topoleski氏は、コードが生成された後に何が起こるかに焦点を当てました。AIが開発ベロシティを劇的に向上させるにつれて、コードレビュー、検証、エンジニアリング品質のメンテナンスが新たなボトルネックになります。Jordan氏の視点は、スケールに成功している組織は、より強力なフィードバックループと、AIが生成したソフトウェアが本番環境で確実に使用できるようにするエンジニアリングシステムを構築しているという考えを裏付けるものでした。
これらを総合すると、これらの議論はより広範な変革の方向性を示しています。AIネイティブなエンジニアリングは、組織がより良いソフトウェア構築方法をどれだけ早く学習し、制度化できるかによって定義されます。最も迅速に行動する企業とは、AIのあらゆる新たな進歩を活用するために、エンジニアリング組織を継続的に再設計する企業です。
今後の展望：次の展開を形作る対話
1日を通じた対話は、実験段階をはるかに超えて進んだ業界の姿を反映していました。すべての組織が変革のジャーニーにおいて異なる段階にありますが、直面している課題は驚くほど共通しています。参加者からのフィードバックは、CTO Circleに対する私たちのビジョンを裏付けるものでした。エンジニアリングリーダーたちは、同様の意思決定に直面している同業者と率直な対話ができる機会を、一貫して高く評価していました。このイベントが価値あるものとなったのは、エンジニアリングリーダーたちが他ではめったにできない率直な対話を行う機会を得られたからです。
業界を横断するSnowflake独自の視点により、同様の課題に直面している組織をまとめることができました。これにより、美化された成功事例ではなく、実践的な教訓を共有するための信頼できるフォーラムを構築することができました。
AIネイティブなエンジニアリングのプレイブックは、まだ執筆途中です。モデルの改善が続き、それに伴ってエンジニアリングの実践が進化するにつれて、これらの要点はさらに重要性を増すでしょう。私たちは今後も、Snowflake自身の変革の深掘りを含め、AIネイティブな組織を構築しているエンジニアリングリーダーからの実践的な教訓を共有していきます。これらの対話が、皆様の組織が直面している課題と共鳴するものであれば、次世代のエンジニアリング組織を構築するために何が必要かを探求し続ける最新のポッドキャストをぜひご確認ください。
