経営者目線でのプラットフォームエンジニアリング

はじめに

ウルシステムズ株式会社さま主催の『開発者の生産性を高めるクラウドプラットフォームのあり方 』を受講してきたので、そのイベントレポートです。

このイベントでは、特に経営者や CTO (Chief Technology Officer) 目線でのプラットフォームエンジニアリングについて語られていました。

アイレットにはあまりない視点のように感じられたので、イベントレポートにまとめます。

イベントレポートのブログ掲載については、登壇されているすべての会社さまから許可を得ていますが、公式のイベントレポートではなく、全ての文責は筆者にあります。

ウルシステムズ株式会社さまセッション

はじめに、『付加価値を産まない重労働から解き放て！　すべてを効率化するPlatform Engineeringの全貌』として、ウルシステムズ株式会社 シニアマネージャー 小出 泰喜さまよりお話がありました。

開発生産性 x プラットフォーム

まず、経営の課題として経済産業省の『2025 年の壁 』を挙げていました。

2025年の壁は、デジタル・トランスフォーメーション (DX) を企業が実現できない場合、2025年にはエンジニアの確保の困難に直面し、資金的にも12兆円/年の経済的損失が発生するというシナリオです。

しかし、実際のビジネスにおいては、2025年を待たずに困難に直面しているとの話でした。

特に、人材の確保において、優秀な人材の確保ができず、確保した人材もやめていってしまう状況にあるとのことです。

この課題を解決するには、『エンジニアが集まり、定着する環境』を実現するため、開発生産性を上げていくことが重要とのことでした。

Lean と DevOps の科学 によると、組織全体のパフォーマンスを上げるには、24 のケイパビリティがあるとのことで、次のセッションではこれらを向上するためのプラットフォームエンジニアリングについて話がありました。

開発者の生産性を阻害する要因

開発者体験、開発者満足度、開発生産性として、ウルシステムズ株式会社 シニアコンサルタント 菅 慎司さまより話がありました。

特に歴史のある企業においては、複雑化するシステムや運用業務、インフラ業務、守るべき企業ポリシーなど、開発環境は複雑になっているとのことです。

開発者は『本来の開発業務』に加えて覚えることや守ることが増え、これらが『認知負荷』として開発生産性を下げているとのことでした。

John Sweller によると、これらはワーキングメモリ (短期記憶) の負荷であり、負荷を軽減することが重要とのことです。
開発者の認知負荷を下げるため、『Platform Engineering』が注目されているとのことです。

開発者体験の向上は、ユーザーに対する価値提供の向上につながり、業績に大きな影響を与えるとのことです。

開発者体験の向上を実現するためには、いくつかの要素があります。

• 開発生産性
• 開発者体験
• 人的リソース効率
• 信頼性
• セキュリティ

『Platform Engineering は、組織と技術から』として、これらを向上させるとともに、目的に合わせた指標を検討することが、企業にとって重要とのことでした。

２つの IDP

Platform Engineering を実現するために、2 つの IDP が重要とのことです。
Internal Developer Portal と、Internal Developer Platform です。

Platform Engineering には、大きく開発運用者と、プラットフォームエンジニアが登場します。

開発運用者は、Internal Developer Portal を通じて、Internal Developer Platform にアクセスします。
プラットフォームエンジニアは、Internal Developer Platform と Internal Developer Portal を通じて、開発運用者の体験を向上します。

Internal Developer Portal は、開発運用者のため、以下のような機能を具備しています。

• Document
• Template
• Catalog (API / Data / etc. )
• GUI
• Dashboard
• Knowledge

Internal Developer Portal がある場合、ポータル操作とカスタマイズのみを通じて、『ビジネスの付加価値』を生む業務に注力することが出来るとのことです。

Internal Developer Platform では、以下のような機能を具備します。

• 開発環境
• CI / CD
• 実行環境
• セキュリティ
• オブザーバビリティ
• 企業ポリシー

Internal Developer Platform では、『標準状態で』 企業のセキュリティやポリシーに準拠し、開発運用者向けに抽象化した機能を提供します。

これらの成功の鍵は、組織と技術を併せ持って対策することが大切であり、アーキテクチャは組織構造に合わせた形態とすることが大切とのことです。

プラットフォームチームがないと、それぞれの開発運用者にプラットフォームに対する深い知識が求められ、それがチーム間の摩擦を生み、開発生産性を下げます。

Platform Engineering という技術的なアプローチがない場合、抽象化がなく、認知負荷がかかり続けます。

Platform Engineering には、組織の変革が必要となるため、マネージャークラスの理解が必要になるとのことです。

取り組み事例

最後に、ウルシステムズ株式会社 シニアコンサルタント 後藤 大樹さまより、大手小売業のシステムモダナイズコンサルティング事例が紹介されました。

お客様の目的は、10年後も廃れないプラットフォーム・開発基盤を構築することとのことです。
10年後のビジネスビジョンはあるが、IT 施策をどうするかウルシステムズさまに相談されたとのことでした。

開発者やエンジニア待遇面をどうするか悩まれており、既存システムのレガシーな部分に関わるとエンジニアがやめてしまうことが課題とのことでした。

Platform Engineering は抽象的なところが多く、人や予算をつけるのは難しいです。
そのため、既存システムのライフサイクルに合わせて、順次理想に近づけるアプローチを取ったとのことでした。

原因分析と対策では、いくつかの例が示されました。

障害時のトレースが遅く、悪影響が出ているが原因分析に時間がかかる、という問題に対しては、『New Relic』によるオブザーバビリティの導入。

クラウドセキュリティ対策が不十分、という問題に対しては、『Sysdig』による EDR や CaaS を含めた CNAPP の実現。

開発者が必要とする情報が断片化している、という問題に対しては、必要な情報を一元管理する Internal Developer Portal の導入。

これらにより対策を行ったとのことです。

特に、情報の一元管理は組織の変革に対して重要とのことでした。
情報の一元管理によって、従業員の意識なども変革できるとのことです。

これらの対策により、開発者の認知負荷を下げるだけでなく、基盤チーム内のエンゲージメントも向上したとのことです。

今回の導入にあたっては、『Platform Engineering』ではなく『業務を改善していく』というキーワードで、開発の現場と進めていったとのことでした。

組織の課題を解決するためには、

• 自社システムの課題は可視化できているか？
• 課題を解決するための施策は具体化できているか？
• その施策には、人、資金、時間がどれほどかかるか検討出来ているか？
• それらのリソースはどこから確保するか、目処がついているか？

これらの検討が重要であるとのことでした。

Google Cloud Japan 合同会社さまセッション

『Google Cloudで実現するPlatform Engineering』として、グーグル・クラウド・ ジャパン合同会社 パートナー事業本部 パートナーエンジニア 菊地 高史さまよりお話がありました。

プラットフォーム管理の課題

Google では、かつては Database や Network、Server など、それぞれ専門チームが対応していたとのことです。
しかし、各チームへの依頼に時間がかかるなど、開発の負担になっていたとのことです。

この課題に対して、Google では Google App Engine として PaaS 製品が普及し、インフラ部分の多くを抽象化することが出来たとのことです。
しかし、PaaS の問題として、プラットフォームの柔軟性が落ちてしまうことが問題でした。

Application Team は、設計から本番まで、アプリケーションライフサイクルの全体に責任を負います。
これらの課題を解決するのが Platform Engineering です。

Google Cloud で実現する Platform Engineering

Platform Engineering では、プラットフォーム側で準備することで、常に『開発できる状態』とします。

開発チームが必要とするものを準備し、利用可能な状態とします。
Platform Engineering にとって重要なことは、通常のプロダクトと同様に『プラットフォームを一つのプロダクト』として、運用管理することだと語られていました。

責任分界点の一つの例示として、Database や Storage などのアプリケーションに利用する部分は開発者管理、CI / CD や Kubenetes Engine などはプラットフォーム側管理にする例があるそうです。

Google Cloud では、Platform Engineering のための機能を準備しています。

• 開発環境としての、Cloud Workstations
• CI としての、Cloud Build
• CD としての、Cloud Deploy
• 開発を効率化する、Gemini Code Assist

これらを活用して、Platform Engineering を実現してほしいとのことでした。

Platform Engineering に必要なことのまとめとして、以下の内容が語られていました。

• 開発者をプロダクトの利用者として理解する。
• プラットフォームを製品のように取り扱う。
• 最適な問題から、解決を図る。
• 実現可能な最小限のプラットフォームを採用する。

これらが、Platform Engineering に必要とのことです。

Sysdig Japan合同会社さまセッション

『開発者の生産性を邪魔しないデベロッパーファーストのCNAPP SYSDIG』として、Sysdig Japan合同会社 General Manager Mac Kawabata（マック カワバタ）さまよりお話がありました。

『クラウドネイティブでもセキュリティとビジネスを両立しなければならない』との話から始まりました。

そもそも、プロダクトのアプリケーションを作っているのは開発者です。
若手のエンジニアで優秀な人は多いですが、それらの方は効率を求めます。

それこそ、コードを書いたら、そのまま動くくらいの効率化をエンジニアは求めています。

Internal Developer Platform を作り上げるのは大変です。
Internal Developer Platform を作るのは、Platform Enginner であり、Platform Engineer は特に貴重な人材です。

大変ですが、諸外国では実現しており、国内に於いても対応が必要とのことでした。

なぜ、コンテナや CNAPP が必要なのか？

高速な CI / CD などを実現する Internal Developer Platform 環境を実現するためには、コンテナは必要不可欠であり、コンテナがないとそもそも実現が不可能なため、 CNAPP が必要とのことでした。

Sysdig の基盤である Falco は、Cloud Native Computing Foundation (CNCF) の Graduated Projects です。
Graduated Projects には、開発が活発で、重要な Project しか選定されていません。

Sysdig は Falco をマネージドで提供しています。

Sysdig の CNAPP

Sysdig では、大きく 4つの機能を提供しています。それぞれ、以下のような問題に対処するためのものです。

• CWP / 脆弱性を管理する
  • 87% のコンテナ Critical や High の脆弱性が存在する
• CSPM・KSPM / 設定ミスを管理する
  • 15% の侵入は、クラウドの設定ミスが起因
• CWP・CDR / ランタイムと脅威検出
  • 72% のコンテナの寿命は 5分未満
• CIEM / 過剰なパーミッション
  • 90% のクラウド権限は実際には使われていない。

CNAPP は、『見張ること』であるとのことです。
不正や犯罪が起きないように監視カメラをつけるのと同様に、不正アクセスが起きないようにシステムを見張ることが、 Sysdig の CNAPP が行っている事とのことでした。

システムを見張ると、多くのイベントが検知されます。
過剰な検知とならないように、ツールを使って通知数を制御することを Sysdig では行っています。

5/5/5 ベンチマーク

システムに対する攻撃は、高速化しています。
これらに対応するため、Sysdig では 5/5/5 ベンチマークを推奨しています。

これは、『5秒で検知 / 5分でトリアージ / 5分で対応』を指しており、これを実現しないと攻撃を防ぐことは難しいとのことでした。

Sysdig には、これを実現するための多くの機能がそろっています。

New Relic株式会社さまセッション

『ビジネスの差別化に向けたDevSecOpsの実践　〜内製化グラデーションとオブザーバビリティ〜』としてNew Relic株式会社 上席エヴァンジェリスト 清水 毅さまよりお話がありました。

内製化の『目的』はなにか

昨今、内製化がトレンドです。

なぜ、内製化を実施するのでしょうか。
多くの企業では、『開発コストの削減』 を実現するため内製化に取り組みますが、エンジニアが離れ、頓挫しています。
短期的なコスト削減ばかりでは、内製化は頓挫すると話をされていました。

清水さま曰く、本来の目的は『ビジネスに対する柔軟さ、迅速さ』を実現することであるとのことです。

内製化を阻害する要因には、人材不足のほか、意思決定や方針・コストがあり、これらを解決するためにも『意思決定の内製化』が重要とのことでした。

そのためにも、『IT 人材の内製化』ではなく『意思決定の内製化』が重要とのことです。

情報セキュリティ10大脅威 2024 [組織] にあるように、『ランサムウェアによる被害』は組織にとって重大なリスクであり、その被害は継続しています。

内製化においても、ランサムウェア対策は必須とのことでした。

DevSecOps の実践

DevSecOps は、近年では Developer が多くの要素を担うことが多くなっています。
特に、Security に対して手間がかかっており、Developer 中心で DevSecOps を回していくためには、内製化を進めることが重要です。

内製化グラデーション

清水さまの提唱する概念に、内製化グラデーションというものがあります。

Dev / Sec / Ops 、すべてを内製化しようとすると失敗します。
内製化を行うとした場合、多くの企業が思うのは『Developer の内製化』です。

しかし、これは先に述べたように多くの場合に失敗します。

そのため、Security や Operation など、自社にとって重要なことの内製化が重要とのことでした。
事業の意思決定に直結することなど、事業者として実施したいことを内製化することが大切とのことです。

企業が、その優位性を高めるためには、簡単に始められることと、簡単にやめられることが重要とのことです。
そのため、最低限実施すること、セキュリティの実践や、アジリティの確保が大切とのことでした。

これを実現するために、問題全体にオブザーバビリティを入れることが重要とのことです。

オブザーバビリティ

オブザーバビリティを理解する上で、重要なことは『トラブルがあった際に、なにもしないで解決することが出来るか？』ということが重要とのことです。

よくある問題としては、以下のようなものがあります。

• トラブルがあった際に、お客様からの連絡で認識する。
• 原因調査のためのログが欠落しており、ログを追加取得する。
• ログから問題を特定する。

これらの問題があると、障害に気がつくことができず、お客様からのクレームに繋がります。

『監視』と『オブザーバビリティ』は別物です。

監視は、インフラやアプリケーションを監視します。
オブザーバビリティは、データを取得し、予防し、改善します。

まとめると、以下の通りとのことです。

たとえば、オブザーバビリティでは顧客のブラウザ応答の遅延を検知し、原因となる指標を確認し、どのような原因で発生したかをプロアクティブに分析することが可能となります。

オブザーバビリティによって、顧客と合意した SLA などのビジネス上の指標と、実際の動作を結びつける事が可能となるとのことです。

New Relic はデータ容量課金ではなく利用者毎のライセンスのため、システムの全フェーズに導入することが容易です。
APM (Application Performance Management) を利用して、Service Level を作成することが可能であり、コードレベルで分析されていることから IAST (Interactive Application Security Testing) を利用してアプリケーションと実行環境を監視しながら脆弱性を検知することすら可能です。

まとめ

本セミナーでは、特に経営層からみた開発者体験の向上が語られていました。

エンジニアとして、ソフトウェアそのものや機能については十分な知識を有していると自負しています。
しかし、その機能が経営にどう繋がるのか、経営の課題をどう解決するのかは、なかなか想像することが難しいです。

本セッションは、経営の課題に対して、どのように最新の機能を活用していくかについて語られていました。

これらのセミナーで得た知識をもとに、お客様の経営課題を解決できるよう、パートナー企業とともに尽力していきたいと思います。