トヨタとGenAIが変える開発者体験

開発者の生産性を蝕む「見えないコスト」 現代の開発者は、本来の業務であるコーディングよりも、ツールの切り替えや情報検索に多くの時間を費やしています。 平均的な開発者は、15~20個のブラウザタブを常に開いています。これは単なる習慣ではなく、複雑化した開発環境が引き起こす「コンテキストスイッチ」の常態化を示しています。 開発者の「認知負荷 (Cognitive Load)」は、企業のイノベーション速度を低下させる最大の要因の一つです。 ・インフラのプロビジョニング依頼に数週間、あるいは数ヶ月を要する。 ・異なるツール、ドキュメント、ダッシュボード間を絶えず行き来することで、集中力が削がれ、生産性が著しく低下します。 ・このスライドデッキでは、この普遍的な課題に対する体系的な解決策と、世界トップクラスの製造業であるトヨタ自動車がどのようにこの課題を克服したかを紹介します。

DevOpsの理想と現実：なぜスケールしないのか？ 「テクノロジーは最も簡単な部分です。最も難しい問題はカルチャーです。」 git Terraform Jira Jenkins Security Hub slack docker kubernetes DevOpsは、開発と運用の連携を促進するための強力な文化であり、手法です。しかし、その実践はツールやプロセスの増殖を招き、意図せずして新たなサイロやボトルネックを生み出しました。特に大企業において、DevOpsを大規模にスケールさせることは極めて困難です。 ・"ツールの乱立"、6,000もの異なるツールが乱立し、標準化が困難に。 ・"属人化"、個々のチームが独自の方法でパイプラインを構築し、知識やベストプラクティスが共有されない。 ・"文化の壁": ツールを導入するだけでは、組織全体の文化やプロセスは変わらない。 この複雑性は、開発者がセルフサービスで迅速に価値を提供することを妨げます。

複雑さへの処方箋：社内開発者プラットフォーム (IDP) 複雑な下位レイヤーをすべて抽象化し、開発者が本来の業務に集中できる環境を提供する。 社内開発者プラットフォーム (Internal Developer Platform) Gartner社も指摘するように、IDPは開発者体験を向上させるための戦略的なアプローチです。IDPは、開発に必要なツール、サービス、ドキュメントへのアクセスを単一のインターフェースに集約します。 IDPの役割: 抽象化: Kubernetes、Terraform、CI/CDパイプラインといった下位レベルのインフラを開発者から隠蔽します。 標準化: 組織のベストプラクティス、セキュリティ要件、コンプライアンスを組み込んだ「ゴールデンパス」を提供します。 セルフサービス: 開発者は、チケットを切ったり誰かに依頼したりすることなく、必要なインフラや環境をオンデマンドで利用できます。 重要なのは、開発者を「顧客」として捉え、彼らのための「製品」としてプラットフォームを構築することです。

IDP構築のデファクトスタンダード：オープンソースのBackstage Spotifyによって開発され、CNCFのインキュベーションプロジェクトでもあるBackstageは、開発者ポータルのための拡張可能なフレームワークです。 Backstageは、単なるツールではなく、社内のあらゆるツールやサービスを統合するための「プラットフォームのプラです。 4つのコア機能 1. Software Catalog: すべてのソフトウェア資産（マイクロサービス、ライブラリ、パイプライン、インフラ）を一元管理する「Single Source of Truth」。所有者、依存関係、ドキュメントを明確にします。 2. Software Templates: 数回のクリックで、ベストプラクティスが組み込まれた新しいサービスやインフラを自動生成します。（例: 本番環境ECSクラスタ、新規Gitリポジトリ） 3. TechDocs: 「Docs-like-code」アプローチで、ドキュメントをコードと共にバージョン管理し、常に最新の状態に保ちます。 4. Search: Confluence、GitHub、社内ドキュメントなど、組織内のあらゆる情報を横断的に検索できる統合検索機能。 強力なプラグインエコシステムにより、Jira、GitHub、Datadogなど既存のツールとシームレスに連携できます。

トヨタの挑戦：カイゼンの精神をソフトウェア開発へ 「There is no best, only better. (ベストはない。常により良いものを。)」 - 豊田章男 カイゼン トヨタ生産方式 (TPS) は、「高品質・低コスト・最短リードタイム」を追求するトヨタの哲学です。その核となるのが「ムダの削減」と「カイゼン (継続的改善)」です。 ソフトウェア開発における「ムダ」: ・繰り返しの作業*: 開発チームが車輪の再発明を繰り返す。 ・一貫性の欠如*: コンテナのデプロイ方法を尋ねると17通りの答えが返ってくる。 ・手戻り*: セキュリティやガバナンスの要件が後から発覚し、修正に多大な工数がかかる。 トヨタは、数十年にわたり有機的に成長してきた数千・数万のアプリケーション群が抱えるこの「ムダ」を特定し、TPSの原則をソフトウェア開発に適用する決断をしました。

トヨタのプラットフォーム戦略：テクノロジー、プロセス、そして人 成功するプラットフォームは、優れた技術だけでなく、それを支えるプロセスと、活用する人々の文化によって成り立っています。 トヨタは自社のプラットフォームを「Chauffeur」と名付け、明確なブランドを確立しました。その構築は、3つの柱に基づいています。 テクノロジー (Technology) Backstageをベースとした開発者ポータル 「ブループリント」(ゴールデンパス) によるIaCの提供 CI/CDパイプラインの標準化 生成AIの活用 プロセス (Process) コード化・自動化ファースト: 手動でのコンソール操作 (ClickOps) を原則禁止。 FinOps: 財務部門を巻き込み、コスト意識を徹底。 プロダクトマネジメント: プラットフォームを社内プロダクトとして扱い、ロードマップとSLAを公開。 ひと (People) Chauffeur コミュニティ形成: 開発者が信頼して使える「安心領域」を醸成。 合意形成 (根回し): パートナーとしてアプリケーションチームと対話し、共に作り上げる。 エバンジェライゼーション: プラットフォームチームのエンジニア自らがユーザーと対話し、フィードバックを直接得る。

Chauffeurポータルの実力：12,000行のコードを数クリックで ベストプラクティスを凝縮した「ブループリント」が、開発者のセルフサービスを実現する。 新規ブループリントの作成 利用可能なブループリント一覧 開発者はいくつかの必須項目を入力するだけ 最終的なアウトプット: 自動生成されたコードのPull Request 組み込まれたコンプライアンス 12,000+ lines of Terraform code generated. 「ブループリント」は、トヨタ版のSoftware Template (ゴールデンパス) です。 例: Spring Boot用ECSブループリント ・開発者はアカウント番号など、いくつかの必須項目を入力するだけ。 ・バックエンドでは、API Gateway、WAF、IAMロール、監視設定などを含む約12,000行のTerraformコードが自動生成される。 ・最終的なアウトプットは、開発者自身のGitリポジトリへのPull Request。プラットフォームチームが開発のボトルネックになることはありません。 組み込まれた価値: ・Well-Architected Score: セキュリティ、信頼性、コスト効率など、AWS Well-Architected Frameworkの要件を満たしていることが保証される。 ・Day 2オペレーション: Graviton3への移行など、インフラのアップグレードはブループリントのバージョンアップとして提供され、全利用者が容易に追随できる。

静的と動的の融合：すべてを見通すSoftware Catalog 従来のCMDBでは捉えきれなかった「誰が、何を、どのように使っているか」という動的な関係性を可視化する。 Software Catalog Customer-API Ownership Team: Platform Engineering Owner: Taro Yamada Last Updated: 2024-05-15 Source: CMDB & Git CI/CD Pipeline Success Build #1452 Branch: main Duration: 5m 20s 最新のステータス (Latest Status) Dependency Graph Visualize Dependencies Scorecards Cost Efficiency 85/100 Good Security Posture 95/100 Excellent コストとセキュリティ (Cost & Security Scores) 統合された情報 ・静的情報 (CMDB): アプリケーションの公式な所有者、ビジネス上の重要度など。 ・動的情報 (Git, AWS API): 実際にコードをコミットしているチーム、CI/CDパイプラインの最新ステータス、利用しているAWSリソース、サービス間の依存関係。 多様な利用者 ・エンジニア: 依存サービスの障害状況やオーナーを迅速に特定。 ・マネージャー/役員: 担当組織のアプリケーション一覧やコスト状況を把握。 ・財務担当者: 正確なコスト配賦 (チャージバック) に利用。 このカタログは、組織全体の透明性を高め、データに基づいた意思決定を促進します。

次世代の開発者アシスタント：生成AIボット「Chauffeur Archie」 大量のドキュメントやブループリントの中から、開発者が必要な情報を瞬時に見つけ出せるように支援する。 Chauffeur Archie User: この機能を実装するのに最適なブループリントは？ Archie: こちらの「ECS Blueprint for Spring Boot」が最適かと思われます。 ECS Blueprint for Spring Boot Scalable containerized Spring Boot application blueprint on ECS. 過去の実績データに基づく推定月額コスト: ¥50,000 - ¥80,000 プラットフォームが成熟し、ドキュメントやブループリントが増えるほど、目的の情報を見つけるのが難しくなります。トヨタはこの課題を解決するために、Amazon Bedrockを活用した生成AIボット「Chauffeur Archie」を開発しました。 Archieの能力 ・ソリューション検索: 「ゼロトラストを実現したい」といった曖昧な要求に対し、関連するブループリントやTechDocsを提示する。 ・コスト見積もり: 「この構成の月額費用は？」という質問に対し、類似のワークロードを持つ他チームの実績データに基づき、コスト範囲を予測する。 ・問題解決: 「このセキュリティアラートを解決するには？」という問いに、具体的な解決策や手順が記載されたドキュメントへ誘導する。 Archieは、開発者の「ググる」時間を削減し、より迅速な課題解決を可能にします。

成果：開発者4人チームの1年分に相当する時間を創出 52 週分の開発時間削減 この削減効果は、開発者4人チームの丸1年分の工数に相当します。 プロジェクト初期段階 (Inception) 12週間のリードタイム短縮 継続的な改善 (Day 2 Upgrades) 40週間の工数削減 40+の承認済みテンプレート (ブループリント) HA/DR構成などを網羅した「質」の高いテンプレート これらはすべて、最終的に収益を生む新製品開発へと再投資された、実在する数字です。

GenAI × Backstage：単なるチャットボットを超えて 生成AIがBackstageのプラグインを「ツール」として利用することで、リアルタイムの状況を反映した、真に実行可能な回答を生成できる。 Tool Use / Function Calling このマイクロサービスのセキュリティアラートを教えて LLM Call Tool Return Real-time Data Backstage Plugin search_backstage_catalog get_security_hub_findings あなたの`my-custom-module`の`read_only_filesystem`フラグを`true`に設定してください 基本的な生成AIの回答は、汎用的で、必ずしもあなたの会社のプラットフォームに即しているとは限りません。 (例: 「Terraformの`aws_ecs_task_definition`リソースを変更してください」→実際には社内モジュールを使うべき) Tool Use (Function Calling) アプローチ 1. LLMはユーザーの質問を解釈し、回答に必要な追加情報を特定します。 2. 「このマイクロサービスのセキュリティアラートを教えて」という質問に対し、LLMは「Security Hubプラグインを呼び出す」という判断を下します。 3. Backstageのバックエンドが実際にAPIを呼び出し、リアルタイムのデータを取得してLLMに返します。 4. LLMは、そのリアルタイムデータと、TechDocsから得た社内モジュールの情報などを組み合わせて、「あなたの`my-custom-module`の`read_only_filesystem`フラグを`true`に設定してください」という具体的で実行可能な回答を生成します。

プロンプト不要の未来へ：UIに組み込まれたインテリジェンス 開発者が質問を考えるのではなく、システムが状況に応じて能動的に解決策を提示する。 Before After Vulnerability details Affected resources (1) 推奨された解決策 S3バケットのパブリックアクセスをブロックする設定。以下のコードをCloudFormationテンプレートに追加してください: [yaml code snippet] 適用 優れたプロンプトを作成するには、経験とスキルが必要です (プロンプトエンジニアリング)。しかし、すべての開発者がその専門家である必要はありません。 フローの組み込み ・チャットインターフェースの代わりに、既存のプラグインUIに直接インテリジェンスを組み込みます。 ・例えば、Security Hubの脆弱性表示画面に「解決策の提案」ボタンを設置します。 ・ボタンをクリックすると、バックエンドでコンテキスト (対象サービス、脆弱性の種類など) を含んだプロンプトが自動生成され、LLMが最適な解決策を提示します。 これにより、開発者はプロンプトエンジニアリングを意識することなく、自然なワークフローの中でAIの支援を受けることができます。 これはAmazon Qなどに見られるアプローチです。

成功への道筋：プラットフォーム戦略の3つの核 トヨタの成功とIDPの未来から、我々が学ぶべき本質は3つあります。これらは、あなたの組織がプラットフォームエンジニアリングの旅を始めるための羅針盤となります。 1. セルフサービス (Self-Service) プラットフォームチームは、中央集権的なゲートキーパーになるべきではありません。開発者が自律的に価値を創造できるような、自動化されたセルフサービスを提供することが根本的な要件です。 原則: Automation First. 2. ネットワーク効果 (Network Effects) プラットフォームは、一部の専門家だけで作るものではありません。実際にそれを使う開発者コミュニティの専門知識やフィードバックを取り込み、共に育てていくことで価値が増大します。 原則: Blend expertise into the product. 3. 継続的改善 (Continuous Improvement - KAIZEN) プラットフォームは作って終わりではありません。Day 2オペレーションこそが本質です。ビジネスやテクノロジーの変化に合わせ、常に改善し続ける文化とプロセスを構築してください。 原則: No product is one and done.