プラットフォームエンジニアリングとは？基本をわかりやすく解説

プラットフォームエンジニアリングとは？目的や基本をわかりやすく解説

DevOpsやSREといった概念が注目されるなか、新たに「プラットフォームエンジニアリング」というアプローチが脚光を浴びています。プラットフォームエンジニアリングは作業効率の向上による開発スピードの加速などのメリットがある一方で、注意点もあるため、導入の可否を慎重に判断することが重要です。
ここでは、プラットフォームエンジニアリングの目的やDevOpsとの違いのほか、メリットや注意点、開発者の管理負担を軽減する方法についても解説します。

プラットフォームエンジニアリングとは開発者の生産性を高めるための取り組み

プラットフォームエンジニアリングとは、内部開発者プラットフォーム（Internal Developer Platform以下IDP）と呼ばれる開発者向けのプラットフォームを構築し、運用していく手法です。IDPには、開発に必要なインフラとツールだけでなく、モニタリング方法や各種のナレッジも組み込まれています。開発者はこれらの機能をセルフサービス式で利用することで、アプリケーション開発に必要な環境を素早く構築できます。ノンコア業務にかかる作業時間を削減し、顧客に質の高いサービスを提供する作業をさらに加速させることができます。

プラットフォームエンジニアリングが注目されている理由

プラットフォームエンジニアリングは、なぜ今注目されているのでしょうか。その理由について見ていきましょう。

開発者の認知負荷の増加

プラットフォームエンジニアリングが注目される理由として、開発者の認知負荷の増加が挙げられます。

パブリッククラウドやコンテナ、インフラのコード化といった技術の進歩は目覚ましく、インフラの専門知識がなくてもアプリケーションが動く環境をセットアップできるようになりました。小規模な環境であればインフラ担当を必要とせずに少人数で構築運用しているケースも多いのではないでしょうか。

しかし、それは裏を返せば開発者の責任範囲が広がったということです。進化し続けるクラウド技術、増え続ける各種の開発ツール、さらには開発環境のメンテナンスデプロイパイプラインの整備、本番環境のモニタリグ設定などを開発者が行うことになると、開発者の負担は増大し、本来行うべきアプリケーション開発が円滑に進まないといった事態になりかねません。

高スキル人材の不足

高スキル人材が不足していることも、プラットフォームエンジニアリングが注目されている理由のひとつです。少数精鋭で開発を高速化・安定化させるためには、アプリケーションだけでなくインフラにも精通した一定レベル以上のスキルを持つ人材を確保する必要があります。そのため開発・運用の広範囲にわたり、高度な知識と技術を持つエンジニアの需要は高まるばかりです。
しかし、こうしたプロフェッショナル人材は限られており、業界の人材不足はその深刻さを増しているのが現状です。仮にそういった人材の確保、育成ができたとしても、その人にタスクが集中してしまい、属人化や燃え尽き症候群のリスクがあり、中長期的には組織のスピードを落としたり技術的負債を抱えることになったりするかもしれません。

プラットフォームエンジニアリングの目的

プラットフォームエンジニアリングの目的は、開発者の認知負荷を下げて、開発をさらに高速化することです。
年々増加する開発者の認知負荷の課題感から、開発に必要なものを使いやすい形でまとめたプラットフォームであるIDPを作り、ノンコア業務をセルフサービス化してコア業務に集中できる環境を整えよう、という発想が生まれました。インフラ構築や運用監視の知識が浅いチームであっても、効率的かつ高速な開発業務を行えることが期待されています。

プラットフォームエンジニアリングとDevOps

プラットフォームエンジニアリングは、DevOpsの原則から構築されたプラクティスだといわれることがあります。DevOpsとは、開発と運用の垣根をなくし、ソフトウェアの迅速な導入と安定的なサービスの提供を目指す概念です。
DevOpsでは開発者に求める知識や業務の負担について課題がありました。そこで、開発者が迅速かつ効率的に作業できる環境を提供するプラットフォームエンジニアリングによって、本来の業務に専念できるようになると期待されています。

DevOpsについては、下記の記事をご覧ください。

「DevOpsを効果的に実践するポイントと陥りやすい課題への解決策」
https://newrelic.com/jp/blog/best-practices/key-to-effective-devops-best-practices

プラットフォームエンジニアリングとSRE

プラットフォームエンジニアリングとしばしば混同される用語に、SRE（Site Reliabirity Engineering）があります。SREとは、手間のかかる運用面をプログラムに任せて自動化し、顧客が満足できるサービスレベルを維持しながら、ソフトウェアサイクルをさらに高速化して、システムとビジネスのアジリティを高める取り組みです。プラットフォームエンジニアリングもSREも、開発プロセスの効率と信頼性を向上させるための取り組みといえます。
しかし、SREが本番環境の信頼性に焦点をあてているのに対して、プラットフォームエンジニアリングは開発者の生産性を重んじている点が大きく異なります。

SREについては、以下の記事をご覧ください。

「SREとは？DevOpsとの違いや、よくある誤解を解説」
https://newrelic.com/jp/blog/best-practices/what-is-sre

プラットフォームエンジニアリングの仕組み

プラットフォームエンジニアリングの内容は、企業によって異なりますが、一般的には下記の図のような仕組みで設計・運用されます。

■一般的なプラットフォームエンジニアリングの仕組み

まず、開発者の課題やフィードバックを元に、開発業務の共通基盤となるIDPを構築します。IDPは開発チームに対してプロダクトとして提供され、環境の立ち上げや運用監視に必要なツール、各種のナレッジが詰め込まれており、セルフサービス機能を実装しています。そのため、開発者は必要なサービスやリソースをリクエストするだけで、必要な環境を素早く取得・利用することが可能です。
IDPは、最新機能へのバーションアップや、新たなナレッジの蓄積など、常に更新が繰り返されるほか、開発者からのフィードバックを受けて、より使いやすく作業効率が高い環境へとブラッシュアップされていきます。

従来、開発チームは環境の構築や設定、運用監視の設定、CI/CDパイプラインの整備を自ら行ったり、他の専門チームに問い合わせや依頼をしたりすることが一般的でした。プラットフォームエンジニアリングでは、セルフサービスのインターフェースを活用し、これらのプロセスを標準化・効率化できます。IDPをセルフサービス式に活用することで認知負荷を軽減し、環境の立ち上げを高速化できるのです。

プラットフォームエンジニアリングのメリット

プラットフォームエンジニアリングを実践した場合、どのようなメリットが得られるのでしょうか。主なメリットをご説明します。

スピーディーかつ効率的な開発が可能

プラットフォームエンジニアリングのメリットは、スピーディーかつ効率的に開発ができることです。プラットフォームエンジニアリングによって、開発者は使いやすいツールを安定的に利用できるため、認知負荷が軽減されるでしょう。他部署への問い合わせや情報の収集にかかるといった手間と時間を省き、コア業務に集中できるため、開発とデプロイのスピードが向上します。
標準化されたツールによってガバナンスを効かせ、セキュリティ上の不安がないよう開発できます。さらに、ゴールデンパスと呼ばれる迅速なプロジェクト開発に役立つコードと機能のテンプレートを用意しておけば、新たなメンバーのオンボーディングもスムーズに行えます。それにより人的リソースの無駄も排除できるのです。

経験の浅い開発者が活躍できる

経験の浅い開発者が活躍できることも、プラットフォームエンジニアリングのメリットです。IDPには、標準化されたツール、蓄積されたナレッジが実装されています。そのため開発者に高いレベルのスキルを要求することなく、安定的な開発が可能になります。
プロフェッショナル人材が不足している中で、ビジネス面でも大きなメリットといえるでしょう。

プラットフォームエンジニアリングの注意点

プラットフォームエンジニアリングは、従来の開発チームが抱えていた課題や問題を大きく改善してくれます。しかしその一方で、下記のような注意点もあります。

継続的な構築・メンテナンスが必要

プラットフォームエンジニアリングは、IDPの継続的な開発・メンテナンスが必要なことに注意が必要です。プラットフォームエンジニアリングは一般的なウェブサービスと同様に、ユーザーである開発者からフィードバックを得ながら、IDPに求める機能を使いやすい形で継続的に構築し、提供し続ける必要があります。この作業を怠ると、開発者に使ってもらえずプラットフォームだけが残るということになりかねません。
また、IDPは、さまざまなツールや技術（クラウド、コンテナ、CI/CDパイプラインなど）を組み合わせて構築するものです。各種の開発ツールは常に進化を続けているため、更新しメンテナンスしていくことが求められます。構造が複雑化すれば、運用やメンテナンスに支障をきたす可能性があるでしょう。

障害の原因特定が困難

IDPがある程度の規模になると、その複雑さからIDPで起きた障害の発生原因を特定するのが難しくなります。また、パフォーマンスの低下が発生しても、その要因がどこにあるのか、正しく突きとめるのが困難になり、サービスレベルが低下したままの状態が続くようになってしまうかもしれません。

自社にプラットフォームエンジニアリングが必要かどうかを見極める

プラットフォームエンジニアリングはメリットもありますが、注意すべき点も多くあります。導入すべきか否か慎重に検討することが必要です。
例えば1,000人規模のような大きな組織で、開発チームにも十分な人材がそろっているなら、実践は可能かもしれません。しかし、スタートアップのような小規模な組織の場合、逆効果になる場合もあります。例えば、エンジニアが5人程度なのに、そのうちの1人月をプラットフォーム構築に割り当ててしまったら、人的リソースを無駄に使うことになりかねません。これでは「手段の目的化」になってしまいます。
そうならないためにも、プラットフォームエンジニアリングが自社に必要かどうか、IDPの構築、運用が可能かどうかを事前にしっかりと検討することが大切です。

IDPを構築しない方法

IDPは構築するまでに手間と時間がかかり、運用を始めてからも更新が欠かせません。そのため組織の規模や人的リソースの状況によっては、IDP以外の方法を使ったほうが無理なく、小回りを利かせやすいケースもあります。ここでは、IDPを構築せずに開発業務を効率化する方法について、ご紹介します。

社内wikiや手順書を充実させる

開発者は、必要な情報をウェブで収集しながら、時には社内の他部署に問い合わせしながら、作業を進めていきます。こうしたノンコア作業の業務負荷に対しては、社内wikiや手順書が有効です。
あらかじめ自社のガバナンスに沿った社内wikiや手順書を用意しておけば、IDPを作らずとも作業効率を高めることができます。こうした社内ポータルのことを内部開発者ポータル（Internal Developer Portal）と呼び、内部開発者プラットフォームより優先させて構築する手法もあります。

テンプレートを活用する

IDPのようなプラットフォームではなく、テンプレートを活用する方法もあります。例えば、先ほど紹介したゴールデンパスのような、コードでインフラを管理するTerraformで、よく使う作業のソースコードをモジュール化してテンプレートとして用意しておきます。そして「この作業をする時は、このテンプレートを使う」というように決めておけば、誰が作業しても同じ結果が得られ、ヒューマンエラーを抑えることができ、作業効率も高められるでしょう。

生産性の向上に役立つオブザーバビリティ

プラットフォームエンジニアリングのベースとなるIDPは、開発業務の基盤です。しかし、その構造は多くの他サービスへのAPIや各ツールを抽象化したものになりがちです。そのため、障害発生時の原因特定が困難になり、現特定に時間がかかるようだと開発プロセスを止めてしまう事態にも発展しかねません。
また、開発者がIDPで構築した環境の運用監視を考えると、運用監視の専門知識がなくてもアプリケーションの異常を素早く検知し、原因を素早く特定できる仕組みやツールが必要です。
そこで重要になるのが、オブザーバビリティです。

オブザーバビリティ（Observability）とは、Observe（観測する）と、Ability（能力）を組み合わせた複合語で、日本語では「可観測性」あるいは「観測する能力」などと訳されます。複雑なシステムやアプリケーションの動きを監視し、把握し続けることを指し、何らかの異常が起こった際、どこで何が起きたのか、なぜ起きたのかを把握することが可能です。
異常が発生した場合に、単にアラートを出すだけでなく、エラーに至った道筋をたどり、どこにその原因があったのかを探り出せます。それにより、予期せぬトラブルに対しても有効に機能するため、問題部分のデバッグをスピーディーに行うことができるのです。

プラットフォームエンジニアリングの導入の有無にかかわらず、開発者を取り巻く環境が大きく変わってきた現代では、開発者こそがオブザーバビリティのある環境を活用すべき時代になったといえるでしょう。

オブザーバビリティについては、下記の記事をご覧ください。

「開発者にとってのオブザーバビリティとは？従来のログデバッグとオブザーバビリティデバッグの違いを解説」
https://newrelic.com/jp/blog/best-practices/what-is-observability-difference-from-debugging

開発者の業務負荷を軽減するなら「New Relic」がおすすめ

プラットフォームエンジニアリングは、開発者の認知負荷を下げて、開発をさらに高速化することを目的としています。しかし、その基盤となるIDPの構築や運用には継続的な人的コストが発生し、構造が複雑になればなるほど、障害発生時の問題特定が難しくなります。

そこで、プラットフォームエンジニアリングの第一歩として、Terraformなどを使ってNew Relicの設定をコード化、テンプレート化し、データの見方といった画面の操作方法を社内Wikiなどにまとめることをおすすめします。こうすることで、開発者の工数を使わずにオブザーバビリティを導入することが可能です。

New Relicはオールインワンのオブザーバビリティ・プラットフォームです。New Relicなら、大規模で複雑なシステムであっても、どこで何が起こっているのかを明確にし、トラブル発生の際には、その原因を素早く突き止めて対処できます。
一般的なオブザーバビリティでは、メトリクス、ログ、トレースのデータを活用しますが、New Relicでは3つのデータに「イベント」を加え、4つのデータの収集、分析を行います。メトリクス、ログ、トレースは、いわば「結果」を示すデータにすぎません。ここにイベントを加えることで、一連のプロセスのどこに障害の要因があるのかを突き止められます。さらに、異常の内容だけでなく、関連するエンティティを一連の情報として表示できるため、ひとつの画面で迅速な原因究明と対処が可能です。

New Relicには、このように開発者の負荷を軽減し、本来の業務に注力するための機能が数多くあります。
開発者の業務負担を軽減し、開発の高速化・安定化を目指す際は、ぜひNew Relicの導入をご検討ください。