$30 off During Our Annual Pro Sale. View Details »

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

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を活用しているメディアサービスの立ち上げ・改善のサポートや、組織作りなどにも取り組む。

shotaTsuge

May 20, 2019
Tweet

More Decks by shotaTsuge

Other Decks in Technology

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