独りよがりのプラットフォーム / 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 -
   

   View Slide

2. twitter.com/toricls
   Tori /
   Sr. Product Developer Advocate
   Containers Product, Amazon Web Services
   ❤ AWS Fargate & AWS Lambda
   toricls
   

   View Slide

3. twitter.com/toricls
   Agenda
   『プラットフォーム』の話をしましょう
   

   View Slide

4. twitter.com/toricls
   『プラットフォーム』？
   

   View Slide

5. twitter.com/toricls
   本⽇の『プラットフォーム』の類義語
   ▶ 共通基盤
   ▶ インフラ基盤
   ▶ 次世代開発プラットフォーム
   ▶ [次世代][統合][インフラ][共通][開発][基盤][プラットフォーム]
   ▶ blah
   

   View Slide

6. twitter.com/toricls
   Why『プラットフォーム/共通基盤/whatever』?
   ▶ リソース利⽤率向上
   ▶ 運⽤効率向上、開発⽣産性向上
   ▶ ⼀貫したセキュリティポリシとエンフォースメント
   ▶ マイクロサービス
   ▶ コンテナ、Kubernetes
   ▶ モダナイズ
   ▶ 来るべき⼤デジタル時代に備え、いまこのタイミングで共通基盤刷新に取り組むことこそが10年20年先の
   我が社の競争⼒獲得にblah
   

   View Slide

7. twitter.com/toricls
   本⽇のお題
   社内/チーム内の課題解決のために構築される
   共通基盤的なものを考察する
   

   View Slide

8. twitter.com/toricls
   共通基盤 - 古今東⻄
   

   View Slide

9. twitter.com/toricls
   共通基盤 - 古今東⻄
   ▶ 技術的な実現⽅法として何を⽤いるか？の話し合いをはじめてから2年以上経過しました
   ▶ ？『話し合いをしている間に陳腐化してきたので技術選定からやり直しです』
   ▶ ？『最近は Kubernetes キテるんじゃないかみたいな話になってます』
   ▶ アサインされたので取り組んでるんですが、なんのために共通基盤を作るのかはよく分かってないです
   ▶ プロジェクト開始当時の担当者は旗振り役含めてみんないなくなりました
   ▶ 3年の歳⽉と多⼤な⼈的リソースを投下して完成
   ▶ ？『基盤ローンチから半年経ちましたが、いまのところ基盤チームの社内ツールだけ動いてます』
   〜 いろんな『プラットフォーム』を⾒てきました 〜
   

   View Slide

10. twitter.com/toricls
    共通基盤 - 古今東⻄
    ▶ 技術的な実現⽅法として何を⽤いるか？の話し合いをはじめてから2年以上経過しました
    ▶ ？『話し合いをしている間に陳腐化してきたので技術選定からやり直しです』
    ▶ ？『最近は Kubernetes キテるんじゃないかみたいな話になってます！』
    ▶ アサインされたので取り組んでるんですが、なんのために共通基盤を作るのかはよく分かってないです
    ▶ プロジェクト開始当時の担当者は旗振り役含めてみんないなくなりました
    ▶ 3年の歳⽉と多⼤な⼈的リソースを投下して完成
    ▶ ？『基盤ローンチから半年経ちましたが、いまのところ基盤チームの社内ツールだけ動いてます』
    〜 いろんな『プラットフォーム』を⾒てきました 〜
    Why?
    

    View Slide

11. twitter.com/toricls
    うまくいかない共通基盤を作るには
    1. 課題設定は、⼤きく、フワっと
    2. ユーザーヒアリングは時間の無駄
    3. 課題を解決できているかどうかは計測ではなく雰囲気で決める
    4. 共通基盤は「使わせる」もの
    5. 共通基盤は作りきり
    

    View Slide

12. twitter.com/toricls
    共通基盤 と
    課題設定
    

    View Slide

13. twitter.com/toricls
    現実とかけ離れたデカすぎる TODO リストは終わらない
    ▶︎
    NG なゴールの例
    ▶ ⽣産性爆上げクールなプラットフォームを作る
    ▶ クラウドネイティブでモダンなプラットフォームを作る
    ❓そもそも⽣産性爆上げとはなんなのか
    ❓クラウドネイティブになるとその結果何が改善されるのか
    ❓モダンとは？？？
    

    View Slide

14. twitter.com/toricls
    タスクに落とし込める課題設定
    ▶︎
    Acceptable なゴールの例
    ▶︎
    年年間の⾦金金銭的インフラ費⽤用を30%削減
    ▶︎
    開発チームのデプロイ回数を現状の1回/3ヶ⽉月から1回/1ヶ⽉月に
    ▶︎
    定常的に必要となるサービスのオートスケーリングを⾃自動化する
    ▶︎
    サービスの連続したダウンタイムを10分以内に抑える仕組みを作る
    ▶︎
    セキュリティポリシ遵守チェックを⼀一部⾃自動化し、⼈人⼒力力作業時間を80%削減する
    ▶︎
    ネットワーク設定のミスオペレーションを5分以内に検知する仕組みを作る
    

    View Slide

15. twitter.com/toricls
    共通基盤 と
    ステークホルダ
    

    View Slide

16. twitter.com/toricls
    共通基盤とステークホルダ
    共通基盤的な
    もの
    基盤の⼈
    運⽤
    開発
    セキュリティ
    神々
    エンドユーザ
    中間にいる神々
    

    View Slide

17. twitter.com/toricls
    共通基盤とステークホルダ
    基盤的なもの
    基盤の⼈
    運⽤
    開発
    セキュリティ
    神々
    エンドユーザ
    中間にいる神々
    基盤をとりまく⼈々が抱えている課題は
    それぞれ異なる
    

    View Slide

18. twitter.com/toricls
    ユーザヒアリング
    ▶ いま何に困っていますか、あるいはこんなことにお困りではないですかと繰り返し聞いてみる
    ▶ 何が欲しいか、ではない
    ▶ 困っている原因とその解消⽅法について仮説を⽴てる
    ▶ 原因の解消⽅法案と解消された結果の予想図をユーザに提案し、意⾒をもらう
    ▶ このタイミングで実装してはならない
    ▶ ホワイトボーディングやドキュメント
    ▶ ユーザのフィードバックをもとに修正
    ▶ 原因を解消しうる最⼩限の実装(MVP)を⽤意し、提供する
    

    View Slide

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 のユーザ
    

    View Slide

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 の実装と効果を測定する指標の策定
    

    View Slide

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)
    

    View Slide

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 として
    リリースされていたかも⾒見見て楽しいポイント)
    

    View Slide

23. twitter.com/toricls
    How we build AWS for over a decade
    ▶︎
    リリースまで継続的に更更新されていく Internal PR/FAQ
    ▶︎ [Public] そのリリースがなんなのか
    ▶︎
    どこにペインポイントがあったのか
    ▶︎
    解決⼿手段としてのアプローチの適切さの考察
    ▶︎
    他の⼿手段やワークアラウンドはなかったのか
    ▶︎
    後⽅方互換性に関する考察, etc., etc., ……
    ▶︎ [Public] このリリースによって顧客のどんな課題が解決されるのか
    ▶︎ [Public] 実際に課題が解決された顧客の声
    ▶︎
    リリースまでベータテストなどを繰り返しながらアップデート
    ▶︎ FAQ (⼀一部は公式ドキュメントなどに反映)
    

    View Slide

24. twitter.com/toricls
    コラム -「ペインポイント」と「課題」
    ▶ 『Pod に Security Group を設定したい』
    ▶ これはペインポイントでも課題でもなく、機能リクエスト
    ▶ なぜ Security Group を Pod に設定したいのか？
    ▶ [課題] Pod 間通信や Pod と RDS のようなクラスタ外リソースとの通信を明⽰的に許可/拒否すること
    でワークロードをセキュアに運⽤したい
    ▶ [ペインポイント] 現時点では Pod に Security Group が設定できないことでノードレベルの Security
    Group でお茶を濁しており、管理が煩雑な上にそもそも求めているセキュリティレベルではない
    ▶ 適切な解決⽅法は実は Security Groups for Pods ではないかもしれない
    

    View Slide

25. twitter.com/toricls
    共通基盤 と
    継続的効果測定
    

    View Slide

26. twitter.com/toricls
    計測可能な(解決できたかを確認できる)課題設定が重要
    ▶︎
    Acceptable な(計測可能な)ゴール設定の例 (再掲)
    ▶︎
    年年間の⾦金金銭的インフラ費⽤用を30%削減
    ▶︎
    開発チームのデプロイ回数を現状の1回/3ヶ⽉月から1回/1ヶ⽉月に
    ▶︎
    定常的に必要となるサービスのオートスケーリングを⾃自動化する
    ▶︎
    サービスの連続したダウンタイムを10分以内に抑える仕組みを作る
    ▶︎
    セキュリティポリシ遵守チェックを⼀一部⾃自動化し、⼈人⼒力力作業時間を80%削減する
    ▶︎
    ネットワーク設定のミスオペレーションを5分以内に検知する仕組みを作る
    

    View Slide

27. twitter.com/toricls
    なぜ計測可能な課題設定が重要なのか
    ▶ 「プラットフォーム」とそのチームの存続意義
    ▶ ステークホルダへの説明責任
    ▶ 成果のない基盤チームは会社にとってただの負債
    ▶ 計測できない成果は成果ではない
    ▶ (成果として扱いにくい/扱われにくい)
    ▶ 計測できないものを課題として設定しない
    ▶ e.g. 「コスト」削減、⽣産性爆上げ、モダン、クラウドネイティブ、超セキュア
    

    View Slide

28. twitter.com/toricls
    共通基盤はなぜ使われないのか
    

    View Slide

29. twitter.com/toricls
    共通基盤はなぜ使われないのか
    ▶ 必要のないものを無理やり使わせようとしている
    ▶ 利⽤者の課題を解決していない (≒ 基盤チームや意思決定層の⾃⼰満⾜の可能性)
    ▶ 想定利⽤者が実は何も困っていない (実際には何か困っていたり、慣れちゃってたりするだけのはず)
    ▶ 説明ニグレクト
    ▶ 何を解決するのかを説明していない、説明が抽象的すぎて伝わっていない
    ▶ どう使うのかを説明していない
    ▶ 他の利⽤者の喜びの声が社内に伝わっていない
    ▶ 最初は良さそうに⾒えたが、作りっぱなしで新たな課題や状況の変化に対応していく気配がない
    

    View Slide

30. twitter.com/toricls
    共通基盤はなぜ使われないのか
    ▶ その解決⼿段は総合的な観点で適切なのか？ (≒ それ本当に XXX 使うのが最適解ですか？)
    ▶ 三輪⾞の扱いで精⼀杯な成熟度のチームがステークホルダにいたとして、彼らにいきなりロードバイク
    の利⽤を強要することは適切なのか？意味はあるのか？
    ▶ まずは補助輪を⽤意して彼らのカルチャーや技術的成熟度を⾼め、「なぜその(あなたが使いたい)技術
    が世の中で課題として認識されつつあるのか？」を理解できるところに引き上げることが先決では？
    ▶ 共通基盤を構成する技術要素に興味がある⼈であれば、「字⾯でだけ理解できる課題」の解決のためにノリ
    ノリで利⽤してくれるでしょう
    ▶ そこに興味がない⼈は「現実の課題」に直⾯しない限り、振り向いてすらくれません
    

    View Slide

31. twitter.com/toricls
    共通基盤はなぜ使われないのか
    ▶ その解決⼿段は総合的な観点で適切なのか？ (≒ それ本当に XXX 使うのが最適解ですか？)
    ▶ 三輪⾞の扱いで精⼀杯な成熟度のチームがステークホルダにいたとして、彼らにいきなりロードバイク
    の利⽤を強要することは適切なのか？意味はあるのか？
    ▶ まずは補助輪を⽤意して彼らのカルチャーや技術的成熟度を⾼め、「なぜその(あなたが使いたい)技術
    が世の中で課題として認識されつつあるのか？」を理解できるところに引き上げることが先決では？
    ▶ 共通基盤を構成する技術要素に興味がある⼈であれば、「字⾯でだけ理解できる課題」の解決のためにノリ
    ノリで利⽤してくれるでしょう
    ▶ そこに興味がない⼈は「現実の課題」に直⾯しない限り、振り向いてすらくれません
    誰のための共通基盤？
    

    View Slide

32. twitter.com/toricls
    For Whom your Platform Runs
    

    View Slide

33. twitter.com/toricls
    うまくいかないプラットフォームを作るには (再掲)
    1. 課題設定は、⼤きく、フワっと
    2. ユーザーヒアリングは時間の無駄
    3. 課題を解決できているかどうかは計測ではなく雰囲気で決める
    4. 共通基盤は「使わせる」もの
    5. 共通基盤は作りきり
    

    View Slide

34. twitter.com/toricls
    価値のある、意味のあるプラットフォームを
    1. 適切な粒度の課題設定
    2. 共通基盤のステークホルダは「顧客」
    3. ひたすらユーザヒアリングと MVP の繰り返し
    4. 計測、計測、計測
    5. 共通基盤は社内向けの「サービス」
    6. 「形のある基盤」という存在にこだわらない
    \ thank you
    /
    

    View Slide