プラットフォームエンジニアリングが「“何でも屋”にされる開発者」を救う：DevOpsの“理想と現実”のギャップを「IDP」で埋める

開発に加えて運用やセキュリティ対策など、開発者はシステムに関わる、さまざまなことを任されるようになっている。「プラットフォームエンジニアリング」は、まさにこうした状況に置かれた開発者を救う手段だ。

[Adrian Bridgwater，TechTarget] PC用表示関連情報

LINE

Hatena

コーディングにとどまらなくなった開発者の役割

　求められるものが高度になるにつれて、開発者の在り方が変わってきた。既に開発者の役割は、ソースコードを書くことをはるかに超え、インフラの管理やセキュリティの確保、運用上の問題への対処なども役割に含むようになった。こうした変化は、単に開発者に対して「もっと多くのことをする」ことを求めるだけのものではない。開発者が開発からリリース、日々の運用まで、自らが携わるシステムの成功について、完全に責任を持つようになってほしいという期待を反映している。

　こうした中で登場したのが「DevOps」（開発と運用の融合）だ。DevOpsは、開発（Development）と運用（Operations）の間に従来あった垣根を取り払うことで、双方の担当者が単一のチームとして協力してシステム全体を支え、開発から運用までを一貫して担うことを可能にした。

　DevOpsは、システムの開発、運用、改善を切れ目なく進められる土台を整え、関係者が従来よりも広い範囲の責任を担えるようにする。その結果、リリースのスピード向上やフィードバックの反映サイクル（フィードバックループ）の短縮、そしてユーザーにとってより良い体験が実現しやすくなる。

DevOpsの“理想と現実”にはギャップが

　開発現場にDevOpsが普及するにつれて、新たな課題が浮上した。開発者が善意だけではなく、ベストプラクティスに基づいてシステムを開発していることを、どう保証するかという課題だ。

　DevOpsによって開発者が新たな機能開発に加え、運用についても大きな責任を負うことは、組織や顧客にとっての成果につながるとの期待があった。現実には、ほとんどの開発者はインフラやシステムの状態監視、セキュリティのトレーニングを受けていないのだ。コンピュータサイエンスを学んだ経験はあっても、インシデント対処については学んでいないという開発者は珍しくない。

　開発者は、

「CI/CD」（継続的インテグレーション／継続的デリバリー）パイプライン（開発からリリースまでの工程を自動的に連携させる仕組み）の構成
アラートの閾値管理
テレメトリーデータ（システムから収集する稼働状況や利用状況）の解釈
ランタイムセキュリティ（稼働しているシステムのセキュリティ）の確保

といった、さまざまな業務を求められるようになっている。これらの知識や経験がないにもかかわらずだ。こうした慣習は非効率的で持続不可能であり、リスキーなのは言うまでもない。開発者が自信と一貫性を持って大規模なシステム構築を担えるように支援するためには、適切なツールと手法を利用できるようにする必要がある。

「プラットフォームエンジニアリング」が開発者の救世主に

併せて読みたいお薦め記事

勢いづくプラットフォームエンジニアリング

　状況を打開する鍵となるのが「プラットフォームエンジニアリング」だ。プラットフォームエンジニアリングはDevOpsに取って代わるわけではなく、DevOpsを首尾よく成功させるのに役立つ。開発者がシステムについて真に責任を持つために必要な要素を提供することで、DevOpsのビジョンと実行のギャップを埋める。

　プラットフォームエンジニアリングの核心にあるのが「内部開発者プラットフォーム」（IDP：Internal Developer Platform）だ。IDPとは、開発者の作業を効率化するための、整備済みツールやベストプラクティス、再利用可能なソフトウェア部品の集合体を指す。開発者に“舗装された道”を提供するので、開発者は白紙の状態から作業をせずに済む。

　IDPは一般的に、以下の事前構成済みの機能やツールを含む。こうした機能やツールは、専任の担当者やチームが、組織のニーズに合わせて設計・構成する。

CI/CDパイプライン
インフラテンプレート（インフラ構築を定型化したひな型）
オブザーバビリティ（可観測性）を高めるためのダッシュボード
アクセス制御や脆弱（ぜいじゃく）性スキャンなどのセキュリティ機能
ソフトウェア品質検証などの自動チェック機能

　開発者はIDPを活用すれば、苦労して新しい手段を考案したり、教訓を学んだりする必要がない。IDPは、業界や組織のベストプラクティスに基づいたデフォルトの選択肢を用意する。開発者はそれらを採用し、自社の要件に合わせて調整・拡張できる。

　IDPにより、開発者はシステムの効果的な運用に役立つツールをすぐに利用できるようになる。開発者は運用エンジニアではないものの、自らのシステムに関わる運用上の問題に、当事者として責任を持つことが期待されるようになっている。その責任を意識して行動することが、より質の高い成果、より迅速なインシデント対処、より緊密なフィードバックループにつながる。

　IDPの大きなメリットは、オブザーバビリティを組み込んでいることだ。開発者は単一の画面でサービスの健全性をモニタリングし、ログと指標を分析し、実用的なアラートを受け取ることができる。チームの規模が拡大するにつれて、ダッシュボードやアラートは、各チームの運用スタイルに合わせてカスタマイズしつつ、全体で共有している基準にも適合させることが可能だ。

　セキュリティについても同様のことが言える。IDPは、一般的には「SIEM」（Security Information and Event Management）といったログ管理ツールと直接連携するわけではないものの、共通のツールによる一貫したログの収集と整形ができる。そのためログをセキュリティチームや既存のログ管理ツールに円滑に渡すことができる。これにより開発者は、信頼性の高い高品質なシステムの構築に集中することが可能だ。セキュリティチームは、脆弱性やセキュリティの不具合が開発現場の足かせにならないように、リアルタイムにデータを入手・活用することが可能になる。

「より包括的な責任を負う開発者」を孤独にしない

　新たにプラットフォームエンジニアリングといった共通化した仕組みを導入することで、むしろ複雑な手続きによる作業の停滞や意思決定の遅延が生じたり、作業が煩雑になったりするのではないかと懸念する向きもある。実際はその逆だ。むしろ一貫性のなさが解消されたり、不必要な再発明がなくなったりするに過ぎない。

　プラットフォームエンジニアリングを導入していないと、リリース自動化やモニタリング、セキュリティ対策などを、システムの開発や運用を担う各チームがそれぞれ個別に用意するといった状況に陥る可能性がある。その結果、ツールの分散や重複作業によって時間や工数が無駄になりかねない。

　ベストプラクティスをツールなどの具体的な形で示すのが、プラットフォームエンジニアリングの特徴だ。プラットフォームエンジニアリングによって、開発者は「どの指標を追跡すべきか」「どのアラートを構成すべきか」といった問題に悩まずに済む。専門家の知識を反映したテンプレートを生かし、時間とともにニーズに合わせてそれらを改良できる。

　プラットフォームエンジニアリングの目的は、開発者に対するマイクロマネジメント（業務を細かく管理すること）ではない。開発者が適切なツールやサポートなしに運用上の難題に取り組むのではなく、信頼できる実行環境や運用基盤（システムを安定稼働させるための仕組み）を利用し、システム機能の設計・実装に集中できるようにすることを目的としている。オブザーバビリティやセキュリティ自動化などの機能を駆使することで、チームはより自信を持って、より迅速にシステムをリリースできるようになる。

　この変化により開発者は、設計からリリース、リリース後の継続的な運用管理まで、システムを取り巻くさまざまな業務について、より包括的な責任を負う立場に近づくことになる。ただし孤立するのではなく、手厚いサポートを受けながら、さまざまな業務に役立つ技術を生かしやすい仕組みに支えられる立場にあるということだ。

　企業はDevOpsによる俊敏性の向上を目指し、開発者を分散させ、必要な技術を提供しようとしている。ただしDevOpsへのベストプラクティスの適用は必ずしも進んでいない。

　プラットフォームエンジニアリングはこの状況を変え、DevOpsを成功に導く。開発者が“あらゆる隣接分野の専門家”になることなく、より迅速かつ安全にシステムをリリースできるようにする。IDPは、エンジニアがエンジニアのために設計した仕組みだ。開発者はIDPにより、先人の肩の上に立つことができる。つまり車輪の再発明をせずに、十分にテストされた実績ある環境に基づいて、自信を持ってシステムを構築できるようになる。

　より俊敏なチーム、より信頼性の高いシステム、次に何が起こっても対処できる組織――。これがプラットフォームエンジニアリングの最終的な成果だ。

本稿は、検索・オブザーバビリティベンダーElasticsearchのCPO（最高プロダクト責任者）、ケン・エクスナー氏による英Computer Weeklyへの寄稿記事を翻訳・編集したものです。