m 365 fm のマイクロソフトナレッジナゲット今回もようこそホストを務めるミルコピーターズです 今日のテーマは誰もが耳にしたことはあるものの本当の意味で理解している人は少ないプラットフォームエンジニアリングについてです 開発者と運用チームがシームレスに連携するというデブオプスは聞いたことがあるでしょうしかしその約束はどこかでほころんでしまいました 開発者が運用作業までになるようになりシステムは破綻したのですこのエピソードを聞き終える頃にはデブオプスの何が問題だったのか 内部開発者プラットフォームの正体チームを導くゴールデンパスの仕組みそして優秀なエンジニアリングチームがなぜそれを構築しているのかが理解できるはずですデブオプスが残した混乱まずは原点に立ち返ってみましょう デブオプスは開発者と運用者の間の壁を取り払うというシンプルで素晴らしい目標を掲げていましたコードを投げて祈るだけの時代は終わりです シフトレフトによりテストセキュリティ運用をプロセスの前段階に移行しました配信の高速化引き継ぎの削減そして責任の明確化を目指したのです 理論上は完璧に見えましたしかし実際には何かが間違っていましたシフトレフトは責任を移しただけでなく積み重ねてしまったのです 以前はコードを書くだけだった開発者が今ではインフラセキュリティ監視kubernetes ci cd パイプラインシークレット管理 さらに聞いたこともないような15のクラウドサービスまで管理しなければならなくなりましたこれらすべてを本来の製品開発と並行して一人でこなしているのです 実際の現場はどうなっているのでしょうかあるチームが新機能テスト用の環境を立ち上げたいとします デブオプス以前ならチケットを切って待つだけでしたデブオプス以降すべて自己責任となり理論上は良さそうですが今ではテラフォーム モジュールを書きkubernetesクラスターを構成しネットワーク設定を行い監視を接続し シークレット管理を考えセキュリティポリシーを適用しなければなりませんかつて誰かが1時間でこなしたチケット作業が今では開発者の3日間の時間を奪っています 本来の製品コードをかけない3日間です彼らはyamlファイルと格闘しロードバランサーがトラフィックを正しく振り分けられない 原因をデバッグしています精神的な負担は計り知れませんすべてのチームが個別にパイプライン デプロイ用スクリプト監視ダッシュボードを構築することになりますそして誰もが手一杯のため妥協が生じます 金曜の締め切りに追われセキュリティがおざなりになりますテスト環境を落とすのを忘れ誰にも気づかれないままクラウド料金が倍になります そして午前2時にシステムが壊れた時構築した開発者本人しか直せないのですこれは持続不可能ですがなぜ今これほど重要なのかその理由を説明しましょう クラウドの複雑性は増すばかりです毎年より多くのサービスツールそして決断が求められているのです現在 ai コーディングツールにより開発者はこれまでより早く1日あたり10倍20倍 時には30倍ものコードを出荷できるようになりましたしかしそのすべてのコードには依然としてインフラセキュリティ監視が必要です より良いシステムがないままコードだけが増えれば混沌が加速するだけですyamlとテラフォームに溺れていると感じているならそれはあなただけではありません これは個人の失敗ではありませんシステムの問題なのです既存のモデルはプラットフォームエンジニアリングの本質を損なってしまいました ではどうすれば解決できるのでしょうかそれがプラットフォームエンジニアリングです最もシンプルな考え方を紹介しましょう この専門分野は開発者の代わりに複雑さを吸収する内部レイヤーを作成します大きなオフィスビルに入る場面を想像してみてください 誰がどのフロアにアクセスできるかどのセキュリティバッジが有効か非常口はどこかといった心配をする必要はありません 受付デスクがすべてを代行してくれるのであなたはただ入って仕事に取り掛かるだけですプラットフォームエンジニアリングは開発者に対してまさにそれを行います すべての開発者がクバネテステラフォームネットワークセキュリティの専門家になる必要はなく中央のプラットフォームチームがその複雑さをすべて管理するレイヤーを作成します 開発者はシンプルなインターフェースを使いボタンをクリックしコマンドを実行しフォームに記入するだけであとはプラットフォームがすべて処理します しかし重要なのはこれがデブオプスとは異なるという点ですデブオプスはすべてのチームに独自のインフラを管理するよう求めましたが プラットフォームエンジニアリングはそれが燃え尽き症候群の原因になると考えますその代わりプラットフォームチームは舗装された道路 つまり一般的タスクを処理するための標準化されテストされた安全な方法を提供します彼らは道路を構築保守しプロダクトチームはその上を走るだけです プラットフォームエンジニアリングの革新的成果は内部開発者プラットフォームidpと呼ばれるものです これは反復的な作業をすべて自動化するセルフサービスシステムだと考えてくださいインフラのプロビジョニングci cd パイプラインセキュリティチェック監視などすべてが組み込まれ標準化されています具体例を見てみましょう プラットフォームがない場合開発者が新しいサービスをデプロイするにはインフラ設定パイプライン作成監視設定に何日も費やすことになります idp があれば ui でデプロイをクリックするか単一のコマンドを実行するだけでプロビジョニングテスト監視デプロイがすべて数分で完了します ではこれによって何が変わるのでしょうかあなたはインフラの何でもやから解放され本来のプロダクトの専門家になれるのです テラフォームの状態ファイルが破損した原因をデバッグする代わりに顧客にとって重要な機能を構築するという本来の仕事に戻れるのですそれこそがこの取り組みの目的なのです内部開発者プラットフォームをわかりやすく解説します それでは内部開発者プラットフォームとは一体何なのか詳細を見ていきましょうそれはすべてを一つのシステムに統合するエンジンです ci cd パイプラインインフラテンプレートセキュリティポリシー監視そしてログ管理6つもの別々のツールを自分でつなぎ合わせる必要はありません 例え話をしましょうゼロから料理するのと自動販売機を使うのとの違いですゼロから料理するには食材を買い野菜を切り調味料を測り 火加減を見張らなければなりません多くの決断と手順が必要で失敗するリスクもたくさんあります自動販売機ならボタンを一つ押すだけで結果が得られます 決断は少なく結果は早く品質も一定です idp 内部開発者プラットフォームはまさにその自動販売機です開発者はインフラがどう構築されるかやシークレットがどこに保存されるかを知る必要はありません ただボタンを押すだけですその自動販売機の中身は何でしょうか中核となる構成要素はかなり標準的なものです 一貫したビルドのためのci cd テンプレート自動で環境を構築するインフラプロビジョニング設定ファイルに認証情報が漏れないようにするシークレット管理 そしてトラブルシューティングに慌てなくて済む可観測性を備えたログ記録ですこれらすべてがプラットフォームチームによって事前設定テスト保守されています 具体例を挙げます開発者がコマンドラインで新しいサービスを作成と入力するかポータルでボタンをクリックします裏側では idp が適切な構造を持つ新しいリポジトリを立ち上げ テストを自動実行するビルドパイプラインを構築し開発環境にサービスをデプロイしてログ付きのヘルスチェック用エンドポイントを追加します これらすべてが数分で完了します開発者はテラフォームファイルやクバネテスマニフェストを一度も触ることはありませんコマンドを入力しただけで稼働中のサービスが出来上がります なぜこれが重要なのでしょうか最大の理由は一貫性です各チームが独自のパイプラインを作り独自のデプロイスクリプトを書くと個別の設定だらけになってしまいます 50のサービスがあれば50通りのやり方がある状態です何かが壊れた時作った本人以外には誰もデバッグできません もしその人が退職していたら運を天に任せるしかありませんidpはすべてのサービスに同じパターンを適用しすべてのデプロイに同じパイプラインを使い すべてのチームに共通のデフォルト設定を提供することでその問題を解消します何か壊れてもパターンは共通で修正方法もドキュメント化されています ではこれがあなたにとって何を意味するのでしょうかもしあなたの組織に50のチームがありそれぞれがバラバラの方法でデプロイしているなら idp がその解決策です チームの自立性が失われるわけではありません退屈で反復的なミスの起きやすい作業が標準化されることで創造的で面白い仕事に 集中できるようになるのですこれは十分価値のあるトレードオフですゴールデンパスは道であり決して折りではありません ゴールデンパスについてお話ししましょう名前は聞いたことがあるかもしれませんがその考え方はシンプルですゴールデンパスとは推奨された事前構築済みのワークフローのことで正しいことを最も簡単に 行えるようにするものですプラットフォームチームはこう言います私たちはこうすることを推奨します テスト済みで動作も確認済み何かあっても私たちがサポートします推奨という言葉に注目してくださいゴールデンパスは強制ではありません 必要であればパスから外れても構いませんがそのパスは高速で安全なデフォルトなのですすでに稼働しておりサポートもドキュメントも整備されています すべてをゼロから考え出す必要はありませんガードレールではなく線路のようなものだと考えてくださいガードレールは衝突した時に助けてくれるものです 反応的で崖から落ちるのを防いでくれますが進む方向を教えてはくれません線路はルートに沿ってスムーズに導いてくれるのでどこで曲がるか迷う必要はありません ゴールデンパスとはこの線路のことです失敗した時に助けるだけでなく前へと進めてくれるのです多くのチームがここで勘違いをしています 開発者のためではなくプラットフォームチームのためのゴールデンパスを作ってしまうのですアーキテクチャの純粋さやセキュリティ準拠あるいはプラットフォームチーム以外には理解できない社内ルールを優先して最適化しますホワイトボード上では素晴らしい設計に見えても実際に使うとひどく使いにくいものです 開発者は静かに回避策を見つけ利用率は低下しプラットフォームチームはなぜ誰も努力を評価してくれないのかと悩むことになります解決策はシンプルですが実行するのは難しいものです 脱出発地が必要なのですパスが開発者のユースケースに合わない場合そこから外れる手段が必要ですデフォルトを上書きしたり独自のパイプラインを持ち込んだりプラットフォームを完全に外れる手段です そしてここからが重要な部分です開発者がパスから外れることは失敗ではなくフィードバックなのです開発者がゴールデンパスを離れるたびにそれは現実的な課題を教えてくれています パスに足りない機能があるかあるいはそのユースケースがそもそもパスに適していないかのどちらかですどちらのシグナルも価値があります 優れたゴールデンパスの実際はこのような姿をしていますチームが新しいバックエンドサービスをデプロイしたいとします彼らはそのパスを利用します 適切な構造を持つテンプレートリポジトリテスト済みの標準ci cd パイプライン組み込みのログと監視そして何かあった時のワンクリックロールバックが提供されますすべてが数日ではなく数分で完了します またパスはプラットフォームチームが保守しているため問題が起きても彼らが解決してくれます開発者がパイプラインデバッグの専門家になる必要はありません これによって予期せぬトラブルが減りますパスはテスト済みなので迅速にリリースできますセキュリティと監視が組み込まれているのでより安全にリリースできます ワンクリックでロールバックできるので自信を持ってリリースできますパスはあなたを制限するためではなくあなたを助けるために存在しますぜひ使ってください 認知負荷を軽減することそこにこそ真のメリットがあるのですプラットフォームが煩雑な作業を引き受ければ開発者は本来のコード作成に集中できます クバネテスのバージョンを気にする必要はありませんクラウド事業者のAPI変更の度にテラフォームモジュールを更新する必要もありません 彼らは機能開発に専念するだけですプラットフォームエンジニアがその複雑さを吸収するからです 彼らは開発者に見せるべきものと隠しておくべきものを取捨選択しますこれは単なる技術的な話ではなく重要な設計上の選択です 重要なのはプラットフォームの利用者にとって価値のある詳細と単なるノイズになる情報の見極めです具体的な例を挙げましょう 新しいサービスをデプロイする際開発者はクラスターのノードサイズやインスタンスタイプ オートスケーリングの敷地などを気にしません彼らが気にするのはサービスが動作するかそして応答速度はどうかだけです そこでプラットフォームはアプリの階層に基づいてこれらすべてを事前設定します小規模サービスならそれに適した設定を提供します 高トラフィックなサービスならまた別の設定を提供します開発者がそうした選択をする必要はないため選択肢を提示することもしません なぜこれが重要なのでしょうか一度に15もの懸念事項を抱え込まなければ開発者の燃え尽きは減るからです 成熟したプラットフォームチームの中には認知負荷を半分近く削減したところもあります精神的な負担が40%から50%も減るのです これは大きな変化です仕事終わりに余力を残せるかそれとも夜の10時に端末と寝めっこしてパイプラインの失敗原因を探るかという違いですしかしここに警告があります 幻想を作り上げてはいけません一部のプラットフォームチームはある穴に陥っています内部で何が起きているのかを理解する術を与えずただ設定を隠してしまうのです それは抽象化ではなく誤魔化しであり何かが起きた瞬間にしっぺ返しを食らいます開発者は見通せない壁にぶつかりプラットフォームは突然自分たちに敵対するブラックボックスのように感じられます これをリーキーアブストラクション不完全な抽象化と呼びます複雑さを隠したつもりでも結局はその複雑さが漏れ出てしまうのです データベースが遅くなったりデプロイが失敗したりセキュリティポリシーが予期せぬ挙動をしたりしますプラットフォームが何の情報も与えてこなかったせいで開発者は状況を把握するためのメンタルモデルすら持っていません 透明性は不可欠です必要な時に必要な情報を開発者にしっかりと提示してくださいただすべてを隠してうまくいくことを祈るようなやり方は避けるべきです その結果コンテキストスイッチが減りフロー状態に入りやすくなります朝からクバネテスのアップグレードが必要かと悩む代わりに来週締め切りの機能開発から1日を始められます 自分の仕事が本来の仕事を取り戻すのですプラットフォームをプロダクトとして扱うこと 今日は社内ツールの仕組みを根元から変えるテーマについてお話しします多くの人はプラットフォームチームは単なるインフラチームだと思っています それは違いますプラットフォームチームはプロダクトチームでありそのプラットフォームを使う開発者こそがチケットを切る相手ではなく顧客なのですその考え方がすべてを変えます プロダクトチームは顧客と対話し何が実際に苦痛なのかを見つけ出し真のニーズに基づいて機能を優先順位付けし採用率を測定します彼らは何かを作って放置するのではなく改善を繰り返します ではプロダクトチームは実際どのようなものなのでしょうか彼らはヘルプデスクのような運用はしません 開発者がチケットを発行しプラットフォームチームがそれを手動で処理するそれはプラットフォームエンジニアリングではなく単なる中央集権的な運用の呼び名を変えただけのものです それではスケールせず認知負荷も軽減されずボトルネックを別のチームに移すだけです彼らが代わりに言っていることはこうです 彼らは適切な指標を測定します最初のデプロイまでの時間新メンバーのオンボーディング速度開発者の満足度スコアなどですこれらはプラットフォームが人々の助けになっているのかそれとも複雑さを増しているだけなのかを判断する指標ですスポティファイが良い例です 彼らのプラットフォームチームは適切なプロダクト組織のように運営されていますロードマップやokrを策定し何が機能していて何が機能していないかについて開発者と対話しています 彼らはプラットフォームを毎日使い続けてもらうための価値を提供し続けるものとして扱っておりそれが確信となる考え方です誰も使わないプラットフォームは単なるプロジェクトであり 隅で誇りをかぶるだけです採用率こそが究極の検証結果なのです開発者が自作のツールではなくあなたのプラットフォームを選んだなら成功したと言えるでしょう もし開発者がそれを避けるならどれほど技術的に優れていても解決はできませんこれはあなたにとって何を意味するのでしょうか もしプラットフォームを構築するならアーキテクチャ図やクバネテスクラスターテラフォームモジュールから始めるのではなくユーザーインタビューから始めるべきです プラットフォームを利用する開発者と話しましょう実際に何が苦痛なのかを見つけ出してください現実的な問題を一つ解決するものを作りそこから繰り返すのです それこそが人々が本当に使いたいと思うものを作る方法ですなぜ今なのでしょうか ai の波ですではなぜ今この話をしているのでしょうか なぜ5年前ではなかったのでしょうかその答えは ai ですgit hubco パイロットのような ai コーディングツールにより開発者はかつてないスピードでコードをリリースできるようになりました数年前と比べて1日あたり10倍20倍のコードを書くことが可能です それは素晴らしいことであり実際にそうですしかしここには落とし穴がありますそのすべてのコードには依然としてインフラが必要です セキュリティも必要ですデプロイテスト運用も不可欠ですシステムが改善されないままコードだけが増えても早くなるわけではありません 単に混乱が加速するだけですもしあなたのチームの開発者がすでに yaml やテラフォームに溺れているなら ai では解決できませんそれはサポートが必要なコードをより多く生成しながらより早く溺れていくだけを意味するのです現在約55%の組織がすでに何らかの形でプラットフォームエンジニアリングを導入しています ガートナー社はその数が2026年末までに80%に達すると予測していますこれは緩やかなトレンドではありません今まさに起きている変化なのです 企業はプラットフォーム層なしではエンジニアリングチームを拡張できないと気づき始めていますai のスピードでコードをリリースする時代においてすべてのチームがすべてを自前で行うという古いやり方は通用しません 多くの人が見落としていることがありますai はプラットフォームの必要性を生み出すだけではありません プラットフォームの構築にも役立つのですプラットフォームチームは ai を使ってテラフォームモジュールの生成やドキュメント作成パイプラインのデバッグを行っています 緊急性を生み出しているその技術こそがそれを解決するツールも提供しているのですここで少し注意点があります ai はあなたにあるものを増幅させる力があります優れたアーキテクチャやよく設計されたプラットフォームなど基盤がしっかりしていれば ai は生産性を2から3倍に高めてくれますしかし基盤が脆弱であれば ai はより大きなミスをより早く犯す手助けをしてしまうだけです 不適切な設定セキュリティホール壊れたインフラそれらすべてが誰にも気づかれる前に本番環境へリリースされてしまいますai は脆弱な基盤を修正してはくれませんむしろそれを露呈させてしまうのです 実例を上げましょう優れた内部開発者プラットフォームを持つ企業ではエンジニア以外でも安全にai ツールをデプロイできますプラットフォームがガードレールを提供してくれるからです セキュリティポリシーも強制されますインフラもプラットフォームが処理しますそのためプロダクトマネージャーはクバネテスやクラウドネットワークを理解していなくても ai 搭載プロトタイプを立ち上げられますこれは強力なことですまさに ai 時代に対応できるチームと取り残されていくチームを分ける境界線となります あなたにとってこれは何を意味するのでしょうかプラットフォームを構築するための猶予期間は終わりつつあります技術が消えていくからではなくプラットフォームを持つチームと持たないチームの格差が急速に広がっているからです 躊躇している毎月すでにプラットフォームを持つチームはさらに先へと進んでいます彼らはより早くリリースし燃え尽きることなく新しいツールにも迅速に適応しています プラットフォームを持たないチームはどんどん遅れをとっています

始めるべきでしょうかもし最初から大規模な内部開発者プラットフォームを構築する必要があると考えているならそれはやめてくださいそれはプロジェクトを始める前に頓挫させる最短の方法です チームが犯す最大の過ちは一度にすべてを構築しようとすることです完璧なプラットフォームを設計しようと何ヶ月も費やし思いつく限りの機能を詰め込もうとします そしてリリースしても何の反応もありません誰も使わないのですなぜでしょうか誰も求めていない問題を解決し使い始めるために少差しほどのマニュアルを読む必要があるからです いいですかそんなことはしてはいけませんまずは小さく始めましょうアーキテクトでもマネージャーでも自分自身の思い込みでもなく開発者と直接話してください 毎日機能を書いている人たちを見つけましょうどこが辛いのか彼らに聞いてみるのです最も時間がかかり多くの人を苛立たせ本来あるべき姿で運用されていないワークフローを見つけ出してください そして最初から最後まで通じるゴールデンパスを一つだけ構築します例えば新しいマイクロサービスの作成とデプロイかもしれません あるいはゼロからの開発環境構築かもしれませんもしかすると何も壊さずにホットフィックスを本番環境へ反映させることかもしれません最も痛みを伴うものを選びその痛みを解消できるパスを構築してください 作り上げ実際のユーザーでテストしフィードバックを集め反復改善しますそれができたら次のパスを一つまた一つと追加していきましょう 一度にすべての問題を解決しようとしないでください一つの問題を徹底的に解決しその勢いを全身の力に変えるのですうまくいっているかどうかどう判断すればいいのでしょうか 正しい指標を測定することですアイデアから初回のデプロイまでの時間削減した手作業のステップ数そして自発的な利用率です開発者が自分たちで構築するよりもあなたのパスを選ぶならそれは成功です もし避けられているなら声に耳を傾け方向転換しましょう避けるべき落とし穴があります プラットフォームの使用を強制しないでください開発者にパスの使用を強要すれば彼らは反発します 彼らは回避策を見つけ出すでしょう独自のスクリプトを構築しあなたに隠すようになりますそうではなくそのパスを使いやすくしてください 他の手段よりも高速に動作するようにします誰の目にも明らかな選択肢にすべきですが唯一の選択肢にしてはいけません 最初のパスが常に最も困難なものですそれはプロダクト思考のすべてを教えてくれます ユーザーとの対話方法優先順位のつけ方を学びそして人々が本当に求めているものを作ることがただ動くものを作ることよりもはるかに難しいことを理解するでしょう しかし一度やり遂げれば2つ目のパスはより簡単になり3つ目はさらに容易になりますプラットフォームは一度に作り上げるものではありません 一つずつパスを積み重ねて構築していくのですシステムとはそういうものです プラットフォームエンジニアリングとは開発者が舗装された道を走り銅の穴を埋める作業に追われず運転に集中できるようにすることです インフラとの戦いに疲れているならまずはチーム内のゴールデンパスを一つたった一つ見つけることから始めてください この情報が必要な人に共有し今後もこのような解説動画が見たい方は登録をお願いします