独りよがりのプラットフォーム / For Whom that Platform Runs

Talked at CloudNative Days Tokyo 2020 #CNDT2020.

Video available at https://event.cloudnativedays.jp/cndt2020/talks/30

Transcript

1. twitter.com/toricls 独りよがりのプラットフォーム Tori Sep. 9, 2020 - For Whom that Platform Runs -
2. twitter.com/toricls Tori / Sr. Product Developer Advocate Containers Product, Amazon Web Services ❤ AWS Fargate & AWS Lambda toricls
3. twitter.com/toricls Agenda 『プラットフォーム』の話をしましょう
4. twitter.com/toricls 『プラットフォーム』？
5. twitter.com/toricls 本⽇の『プラットフォーム』の類義語 ▶ 共通基盤 ▶ インフラ基盤 ▶ 次世代開発プラットフォーム ▶ [次世代][統合][インフラ][共通][開発][基盤][プラットフォーム] ▶ blah
6. twitter.com/toricls Why『プラットフォーム/共通基盤/whatever』? ▶ リソース利⽤率向上 ▶ 運⽤効率向上、開発⽣産性向上 ▶ ⼀貫したセキュリティポリシとエンフォースメント ▶ マイクロサービス ▶ コンテナ、Kubernetes ▶ モダナイズ ▶ 来るべき⼤デジタル時代に備え、いまこのタイミングで共通基盤刷新に取り組むことこそが10年20年先の 我が社の競争⼒獲得にblah
7. twitter.com/toricls 本⽇のお題 社内/チーム内の課題解決のために構築される 共通基盤的なものを考察する
8. twitter.com/toricls 共通基盤 - 古今東⻄
9. twitter.com/toricls 共通基盤 - 古今東⻄ ▶ 技術的な実現⽅法として何を⽤いるか？の話し合いをはじめてから2年以上経過しました ▶ ？『話し合いをしている間に陳腐化してきたので技術選定からやり直しです』 ▶ ？『最近は Kubernetes キテるんじゃないかみたいな話になってます』 ▶ アサインされたので取り組んでるんですが、なんのために共通基盤を作るのかはよく分かってないです ▶ プロジェクト開始当時の担当者は旗振り役含めてみんないなくなりました ▶ 3年の歳⽉と多⼤な⼈的リソースを投下して完成 ▶ ？『基盤ローンチから半年経ちましたが、いまのところ基盤チームの社内ツールだけ動いてます』 〜 いろんな『プラットフォーム』を⾒てきました 〜
10. twitter.com/toricls 共通基盤 - 古今東⻄ ▶ 技術的な実現⽅法として何を⽤いるか？の話し合いをはじめてから2年以上経過しました ▶ ？『話し合いをしている間に陳腐化してきたので技術選定からやり直しです』 ▶ ？『最近は Kubernetes キテるんじゃないかみたいな話になってます！』 ▶ アサインされたので取り組んでるんですが、なんのために共通基盤を作るのかはよく分かってないです ▶ プロジェクト開始当時の担当者は旗振り役含めてみんないなくなりました ▶ 3年の歳⽉と多⼤な⼈的リソースを投下して完成 ▶ ？『基盤ローンチから半年経ちましたが、いまのところ基盤チームの社内ツールだけ動いてます』 〜 いろんな『プラットフォーム』を⾒てきました 〜 Why?
11. twitter.com/toricls うまくいかない共通基盤を作るには 1. 課題設定は、⼤きく、フワっと 2. ユーザーヒアリングは時間の無駄 3. 課題を解決できているかどうかは計測ではなく雰囲気で決める 4. 共通基盤は「使わせる」もの 5. 共通基盤は作りきり
12. twitter.com/toricls 共通基盤 と 課題設定
13. twitter.com/toricls 現実とかけ離れたデカすぎる TODO リストは終わらない ▶︎ NG なゴールの例 ▶ ⽣産性爆上げクールなプラットフォームを作る ▶ クラウドネイティブでモダンなプラットフォームを作る ❓そもそも⽣産性爆上げとはなんなのか ❓クラウドネイティブになるとその結果何が改善されるのか ❓モダンとは？？？
14. twitter.com/toricls タスクに落とし込める課題設定 ▶︎ Acceptable なゴールの例 ▶︎ 年年間の⾦金金銭的インフラ費⽤用を30%削減 ▶︎ 開発チームのデプロイ回数を現状の1回/3ヶ⽉月から1回/1ヶ⽉月に ▶︎ 定常的に必要となるサービスのオートスケーリングを⾃自動化する ▶︎ サービスの連続したダウンタイムを10分以内に抑える仕組みを作る ▶︎ セキュリティポリシ遵守チェックを⼀一部⾃自動化し、⼈人⼒力力作業時間を80%削減する ▶︎ ネットワーク設定のミスオペレーションを5分以内に検知する仕組みを作る
15. twitter.com/toricls 共通基盤 と ステークホルダ
16. twitter.com/toricls 共通基盤とステークホルダ 共通基盤的な もの 基盤の⼈ 運⽤ 開発 セキュリティ 神々 エンドユーザ 中間にいる神々
17. twitter.com/toricls 共通基盤とステークホルダ 基盤的なもの 基盤の⼈ 運⽤ 開発 セキュリティ 神々 エンドユーザ 中間にいる神々 基盤をとりまく⼈々が抱えている課題は それぞれ異なる
18. twitter.com/toricls ユーザヒアリング ▶ いま何に困っていますか、あるいはこんなことにお困りではないですかと繰り返し聞いてみる ▶ 何が欲しいか、ではない ▶ 困っている原因とその解消⽅法について仮説を⽴てる ▶ 原因の解消⽅法案と解消された結果の予想図をユーザに提案し、意⾒をもらう ▶ このタイミングで実装してはならない ▶ ホワイトボーディングやドキュメント ▶ ユーザのフィードバックをもとに修正 ▶ 原因を解消しうる最⼩限の実装(MVP)を⽤意し、提供する
19. twitter.com/toricls How we build AWS for over a decade ▶︎ 90 - 95% ▶ AWS が1年間にリリースする新サービスや新機能のうちユーザリクエストをベースにしたもの ▶ ユーザリクエストの多くは「欲しいもの」であり、その声をもとに実際の課題やペインポイント について仮説を⽴ててユーザヒアリング ▶ ユーザリクエストを集計し、各サービスチームごとに実装の優先順位を決定 ▶ AWS 内部の⼈間(e.g. トリ)が「こんな機能が欲しい」と⾔っても集計にはカウントしない ▶ ただし AWS 内の他のサービスチームは「ユーザ」 ▶ e.g. Amazon SageMaker は Amazon ECS のユーザ
20. twitter.com/toricls How we build AWS for over a decade 1. Working Backwards ▶︎ “We try to work backwards from the customer, rather than starting with an idea for a product and trying to bolt customers onto it.” - Ian McAllister ex-GM at Amazon ▶ 仮説をもとにユーザヒアリング 2. PR/FAQ ▶ 最初にプレスリリースを書く (全てのプレスリリースが表に出るわけではないが、必ず書く) ▶ 顧客がそのリリースに対して抱くであろう疑問や質問に答える FAQ を書く ▶ 解こうとしている課題を適切に顧客の視点で捉えられているか確認する重要なプロセス 3. MVP の実装と効果を測定する指標の策定
21. twitter.com/toricls https://github.com/aws/containers-roadmap/issues/53 How we build AWS for over a decade https://github.com/aws/containers-roadmap/projects/1 - AWS Public Containers Roadmap on GitHub - e.g. #53 Amazon EFS Support in AWS Fargate (launched)
22. twitter.com/toricls How we build AWS for over a decade - AWS Lambda Press Release - https://press.aboutamazon.com/news-releases/news-release-details/amazon-web-services-announces-aws-lambda 1. このリリースはなんのか 2. このリリースによって顧客のどんな課題が解決され るのか 3. 実際に課題が解決される(た)顧客の声 (初期の Lambda がいかに今と⽐比べて少ない機能, MVP として リリースされていたかも⾒見見て楽しいポイント)
23. twitter.com/toricls How we build AWS for over a decade ▶︎ リリースまで継続的に更更新されていく Internal PR/FAQ ▶︎ [Public] そのリリースがなんなのか ▶︎ どこにペインポイントがあったのか ▶︎ 解決⼿手段としてのアプローチの適切さの考察 ▶︎ 他の⼿手段やワークアラウンドはなかったのか ▶︎ 後⽅方互換性に関する考察, etc., etc., …… ▶︎ [Public] このリリースによって顧客のどんな課題が解決されるのか ▶︎ [Public] 実際に課題が解決された顧客の声 ▶︎ リリースまでベータテストなどを繰り返しながらアップデート ▶︎ FAQ (⼀一部は公式ドキュメントなどに反映)
24. twitter.com/toricls コラム -「ペインポイント」と「課題」 ▶ 『Pod に Security Group を設定したい』 ▶ これはペインポイントでも課題でもなく、機能リクエスト ▶ なぜ Security Group を Pod に設定したいのか？ ▶ [課題] Pod 間通信や Pod と RDS のようなクラスタ外リソースとの通信を明⽰的に許可/拒否すること でワークロードをセキュアに運⽤したい ▶ [ペインポイント] 現時点では Pod に Security Group が設定できないことでノードレベルの Security Group でお茶を濁しており、管理が煩雑な上にそもそも求めているセキュリティレベルではない ▶ 適切な解決⽅法は実は Security Groups for Pods ではないかもしれない
25. twitter.com/toricls 共通基盤 と 継続的効果測定
26. twitter.com/toricls 計測可能な(解決できたかを確認できる)課題設定が重要 ▶︎ Acceptable な(計測可能な)ゴール設定の例 (再掲) ▶︎ 年年間の⾦金金銭的インフラ費⽤用を30%削減 ▶︎ 開発チームのデプロイ回数を現状の1回/3ヶ⽉月から1回/1ヶ⽉月に ▶︎ 定常的に必要となるサービスのオートスケーリングを⾃自動化する ▶︎ サービスの連続したダウンタイムを10分以内に抑える仕組みを作る ▶︎ セキュリティポリシ遵守チェックを⼀一部⾃自動化し、⼈人⼒力力作業時間を80%削減する ▶︎ ネットワーク設定のミスオペレーションを5分以内に検知する仕組みを作る
27. twitter.com/toricls なぜ計測可能な課題設定が重要なのか ▶ 「プラットフォーム」とそのチームの存続意義 ▶ ステークホルダへの説明責任 ▶ 成果のない基盤チームは会社にとってただの負債 ▶ 計測できない成果は成果ではない ▶ (成果として扱いにくい/扱われにくい) ▶ 計測できないものを課題として設定しない ▶ e.g. 「コスト」削減、⽣産性爆上げ、モダン、クラウドネイティブ、超セキュア
28. twitter.com/toricls 共通基盤はなぜ使われないのか
29. twitter.com/toricls 共通基盤はなぜ使われないのか ▶ 必要のないものを無理やり使わせようとしている ▶ 利⽤者の課題を解決していない (≒ 基盤チームや意思決定層の⾃⼰満⾜の可能性) ▶ 想定利⽤者が実は何も困っていない (実際には何か困っていたり、慣れちゃってたりするだけのはず) ▶ 説明ニグレクト ▶ 何を解決するのかを説明していない、説明が抽象的すぎて伝わっていない ▶ どう使うのかを説明していない ▶ 他の利⽤者の喜びの声が社内に伝わっていない ▶ 最初は良さそうに⾒えたが、作りっぱなしで新たな課題や状況の変化に対応していく気配がない
30. twitter.com/toricls 共通基盤はなぜ使われないのか ▶ その解決⼿段は総合的な観点で適切なのか？ (≒ それ本当に XXX 使うのが最適解ですか？) ▶ 三輪⾞の扱いで精⼀杯な成熟度のチームがステークホルダにいたとして、彼らにいきなりロードバイク の利⽤を強要することは適切なのか？意味はあるのか？ ▶ まずは補助輪を⽤意して彼らのカルチャーや技術的成熟度を⾼め、「なぜその(あなたが使いたい)技術 が世の中で課題として認識されつつあるのか？」を理解できるところに引き上げることが先決では？ ▶ 共通基盤を構成する技術要素に興味がある⼈であれば、「字⾯でだけ理解できる課題」の解決のためにノリ ノリで利⽤してくれるでしょう ▶ そこに興味がない⼈は「現実の課題」に直⾯しない限り、振り向いてすらくれません
31. twitter.com/toricls 共通基盤はなぜ使われないのか ▶ その解決⼿段は総合的な観点で適切なのか？ (≒ それ本当に XXX 使うのが最適解ですか？) ▶ 三輪⾞の扱いで精⼀杯な成熟度のチームがステークホルダにいたとして、彼らにいきなりロードバイク の利⽤を強要することは適切なのか？意味はあるのか？ ▶ まずは補助輪を⽤意して彼らのカルチャーや技術的成熟度を⾼め、「なぜその(あなたが使いたい)技術 が世の中で課題として認識されつつあるのか？」を理解できるところに引き上げることが先決では？ ▶ 共通基盤を構成する技術要素に興味がある⼈であれば、「字⾯でだけ理解できる課題」の解決のためにノリ ノリで利⽤してくれるでしょう ▶ そこに興味がない⼈は「現実の課題」に直⾯しない限り、振り向いてすらくれません 誰のための共通基盤？
32. twitter.com/toricls For Whom your Platform Runs
33. twitter.com/toricls うまくいかないプラットフォームを作るには (再掲) 1. 課題設定は、⼤きく、フワっと 2. ユーザーヒアリングは時間の無駄 3. 課題を解決できているかどうかは計測ではなく雰囲気で決める 4. 共通基盤は「使わせる」もの 5. 共通基盤は作りきり
34. twitter.com/toricls 価値のある、意味のあるプラットフォームを 1. 適切な粒度の課題設定 2. 共通基盤のステークホルダは「顧客」 3. ひたすらユーザヒアリングと MVP の繰り返し 4. 計測、計測、計測 5. 共通基盤は社内向けの「サービス」 6. 「形のある基盤」という存在にこだわらない \ thank you /