Well-Architectedな組織を 実現するためのチャレンジ - なぜ、CA W-Aを作ろうと思ったのか - #jawsdays 2019

「 Are you Well-Architected? 」
2015年、 AWS Well-Architected Framework が発表され、昨年の re:Invent では、 AWS Well-Architected Tool が発表されました。
Well-Architected という言葉を耳にする機会が増えてきたと感じますが、組織としては Well-Architected な状態でしょうか？

本セッションでは、昨年末に CyberAgent Developers Blog へ寄稿した記事( https://developers.cyberagent.co.jp/blog/archives/19224/ )の内容を中心に話す予定です。また、記事では紹介しきれなかった以下の取り組みなどについても話す予定でいます。
– 横断インフラ組織として抱える課題に対して取り組んできたこと
– Organizational Reliability Engineer（ORE） というロール
– 独自で作っている Well-Architected Framework（CA W-A） が目指しているビジョン

柘植 翔太
株式会社サイバーエージェント 技術本部サービスリライアビリティグループ
Senior Organizational Reliability Engineer

2014年、株式会社サイバーエージェントへ入社。
入社後は、インフラエンジニアとして、様々なメディアサービスのインフラを担当。現在は、主にPublic Cloudを活用しているメディアサービスの立ち上げ・改善のサポートや、組織作りなどにも取り組む。

Transcript

1. Well-Architectedな組織を
   

   実現するためのチャレンジ
   
   
   - なぜ、CA W-Aを作ろうと思ったのか -
   
   
   @JAWS DAYS
   2
   01
   9
   #jawsdays #jd
   2
   0 1
   9
   _e
   株式会社サイバーエージェント
   
   
   技術本部サービスリライアビリティグループ
   
   
   柘植 翔太
   

   View Slide

2. 名前 柘植 翔太 @shotaTsuge
   • 所属
   
   
   株式会社サイバーエージェント
   
   
   技術本部サービスリライアビリティグループ
   
   
   • ロール
   
   
   Senior Organizational Reliability Engineer
   
   
   • 好きなAWSサービス
   
   
   AWS Well-Architected Framework
   
   
   • コミュニティ活動
   
   
   Japan AWS User Group（
   2
   0 1
   2
   -
   2 0 16
   ）
   

   View Slide

3. 名前 柘植 翔太 @shotaTsuge
   • 会社での経歴
   
   
   20 1
   4
   /
   0 4
   -
   2014
   /
   09
   Software Engineer @ AmebaPigg
   
   
   20 1
   4
   /
   0 9
   -
   2018
   /
   03
   Infrastructure Engineer
   
   
   - Ameba Pigg
   
   
   - Social Game Services
   
   
   - Curation Media Services
   
   
   - Streaming Services
   
   
   - Matching Services
   
   
   - AdTech Services
   
   
   - FinTech Services
   
   
   - And more
   …
   
   20 1
   8
   /
   0 4
   - Senior Organizational Reliability Engineer
   

   View Slide

4. 寄稿歴
   • サイバーエージェント公式デベロッパーブログ
   
   
   https://developers.cyberagent.co.jp/blog/archives/
   19224
   /
   
   
   • Software Design
   201 9
   年2⽉号 - SRE特集 -
   
   
   https://gihyo.jp/magazine/SD/archive/
   2 01 9
   /
   20 1 90 2
   
   • AWS導⼊事例
   
   
   https://aws.amazon.com/jp/solutions/case-studies/torte/
   

   View Slide

5. 良かったらいいねして下さいw
   • サイバーエージェント公式デベロッパーブログ
   
   
   https://developers.cyberagent.co.jp/blog/archives/
   19224
   /
   

   View Slide

6. 本セッションの内容
   • 本セッションで話すこと📢
   
   
   - ⾃分が所属する横断的インフラ組織がどんな悩みを抱えながら歩んでいるのか
   
   
   - OREというロールをなぜ作ったのか、そもそもどういったロールなのか
   
   
   - なぜ、独⾃でWell-Architected Framework（CA W-A）を作っているのか
   
   
   - Well-Architected Frameworkにどんな可能性を感じているのか
   
   
   • 本セッションでの注意⚠
   
   
   技術的なことは話しません🙇
   
   
   CA W-Aは、現時点では試作段階であり、本セッションにおける発⾔は、
   
   
   所属するチームとしての⾒解であり、会社全体の意向ではありません🙏
   

   View Slide

7. 登壇者からのお願い
   • 本セッションへのお気持ち
   
   
   今⽇は、友達が欲しくて登壇しに来たので、優しく⾒守ってください🙏
   
   
   

   同じように悩んでいる⼈いれば、
   

   #jawsdays , #jd
   20 1
   9
   _e のハッシュタグ付けてつぶやいてもいいし、
   

   本セッションが終わった後に、登壇者に話しかけてくれると喜びます☺
   

   本セッションが終わった後に、より多くの様々な議論が⽣まれてくれれば幸いです🙏
   

   View Slide

8. 1
   .Introduction
   
   
   所属する会社 / 組織について
   
   
   2
   .History of the Organization
   
   
   インフラ組織としての歩みと課題について
   
   
   3
   .Organizational Reliability Engineering
   
   
   ORE / AWS W-A / CA W-Aについて
   
   
   ORE / CA W-Aの今後について
   
   
   4
   .Summary
   
   
   伝えたかったこと
   

   View Slide

9. Introduction
   

   View Slide

10. 所属する会社について
    

    View Slide

11. 所属する会社について
    • 株式会社サイバーエージェント
    
    
    巷では、CAって呼ばれています
    
    
    • 従業員数（連結）は、約5,000⼈
    
    
    • 事業について
    
    
    - メディア事業
    
    
    - スタートアップ（新規）事業
    
    
    - ゲーム事業
    
    
    - インターネット広告事業
    
    
    • 今年の春に、オフィス移転予定
    
    
    グループ全体ではなく、⼀部事業部
    

    View Slide

12. 所属する会社について
    • CAのエンジニア⽂化
    
    
    与えられる裁量とそれに対する責任も⼤きい
    
    
    ネイティブエンジニアから、サーバサイドエンジニアへ転向するなども出来る
    
    
    CAグループ内での移動も出来るので、違う業種のサービスも関わることが出来る
    
    
    CAに興味ある⼈は、ZEHI !!
    
    
    https://www.wantedly.com/companies/cyberagent
    
    
    ⾃分のチームも絶賛募集中です！少しでも興味あるって⼈は気軽に声かけて下さい🙏
    
    
    https://www.wantedly.com/projects/
    20 8 915
    

    View Slide

13. 所属する組織について
    

    View Slide

14. 所属する組織について
    • 技術本部とは
    
    
    社内でメディア管轄と呼ばれているサイバーエージェントグループのメディア事業や
    

    スタートアップ（新規）事業のサービスに対して横断的なサポートなどをしている組織
    
    
    共通基盤や秋葉原ラボ、Private Cloudなども、この組織に属している
    

    View Slide

15. • メディア管轄のサービス（⼀部抜粋）
    所属する組織について
    

    View Slide

16. 所属する組織について
    • サービスリライアビリティグループとは
    
    
    メディア管轄のサービスのインフラ領域を横断的にサポートしているグループ
    
    
    Service Reliability Groupの頭⽂字を取って、SRGと呼ばれている
    
    
    主に、既存サービスの改善や新規⽴ち上げなどを⾏なっている
    
    
    ⼗数⼈で、⼤⼩合わせて200弱のサービス‧システムをサポートしている💪
    
    
    SRG内には、いくつかのチームがある
    

    View Slide

17. 所属する組織について
    • メディア管轄とSRGの相関図
    

    View Slide

18. History of the Organization
    

    View Slide

19. インフラ組織としての歩みと課題
    

    View Slide

20. インフラ組織としての歩みと課題
    • SRGの前⾝となるインフラ組織（〜2015年）
    
    
    会社の歴史と共に、組織の形態を変えていた
    
    
    - 今のSRGのように横断組織の時もあれば、サービス付の時代もあった
    
    
    - 昔ながらのインフラ屋的なオンプレ時代
    
    
    - ⾃前のオンプレミス環境
    
    
    - サーバのラッキングやミドルウェアのセットアップをしていた
    
    
    - Private CloudやPublic Cloudへとシフト（2012年〜）
    
    
    - Private Cloud専属チームの結成
    
    
    - Public Cloudの利⽤が徐々に拡⼤
    

    View Slide

21. インフラ組織としての歩みと課題
    • SRGの前⾝となるインフラ組織（〜2015年）
    
    
    インフラチームの働き⽅も、以下のような責務に変わっていった
    
    
    - Provisioning
    
    
    - Infrastructure as a Code , Deploy pipeline
    
    
    - Scalability
    
    
    - Capacity Planning
    
    
    - Performance
    
    
    - DB/App Tuning , Stress Test
    
    
    - Monitoring
    
    
    - On-Call
    
    
    - Security
    

    View Slide

22. インフラ組織としての歩みと課題
    • SRGとしての始まり（2015年〜）
    
    
    この頃、横断組織のインフラエンジニアとしてのアプローチにもどかしさを感じていた
    
    
    - もっとプロダクトに貢献できるんじゃないのか
    
    
    信頼性を軸としたプロダクト貢献をする組織に変わるべく…
    
    
    SREを⽬指そうと、組織名をサービスリライアビリティグループに変更しました
    
    
    きっかけは、SREが流⾏り始めてたので、その流れに乗った感じです🏄
    

    View Slide

23. インフラ組織としての歩みと課題
    • SREとしての活動を始める（2016年〜）
    
    
    Site Reliability Engineeringの哲学を学ぶ
    
    
    - Google SREとのディスカッション
    
    
    - Site Reliability Engineeringに関する書籍の輪読会
    
    
    - Site Reliability Engineering
    
    
    - The Site Reliability Workbook
    
    
    - 以下の4つの分類を中⼼に学んでいった
    
    
    - Software Engineering
    
    
    - System Engineering
    
    
    - Overhead
    
    
    - Toil
    

    View Slide

24. インフラ組織としての歩みと課題
    • SREとしての活動を始める（2016年〜）
    
    
    Site Reliability Engineeringの哲学を学ぶ
    
    
    学んだことを元に、以下の取り組みなどを進めていきました
    
    
    - Toil撲滅運動（50%ルール）
    
    
    - Postmortem
    
    
    - Runbook
    
    
    - On-boardingプロセス
    
    
    - 障害対応フローの再設計（On-Callへ向けて）
    
    
    - SRGとしてのSREの再定義
    

    View Slide

25. インフラ組織としての歩みと課題
    • SREやろうとしたけど（2017年〜）
    
    
    結果どうだったのか
    
    
    SREに名前を変えただけ😇
    
    
    - 横断組織で、メディア組織全体としての信頼性を担保するSREにはなれなかった
    
    
    - 直接的なサービスの信頼性向上という意味では、インフラエンジニアの時と変化がなかった
    
    
    感じた課題
    
    
    横断組織として網羅的なアプローチが難しい😥
    
    
    - SRGのメンバーの10倍以上の多種多様なメディアサービス数
    
    
    - サービス毎に技術スタックも異なる
    

    View Slide

26. インフラ組織としての歩みと課題
    • SREやろうとしたけど（2017年〜）
    
    
    感じた課題
    
    
    信頼性を担保することのメリットが分かりづらい
    
    
    - そもそも、誰に対しての信頼性なのか？🤔
    
    
    - エンジニア層に対して？
    
    
    - ビジネス層に対して？
    
    
    - ユーザ層に対して？
    

    そもそも現状のリスクが可視化できていないし、優先度も共通認識されていない
    
    
    - 何がしたかったのか？
    
    
    - 何でしたいのか？
    

    View Slide

27. インフラ組織としての歩みと課題
    • もっと根本的な組織課題について考える（2017年〜）
    
    
    ⽬⽴ったやつが評価される
    
    
    - 本当に⼤事かもしれないけど、不満が⽣まれやすい
    
    
    それぞれが、⼤事なことやってると思ってる
    
    
    - 組織にとって⼤事なこと（優先度含め）が、定義されてないから評価されにくい
    
    
    - ⾃分ではそこが定義できない（マネージャとかに委ねたい）
    
    
    - 最悪、評価されないから退職リスクもあΔ😱
    横断組織メリットがあるというが、誰もそのメリットが最⼤化できる組織にしていない
    
    
    - 横断組織とか⾔いつつ、狭い枠の中（所属する組織）でしか仕事してない
    
    
    - 結果メリット出せなくて、横断組織いらないってなりがち😱
    

    View Slide

28. インフラ組織としての歩みと課題
    • 改めて、横断組織のメリットを考える（2017年〜）
    
    
    横断組織としての強みは
    
    
    - インフラ視点として考えるなら、
    
    
    - 多種多様なサービスに関わってるからこそのナレッジ
    
    
    - そのナレッジがあるから、サービス全体の信頼性を底上げできる
    
    
    - 我々がすべきなのは、System Architectureの信頼性に対してのアプローチなのでは
    
    
    他にも⼤事なこと
    
    
    - そもそも事業会社だったら、サービスの成⻑視点で考えるべき
    
    
    - Service Architectureの信頼性を最⼤値を伸ばすアプローチ
    

    View Slide

29. インフラ組織としての歩みと課題
    • ⾃分達の組織に適⽤する（2018年〜）
    
    
    Site Reliability Engineeringの哲学を、2つの属性にわける
    
    
    - System Architecture Reliability
    
    
    - 横断組織としてサービスの信頼性を担保するロール
    
    
    - 多種多様なメディアサービス全体の信頼性の底上げをする
    
    
    - Service Architecture Reliability
    
    
    - 特定サービスの専任としてのアプローチするロール
    
    
    - サービスの信頼性の最⼤値を伸ばす
    
    
    - もっと知りたいという⼈は、 Software Design
    20 19
    年2⽉号 - SRE特集 - を読んで下さい🙇
    
    
    でも、現状のSRGの組織状態では、難しいとも感じた
    

    View Slide

30. インフラ組織としての歩みと課題
    • 改めて、横断組織の強みとすべきことを考える（2018年〜）
    
    
    なぜ出来てないのか🤔
    
    
    - ⽬標（ビジョン）の共有ができておらず、すべきことが可視化できてない
    
    
    - 雰囲気でなく、スコープや現状‧ニーズを共通認識持てるようにする必要がある
    
    
    - 可視化できてれば、必要なロールもわかるし、それを作ることもできる
    
    
    - 個⼈的には、インフラエンジニアとか SRE はロールが⼤きすぎる
    

    - 組織間のコミュニケーションが⾜りていない
    
    
    - ⽬標（ビジョン）が明確じゃないから、コミュニケーションの壁も感じている
    
    
    - 結果、ナレッジの共有ができない🙅
    
    
    これらのことを踏まえ、OREというロールを作ることにしました
    

    View Slide

31. Organizational
    

    Reliability
    

    Engineering
    

    View Slide

32. OREとは
    

    View Slide

33. OREとは
    • そもそも信頼性とは？
    
    
    とりあえず、Wikipediaで調べてみた👀
    
    
    なるほど、じゃあ⾃分達が考える必要がある信頼性って何なんだろうか？🤔
    

    View Slide

34. OREとは
    • 4つの信頼性の層
    
    
    Corporation（会社） ← IR（Investor Relations）
    
    
    ⇅
    
    
    Customer（顧客） ← CRE（Customer Reliability Engineering）
    
    
    ⇅
    
    
    Cooperation（連携）← ORE（Organizational Reliability Engineering）
    
    
    ⇅ ↑横断組織だからͦ͜ͷඞཁੑ💪
    
    
    Service（サービス） ← SRE（Site Reliability Engineering）
    

    View Slide

35. OREとは
    • ミッション
    
    
    組織的な信頼性向上のために頑張るエンジニア
    
    
    組織全体としてのナレッジが最⼤化されサービスへ還元できている状態にする
    
    
    - 横断組織のインフラエンジニア だからこそ持っているナレッジを適切に提供する
    
    
    事業部レベルでのシステムリスクが共通認識できている状態にする
    
    
    - サービスの抱える課題を優先度やスコープとそのメリットも含めて、可視化する
    
    
    - 組織間コミュニケーションを活発化させる🤝
    
    
    サービス成⻑へつながる技術戦略が作れている状態にする
    
    
    - ⾃分達のバックグラウンド的には、System Architectureの視点がやりやすい
    

    View Slide

36. OREとは
    • 要は、こういうこと
    
    
    ⽬的が明確化されてて、それに向かってのアクションが取りやすい状況
    
    
    課題の可視化
    
    
    ↓
    
    
    共通認識（優先順位‧スコープ）
    
    
    ↓
    
    
    アクションが取れる状態（ナレッジを適切に提供）
    
    
    ↓
    
    
    サービス成⻑へコミットできる
    
    
    System Architectureって視点だと、 AWS Well-Architected Framework
    
    
    とか良さそうだと思い、試すことにしました
    

    View Slide

37. AWS W-Aについて
    

    View Slide

38. AWS W-A について
    • AWS Well-Architected Framework（AWS W-A）とは
    
    
    AWSをユーザ向けに10年以上に提供した上で得られた経験を元に、
    

    提供してくれているシステム設計‧運⽤の “⼤局的な” 考え⽅とベストプラクティス集
    
    
    AWS W-Aの構成要素のホワイトペーパーや確認質問集も定期的に更新されている
    
    
    AWSのソリューションアーキテクト（AWS W-A認定パートナー）も構成要素に含まれている
    
    
    最近では、AWS Well-Architected Tool も発表され、セルフチェックをすることも可能に
    
    
    2018/02時点では、⽇本語対応はされていません
    

    View Slide

39. AWS W-A について
    • ホワイトペーパーについて
    
    
    5つの柱（ホワイトペーパーの構成）
    
    
    - 運⽤の優秀性
    
    
    - セキュリティ
    
    
    - 信頼性
    
    
    - パフォーマンス効率
    
    
    - コスト最適化
    
    
    ※ 2019/02時点
    

    最近では…
    
    
    IoT や Serverless 向けのホワイトペーパーも出ている
    
    
    より詳しく知りたい⼈は、公式サイトを⾒てください
    

    View Slide

40. AWS W-A について
    • よくある誤解
    
    
    AWS W-A をやればええ感じに出来ると思っている
    
    
    あくまで設計 “原則” なので、実装の詳細やアーキテクチャパターンは扱っていない
    
    
    AWS W-A は、銀の弾丸ではない🙅
    
    
    監査（Audit）的な使い⽅が出来ると思っている
    
    
    現状を知るのには使えるが、監査的な使い⽅は望ましくない
    
    
    AWS W-A をすれば OK ではなく、そこからどうやっていくかを⼀緒に考えることが⼤切
    
    
    ガバナンスのインプットには使えると思っている（個⼈的⾒解）
    
    
    ⼀回やればOKだと思っている
    
    
    AWS W-A は定期的に実施する必要がある
    
    
    AWS W-A のフロー（チェック‧改善）を継続的にまわすことが重要
    

    View Slide

41. AWS W-A について
    • もっとAWS W-Aを知りたい⼈におすすめの資料
    
    
    AWS Black Belt Online Seminar ＆ 公式ドキュメント（英語）
    

    View Slide

42. AWS W-A について
    • 実際に AWS W-A を試してみて
    
    
    AWS W-Aを試してみた、サービスの⼈からの意⾒👂
    
    
    - 運⽤周りのヒントをもらったので、それをもとに改善していこうと思えた👍
    
    
    - どういったセキュリティリスクがあるかを認識することができた👍
    
    
    などのポジティブな意⾒をもらいつつも…
    
    
    ⚠ ⾃分達の組織が試す段階では、AWS Well-Architected Tool は発表されていなかったので、
    弊社担当のソリューションアーキテクトによる実施の話になります。
    

    View Slide

43. AWS W-A について
    • 実際に AWS W-A を試してみて
    
    
    AWS W-Aを試してみた、サービスの⼈からの意⾒👂
    
    
    - 複数項⽬からの選択式なので、項⽬によっては回答が難しい
    
    
    - 実際に課題は分かったけど、事業レベルでどう改善を進めていけば良いかわからない
    
    
    - 定期的にセルフチェックしたい
    
    
    という声も、多数ありました。
    
    
    また、弊社ではAWS以外のプラットフォームも活⽤しているので、
    
    
    同じ様なアプローチが出来ないかと思うようになり、
    
    
    プラットフォームに依存しない Well-Architected Frameworkを作ることにしました。
    
    
    ⚠ ⾃分達の組織が試す段階では、AWS Well-Architected Tool は発表されていなかったので、
    
    
    弊社担当のソリューションアーキテクトによる実施の話になります。
    

    View Slide

44. CA W-Aについて
    

    View Slide

45. CA W-A について
    • CA Well-Architected Framework（CA W-A）とは
    
    
    - AWS W-Aを元に作成した、プラットフォームに依存しない汎⽤的なフレームワーク
    
    
    - 質を落とさないようにしつつ、回答のハードルを下げる
    
    
    - 複数項⽬からの選択式ではなく、Yes/No だけで判定できる⽅法を採⽤
    
    
    - 回答しづらい項⽬は削除するなど、質問数を可能な限り削減
    
    
    - 内製だからできるカスタマイズ
    
    
    - Google App Script で⾃動集計 & 解析や Slack 通知を実施してくれる Bot を⽤意
    
    
    - ヒアリングシートの管理 & 運⽤を⾃動化
    
    
    - Review Report（レビュー結果）の Suggestion
    
    
    - 社内ナレッジを適切に共有することが可能
    

    View Slide

46. CA W-A について
    • ⼤枠は、AWS W-Aと同じ5つの柱
    
    
    合計75の項⽬を回答することにより、現状のサービスの状態を紐解く
    
    
    - Security
    
    
    - Reliability
    
    
    - Performance
    
    
    - Cost Optimization
    
    
    - Operations
    

    View Slide

47. CA W-A について
    • サービスの今を⾒つめ直すための新たなライフサイクルを⽣み出す
    学習
    Condition Review
    測定
    Condition Review
    改善/事業貢献
    Improvement
    コミュニケーション
    Review Report
    
    
    Discussion & Planning
    1
    2
    3
    4
    

    View Slide

48. CA W-A について
    • 実際に、CA W-Aを試してみたサービスからの声
    
    
    - AWS以外のプラットフォームでも⾏えるのは嬉しい
    
    
    - 現状のサービスが抱えている潜在的なリスクの可視化ができる
    
    
    - 現状課題に対して、事業部全体で共通認識を持てる
    
    
    - 事業部にとって何をすればいいのかを考えるときの資料として活⽤できる
    
    
    - 社内に存在するナレッジを活⽤できるようになる
    
    
    - 知らなかったことを知れたり、それによる議論などが⽣まれる🗣
    

    View Slide

49. CA W-Aの実施フロー
    

    View Slide

50. CA W-A の実施フロー
    CONDITION REVIEW
    事前にサービスの
    
    
    コンディションチェック
    01
    START
    REVIEW REPORT
    ORE とサービスの技術責任者で
    
    
    2時間レビュー会を実施
    
    
    02
    DISCUSSION & PLANNING
    事業責任者 & 技術責任者と
    
    
    課題の認識合わせ
    03
    

    View Slide

51. CA W-A の実施フロー
    IMPROVEMENT
    浮上した課題を実際に改善し、
    
    
    互いに事業を成⻑させていく
    04
    半年後に 01 から再度実施
    

    View Slide

52. CA W-A の実施フロー
    01
    CONDITION REVIEW
    

    View Slide

53. CONDITION REVIEW
    • ヒアリングシートについて
    
    
    サービスのコンディションをチェックする質問集✍
    
    
    権限管理や運⽤のしやすさを考慮し、Googleスプレッドシートで管理
    
    
    Google App Scriptを使って、レビュー結果の⾃動集計や解析もしている
    

    View Slide

54. CONDITION REVIEW
    • ヒアリングシートについて
    
    
    スプレッドシートをカスタマイズし、簡易的なレビュー結果をSlackへ通知
    ポ
    チ
    ッ
    

    View Slide

55. CA W-A の実施フロー
    02
    REVIEW REPORT
    

    View Slide

56. REVIEW REPORT
    • Googleドキュメントを利⽤している
    
    
    - Overall Result（全体的な結果）
    
    
    - 各優先度の合計数を表⽰
    
    
    - Pillar Results（詳細結果）
    
    
    - ⼤枠毎に優先度の数を表⽰
    
    
    - Suggestion（改善案 or 参考資料）
    
    
    - 優先度が⾼い順に表⽰
    
    
    - 現在、試⾏錯誤を繰り返しています
    

    View Slide

57. CA W-A の実施フロー
    03
    DISCUSSION & PLANNING
    

    View Slide

58. DISCUSSION＆PLANNING
    • CA W-Aフローの中でこのステップが⼀番重要になる
    
    
    責任者との現状を理解した上での改善計画を⽴てるためには、
    
    
    以下を明確にしないといけない
    
    
    - 何が問題なのか
    
    
    - 問題に対しての利害関係者は誰なのか
    
    
    - 問題箇所の技術領域に詳しいのは誰なのか
    
    
    - 問題を解決する上で誰が責任者になるのか
    
    
    特に、 何が問題なのか と 責任者 が明確になっていないと、
    
    
    次のステップの Improvement（改善） を着⼿することは⾮常に難しい
    

    View Slide

59. CA W-A の実施フロー
    04
    IMPROVEMENT
    

    View Slide

60. IMPROVEMENT
    • どうやって改善を進めるのか
    
    
    Review Report の Suggestion が重要になる
    
    
    組織として持っているナレッジ（ベストプラクティスやモジュールの提供など）を
    
    
    効率的に提供する為に、複数サービスでのCA W-Aレビューの結果をもとに、
    
    
    傾向的に早く提供した⽅が良いものから準備を進めている
    
    
    どういった Suggestion をしてるのか
    
    
    - ベストプラクティス集
    
    
    - ECS, CI/CD
    …
    
    - Terraform の共通モジュール
    
    
    - Ansible の共通 Playbook
    
    
    - オペレーション周りの⾃動化ツール
    
    
    - and more
    …
    

    View Slide

61. IMPROVEMENT
    • CA W-Aとは何なのか？
    
    
    CA W-Aは、コミュニケーションツールだと考えています🤝
    
    
    ただ、チェックするのが⽬的ではなく
    
    
    技術から事業成⻑を促すためのコミュニケーションツール💪
    
    
    として考えています
    
    
    CA W-Aについて、もっと詳しく知りたいという⼈は、
    
    
    CA BASE CAMPという社内カンファレンスに登壇した資料を後⽇アップ予定なので、
    
    
    是⾮それを⾒てください🙏
    

    View Slide

62. CA W-Aの今後について
    

    View Slide

63. CA W-A の今後について
    ⾃動で前回のレビュー結果と⽐較し、再集計までしてくれる機能の追加
    
    
    提案できる情報の最⼤化
    
    
    AWS W-A Tool のロードマップによっては、統合も検討
    

    View Slide

64. CA W-A の今後について
    • AWS W-A Toolが、AWS以外でも使えるように㊗
    
    
    

    View Slide

65. OREの今後について
    

    View Slide

66. OREの今後について
    • CA W-Aは、始まりに過ぎない
    
    
    横断的なアプローチなので、 System Architecture Reliability の要素が⼤きい
    
    
    • 我々がやるべきことは、まだ沢⼭ある
    
    
    サービスの信頼性の最⼤値を伸ばす、 Service Architecture Reliability 的な
    
    
    アプローチをいかに実践していくかが⼤事
    
    
    ビジネスKPIに紐づくSLI/SLOの策定と計測をサポートする為のフレームワークも作成予定
    
    
    そのために、SRGに所属するインフラエンジニア を適切なロールに細分化することも
    

    考えています。
    

    View Slide

67. OREの今後について
    • 今更ですがOREの⽬指すビジョンについて
    
    
    我々は、Curiosity をテーマに掲げています
    
    
    - 好奇⼼が湧く（ワクワクする）ことが出来る組織を⽬指そう！
    
    
    - その組織を⽬指している⾃分達も、好奇⼼をもって取り組もう！
    

    View Slide

68. Summary
    

    View Slide

69. 伝えたかったこと
    

    View Slide

70. 伝えたかったこと
    • ⽬標（ビジョン）明確化しましょう！
    
    
    明確化されてないと、アクション取りづらくないですか？
    
    
    多くの組織における⽬標は、サービス成⻑させて、会社も成⻑させることじゃないかと
    
    
    そのために、もっとコミュニケーションしていきましょう🗣
    
    
    Well-Architected Frameworkは、⼀つの⼿段として使えるもの🙆
    
    
    分散されているナレッジの蓄積や共有を適切に⾏うこともできる
    
    
    AWSでサービス運⽤してるなら、AWS W-Aは使わない理由はない
    
    
    • すべきことをベースにロール（役割）も考えてほしい
    
    
    本当に必要なロールは何なのか？🤔
    
    
    ないなら、⾃分達で宣⾔してもいい🙆 だから、ORE作りました💪
    

    View Slide

71. 伝えたかったこと
    • ワクワクして働ける場を作ろう！
    
    
    結局はこれのために、組織について議論するのでは…
    
    
    みんなが納得いく評価制度を作るのは難しいけど、そんな環境は作れるはず
    
    
    そしたら、⼈事に⾔われなくても、リファラル採⽤やりますよね🙆
    
    
    • AWS系のカンファレンスなので…
    
    
    フィードバックとか、フューチャーリクエストどんどん投げましょ🗣
    
    
    それで、もっとディスカッションしていきましょ！
    
    
    ⾃分達も AWS W-A 含め何かしらの形で、今後もコントリビュートしていくお気持ちです！
    

    View Slide

72. 最後に
    

    View Slide

73. Special Thanks
    • JAWS DAYS
    2019
    Stu
    ff
    🙇
    
    
    本当に感謝しかないです🙌
    • ORE Team
    
    
    Shonosuke Okada（@rm_rf_slant）
    
    
    • AWS Well-Architected Team and Japan AWS Team
    
    
    いつも⼤変お世話になってます🙌
    

    View Slide

74. Every day is still Day One :)
    
    
    - 我々のチャレンジは続く -
    

    View Slide

75. ご静聴ありがとうございました🙇
    

    View Slide