しみじみ語る Microsoftの考える プラットフォームエンジニアリング 日本マイクロソフト株式会社 シニアクラウドソリューションアーキテクト 真壁 徹

About me • 真壁 徹(まかべ とおる) • 日本マイクロソフト株式会社 • シニア クラウドソリューションアーキテクト(App Innovation) • アプリケーションとプラットフォームの間にあるグレーゾーンを得意とする • 国立 北陸先端科学技術大学院大学 修了 修士(情報科学) • 分散コンピューティングの学びなおし/研究のため、社会人コースへ • 研究: 分散コンピューティング基盤における宣言的構成管理(2021年 情報処理学会 山下記念研究賞) • 主な著書 • しくみがわかる Kubernetes(翔泳社) • クラウドアプリケーション 10の設計原則(インプレス)

お伝えしたいこと • Microsoftは、プラットフォームエンジニアリングに多様な関わりを持つ • 開発者向けプラットフォームを構成するサービスやツールのベンダーである • サービスやツールの開発チームを支える内部開発プラットフォームを持つ • プロフェッショナルサービスが、顧客のプラットフォームエンジニアリングを支援する • 組織横断で集約した知見を、ガイドとして公開 • Platform engineering guide | Microsoft Learn • 話者の経験を交え、ポイントをしみじみ紹介 • ガイドの和訳版とは表現が異なります (話者が原文を意訳) • 製品紹介はしません

Microsoftの考える プラットフォームエンジニアリング

プラットフォームエンジニアリングとは  自社の開発者を顧客とし、課題解決のしくみを作ること  開発者が抱える課題の解決を目指す (リードタイム、コスト、セキュリティやコンプライアンス、etc)  ガードレールで守りつつ、開発者体験を向上させる  顧客と提供者という関係は、仕事を進めるうえでわかりやすい  プロダクトマインドセットが重要  作っても使われない「独りよがりのプラットフォーム」や共通基盤に欠けていた価値観  DevOpsでの議論や実践を土台にしている  DevOpsを置き換えるものではない  「導入し すぐに役立つ サムシング」ではない  Platform “Engineering” What is platform engineering? | Microsoft Learn

プラットフォームエンジニアリングの原則  それぞれの顧客が大事  顧客が歩きたいと思える、「舗装した道」 を提供する  完全に舗装された道 (ゴールデンパス) を押しつけず、寄り道も認める  寄り道を舗装 (プラットフォームエンジニアがサポート) するかは、戦略や成熟度による  プロダクトマインドセットを持つ  自社向けに作っても、使ってもらえない時代 (顧客には多様な選択肢がある)  成功を定義し、評価する (コストセンターは価値を理解してもらいにくい)  セルフサービスで力を与える  すぐには実現が難しいことも覚悟する (必要条件や出発点ではなく、目指す姿)  見つけやすくする  存在を知られなければ、使ってもらえない Platform engineering principles | Microsoft Learn

顧客とは “開発者を内部開発プラットフォームの主な顧客として考えることは、その成功の ために不可欠です。簡単のため、これらの顧客を開発者と呼びますが、彼らは 「チーム・トポロジー」で言うストリームアラインドチームのメンバーです。機械学習の 専門家やデータサイエンティストなどの役割を含むことがあります” (Each customer is important | Microsoft Learn) 話者談: ストリームが「切れている」チームは顧客か否か?は議論になりやすい (例: 開発をまるっと外部に任せており、「開発者」がいないチーム)

成熟度に合わせ、段階的に対象顧客を広げるのも手  Start Right - templates  楽に早くはじめられるようにする  テンプレートの提供 (リポジトリ、ツール、パイプライン、SDK、パッケージ、サンプルコード、etc)  Stay Right - governance  適切、安全な状態を維持する  ポリシーの自動適用  Get Right - campaigns  実績と自信をもとに、顧客の対象を広げる  横展開キャンペーンの実施 話者談: 初期に意欲的な顧客とStart & Stay Rightをできるかが鍵。実績と自信がない段 階で従来の環境、手法にこだわるチームを顧客に選ぶと、「ぶれ」やすい Empower with self-service | Microsoft Learn

どこからはじめるか どのように進めるか/評価するか

まず、顧客接点となる統合ポータルを作る? “統合ポータルからはじめたくなるかもしれませんが、多くの場合、これは最良の出 発点ではありません” (Each customer is important | Microsoft Learn)

よいポータルには、よい土台が必要 Design a developer self-service foundation | Microsoft Learn

インターフェースに対する開発者のニーズは多様 How should I add identity to our application? Your company has an enterprise service that 50 other projects have built on. Here’s some links: • Team Page • Source Code • Start right template GUI CLI チャット IDE/エディター 話者談: いきなり統合ポータルを目指さず、GUIでの提供が効果的な機能、従来なかった 機能に絞ってはじめると受け入れられやすい

チームを作る 「トイル」の自動化 インベントリの提供 テンプレートの 提供 環境の 提供 最適化 Break down the problem space | Microsoft Learn プロダクトマインドセットを持った、プラットフォームエンジニアリングチームを 立ち上げる 開発者が特に苦労している「トイル」を特定し、自動化するこ とで実績と自信、信頼関係を得る 開発者が使っている/使いたいツールやプラットフォームの情報を 集約し、見つけやすくする ツールやプラットフォームをテンプレートとして提供する セルフサービスプラットフォームの 確立 組織の標準に準拠した、ガードレール付きの 環境を提供する 進め方の例

どのようなメンバーではじめるか “プラットフォームエンジニアは、プロダクトマインドセットを持ち、運用を理解する必 要があります。開発者としてスタートしたか、運用チームにいたかは、スキルセットよ りも重要ではありません。内部開発者プラットフォームを構築するチームは、開発、 運用、K8sの管理者、SRE、IaC の専門家など、さまざまなバックグラウンドを持つ さまざまなチーム メンバーを参加させることで、力を得ます“ (Build the team | Microsoft Learn) 話者談: たとえば統合ポータルを作りたいならUI/UXのスキルが必要なはず。しかし、たいて い初期メンバーに得意な人はいない (インフラに強い人が集まってはじめる傾向がある)

事例: H&M社 プラットフォームエンジニアリングチーム構成 Leverage AKS for your enterprise platform: H&M’s journey | BRK123 (youtube.com)

チームにおける 重要な役割  スポンサー  一般的には役員クラス  成熟や対象顧客の拡大でニーズと必要なスキルは増えるため、採用や異動、育成への影響力も要る  全社セキュリティ、ガバナンスチームとの調整役  全社セキュリティ、ガバナンスチームから参加してもらう手もある  プロダクトマネージャー  肩書、専任にする必要はなく、あくまで役割  顧客の代弁者  顧客から参加してもらう手もある Build the team | Microsoft Learn

内部開発者プラットフォームの構成要素、分類例 Break down the problem space | Microsoft Learn 話者談: 本番環境の作成や運用をプラットフォームエンジニアリングチームが行うかは議論 がある。テンプレートやポリシーなどしくみの提供までで、主体は顧客、が多い印象

Microsoftの内部開発プラットフォームについてよく聞かれること  統合ポータルはありますか？  あります。技術関連部署のWikiの集合体のようなものです。発見とコラボレーション、学びを目的としています  社内オープンソース (インナーソース) 活動を促進する、また、オンボーディングを支えるしくみでもあります  開発に使うサービスやツールは標準化されていますか？  様々なサービスやツールが提供されていますが、何を選ぶかは各チームに委任されています  サービスやツールをセルフサービスで使えたり、プラットフォームエンジニアの支援を受けられたりします  端末は貸与されますが、BYODする人が多いです (MacやLinux Desktopを使っているチームや人も)  ガードレールはどのように作っていますか？  Microsoft Defender、AzureやGitHubのセキュリティ系機能など自社製品を活用しています  たとえばAzureにリソースを作ると、全社ポリシーに応じてNSGやMicrosoft DefenderなどがAzure Policyか ら差し込まれます (戦略や方針) Transforming modern engineering at Microsoft - Inside Track Blog

開発者の生産性や満足度を評価するフレームワーク、手法例  DORA Metrics  NSAT (Net user SATisfaction score)  SPACE Framework  “Accelerate (邦題: LeanとDevOpsの科学)”のNicole ForsgrenがMicrosoft Researchで研究  The SPACE of Developer Productivity - ACM Queue  Satisfaction & well-being  Performance  Activity  Communication & collaboration  Efficiency & flow 話者談: Microsoftでは全てを使っているわけではなく、つまんでいる。また、評価すべき指 標は何かを継続的に議論し、必要があれば変えている

内部開発者プラットフォームの成功指標メトリック例 利用状況 スループットや時間 信頼性 • 新規開発者やチーム数 • 定着数や率 • エンゲージメント • アクティブユーザー数 • 使われている機能や実行回数 • 開発者のNSAT • 見つけやすさ • 使いやすさ • 欲しい機能があるか • ドキュメントのわかりやすさ • プラットフォームエンジニアによる支 援の満足度 • ビルド時間 • テスト時間 • デプロイ時間 • 改善、拡充にかかる期間 • 開発用サービスやツールが利用でき るようになるまでの時間 • 問題を検知するまでの時間 • 問題を緩和、回復するまでの時間 • SLO評価 話者談: 初期のプラットフォームでは採れるメトリックが限られがち。作らずにマネージドサービスを 利用する場合は、それ次第でもある。NSATなどサーベイも活用し、顧客満足度を測る

しみじみ実践例

とある開発者のニーズ  生成AI技術と文書資産を活かした社内向けチャットボットを作ることになった  知見はない  試行錯誤は覚悟のうえだが、走り出すためのテンプレートは欲しい  シンプルでよいので、すぐに動かせるテンプレートが欲しい (アプリケーションからインフラまで)  クラウドサービスプロバイダーがサンプルを公開しているが、そのまま使って社内で怒られるのは嫌だ  全社セキュリティ、ガバナンスに関するルールやポリシーには従いたい  開発者のコーディング、テスト環境の整備も悩みの種  過度、独自に抽象化して欲しくない  使うと判断する前に中身を見たい  テンプレートの実装から学びたい  工夫やトラブルシューティングができなくなるのは嫌  世で広く使われているツール、インターフェイスを使い、本やWebで得られる知識を活かしたい

とあるプラットフォームエンジニアリングチームのアプローチ  コードを提供しよう  文書のインデックス化と、LLMサービスのAPIをコールする、シンプルなチャットアプリケーションのコード  インフラを構成するコード (IaC)  開発者の端末環境を作るコード (dev container)  開発パイプラインを構成するコード (GitHub ActionsかAzure DevOpsのYAML)  上記をまとめたGitリポジトリ  ガードレールを提供しよう  クラウドサービスのポリシー強制機能などを活用  うまくいったら、実績あるテンプレートとして社内公開しよう  ほかの開発チームからも相談あるかもしれないし  コードの提供なので、部分的に使う/参考にしてもらってもいいし  いつか統合ポータルを作るかもしれないけど、まずはテンプレートの集約、紹介サイトを作ってみよう

提供するリポジトリの基本構造 開発パイプラインにAzure DevOpsを使う場合の構成 dev container構成 開発パイプラインにGitHub Actionsを使う場合の構成 VS Code構成 インフラコード (Bicep、HCLなど) アプリケーションコード E2Eテストコード (Playwrightなど)

実はAzure Developer CLIのアプローチを参考にした  Azure Developer CLI (azd)  シンプルなコマンドで、Azureリソースのプロビジョニングとアプリケーションのビルド、デプロイを行う  Goで書かれたオープンソースソフトウェア  構造やルールに従ったリポジトリであれば利用、拡張可能  仮にazdの利用をやめてもコードは残るので、別のしくみから使えばよい  対応言語: Node.js、Python、.NET、Java  対応IaC: Bicep、Terraform  アプリケーションを動かすまでの手数が少ない  $ azd init -t (もしくはリポジトリのクローン)  $ azd auth login  $ azd up  Microsoft社員を中心に、azd対応リポジトリを集約、公開している  awesome-azd

awesome-azd Awesome Azure Developer CLI • Azure Developer CLI対応リポジトリ検索サイト • 2024/6/11時点で、114のテンプレートがある • リポジトリの実体はGitHub上にある • Azure Developer CLIを使わない場合でも、コー ドは使える/参考になる

ご参考: 生成AIと文書資産を活かしたチャットボット (azd対応) azure-search-openai-demo-java/docs/aca/README-ACA.md at main · Azure-Samples/azure-search-openai- demo-java (github.com)

まとめ

お伝えしたかったこと • 「誰」と進めるかは、とても重要 • 仲間 • 顧客 • 顧客価値にフォーカスする • 特定の顧客の課題とニーズにフォーカスし、小さくはじめる • いきなり統合ポータル、セルフサービスを目指さなくてもよい • たとえば、コードを中心としたコミュニケーションからはじめる • 対象顧客の拡大やプラットフォームの拡充は、実績と自信、信頼を得てから

参考資料

代表的なMicrosoft/GitHub製品とのマッピング例 • Microsoft Dev Box • Visual Studio/Code • GitHub Codespaces/Copilot • GitHub • Azure DevOps • GitHub • Azure DevOps • Azure Load Testing • Microsoft Playwright Testing • Azure • Azure • Microsoft Defender • Azure App. Insights • Azure Chaos Studio • GitHub • Azure DevOps • Azure Monitor • GitHub • Azure DevOps • GitHub • Azure DevOps • Azure API Center • Azure Deployment Environments • Azure Developer CLI • Microsoft Entra ID

No content