内部開発者プラットフォーム（IDP）とは

すべての開発チームがサーバー、ネットワーク、セキュリティー・プロトコル、およびソフトウェア・デプロイメントを構成する独自の方法を自ら模索する代わりに、チームは会社のルールやベスト・プラクティスにすでに準拠している、あらかじめ用意された「ゴールデン・パス」を使用できます。開発者は（例えば「新しいマイクロサービスの立ち上げ」や「プレビュー環境のプロビジョニング」を行うために）そのパスに従うだけでよく、プラットフォームがバックグラウンドの自動化を通じて残りの処理をこなします。

IDPは、組織内のすべての開発チームがほぼ同じルールに従うように、異種のプロセスを統合する方法です。そして、基盤となるインフラストラクチャーに関する決定を処理するため、開発者はコードをリリースするためにインフラストラクチャーに関する深い専門知識を必要としません。

IDPは通常、専用のDevOps、運用、またはプラットフォーム・エンジニアリング・チームによって設計および維持されますが、その主なユーザーはアプリケーション・デベロッパーです。プラットフォームは、いくつかの異なるツールチェーンとテクノロジー（コンテナー・オーケストレーション、インフラストラクチャー・アズ・コード（IaC）、継続的インテグレーション／継続的デリバリー（CI／CD）、オブザーバビリティーツールなど）を、一貫性のあるエコシステムに統合します。

IDPは、組織の断片化しがちなソフトウェア・エンジニアリング、デリバリー、および開発の機能に秩序と一貫性をもたらします。これにより、組織はソフトウェア開発環境とプラクティスの複雑さを管理できるようになり、それらを簡素化および合理化して多くのメリットをもたらします。

意味のあるコーディング作業に深く集中している状態である「フロー状態」に入り、それを維持するエンジニアの能力は、ソフトウェアのイノベーションを目指す組織にとって非常に大きな価値があります。この状態では、注意が散漫になることなく、進捗が途切れなく続いているように感じられます。エンジニアは、邪魔されることなく問題に取り組む時間を確保できるため、より複雑な問題を分解することができます。

しかし、フロー状態は脆弱です。開発者は、ある種の問題から別の問題へとコンテキストを切り替えなければならないことがあり、この精神的な移行によって最初の問題の進捗が途絶え、最終的に最初の問題に戻ったときにゼロからのスタートを余儀なくされることがあります。例えば、バグ・レポートで特定された問題（ホテルの予約ユーティリティーが、ユーザーの正しいタイム・ゾーンで日時を表示しない理由）のトラブルシューティングを試みているコーダーを想像してください。それは、JavaScriptが根本的なレベルで時間をどのように処理するかに関わる、厄介な問題です。単純なフォーマットの問題ではありません。彼らは、タイムスタンプがバックエンドとフロントエンドを通過してUIへとどのように移動するかを追跡しています。彼らは、ローカルのブラウザー設定や、日付オブジェクトがさまざまな条件下でどのように動作するかについて考えています。頭の中に留めておくべき情報は膨大ですが、彼らは突破口を開く寸前です。

その後、彼らはエディターを離れてCI／CDツールを開き、そのサービスに適したパイプラインを検索し、この特定のプロジェクトがデプロイメントをどのように処理するかを思い出し、構成を修正し、パイプラインの実行を待ち、動作を確認するために別のモニタリング・ツールを開かなければなりません...

彼らは問題についての思考から離れ、インフラストラクチャー、ツール、およびプロセスを操作するという異なるモードへと移行しなければなりませんでした。そして、バグの修正に戻る頃には、問題について築き上げていた繊細な理解は消え去っています。今や、彼らはゼロから始めなければなりません。これは、組織にとっては時間の浪費を意味し、エンジニアにとっては不満を意味します。IDPは、副次的な懸念事項を処理することでこの浪費を削減し、結果として市場投入までの時間を短縮し、開発者の生産性を高め、開発者体験を向上させます。

組織が成長するにつれて、その開発環境はますます複雑になります。あるチームが特定のツールを採用する一方で、別のチームは同様のタスクを達成するために競合する別のツールを選択する場合があります。チームは異種のワークフローを開発し、インフラストラクチャー、デプロイメント、またはセキュリティーについて、それぞれのユースケースには個別に役立つものの、全体としては競合や非効率性を引き起こす決定を下すことがあります。環境が一貫していないと、ボトルネックが多発します。これらの不整合は時間の経過とともに蓄積され、システムの拡張をより困難にします。対照的に、IDPは、断片化され一貫性のない一連のプラクティスを、一貫性のある再現可能な開発者ワークフローおよびソフトウェア・デリバリー・プロセスへと変革します。

命名規則、セキュリティー・プラクティス、CI／CDパイプラインなどの考慮事項について、IDPはテンプレートを提供し、再利用可能なスキャフォールディングを介して一貫したワークフローを確立することにより、ばらつきを減らします。このようにして、開発者はゼロから始める必要がなく、リポジトリーを自動的にプロビジョニングし、ビルドおよびデプロイメント・パイプラインを構成し、モニタリングとセキュリティーを統合するテンプレートを選択できます。

IDPは、セキュリティーおよびコンプライアンスの機能をワークフローに直接組み込みます。例えば、すべてのサービスに適切な認証メカニズムが含まれ、承認されたネットワーク構成に準拠していることを確実にできます。このようにして、開発者は特定のアプローチが要件を満たすかどうかを考えて時間を浪費する必要がなくなります。コントロールが一貫して適用される（プラットフォーム自体に組み込まれている）ため、適切なプロトコルが遵守されます。

すべてのチームが同じパターンに従う場合、開発者が馴染みのないコードベースを理解し、貢献することがより容易になります。共有された規則により、プロジェクト間の切り替えに必要な認知負荷が軽減され、新しい開発者はより迅速にオンボーディングできます。

一貫したフレームワークがなければ、組織の成長は混乱を招く可能性があり、新しいサービスが導入されるたびにばらつきや複雑さが増すことになります。IDPは、拡張を可能にし、リソース配分の最適化を支援する、安定したエンタープライズ・グレードの基盤を提供します。ベスト・プラクティスをシステム全体に自動的に普及させることができ、小規模なプラットフォーム・エンジニアリング・チームであっても、大規模な組織の開発プラクティスに影響を与えることができます。

IDPは単一のツールではなく、開発者の特定のニーズに対処し、よりシームレスな開発者体験を創出するために連携して機能する機能のシステムです。実装は異なりますが、最も一般的なコンポーネントを以下に示します。

開発者ポータル：多くの場合内部開発者ポータルと呼ばれ、これは開発者が対話する主要なインターフェースです。多くの場合、Backstageのようなオープンソース・ツールで構築され、中央ダッシュボード、サービス・カタログ、ドキュメンテーション、テンプレート、プラグイン、およびワークフローを提供します。それは、プラットフォームの開発者用セルフサービス・コントロール・パネルです。

サービス・カタログ：サービス・カタログとは、すべてのサービス、システム、およびリソースの構造化されたインベントリーです。これは所有権や依存関係を定義し、その他のメタデータを提供するため、誰が何を所有しているか、またサービスが互いにどのように影響し合っているかを誰もが把握できるようになります。

スキャフォールディングとテンプレート：これらは新しいサービスを作成するための事前定義された青写真であり、ユーザーはGitHubリポジトリーの作成、CI／CDパイプラインの設定、標準構成の適用、ロギングとモニタリングの統合などを迅速に行うことができます。パイプラインはベスト・プラクティスが組み込まれた状態で事前構成され、再利用可能であるため、開発者はそれらをゼロから設計する必要がありません。

インフラストラクチャー・プロビジョニング：このレイヤーは、さまざまなクラウド・プロバイダーによるハイブリッドまたはマルチクラウドアーキテクチャー全体の環境、リソース、およびアプリケーション・ワークロードの作成と管理を処理し、多くの場合、自動化にGitOpsの原則を活用します。

環境管理：多くの組織では、構成の違い、依存関係の不一致、およびデータの不整合により、開発環境、ステージング環境、および本番環境が時間の経過とともに乖離していきます。IDPは、環境の均等性を促進し、曖昧さを排除し、環境の予測可能性を高めることで、この問題に対処します。

オブザーバビリティー：可視性がデフォルトでシステム動作に組み込まれており、ログ、メトリクス、トレースなどのリアルタイムの洞察を提供します。

シークレットと構成の管理：APIキー、認証情報、および環境変数が安全に処理され、シークレットがハード・コーディングされるのを防ぎ、アクセスを制御して監査可能にします。

ガバナンス：セキュリティーおよびコンプライアンスのポリシーが自動的に適用され、スコアカードやロールベースのアクセス制御（RBAC）などのガバナンス・コントロールによって、誰がデプロイできるか、誰が何にアクセスできるか、ワークフローがどのように承認されるかが定義されます。

ドキュメンテーション：ドキュメンテーションは散在するのではなく、サービスと並行して存在し、ポータルを通じて検索できます。

エージェント型コーディングアシスタントが本番環境グレードのIDPを単独で組み立てることはありませんが、複数のステップにわたってアクティブに計画、生成、反復し、プラットフォームのブートストラッピングからゴールデン・パスの作成、ツールの統合に至るプロセス全体を加速できます。アーキテクチャーには依然として人間の判断が必要であり、それはテクノロジーだけでなく、組織やチームの構造にも大きく関係しているためです。

一度構築されると、エージェント型コーディング・アシスタントはIDP内で動作し、静的なポータルから、より動的でタスク指向の環境への変革を支援できます。例えば、IBM Bobはプラットフォームのコンポーネントと統合し、以下のようなタスクを支援できます。

• サービスのテンプレートや標準の読み取り
• CI／CD構成やワークフローとの対話
• リポジトリー間でのコードの生成と修正
• （適切な承認を得た上での）ビルド、テスト、およびデプロイメントのトリガーの支援
• 接続されたツールを通じたログやオブザーバビリティー・データの解釈

単なるチャットボットをはるかに超えて、それはプラットフォームへのインテリジェントなインターフェースとして機能します。開発者は手動でフォームやワークフローを操作する代わりに、「新しいサービスの作成」といったアクションを要求でき、アシスタントは標準、ガードレール、およびゴールデン・パスに準拠しながら、必要なステップのオーケストレーションを支援できます。明確に定義された環境では、必要に応じて人間のレビューを組み込みながら、サービス・カタログのメタデータやコンテキストを使用して自らのアクションを導くことができます。