AI 時代に組織はどう変わるか — Jeff Barr が語る開発チームの未来と、三菱電機の挑戦

みなさん、こんにちは。ソリューションアーキテクトの稲田です。

本記事は、三菱電機グループの社内 AWS ユーザーグループ「MAWS（Mitsubishi AWS User Group）」シリーズの第 3 弾です。第 1 弾では一人のエンジニアの小さな行動から 300 人を超えるコミュニティへと成長した誕生ストーリーを、第 2 弾では実務への展開や経営層との対話、次世代への継承といった MAWS の進化をお伝えしました。

2026 年 3 月 6 日、755 名に成長した MAWS のリーダーたちが AWS Tokyo Executive Briefing Center に集まり、AWS VP / Chief Evangelist の Jeff Barr とのセッションが実現しました。Jeff の 23 年間の AWS での経験をもとに、AI 時代における開発組織の変化、生産性のパラダイムシフト、そして人材育成の課題について議論が交わされました。

本記事では、セッションで共有されたインサイトと、MAWS メンバーとの対話から見えてきた AI 時代の組織変革の姿をお伝えします。

コミュニティの原点 — Jeff Barr の原体験

セッションの冒頭、Jeff は自身の原体験を語りました。約 50 年前、Northwest Computer Club というコミュニティに参加していた頃の話です。

そこでは年齢も経歴も関係なく、メンバーとして参加し、つながり、貢献する意志さえあればそれで十分でした。家庭の問題で個人的に困難な時期にあった Jeff にとって、クラブは単なる技術リソースではなく、コミュニティであり、友人そのものだったといいます。

50 年近く経った今も、テクニカルコミュニティの形成と成長を支援することが自身のモチベーションの源泉であり、JAWS-UG や MAWS を通じた活動に深い感謝を示しました。

「現場」から変革を起こす — MAWS と Serendie®

DX イニシアティブ「Serendie」

三菱電機は現在、DX のイニシアティブであるデジタル基盤「Serendie」により、イノベーティブカンパニーへの変革を進めています。従来のビジネスモデルはハードウェア販売によるワンタイムレベニューが中心でしたが、デジタルサービスによるリカーリングレベニューへの転換を推進しています。

この変革には 3 つの挑戦があります。データ活用したサービスの創出を主としたビジネスモデル変革、AI など最新技術をグローバルに展開するためのデジタル基盤強化、そして、課題をクイックに解決するアジャイル開発の加速を主眼としたマインドセット変革です。

重要なのは、この変革がトップダウンだけでなく全メンバーが推進する形で進められている点です。その中で MAWS がキーロールを担っています。

755 名に成長した MAWS

第 1 弾で 300 名だった MAWS のメンバーは、755 名にまで成長しました。活動拠点は横浜、東京、関西エリアに広がっています。

MAWS のコアパーパスは、異なる事業所・事業部をまたいだクロスチームのつながりを促進することです。「周りに AWS に詳しい人がいない」「ジュニアエンジニアには質問しづらい」といった現場の課題に対し、Viva Engage や Teams 等を活用してボランティアが質問対応からトラブルシューティングまで支援する体制を構築しています。異なる事業部のシニアエンジニアが回答者として参加することで、組織の壁を越えた知識共有が実現しています。

コミュニティの成長サイクル

MAWS の運営哲学は、外部コミュニティの「幅広い知識・経験」と社内コミュニティの「メンバーの成長支援」の両方の良いところを組み合わせることにあります。

成長サイクルは明確です。まずエンジニアがコミュニティプログラムに聴講者として参加し、知識と経験を現場に持ち帰る。次のステージでは発表者・登壇者として参加し、その経験を CCoE（Cloud Center of Excellence）に共有する。やがてクラウドアーキテクチャやユースケースを公式組織として事業部門に推奨するようになり、事業部門からさらに多くの人がコミュニティに参加するという好循環が生まれています。

第 2 弾でもお伝えした通り、2025 年 4 月からは「DX Innovation Academy（DIA）」で MAWS メンバーがリードする AWS コースも開講しています。さらに、現場レベルでは AI 駆動開発の実践も加速しており、電力 ICT センターでは Kiro と GitLab を組み合わせた開発ワークフローの標準化や、33 名のエンジニアが参加した AI-DLC Unicorn Gym など、コミュニティから生まれた実践的な取り組みが次々と展開されています。

「エンジニアとしてモチベーションを持ち、自分たちが会社を変えるんだという決意。これが我々のスピリットです。」と MAWS メンバーは語ります。

製造業は「現場主義」が根付いた業界です。トップダウンの号令だけでは、15 万人規模の組織は動きません。三菱電機では、経営層による戦略的な方向付けと、MAWS のようなボトムアップの技術コミュニティを組み合わせた「サンドイッチアプローチ」で変革を推進しています。

Jeff はこの取り組みに非常に感銘を受けたと述べ、MAWS の 2 年間での成長を高く評価しました。

AI 時代の開発組織 — Jeff Barr のインサイト

2 Pizza チームから 1 Pizza チームへ

Jeff がまず投げかけたのは、「AI ツールで開発者の生産性が上がったとき、組織はどう変わるべきか？」という問いでした。三菱電機のメンバーからは「むしろ対面コミュニケーションの重要性が増している」という声が上がり、Jeff も強く同意しました。

Amazon では長年「2 Pizza Team（ピザ 2 枚で足りる人数のチーム）」が組織設計の原則でした。しかし AI 時代には、より少人数で深い議論と迅速な意思決定ができる「1 Pizza Team」へと進化しつつあるといいます。開発チームのメンバーが同じ場所に、時には同じ部屋にいることの重要性が増しています。理由は明快で、重要な意思決定をより早く、より頻繁に行う必要があるからです。

極端な例としてハッカーハウス（開発者が同じ場所に住み込みで開発する形態）も紹介されましたが、Jeff はこれを「観察であり推奨ではない。ワークライフバランスは重要だ」と冗談交じりに付け加えました。

20 倍のコミット増、そしてボトルネックの移動

生成 AI ツールの活用により、開発者の週次コミット数が最大 20 倍に増加した事例が報告されています。注目すべきは、この変化がマネージャーからのトップダウンではなく、開発者自身のボトムアップによるカルチャーの変化として起きている点です。

しかし、この生産性向上には深刻な副作用があります。コード生産量の急増により、シニア開発者によるコードレビュー、コードのマージ、そして CI/CD パイプライン全体といった下流プロセスにボトルネックが移動しているのです。

Jeff は BMW Group の事例を紹介しました。BMW は CI/CD プロセス全体のシステムを数年かけて再構築し、効率化を実現しています。20 倍の生産性向上を実際に享受するには、ダウンストリームのボトルネック解消が不可欠であり、次のイノベーションの波はマージ、レビュー、テスト、デプロイの効率化から生まれるだろうと Jeff は見ています。

これは三菱電機のような大規模組織にとって特に重要な示唆です。開発者個人の生産性向上だけでなく、組織全体のデリバリーパイプラインを見直す必要があるということです。

76 日間で 2 年分の開発を完了 — Project Mantle

Jeff は AWS 社内の事例として「Project Mantle」を紹介しました。これは Amazon Bedrock の推論インフラを刷新するプロジェクトで、急増する AI 推論需要に対応するために立ち上げられました。

Mantle は Bedrock の全モデルのホスティングと推論リクエスト処理を担う重要コンポーネントであり、最もシニアなエンジニアがアサインされました。当初の見積もりは約 2 年。しかしチームが生成 AI の活用を実験した結果、11 人のチームがコードゼロからデプロイまでわずか 76 日で完了させました。

「AI が実装・テストし、人間がレビューする」というサイクルを 1 時間以内で回す体制を構築し、個々の開発者の生産性は 10〜20 倍に向上。同時に「ゼロオペレーターアクセス」——AWS のオペレーターですら顧客データにアクセスできない——という高いセキュリティ基準も達成しています。

この経験はシニア開発者にとっての「目から鱗」のウェイクアップコールとなり、GenAI の正しい活用法を組織全体に示す象徴的な事例となりました。

トークンエコノミクス — 新しい KPI の登場

AI 活用が進む中、企業は「トークン消費量」を新たな KPI として追跡し始めています。トークン使用量を開発者やプロジェクトにマッピングして可視化し、フィードバックして改善を促す取り組みが広がっています。

興味深いのは、トークンコストと開発者コストの比較が、エンジニアのアサイン方針を見直すきっかけになっている点です。AI ツールによって一人あたりの生産性が飛躍的に向上するなら、少数精鋭の内製チームの方が合理的——全体的には自社開発者を持つ方向へのトレンドが見られます。

AI 時代の人材育成

「High Judgment」— シニアとジュニアを分けるもの

Amazon/AWS において、シニアエンジニアとジュニアエンジニアの違いは何か。Jeff の答えは明確でした。もはや技術スキルの差ではない。アーキテクチャの深い理解と、困難な状況で質の高い意思決定ができる能力「High Judgment」こそがシニアを定義するものです。

「ジュニアエンジニアはどう育てるべきか」という三菱電機側からの問いに対し、Jeff はこれがグローバル全体で業界が直面している問いだと認めた上で、教えるべきはコーディングスキルだけではなく、コミュニケーション能力、正しい判断を下す力、そしてビジネスの理解だと述べました。

具体的な育成方法としては、シニア開発者が大きな判断をする場面にジュニアを同席させ、困難な意思決定を経験する機会を意図的に与えること。そして成功事例だけでなく失敗事例からも学ばせることが重要だとしました。

セッションでは、三菱電機のメンバーから「冬休みに AI を活用して個人で約 10 万行のビジネスアプリケーションを開発した」という経験が共有されました。Jeff はこれに触れ、今後 10 年以内にユニ・ユニコーン（一人でユニコーン企業（10 億ドル評価）を築く個人）が登場する可能性があると語りました。

20 年で逆転したスキルセット、そして「性格の変化」

Jeff が語った中で最も印象的だったのは、開発者に求められるスキルの逆転現象です。

20 年前は、できるだけ少ないコードで、小さく効率的に、データも最小限にと教えられていました。今は逆です。プロンプトにできるだけ多くの情報を与え、データを最大限に活用することが求められます。かつて開発者は一人で静かに作業できることが美徳でした。今はチームの一員として多くの言葉を発し、頻繁にコミュニケーションを取ることが不可欠です。

「多くの開発者は、一人で静かに働けるからこそこの職業を選んだのです。この変化は技術的な変化というより、性格の変化に近い。これが個人にとっても組織にとっても最も興味深いチャレンジになるだろう。」と Jeff は述べました。

失敗をシステムに帰属させる — Amazon の COE プロセス

ジュニアエンジニアの育成に関連して、Jeff は Amazon に長年存在する障害対応プロセス「COE（Correction of Errors）」を紹介しました。

システムやプロセスに障害が発生した際、まず問題を修正し、次に根本原因を深く分析・議論する。その上で、ミリ秒単位で障害の各段階を記録した詳細なドキュメントを作成し、再発防止策を記載します。

核心的な原則は、障害の原因を常にシステムやプロセスに帰属させ、決して個人を責めないことです。すべての COE はナンバリングされアーカイブされ、組織全体の学習資産として機能します。シニアエンジニアは有名な COE を番号で記憶しており、「COE 253 番の教訓を思い出せ」といった会話が日常的に交わされるといいます。運用上の重要なルールとして、COE が発行されたシステムは、問題が解決されるまで新機能の開発が停止されます。特に大きな障害については、シニアエンジニアが社内プレゼンテーションで教訓を共有します。このメカニズムにより、システムは時間の経過とともにより堅牢でレジリエントになっていきます。

Jeff はこれをジュニアエンジニアがシニアに成長するための重要な学習機会としても位置づけました。この「失敗から学ぶ文化」は、MAWS のようなコミュニティが社内で知見を共有する際のモデルケースにもなり得るでしょう。

ディスカッション — ナレッジ共有と組織変革

セッション後半では、三菱電機の現場が直面する課題と、コミュニティの未来について活発な議論が交わされました。

三菱電機側からは、社内に多様なデータが存在するが構造化されておらず、エンジニアがドメインナレッジにアクセスできないという課題が提起されました。Jeff は、社内データと構造を反映した独自モデルを構築し、開発プロセスのコンテキストとして活用することを提案しました。ただし、既存のリポジトリや Wiki を検索するよりも生成 AI で新しいものを作った方が速いケースも出てきており、多くの企業が同様のジレンマに直面しているといいます。「8〜10 時間のフライトに乗ると、着陸した時には世界が変わっているかもしれない。」という Jeff の言葉が、その変化のスピード感を物語っています。

コミュニティのあり方についても議論が深まりました。熱意のある人が集まるコミュニティは、課題に直面しても諦めずに前に進む力がある。単なるプロジェクトメンバーグループではなく、コミュニティとして進化していること自体が強靭性の源泉になっているとの見解が共有されました。Jeff は AWS の誕生ストーリーにも触れ、AWS 以前の Amazon 社内では各チームが同じ基本的な問題を並行して解決しており、サーバー調達にはマネージャー間でスプレッドシートを回覧して翌年の需要を予測するという柔軟性のないプロセスが存在していたと語りました。このプロセスがイノベーションを遅延させていたことが EC2 と S3 のローンチにつながり、今年でローンチから 20 周年を迎えます。

三菱電機の「コミュニティに KPI は必要か」という問いに対しては、Jeff は「KPI は必要だがコミュニティの種類によって大きく異なる」との回答でした。会員数だけでなく、参加頻度、参加の深さ、エンゲージメントの度合いを測定すべきであり、日本国内で同様の社内開発者コミュニティを持つ企業のリーダー同士が集まってベストプラクティスを比較することも Jeff は推奨しました。

おわりに

セッションを通じて浮かび上がったのは、AI 時代の変革は技術だけの問題ではないということです。

チームは「2 Pizza」から「1 Pizza」へと小さくなり、対面での密なコミュニケーションと迅速な意思決定がこれまで以上に重要になっています。開発者の生産性は劇的に向上していますが、その恩恵を真に享受するには CI/CD などダウンストリーム全体の最適化が不可欠です。

人材育成の面では、シニアとジュニアの差はもはや技術力ではなく「High Judgment」にあります。20 年前と真逆のスキルセットが求められる時代において、意思決定の経験を意図的に与え、Amazon の COE プロセスのように成功と失敗の両方から組織的に学ぶ仕組みが鍵となります。

そして、751 名規模に成長した MAWS の取り組みが示すように、社内コミュニティは単なる技術リソースではなく、企業文化変革のドライバーそのものです。

製造業の巨人の中で、現場のエンジニアたちが自ら変革を推進する。トップダウンとボトムアップの「サンドイッチアプローチ」は、日本の大企業が DX を実現するための一つの解として、参考になるのではないでしょうか。

Amazon Web Services ブログ