DevOpsの“理想と現実”のギャップを「IDP」で埋める
プラットフォームエンジニアリングが「“何でも屋”にされる開発者」を救う
開発に加えて運用やセキュリティ対策など、開発者はシステムに関わる、さまざまなことを任されるようになっている。「プラットフォームエンジニアリング」は、まさにこうした状況に置かれた開発者を救う手段だ。
システムの開発者が強いプレッシャーにさらされていることは、周知の事実だ。経営者は競争で優位に立つために、開発者にシステムの迅速なリリース(公開・提供)を求める。さらにそのシステムに対して、揺るぎない信頼性や機能の進化、堅牢(けんろう)なデータセキュリティを期待する。法律や業界標準などのルール、ガイドラインの急速な変化が、開発者が直面する課題をさらに複雑にしている。
コーディングにとどまらなくなった開発者の役割
求められるものが高度になるにつれて、開発者の在り方が変わってきた。既に開発者の役割は、ソースコードを書くことをはるかに超え、インフラの管理やセキュリティの確保、運用上の問題への対処なども役割に含むようになった。こうした変化は、単に開発者に対して「もっと多くのことをする」ことを求めるだけのものではない。開発者が開発からリリース、日々の運用まで、自らが携わるシステムの成功について、完全に責任を持つようになってほしいという期待を反映している。
こうした中で登場したのが「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への寄稿記事を翻訳・編集したものです。
Copyright © ITmedia, Inc. All Rights Reserved.
Computer Weekly発 世界に学ぶIT導入・活用術
この記事の著者
関連記事
新着ホワイトペーパー PR
-
事例
[サイボウズ株式会社] DXに必要な「Dスキル」「Xスキル」を持った人材を育成するには? -
市場調査・トレンド
[サイボウズ株式会社] データで見る、DXが「順調に進む企業」と「つまずく企業」の違い -
製品資料
[サイボウズ株式会社] 賛否が割れがちな「Notesからの移行」 新環境への移行を納得してもらうには? -
事例
[ServiceNow Japan合同会社] 農林中金に学ぶ内製開発 処理効率を約2倍に高めAI活用も加速させた方法とは? -
事例
[ServiceNow Japan合同会社] NTTグループのデジタル変革術、17万人が利用する決裁プロセス刷新の全貌
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
AI全部入り「Microsoft 365 E7」に企業が二の足を踏む訳 移行意向はわずか4%
-
2
【基本情報技術者試験】「デュプレックスシステム」と「デュアルシステム」の違いは?
-
3
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
4
なぜOpenAIやAnthropicのAIは「脱走」したのか 情シスが迫られるエージェント統制
-
5
GitHubが指摘 AIが書いた「おそらく動くコード」が招くシステム崩壊
-
6
「高すぎるGPU」を捨てAI推論をCPUへ Armが示す電力とコストの現実解
-
7
Anthropicが明かす AIは入力データを「どこまで覚えているのか」
-
8
【漫画付き】"RAG導入失敗3例"と処方箋 「入れても使われない」を終わらせる
-
9
「にゃんこ大戦争」がAWSを脱出した理由 無停止移行に潜む“わな”
-
10
なぜ10億円払って“高額な塩漬け”を作るのか? SAPクラウド移行の闇
ホワイトペーパーランキング PR
-
1
生成AIのハルシネーションを防止 回答精度を高めるセマンティックレイヤーとは
-
2
5回聞くだけじゃ足りない? トヨタ式「なぜなぜ分析」の正しい実践方法
-
3
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
4
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
5
「脱Excel」か「Excel快適化」か? 現場にやさしい業務改善の進め方
-
6
マンガで解説:「ゼロトラスト」「SASE」の必要性とメリット
-
7
5分で分かる「セキュア大容量ファイル転送サービス」の機能とメリット
-
8
情報セキュリティ対策早分かりガイド:25の自社診断で弱点と解決策を理解
-
9
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは?
-
10
AIが「わざわざ使うツール」になっていない? 業務で自然に使う導線にする秘訣
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー