WEBVTT 00:00:00.000 --> 00:00:09.260 m 365 fm のマイクロソフトナレッジナゲット今回もようこそホストを務めるミルコピーターズです 今日のテーマは誰もが耳にしたことはあるものの本当の意味で理解している人は少ない 00:00:09.260 --> 00:00:14.820 プラットフォームエンジニアリングについてです 開発者と運用チームがシームレスに連携するというデブオプスは聞いたことがあるでしょう 00:00:14.820 --> 00:00:20.580 しかしその約束はどこかでほころんでしまいました 開発者が運用作業までになるようになりシステムは破綻したのです 00:00:20.580 --> 00:00:31.020 このエピソードを聞き終える頃にはデブオプスの何が問題だったのか 内部開発者プラットフォームの正体チームを導くゴールデンパスの仕組みそして優秀なエンジニアリングチームがなぜそれを構築しているのかが理解できるはずです 00:00:31.020 --> 00:00:39.020 デブオプスが残した混乱まずは原点に立ち返ってみましょう デブオプスは開発者と運用者の間の壁を取り払うというシンプルで素晴らしい目標を掲げていました 00:00:39.020 --> 00:00:44.900 コードを投げて祈るだけの時代は終わりです シフトレフトによりテストセキュリティ運用をプロセスの前段階に移行しました 00:00:44.900 --> 00:00:51.880 配信の高速化引き継ぎの削減そして責任の明確化を目指したのです 理論上は完璧に見えましたしかし実際には何かが間違っていました 00:00:51.880 --> 00:00:59.760 シフトレフトは責任を移しただけでなく積み重ねてしまったのです 以前はコードを書くだけだった開発者が今ではインフラセキュリティ監視 00:00:59.760 --> 00:01:06.560 kubernetes ci cd パイプラインシークレット管理 さらに聞いたこともないような15のクラウドサービスまで管理しなければならなくなりました 00:01:06.560 --> 00:01:12.320 これらすべてを本来の製品開発と並行して一人でこなしているのです 実際の現場はどうなっているのでしょうか 00:01:12.320 --> 00:01:17.760 あるチームが新機能テスト用の環境を立ち上げたいとします デブオプス以前ならチケットを切って待つだけでした 00:01:17.760 --> 00:01:22.540 デブオプス以降すべて自己責任となり理論上は良さそうですが今ではテラフォーム モジュールを書き 00:01:22.540 --> 00:01:29.220 kubernetesクラスターを構成しネットワーク設定を行い監視を接続し シークレット管理を考えセキュリティポリシーを適用しなければなりません 00:01:29.220 --> 00:01:36.380 かつて誰かが1時間でこなしたチケット作業が今では開発者の3日間の時間を奪っています 本来の製品コードをかけない3日間です 00:01:36.380 --> 00:01:42.720 彼らはyamlファイルと格闘しロードバランサーがトラフィックを正しく振り分けられない 原因をデバッグしています精神的な負担は計り知れません 00:01:42.720 --> 00:01:46.680 すべてのチームが個別にパイプライン デプロイ用スクリプト監視ダッシュボードを構築することになります 00:01:46.680 --> 00:01:52.120 そして誰もが手一杯のため妥協が生じます 金曜の締め切りに追われセキュリティがおざなりになります 00:01:52.120 --> 00:02:00.320 テスト環境を落とすのを忘れ誰にも気づかれないままクラウド料金が倍になります そして午前2時にシステムが壊れた時構築した開発者本人しか直せないのです 00:02:00.320 --> 00:02:09.080 これは持続不可能ですがなぜ今これほど重要なのかその理由を説明しましょう クラウドの複雑性は増すばかりです毎年より多くのサービスツールそして決断が求められているのです 00:02:09.080 --> 00:02:14.880 現在 ai コーディングツールにより開発者はこれまでより早く1日あたり10倍20倍 時には30倍ものコードを出荷できるようになりました 00:02:14.880 --> 00:02:21.680 しかしそのすべてのコードには依然としてインフラセキュリティ監視が必要です より良いシステムがないままコードだけが増えれば混沌が加速するだけです 00:02:21.680 --> 00:02:30.160 yamlとテラフォームに溺れていると感じているならそれはあなただけではありません これは個人の失敗ではありませんシステムの問題なのです既存のモデルはプラットフォームエンジニアリングの本質を損なって 00:02:30.160 --> 00:02:33.960 しまいました ではどうすれば解決できるのでしょうかそれがプラットフォームエンジニアリングです 00:02:33.960 --> 00:02:39.480 最もシンプルな考え方を紹介しましょう この専門分野は開発者の代わりに複雑さを吸収する内部レイヤーを作成します 00:02:39.480 --> 00:02:46.180 大きなオフィスビルに入る場面を想像してみてください 誰がどのフロアにアクセスできるかどのセキュリティバッジが有効か非常口はどこかといった心配をする 00:02:46.180 --> 00:02:50.260 必要はありません 受付デスクがすべてを代行してくれるのであなたはただ入って仕事に取り掛かるだけです 00:02:50.260 --> 00:02:58.200 プラットフォームエンジニアリングは開発者に対してまさにそれを行います すべての開発者がクバネテステラフォームネットワークセキュリティの専門家になる必要はなく 00:02:58.200 --> 00:03:05.620 中央のプラットフォームチームがその複雑さをすべて管理するレイヤーを作成します 開発者はシンプルなインターフェースを使いボタンをクリックしコマンドを実行し 00:03:05.620 --> 00:03:10.940 フォームに記入するだけであとはプラットフォームがすべて処理します しかし重要なのはこれがデブオプスとは異なるという点です 00:03:10.940 --> 00:03:15.760 デブオプスはすべてのチームに独自のインフラを管理するよう求めましたが プラットフォームエンジニアリングはそれが燃え尽き症候群の原因になると考えます 00:03:15.760 --> 00:03:21.360 その代わりプラットフォームチームは舗装された道路 つまり一般的タスクを処理するための標準化されテストされた安全な方法を提供します 00:03:21.360 --> 00:03:28.460 彼らは道路を構築保守しプロダクトチームはその上を走るだけです プラットフォームエンジニアリングの革新的成果は内部開発者プラットフォーム 00:03:28.460 --> 00:03:34.240 idpと呼ばれるものです これは反復的な作業をすべて自動化するセルフサービスシステムだと考えてください 00:03:34.240 --> 00:03:40.640 インフラのプロビジョニングci cd パイプラインセキュリティチェック監視などすべてが組み込まれ標準化されています 00:03:40.640 --> 00:03:47.100 具体例を見てみましょう プラットフォームがない場合開発者が新しいサービスをデプロイするにはインフラ設定パイプライン作成 00:03:47.100 --> 00:03:54.020 監視設定に何日も費やすことになります idp があれば ui でデプロイをクリックするか単一のコマンドを実行するだけで 00:03:54.020 --> 00:04:00.400 プロビジョニングテスト監視デプロイがすべて数分で完了します ではこれによって何が変わるのでしょうか 00:04:00.400 --> 00:04:09.520 あなたはインフラの何でもやから解放され本来のプロダクトの専門家になれるのです テラフォームの状態ファイルが破損した原因をデバッグする代わりに顧客にとって重要な機能を構築するという本来の仕事に戻れるのです 00:04:09.520 --> 00:04:16.640 それこそがこの取り組みの目的なのです内部開発者プラットフォームをわかりやすく解説します それでは内部開発者プラットフォームとは一体何なのか詳細を見ていきましょう 00:04:16.640 --> 00:04:23.460 それはすべてを一つのシステムに統合するエンジンです ci cd パイプラインインフラテンプレートセキュリティポリシー監視そしてログ管理 00:04:23.460 --> 00:04:30.840 6つもの別々のツールを自分でつなぎ合わせる必要はありません 例え話をしましょうゼロから料理するのと自動販売機を使うのとの違いです 00:04:30.840 --> 00:04:38.480 ゼロから料理するには食材を買い野菜を切り調味料を測り 火加減を見張らなければなりません多くの決断と手順が必要で失敗するリスクもたくさんあります 00:04:38.480 --> 00:04:46.660 自動販売機ならボタンを一つ押すだけで結果が得られます 決断は少なく結果は早く品質も一定です idp 内部開発者プラットフォームはまさにその自動販売機です 00:04:46.660 --> 00:04:53.680 開発者はインフラがどう構築されるかやシークレットがどこに保存されるかを知る必要はありません ただボタンを押すだけですその自動販売機の中身は何でしょうか 00:04:53.680 --> 00:05:01.100 中核となる構成要素はかなり標準的なものです 一貫したビルドのためのci cd テンプレート自動で環境を構築するインフラプロビジョニング 00:05:01.100 --> 00:05:07.600 設定ファイルに認証情報が漏れないようにするシークレット管理 そしてトラブルシューティングに慌てなくて済む可観測性を備えたログ記録です 00:05:07.600 --> 00:05:17.580 これらすべてがプラットフォームチームによって事前設定テスト保守されています 具体例を挙げます開発者がコマンドラインで新しいサービスを作成と入力するかポータルでボタンをクリックします 00:05:17.580 --> 00:05:25.620 裏側では idp が適切な構造を持つ新しいリポジトリを立ち上げ テストを自動実行するビルドパイプラインを構築し開発環境にサービスをデプロイして 00:05:25.620 --> 00:05:33.600 ログ付きのヘルスチェック用エンドポイントを追加します これらすべてが数分で完了します開発者はテラフォームファイルやクバネテスマニフェストを一度も触ることはありません 00:05:33.600 --> 00:05:41.440 コマンドを入力しただけで稼働中のサービスが出来上がります なぜこれが重要なのでしょうか最大の理由は一貫性です各チームが独自のパイプラインを作り 00:05:41.440 --> 00:05:47.900 独自のデプロイスクリプトを書くと個別の設定だらけになってしまいます 50のサービスがあれば50通りのやり方がある状態です 00:05:47.900 --> 00:05:54.160 何かが壊れた時作った本人以外には誰もデバッグできません もしその人が退職していたら運を天に任せるしかありません 00:05:54.160 --> 00:06:00.820 idpはすべてのサービスに同じパターンを適用しすべてのデプロイに同じパイプラインを使い すべてのチームに共通のデフォルト設定を提供することでその問題を解消します 00:06:00.820 --> 00:06:06.140 何か壊れてもパターンは共通で修正方法もドキュメント化されています ではこれがあなたにとって何を意味するのでしょうか 00:06:06.140 --> 00:06:12.340 もしあなたの組織に50のチームがありそれぞれがバラバラの方法でデプロイしているなら idp がその解決策です チームの自立性が失われるわけではありません 00:06:12.340 --> 00:06:19.240 退屈で反復的なミスの起きやすい作業が標準化されることで創造的で面白い仕事に 集中できるようになるのですこれは十分価値のあるトレードオフです 00:06:19.240 --> 00:06:25.980 ゴールデンパスは道であり決して折りではありません ゴールデンパスについてお話ししましょう名前は聞いたことがあるかもしれませんがその考え方はシンプルです 00:06:25.980 --> 00:06:30.400 ゴールデンパスとは推奨された事前構築済みのワークフローのことで正しいことを最も簡単に 行えるようにするものです 00:06:30.400 --> 00:06:37.460 プラットフォームチームはこう言います私たちはこうすることを推奨します テスト済みで動作も確認済み何かあっても私たちがサポートします 00:06:37.460 --> 00:06:45.300 推奨という言葉に注目してくださいゴールデンパスは強制ではありません 必要であればパスから外れても構いませんがそのパスは高速で安全なデフォルトなのです 00:06:45.300 --> 00:06:52.500 すでに稼働しておりサポートもドキュメントも整備されています すべてをゼロから考え出す必要はありませんガードレールではなく線路のようなものだと考えてください 00:06:52.500 --> 00:07:00.240 ガードレールは衝突した時に助けてくれるものです 反応的で崖から落ちるのを防いでくれますが進む方向を教えてはくれません線路はルートに沿ってスムーズに導いてくれるので 00:07:00.240 --> 00:07:06.640 どこで曲がるか迷う必要はありません ゴールデンパスとはこの線路のことです失敗した時に助けるだけでなく前へと進めてくれるのです 00:07:06.640 --> 00:07:11.920 多くのチームがここで勘違いをしています 開発者のためではなくプラットフォームチームのためのゴールデンパスを作ってしまうのです 00:07:11.920 --> 00:07:17.260 アーキテクチャの純粋さやセキュリティ準拠あるいはプラットフォームチーム以外には理解できない社内ルールを優先して最適化します 00:07:17.260 --> 00:07:25.660 ホワイトボード上では素晴らしい設計に見えても実際に使うとひどく使いにくいものです 開発者は静かに回避策を見つけ利用率は低下しプラットフォームチームはなぜ誰も努力を評価してくれないのかと悩むことになります 00:07:25.660 --> 00:07:32.840 解決策はシンプルですが実行するのは難しいものです 脱出発地が必要なのですパスが開発者のユースケースに合わない場合そこから外れる手段が必要です 00:07:32.840 --> 00:07:41.520 デフォルトを上書きしたり独自のパイプラインを持ち込んだりプラットフォームを完全に外れる手段です そしてここからが重要な部分です開発者がパスから外れることは失敗ではなくフィードバックなのです 00:07:41.520 --> 00:07:48.800 開発者がゴールデンパスを離れるたびにそれは現実的な課題を教えてくれています パスに足りない機能があるかあるいはそのユースケースがそもそもパスに適していないかのどちらかです 00:07:48.800 --> 00:07:55.240 どちらのシグナルも価値があります 優れたゴールデンパスの実際はこのような姿をしていますチームが新しいバックエンドサービスをデプロイしたいとします 00:07:55.240 --> 00:08:04.800 彼らはそのパスを利用します 適切な構造を持つテンプレートリポジトリテスト済みの標準ci cd パイプライン組み込みのログと監視そして何かあった時のワンクリックロールバックが提供されます 00:08:04.800 --> 00:08:11.100 すべてが数日ではなく数分で完了します またパスはプラットフォームチームが保守しているため問題が起きても彼らが解決してくれます 00:08:11.100 --> 00:08:18.300 開発者がパイプラインデバッグの専門家になる必要はありません これによって予期せぬトラブルが減りますパスはテスト済みなので迅速にリリースできます 00:08:18.300 --> 00:08:25.180 セキュリティと監視が組み込まれているのでより安全にリリースできます ワンクリックでロールバックできるので自信を持ってリリースできますパスはあなたを制限するためではなく 00:08:25.180 --> 00:08:31.360 あなたを助けるために存在しますぜひ使ってください 認知負荷を軽減することそこにこそ真のメリットがあるのです 00:08:31.360 --> 00:08:37.320 プラットフォームが煩雑な作業を引き受ければ開発者は本来のコード作成に集中できます クバネテスのバージョンを気にする必要はありません 00:08:37.320 --> 00:08:42.620 クラウド事業者のAPI変更の度にテラフォームモジュールを更新する必要もありません 彼らは機能開発に専念するだけです 00:08:42.620 --> 00:08:47.280 プラットフォームエンジニアがその複雑さを吸収するからです 彼らは開発者に見せるべきものと隠しておくべきものを取捨選択します 00:08:47.280 --> 00:08:54.240 これは単なる技術的な話ではなく重要な設計上の選択です 重要なのはプラットフォームの利用者にとって価値のある詳細と単なるノイズになる情報の見極めです 00:08:54.240 --> 00:09:01.660 具体的な例を挙げましょう 新しいサービスをデプロイする際開発者はクラスターのノードサイズやインスタンスタイプ オートスケーリングの敷地などを気にしません 00:09:01.660 --> 00:09:08.140 彼らが気にするのはサービスが動作するかそして応答速度はどうかだけです そこでプラットフォームはアプリの階層に基づいてこれらすべてを事前設定します 00:09:08.140 --> 00:09:12.540 小規模サービスならそれに適した設定を提供します 高トラフィックなサービスならまた別の設定を提供します 00:09:12.540 --> 00:09:17.120 開発者がそうした選択をする必要はないため選択肢を提示することもしません なぜこれが重要なのでしょうか 00:09:17.120 --> 00:09:24.160 一度に15もの懸念事項を抱え込まなければ開発者の燃え尽きは減るからです 成熟したプラットフォームチームの中には認知負荷を半分近く削減したところもあります 00:09:24.160 --> 00:09:33.000 精神的な負担が40%から50%も減るのです これは大きな変化です仕事終わりに余力を残せるかそれとも夜の10時に端末と寝めっこしてパイプラインの失敗原因を探るかという違いです 00:09:33.000 --> 00:09:38.640 しかしここに警告があります 幻想を作り上げてはいけません一部のプラットフォームチームはある穴に陥っています 00:09:38.640 --> 00:09:46.840 内部で何が起きているのかを理解する術を与えずただ設定を隠してしまうのです それは抽象化ではなく誤魔化しであり何かが起きた瞬間にしっぺ返しを食らいます 00:09:46.840 --> 00:09:53.680 開発者は見通せない壁にぶつかりプラットフォームは突然自分たちに敵対するブラックボックスのように感じられます これをリーキーアブストラクション不完全な抽象化と呼びます 00:09:53.680 --> 00:10:00.680 複雑さを隠したつもりでも結局はその複雑さが漏れ出てしまうのです データベースが遅くなったりデプロイが失敗したりセキュリティポリシーが予期せぬ挙動をしたりします 00:10:00.680 --> 00:10:08.880 プラットフォームが何の情報も与えてこなかったせいで開発者は状況を把握するためのメンタルモデルすら持っていません 透明性は不可欠です必要な時に必要な情報を開発者にしっかりと提示してください 00:10:08.880 --> 00:10:15.060 ただすべてを隠してうまくいくことを祈るようなやり方は避けるべきです その結果コンテキストスイッチが減りフロー状態に入りやすくなります朝から 00:10:15.060 --> 00:10:22.800 クバネテスのアップグレードが必要かと悩む代わりに来週締め切りの機能開発から1日を始められます 自分の仕事が本来の仕事を取り戻すのです 00:10:22.800 --> 00:10:28.420 プラットフォームをプロダクトとして扱うこと 今日は社内ツールの仕組みを根元から変えるテーマについてお話しします 00:10:28.420 --> 00:10:37.240 多くの人はプラットフォームチームは単なるインフラチームだと思っています それは違いますプラットフォームチームはプロダクトチームでありそのプラットフォームを使う開発者こそがチケットを切る相手ではなく顧客なのです 00:10:37.240 --> 00:10:44.760 その考え方がすべてを変えます プロダクトチームは顧客と対話し何が実際に苦痛なのかを見つけ出し真のニーズに基づいて機能を優先順位付けし採用率を測定します 00:10:44.760 --> 00:10:50.300 彼らは何かを作って放置するのではなく改善を繰り返します ではプロダクトチームは実際どのようなものなのでしょうか 00:10:50.300 --> 00:10:56.960 彼らはヘルプデスクのような運用はしません 開発者がチケットを発行しプラットフォームチームがそれを手動で処理するそれはプラットフォームエンジニアリングではなく 00:10:56.960 --> 00:11:03.120 単なる中央集権的な運用の呼び名を変えただけのものです それではスケールせず認知負荷も軽減されずボトルネックを別のチームに移すだけです 00:11:03.120 --> 00:11:10.960 彼らが代わりに言っていることはこうです 彼らは適切な指標を測定します最初のデプロイまでの時間新メンバーのオンボーディング速度開発者の満足度スコアなどです 00:11:10.960 --> 00:11:15.780 これらはプラットフォームが人々の助けになっているのかそれとも複雑さを増しているだけなのかを判断する指標です 00:11:15.780 --> 00:11:20.140 スポティファイが良い例です 彼らのプラットフォームチームは適切なプロダクト組織のように運営されています 00:11:20.140 --> 00:11:28.340 ロードマップやokrを策定し何が機能していて何が機能していないかについて開発者と対話しています 彼らはプラットフォームを毎日使い続けてもらうための価値を提供し続けるものとして扱っており 00:11:28.340 --> 00:11:36.180 それが確信となる考え方です誰も使わないプラットフォームは単なるプロジェクトであり 隅で誇りをかぶるだけです採用率こそが究極の検証結果なのです 00:11:36.180 --> 00:11:43.200 開発者が自作のツールではなくあなたのプラットフォームを選んだなら成功したと言えるでしょう もし開発者がそれを避けるならどれほど技術的に優れていても解決はできません 00:11:43.200 --> 00:11:48.180 これはあなたにとって何を意味するのでしょうか もしプラットフォームを構築するならアーキテクチャ図やクバネテスクラスター 00:11:48.180 --> 00:11:55.780 テラフォームモジュールから始めるのではなくユーザーインタビューから始めるべきです プラットフォームを利用する開発者と話しましょう実際に何が苦痛なのかを見つけ出してください 00:11:55.780 --> 00:12:01.200 現実的な問題を一つ解決するものを作りそこから繰り返すのです それこそが人々が本当に使いたいと思うものを作る方法です 00:12:01.200 --> 00:12:08.100 なぜ今なのでしょうか ai の波ですではなぜ今この話をしているのでしょうか なぜ5年前ではなかったのでしょうかその答えは ai です 00:12:08.100 --> 00:12:12.840 git hubco パイロットのような ai コーディングツールにより開発者はかつてないスピードでコードをリリースできるようになりました 00:12:12.840 --> 00:12:19.760 数年前と比べて1日あたり10倍20倍のコードを書くことが可能です それは素晴らしいことであり実際にそうですしかしここには落とし穴があります 00:12:19.760 --> 00:12:25.300 そのすべてのコードには依然としてインフラが必要です セキュリティも必要ですデプロイテスト運用も不可欠です 00:12:25.300 --> 00:12:30.000 システムが改善されないままコードだけが増えても早くなるわけではありません 単に混乱が加速するだけです 00:12:30.000 --> 00:12:38.100 もしあなたのチームの開発者がすでに yaml やテラフォームに溺れているなら ai では解決できませんそれはサポートが必要なコードをより多く生成しながらより早く溺れていくだけを意味するのです 00:12:38.100 --> 00:12:46.740 現在約55%の組織がすでに何らかの形でプラットフォームエンジニアリングを導入しています ガートナー社はその数が2026年末までに80%に達すると予測しています 00:12:46.740 --> 00:12:53.960 これは緩やかなトレンドではありません今まさに起きている変化なのです 企業はプラットフォーム層なしではエンジニアリングチームを拡張できないと気づき始めています 00:12:53.960 --> 00:13:00.020 ai のスピードでコードをリリースする時代においてすべてのチームがすべてを自前で行うという古いやり方は通用しません 多くの人が見落としていることがあります 00:13:00.020 --> 00:13:04.280 ai はプラットフォームの必要性を生み出すだけではありません プラットフォームの構築にも役立つのです 00:13:04.280 --> 00:13:12.940 プラットフォームチームは ai を使ってテラフォームモジュールの生成やドキュメント作成パイプラインのデバッグを行っています 緊急性を生み出しているその技術こそがそれを解決するツールも提供しているのです 00:13:12.940 --> 00:13:17.300 ここで少し注意点があります ai はあなたにあるものを増幅させる力があります 00:13:17.300 --> 00:13:23.100 優れたアーキテクチャやよく設計されたプラットフォームなど基盤がしっかりしていれば ai は生産性を2から3倍に高めてくれます 00:13:23.100 --> 00:13:31.340 しかし基盤が脆弱であれば ai はより大きなミスをより早く犯す手助けをしてしまうだけです 不適切な設定セキュリティホール壊れたインフラそれらすべてが誰にも気づかれる前に本番環境へリリースされてしまいます 00:13:31.340 --> 00:13:39.220 ai は脆弱な基盤を修正してはくれませんむしろそれを露呈させてしまうのです 実例を上げましょう優れた内部開発者プラットフォームを持つ企業ではエンジニア以外でも安全に 00:13:39.220 --> 00:13:45.640 ai ツールをデプロイできますプラットフォームがガードレールを提供してくれるからです セキュリティポリシーも強制されますインフラもプラットフォームが処理します 00:13:45.640 --> 00:13:52.320 そのためプロダクトマネージャーはクバネテスやクラウドネットワークを理解していなくても ai 搭載プロトタイプを立ち上げられますこれは強力なことです 00:13:52.320 --> 00:14:01.720 まさに ai 時代に対応できるチームと取り残されていくチームを分ける境界線となります あなたにとってこれは何を意味するのでしょうかプラットフォームを構築するための猶予期間は終わりつつあります 00:14:01.720 --> 00:14:11.300 技術が消えていくからではなくプラットフォームを持つチームと持たないチームの格差が急速に広がっているからです 躊躇している毎月すでにプラットフォームを持つチームはさらに先へと進んでいます 00:14:11.300 --> 00:14:17.640 彼らはより早くリリースし燃え尽きることなく新しいツールにも迅速に適応しています プラットフォームを持たないチームはどんどん遅れをとっています 00:14:22.320 --> 00:14:26.980 始めるべきでしょうかもし最初から大規模な内部開発者プラットフォームを構築する必要があると考えているならそれはやめてください 00:14:26.980 --> 00:14:34.820 それはプロジェクトを始める前に頓挫させる最短の方法です チームが犯す最大の過ちは一度にすべてを構築しようとすることです完璧なプラットフォームを設計しようと何ヶ月も 00:14:34.820 --> 00:14:40.200 費やし思いつく限りの機能を詰め込もうとします そしてリリースしても何の反応もありません誰も使わないのです 00:14:40.200 --> 00:14:48.340 なぜでしょうか誰も求めていない問題を解決し使い始めるために少差しほどのマニュアルを読む必要があるからです いいですかそんなことはしてはいけませんまずは小さく始めましょう 00:14:48.340 --> 00:14:56.040 アーキテクトでもマネージャーでも自分自身の思い込みでもなく開発者と直接話してください 毎日機能を書いている人たちを見つけましょうどこが辛いのか彼らに聞いてみるのです 00:14:56.040 --> 00:15:03.420 最も時間がかかり多くの人を苛立たせ本来あるべき姿で運用されていないワークフローを見つけ出してください そして最初から最後まで通じるゴールデンパスを一つだけ構築します 00:15:03.420 --> 00:15:12.380 例えば新しいマイクロサービスの作成とデプロイかもしれません あるいはゼロからの開発環境構築かもしれませんもしかすると何も壊さずにホットフィックスを本番環境へ反映させることかもしれません 00:15:12.380 --> 00:15:19.180 最も痛みを伴うものを選びその痛みを解消できるパスを構築してください 作り上げ実際のユーザーでテストしフィードバックを集め反復改善します 00:15:19.180 --> 00:15:26.580 それができたら次のパスを一つまた一つと追加していきましょう 一度にすべての問題を解決しようとしないでください一つの問題を徹底的に解決しその勢いを全身の力に変えるのです 00:15:26.580 --> 00:15:34.560 うまくいっているかどうかどう判断すればいいのでしょうか 正しい指標を測定することですアイデアから初回のデプロイまでの時間削減した手作業のステップ数そして自発的な利用率です 00:15:34.560 --> 00:15:40.660 開発者が自分たちで構築するよりもあなたのパスを選ぶならそれは成功です もし避けられているなら声に耳を傾け方向転換しましょう 00:15:40.660 --> 00:15:44.020 避けるべき落とし穴があります プラットフォームの使用を強制しないでください 00:15:44.020 --> 00:15:49.920 開発者にパスの使用を強要すれば彼らは反発します 彼らは回避策を見つけ出すでしょう独自のスクリプトを構築しあなたに隠すようになります 00:15:49.920 --> 00:15:53.480 そうではなくそのパスを使いやすくしてください 他の手段よりも高速に動作するようにします 00:15:53.480 --> 00:15:58.340 誰の目にも明らかな選択肢にすべきですが唯一の選択肢にしてはいけません 最初のパスが常に最も困難なものです 00:15:58.340 --> 00:16:04.360 それはプロダクト思考のすべてを教えてくれます ユーザーとの対話方法優先順位のつけ方を学びそして人々が本当に求めているものを作ることが 00:16:04.360 --> 00:16:10.120 ただ動くものを作ることよりもはるかに難しいことを理解するでしょう しかし一度やり遂げれば2つ目のパスはより簡単になり3つ目はさらに容易になります 00:16:10.120 --> 00:16:14.280 プラットフォームは一度に作り上げるものではありません 一つずつパスを積み重ねて構築していくのです 00:16:14.280 --> 00:16:18.380 システムとはそういうものです プラットフォームエンジニアリングとは開発者が舗装された道を走り 00:16:18.380 --> 00:16:23.960 銅の穴を埋める作業に追われず運転に集中できるようにすることです インフラとの戦いに疲れているならまずはチーム内のゴールデンパスを一つ 00:16:23.960 --> 00:16:29.700 たった一つ見つけることから始めてください この情報が必要な人に共有し今後もこのような解説動画が見たい方は登録をお願いします