SlideShare a Scribd company logo
1 of 75
Download to read offline
Well-Architectedな組織を

実現するためのチャレンジ
- なぜ、CA W-Aを作ろうと思ったのか -
@JAWS DAYS #jawsdays #jd _e
株式会社サイバーエージェント
技術本部サービスリライアビリティグループ
柘植 翔太
名前 柘植 翔太 @shotaTsuge
• 所属
株式会社サイバーエージェント
技術本部サービスリライアビリティグループ
• ロール
Senior Organizational Reliability Engineer
• 好きなAWSサービス
AWS Well-Architected Framework
• コミュニティ活動
Japan AWS User Group( - )
名前 柘植 翔太 @shotaTsuge
• 会社での経歴
/ - / Software Engineer @ AmebaPigg
/ - / Infrastructure Engineer
- Ameba Pigg
- Social Game Services
- Curation Media Services
- Streaming Services
- Matching Services
- AdTech Services
- FinTech Services
- And more
/ - Senior Organizational Reliability Engineer
寄稿歴
• サイバーエージェント公式デベロッパーブログ
https://developers.cyberagent.co.jp/blog/archives/ /
• Software Design 年2⽉号 - SRE特集 -
https://gihyo.jp/magazine/SD/archive/ /
• AWS導⼊事例
https://aws.amazon.com/jp/solutions/case-studies/torte/
良かったらいいねして下さいw
• サイバーエージェント公式デベロッパーブログ
https://developers.cyberagent.co.jp/blog/archives/ /
本セッションの内容
• 本セッションで話すこと📢
- ⾃分が所属する横断的インフラ組織がどんな悩みを抱えながら歩んでいるのか
- OREというロールをなぜ作ったのか、そもそもどういったロールなのか
- なぜ、独⾃でWell-Architected Framework(CA W-A)を作っているのか
- Well-Architected Frameworkにどんな可能性を感じているのか
• 本セッションでの注意⚠
技術的なことは話しません🙇
CA W-Aは、現時点では試作段階であり、本セッションにおける発⾔は、
所属するチームとしての⾒解であり、会社全体の意向ではありません🙏
登壇者からのお願い
• 本セッションへのお気持ち
今⽇は、友達が欲しくて登壇しに来たので、優しく⾒守ってください🙏


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

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

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


本セッションが終わった後に、より多くの様々な議論が⽣まれてくれれば幸いです🙏
.Introduction
所属する会社 / 組織について
.History of the Organization
インフラ組織としての歩みと課題について
.Organizational Reliability Engineering
ORE / AWS W-A / CA W-Aについて
ORE / CA W-Aの今後について
.Summary
伝えたかったこと
Introduction
所属する会社について
所属する会社について
• 株式会社サイバーエージェント
巷では、CAって呼ばれています
• 従業員数(連結)は、約5,000⼈
• 事業について
- メディア事業
- スタートアップ(新規)事業
- ゲーム事業
- インターネット広告事業
• 今年の春に、オフィス移転予定
グループ全体ではなく、⼀部事業部
所属する会社について
• CAのエンジニア⽂化
与えられる裁量とそれに対する責任も⼤きい
ネイティブエンジニアから、サーバサイドエンジニアへ転向するなども出来る
CAグループ内での移動も出来るので、違う業種のサービスも関わることが出来る
CAに興味ある⼈は、ZEHI !!
https://www.wantedly.com/companies/cyberagent
⾃分のチームも絶賛募集中です!少しでも興味あるって⼈は気軽に声かけて下さい🙏
https://www.wantedly.com/projects/
所属する組織について
所属する組織について
• 技術本部とは
社内でメディア管轄と呼ばれているサイバーエージェントグループのメディア事業や

スタートアップ(新規)事業のサービスに対して横断的なサポートなどをしている組織
共通基盤や秋葉原ラボ、Private Cloudなども、この組織に属している
• メディア管轄のサービス(⼀部抜粋)
所属する組織について
所属する組織について
• サービスリライアビリティグループとは
メディア管轄のサービスのインフラ領域を横断的にサポートしているグループ
Service Reliability Groupの頭⽂字を取って、SRGと呼ばれている
主に、既存サービスの改善や新規⽴ち上げなどを⾏なっている
⼗数⼈で、⼤⼩合わせて200弱のサービス‧システムをサポートしている💪
SRG内には、いくつかのチームがある
所属する組織について
• メディア管轄とSRGの相関図
History of the Organization
インフラ組織としての歩みと課題
インフラ組織としての歩みと課題
• SRGの前⾝となるインフラ組織(〜2015年)
会社の歴史と共に、組織の形態を変えていた
- 今のSRGのように横断組織の時もあれば、サービス付の時代もあった
- 昔ながらのインフラ屋的なオンプレ時代
- ⾃前のオンプレミス環境
- サーバのラッキングやミドルウェアのセットアップをしていた
- Private CloudやPublic Cloudへとシフト(2012年〜)
- Private Cloud専属チームの結成
- Public Cloudの利⽤が徐々に拡⼤
インフラ組織としての歩みと課題
• SRGの前⾝となるインフラ組織(〜2015年)
インフラチームの働き⽅も、以下のような責務に変わっていった
- Provisioning
- Infrastructure as a Code , Deploy pipeline
- Scalability
- Capacity Planning
- Performance
- DB/App Tuning , Stress Test
- Monitoring
- On-Call
- Security
インフラ組織としての歩みと課題
• SRGとしての始まり(2015年〜)
この頃、横断組織のインフラエンジニアとしてのアプローチにもどかしさを感じていた
- もっとプロダクトに貢献できるんじゃないのか
信頼性を軸としたプロダクト貢献をする組織に変わるべく…
SREを⽬指そうと、組織名をサービスリライアビリティグループに変更しました
きっかけは、SREが流⾏り始めてたので、その流れに乗った感じです🏄
インフラ組織としての歩みと課題
• SREとしての活動を始める(2016年〜)
Site Reliability Engineeringの哲学を学ぶ
- Google SREとのディスカッション
- Site Reliability Engineeringに関する書籍の輪読会
- Site Reliability Engineering
- The Site Reliability Workbook
- 以下の4つの分類を中⼼に学んでいった
- Software Engineering
- System Engineering
- Overhead
- Toil
インフラ組織としての歩みと課題
• SREとしての活動を始める(2016年〜)
Site Reliability Engineeringの哲学を学ぶ
学んだことを元に、以下の取り組みなどを進めていきました
- Toil撲滅運動(50%ルール)
- Postmortem
- Runbook
- On-boardingプロセス
- 障害対応フローの再設計(On-Callへ向けて)
- SRGとしてのSREの再定義
インフラ組織としての歩みと課題
• SREやろうとしたけど(2017年〜)
結果どうだったのか
SREに名前を変えただけ😇
- 横断組織で、メディア組織全体としての信頼性を担保するSREにはなれなかった
- 直接的なサービスの信頼性向上という意味では、インフラエンジニアの時と変化がなかった
感じた課題
横断組織として網羅的なアプローチが難しい😥
- SRGのメンバーの10倍以上の多種多様なメディアサービス数
- サービス毎に技術スタックも異なる
インフラ組織としての歩みと課題
• SREやろうとしたけど(2017年〜)
感じた課題
信頼性を担保することのメリットが分かりづらい
- そもそも、誰に対しての信頼性なのか? 🤔
- エンジニア層に対して?
- ビジネス層に対して?
- ユーザ層に対して?

そもそも現状のリスクが可視化できていないし、優先度も共通認識されていない
- 何がしたかったのか?
- 何でしたいのか?
インフラ組織としての歩みと課題
• もっと根本的な組織課題について考える(2017年〜)
⽬⽴ったやつが評価される
- 本当に⼤事かもしれないけど、不満が⽣まれやすい
それぞれが、⼤事なことやってると思ってる
- 組織にとって⼤事なこと(優先度含め)が、定義されてないから評価されにくい
- ⾃分ではそこが定義できない(マネージャとかに委ねたい)
- 最悪、評価されないから退職リスクもある 😱
横断組織メリットがあるというが、誰もそのメリットが最⼤化できる組織にしていない
- 横断組織とか⾔いつつ、狭い枠の中(所属する組織)でしか仕事してない
- 結果メリット出せなくて、横断組織いらないってなりがち 😱
インフラ組織としての歩みと課題
• 改めて、横断組織のメリットを考える(2017年〜)
横断組織としての強みは
- インフラ視点として考えるなら、
- 多種多様なサービスに関わってるからこそのナレッジ
- そのナレッジがあるから、サービス全体の信頼性を底上げできる
- 我々がすべきなのは、System Architectureの信頼性に対してのアプローチなのでは
他にも⼤事なこと
- そもそも事業会社だったら、サービスの成⻑視点で考えるべき
- Service Architectureの信頼性を最⼤値を伸ばすアプローチ
インフラ組織としての歩みと課題
• ⾃分達の組織に適⽤する(2018年〜)
Site Reliability Engineeringの哲学を、2つの属性にわける
- System Architecture Reliability
- 横断組織としてサービスの信頼性を担保するロール
- 多種多様なメディアサービス全体の信頼性の底上げをする
- Service Architecture Reliability
- 特定サービスの専任としてのアプローチするロール
- サービスの信頼性の最⼤値を伸ばす
- もっと知りたいという⼈は、 Software Design 年2⽉号 - SRE特集 - を読んで下さい 🙇
でも、現状のSRGの組織状態では、難しいとも感じた
インフラ組織としての歩みと課題
• 改めて、横断組織の強みとすべきことを考える(2018年〜)
なぜ出来てないのか🤔
- ⽬標(ビジョン)の共有ができておらず、すべきことが可視化できてない
- 雰囲気でなく、スコープや現状‧ニーズを共通認識持てるようにする必要がある
- 可視化できてれば、必要なロールもわかるし、それを作ることもできる
- 個⼈的には、インフラエンジニアとか SRE はロールが⼤きすぎる

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

Reliability

Engineering
OREとは
OREとは
• そもそも信頼性とは?
とりあえず、Wikipediaで調べてみた👀
なるほど、じゃあ⾃分達が考える必要がある信頼性って何なんだろうか?🤔
OREとは
• 4つの信頼性の層
Corporation(会社) ← IR(Investor Relations)
⇅
Customer(顧客) ← CRE(Customer Reliability Engineering)
⇅
Cooperation(連携)← ORE(Organizational Reliability Engineering)
⇅ ↑横断組織だからこその必要性💪
Service(サービス) ← SRE(Site Reliability Engineering)
OREとは
• ミッション
組織的な信頼性向上のために頑張るエンジニア
組織全体としてのナレッジが最⼤化されサービスへ還元できている状態にする
- 横断組織のインフラエンジニア だからこそ持っているナレッジを適切に提供する
事業部レベルでのシステムリスクが共通認識できている状態にする
- サービスの抱える課題を優先度やスコープとそのメリットも含めて、可視化する
- 組織間コミュニケーションを活発化させる 🤝
サービス成⻑へつながる技術戦略が作れている状態にする
- ⾃分達のバックグラウンド的には、System Architectureの視点がやりやすい
OREとは
• 要は、こういうこと
⽬的が明確化されてて、それに向かってのアクションが取りやすい状況
課題の可視化
↓
共通認識(優先順位‧スコープ)
↓
アクションが取れる状態(ナレッジを適切に提供)
↓
サービス成⻑へコミットできる
System Architectureって視点だと、 AWS Well-Architected Framework
とか良さそうだと思い、試すことにしました
AWS W-Aについて
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時点では、⽇本語対応はされていません
AWS W-A について
• ホワイトペーパーについて
5つの柱(ホワイトペーパーの構成)
- 運⽤の優秀性
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
※ 2019/02時点

最近では…
IoT や Serverless 向けのホワイトペーパーも出ている
より詳しく知りたい⼈は、公式サイトを⾒てください
AWS W-A について
• よくある誤解
AWS W-A をやればええ感じに出来ると思っている
あくまで設計 “原則” なので、実装の詳細やアーキテクチャパターンは扱っていない
AWS W-A は、銀の弾丸ではない!
監査(Audit)的な使い⽅が出来ると思っている
現状を知るのには使えるが、監査的な使い⽅は望ましくない
AWS W-A をすれば OK ではなく、そこからどうやっていくかを⼀緒に考えることが⼤切
ガバナンスのインプットには使えると思っている(個⼈的⾒解)
⼀回やればOKだと思っている
AWS W-A は定期的に実施する必要がある
AWS W-A のフロー(チェック‧改善)を継続的にまわすことが重要
AWS W-A について
• もっとAWS W-Aを知りたい⼈におすすめの資料
AWS Black Belt Online Seminar & 公式ドキュメント(英語)
AWS W-A について
• 実際に AWS W-A を試してみて
AWS W-Aを試してみた、サービスの⼈からの意⾒👂
- 運⽤周りのヒントをもらったので、それをもとに改善していこうと思えた👍
- どういったセキュリティリスクがあるかを認識することができた👍
などのポジティブな意⾒をもらいつつも…
⚠ ⾃分達の組織が試す段階では、AWS Well-Architected Tool は発表されていなかったので、
弊社担当のソリューションアーキテクトによる実施の話になります。
AWS W-A について
• 実際に AWS W-A を試してみて
AWS W-Aを試してみた、サービスの⼈からの意⾒👂
- 複数項⽬からの選択式なので、項⽬によっては回答が難しい
- 実際に課題は分かったけど、事業レベルでどう改善を進めていけば良いかわからない
- 定期的にセルフチェックしたい
という声も、多数ありました。
また、弊社ではAWS以外のプラットフォームも活⽤しているので、
同じ様なアプローチが出来ないかと思うようになり、
プラットフォームに依存しない Well-Architected Frameworkを作ることにしました。
⚠ ⾃分達の組織が試す段階では、AWS Well-Architected Tool は発表されていなかったので、
弊社担当のソリューションアーキテクトによる実施の話になります。
CA W-Aについて
CA W-A について
• CA Well-Architected Framework(CA W-A)とは
- AWS W-Aを元に作成した、プラットフォームに依存しない汎⽤的なフレームワーク
- 質を落とさないようにしつつ、回答のハードルを下げる
- 複数項⽬からの選択式ではなく、Yes/No だけで判定できる⽅法を採⽤
- 回答しづらい項⽬は削除するなど、質問数を可能な限り削減
- 内製だからできるカスタマイズ
- Google App Script で⾃動集計 & 解析や Slack 通知を実施してくれる Bot を⽤意
- ヒアリングシートの管理 & 運⽤を⾃動化
- Review Report(レビュー結果)の Suggestion
- 社内ナレッジを適切に共有することが可能
CA W-A について
• ⼤枠は、AWS W-Aと同じ5つの柱
合計75の項⽬を回答することにより、現状のサービスの状態を紐解く
- Security
- Reliability
- Performance
- Cost Optimization
- Operations
CA W-A について
• サービスの今を⾒つめ直すための新たなライフサイクルを⽣み出す
学習
Condition Review
測定
Condition Review
改善/事業貢献
Improvement
コミュニケーション
Review Report
Discussion & Planning
CA W-A について
• 実際に、CA W-Aを試してみたサービスからの声
- AWS以外のプラットフォームでも⾏えるのは嬉しい
- 現状のサービスが抱えている潜在的なリスクの可視化ができる
- 現状課題に対して、事業部全体で共通認識を持てる
- 事業部にとって何をすればいいのかを考えるときの資料として活⽤できる
- 社内に存在するナレッジを活⽤できるようになる
- 知らなかったことを知れたり、それによる議論などが⽣まれる🗣
CA W-Aの実施フロー
CA W-A の実施フロー
CONDITION REVIEW
事前にサービスの
コンディションチェック
START
REVIEW REPORT
ORE とサービスの技術責任者で
2時間レビュー会を実施
DISCUSSION & PLANNING
事業責任者 & 技術責任者と
課題の認識合わせ
CA W-A の実施フロー
IMPROVEMENT
浮上した課題を実際に改善し、
互いに事業を成⻑させていく
半年後に から再度実施
CA W-A の実施フロー
CONDITION REVIEW
CONDITION REVIEW
• ヒアリングシートについて
サービスのコンディションをチェックする質問集✍
権限管理や運⽤のしやすさを考慮し、Googleスプレッドシートで管理
Google App Scriptを使って、レビュー結果の⾃動集計や解析もしている
CONDITION REVIEW
• ヒアリングシートについて
スプレッドシートをカスタマイズし、簡易的なレビュー結果をSlackへ通知
ポ
チ
ッ
CA W-A の実施フロー
REVIEW REPORT
REVIEW REPORT
• Googleドキュメントを利⽤している
- Overall Result(全体的な結果)
- 各優先度の合計数を表⽰
- Pillar Results(詳細結果)
- ⼤枠毎に優先度の数を表⽰
- Suggestion(改善案 or 参考資料)
- 優先度が⾼い順に表⽰
- 現在、試⾏錯誤を繰り返しています
CA W-A の実施フロー
DISCUSSION & PLANNING
DISCUSSION&PLANNING
• CA W-Aフローの中でこのステップが⼀番重要になる
責任者との現状を理解した上での改善計画を⽴てるためには、
以下を明確にしないといけない
- 何が問題なのか
- 問題に対しての利害関係者は誰なのか
- 問題箇所の技術領域に詳しいのは誰なのか
- 問題を解決する上で誰が責任者になるのか
特に、 何が問題なのか と 責任者 が明確になっていないと、
次のステップの Improvement(改善) を着⼿することは⾮常に難しい
CA W-A の実施フロー
IMPROVEMENT
IMPROVEMENT
• どうやって改善を進めるのか
Review Report の Suggestion が重要になる
組織として持っているナレッジ(ベストプラクティスやモジュールの提供など)を
効率的に提供する為に、複数サービスでのCA W-Aレビューの結果をもとに、
傾向的に早く提供した⽅が良いものから準備を進めている
どういった Suggestion をしてるのか
- ベストプラクティス集
- ECS, CI/CD
- Terraform の共通モジュール
- Ansible の共通 Playbook
- オペレーション周りの⾃動化ツール
- and more
IMPROVEMENT
• CA W-Aとは何なのか?
CA W-Aは、コミュニケーションツールだと考えています🤝
ただ、チェックするのが⽬的ではなく
技術から事業成⻑を促すためのコミュニケーションツール💪
として考えています
CA W-Aについて、もっと詳しく知りたいという⼈は、
CA BASE CAMPという社内カンファレンスに登壇した資料を後⽇アップ予定なので、
是⾮それを⾒てください🙏
CA W-Aの今後について
CA W-A の今後について
⾃動で前回のレビュー結果と⽐較し、再集計までしてくれる機能の追加
提案できる情報の最⼤化
AWS W-A Tool のロードマップによっては、統合も検討
CA W-A の今後について
• AWS W-A Toolが、AWS以外でも使えるように㊗
OREの今後について
OREの今後について
• CA W-Aは、始まりに過ぎない
横断的なアプローチなので、 System Architecture Reliability の要素が⼤きい
• 我々がやるべきことは、まだ沢⼭ある
サービスの信頼性の最⼤値を伸ばす、 Service Architecture Reliability 的な
アプローチをいかに実践していくかが⼤事
ビジネスKPIに紐づくSLI/SLOの策定と計測をサポートする為のフレームワークも作成予定
そのために、SRGに所属するインフラエンジニア を適切なロールに細分化することも

考えています。
OREの今後について
• 今更ですがOREの⽬指すビジョンについて
我々は、Curiosity をテーマに掲げています
- 好奇⼼が湧く(ワクワクする)ことが出来る組織を⽬指そう!
- その組織を⽬指している⾃分達も、好奇⼼をもって取り組もう!
Summary
伝えたかったこと
伝えたかったこと
• ⽬標(ビジョン)明確化しましょう!
明確化されてないと、アクション取りづらくないですか?
多くの組織における⽬標は、サービス成⻑させて、会社も成⻑させることじゃないかと
そのために、もっとコミュニケーションしていきましょう🗣
Well-Architected Frameworkは、⼀つの⼿段として使えるもの"
分散されているナレッジの蓄積や共有を適切に⾏うこともできる
AWSでサービス運⽤してるなら、AWS W-Aは使わない理由はない
• すべきことをベースにロール(役割)も考えてほしい
本当に必要なロールは何なのか?🤔
ないなら、⾃分達で宣⾔してもいい" だから、ORE作りました💪
伝えたかったこと
• ワクワクして働ける場を作ろう!
結局はこれのために、組織について議論するのでは…
みんなが納得いく評価制度を作るのは難しいけど、そんな環境は作れるはず
そしたら、⼈事に⾔われなくても、リファラル採⽤やりますよね.
• AWS系のカンファレンスなので…
フィードバックとか、フューチャーリクエストどんどん投げましょ🗣
それで、もっとディスカッションしていきましょ!
⾃分達も AWS W-A 含め何かしらの形で、今後もコントリビュートしていくお気持ちです!
最後に
Special Thanks
• JAWS DAYS Stuff 🙇
本当に感謝しかないです🙌
• ORE Team
Shonosuke Okada(@rm_rf_slant)
• AWS Well-Architected Team and Japan AWS Team
いつも⼤変お世話になってます🙌
Every day is still Day One :)
- 我々のチャレンジは続く -
ご静聴ありがとうございました🙇

More Related Content

What's hot

20200721 AWS Black Belt Online Seminar AWS App Mesh
20200721 AWS Black Belt Online Seminar AWS App Mesh20200721 AWS Black Belt Online Seminar AWS App Mesh
20200721 AWS Black Belt Online Seminar AWS App MeshAmazon Web Services Japan
 
緊急Ques - コードのメトリクスに基づくリファクタリング戦略
緊急Ques - コードのメトリクスに基づくリファクタリング戦略緊急Ques - コードのメトリクスに基づくリファクタリング戦略
緊急Ques - コードのメトリクスに基づくリファクタリング戦略Tomoki Kuriyama
 
202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN
202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN
202110 AWS Black Belt Online Seminar AWS Site-to-Site VPNAmazon Web Services Japan
 
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)NTT DATA Technology & Innovation
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove Itsuki Kuroda
 
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugItsuki Kuroda
 
AWS Black Belt Online Seminar 2017 Amazon Pinpoint で始めるモバイルアプリのグロースハック
AWS Black Belt Online Seminar 2017 Amazon Pinpoint で始めるモバイルアプリのグロースハックAWS Black Belt Online Seminar 2017 Amazon Pinpoint で始めるモバイルアプリのグロースハック
AWS Black Belt Online Seminar 2017 Amazon Pinpoint で始めるモバイルアプリのグロースハックAmazon Web Services Japan
 
20191016 AWS Black Belt Online Seminar Amazon Route 53 Resolver
20191016 AWS Black Belt Online Seminar Amazon Route 53 Resolver20191016 AWS Black Belt Online Seminar Amazon Route 53 Resolver
20191016 AWS Black Belt Online Seminar Amazon Route 53 ResolverAmazon Web Services Japan
 
[AKIBA.AWS] NLBとPrivateLinkの仕様に立ち向かう
[AKIBA.AWS] NLBとPrivateLinkの仕様に立ち向かう[AKIBA.AWS] NLBとPrivateLinkの仕様に立ち向かう
[AKIBA.AWS] NLBとPrivateLinkの仕様に立ち向かうShuji Kikuchi
 
AWS Black Belt Online Seminar 2017 Auto Scaling
AWS Black Belt Online Seminar 2017 Auto ScalingAWS Black Belt Online Seminar 2017 Auto Scaling
AWS Black Belt Online Seminar 2017 Auto ScalingAmazon Web Services Japan
 
1年目で(ほぼ)全冠して案件で躓いたので振り返り.pdf
1年目で(ほぼ)全冠して案件で躓いたので振り返り.pdf1年目で(ほぼ)全冠して案件で躓いたので振り返り.pdf
1年目で(ほぼ)全冠して案件で躓いたので振り返り.pdfhama
 
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話Yusuke Hisatsu
 
動的コンテンツをオリジンとしたCloudFrontを構築してみた
動的コンテンツをオリジンとしたCloudFrontを構築してみた動的コンテンツをオリジンとしたCloudFrontを構築してみた
動的コンテンツをオリジンとしたCloudFrontを構築してみたTaiki Kawamura
 
株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...
株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...
株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...Google Cloud Platform - Japan
 
AWS Black Belt Online Seminar 2017 Amazon DynamoDB
AWS Black Belt Online Seminar 2017 Amazon DynamoDB AWS Black Belt Online Seminar 2017 Amazon DynamoDB
AWS Black Belt Online Seminar 2017 Amazon DynamoDB Amazon Web Services Japan
 
AWS初心者向けWebinar AWSとのネットワーク接続入門
AWS初心者向けWebinar AWSとのネットワーク接続入門AWS初心者向けWebinar AWSとのネットワーク接続入門
AWS初心者向けWebinar AWSとのネットワーク接続入門Amazon Web Services Japan
 

What's hot (20)

20200721 AWS Black Belt Online Seminar AWS App Mesh
20200721 AWS Black Belt Online Seminar AWS App Mesh20200721 AWS Black Belt Online Seminar AWS App Mesh
20200721 AWS Black Belt Online Seminar AWS App Mesh
 
緊急Ques - コードのメトリクスに基づくリファクタリング戦略
緊急Ques - コードのメトリクスに基づくリファクタリング戦略緊急Ques - コードのメトリクスに基づくリファクタリング戦略
緊急Ques - コードのメトリクスに基づくリファクタリング戦略
 
202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN
202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN
202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN
 
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
 
Google Cloud で実践する SRE
Google Cloud で実践する SRE  Google Cloud で実践する SRE
Google Cloud で実践する SRE
 
Lean coffee
Lean coffeeLean coffee
Lean coffee
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
 
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
 
AWS Black Belt Online Seminar 2017 Amazon Pinpoint で始めるモバイルアプリのグロースハック
AWS Black Belt Online Seminar 2017 Amazon Pinpoint で始めるモバイルアプリのグロースハックAWS Black Belt Online Seminar 2017 Amazon Pinpoint で始めるモバイルアプリのグロースハック
AWS Black Belt Online Seminar 2017 Amazon Pinpoint で始めるモバイルアプリのグロースハック
 
DevOps with Database on AWS
DevOps with Database on AWSDevOps with Database on AWS
DevOps with Database on AWS
 
20191016 AWS Black Belt Online Seminar Amazon Route 53 Resolver
20191016 AWS Black Belt Online Seminar Amazon Route 53 Resolver20191016 AWS Black Belt Online Seminar Amazon Route 53 Resolver
20191016 AWS Black Belt Online Seminar Amazon Route 53 Resolver
 
[AKIBA.AWS] NLBとPrivateLinkの仕様に立ち向かう
[AKIBA.AWS] NLBとPrivateLinkの仕様に立ち向かう[AKIBA.AWS] NLBとPrivateLinkの仕様に立ち向かう
[AKIBA.AWS] NLBとPrivateLinkの仕様に立ち向かう
 
AWS Black Belt Online Seminar 2017 Auto Scaling
AWS Black Belt Online Seminar 2017 Auto ScalingAWS Black Belt Online Seminar 2017 Auto Scaling
AWS Black Belt Online Seminar 2017 Auto Scaling
 
1年目で(ほぼ)全冠して案件で躓いたので振り返り.pdf
1年目で(ほぼ)全冠して案件で躓いたので振り返り.pdf1年目で(ほぼ)全冠して案件で躓いたので振り返り.pdf
1年目で(ほぼ)全冠して案件で躓いたので振り返り.pdf
 
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
 
動的コンテンツをオリジンとしたCloudFrontを構築してみた
動的コンテンツをオリジンとしたCloudFrontを構築してみた動的コンテンツをオリジンとしたCloudFrontを構築してみた
動的コンテンツをオリジンとしたCloudFrontを構築してみた
 
株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...
株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...
株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...
 
AWS Black Belt Online Seminar 2017 Amazon DynamoDB
AWS Black Belt Online Seminar 2017 Amazon DynamoDB AWS Black Belt Online Seminar 2017 Amazon DynamoDB
AWS Black Belt Online Seminar 2017 Amazon DynamoDB
 
AWS初心者向けWebinar AWSとのネットワーク接続入門
AWS初心者向けWebinar AWSとのネットワーク接続入門AWS初心者向けWebinar AWSとのネットワーク接続入門
AWS初心者向けWebinar AWSとのネットワーク接続入門
 
ここから始めるAWSセキュリティ
ここから始めるAWSセキュリティここから始めるAWSセキュリティ
ここから始めるAWSセキュリティ
 

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

機敏な製品リリースを可能にする企業内の連携モデルを提示するScaled Agile Framework (SAFe) のご紹介
機敏な製品リリースを可能にする企業内の連携モデルを提示するScaled Agile Framework (SAFe) のご紹介機敏な製品リリースを可能にする企業内の連携モデルを提示するScaled Agile Framework (SAFe) のご紹介
機敏な製品リリースを可能にする企業内の連携モデルを提示するScaled Agile Framework (SAFe) のご紹介takuf
 
スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:
スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:
スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:schoowebcampus
 
AWS における Microservices Architecture と DevOps を推進する組織と人とツール
AWS における Microservices Architecture と DevOps を推進する組織と人とツールAWS における Microservices Architecture と DevOps を推進する組織と人とツール
AWS における Microservices Architecture と DevOps を推進する組織と人とツールAmazon Web Services Japan
 
JAWS-UG三都物語_企業でのAWS導入のエントリーポイント
JAWS-UG三都物語_企業でのAWS導入のエントリーポイントJAWS-UG三都物語_企業でのAWS導入のエントリーポイント
JAWS-UG三都物語_企業でのAWS導入のエントリーポイントToshiyuki Konparu
 
【de:code 2020】 Apps on Azure AD - アプリケーション連携 WHY と HOW
【de:code 2020】 Apps on Azure AD - アプリケーション連携 WHY と HOW【de:code 2020】 Apps on Azure AD - アプリケーション連携 WHY と HOW
【de:code 2020】 Apps on Azure AD - アプリケーション連携 WHY と HOW日本マイクロソフト株式会社
 
Web制作/SIerのためのAWS
Web制作/SIerのためのAWSWeb制作/SIerのためのAWS
Web制作/SIerのためのAWS真吾 吉田
 
負荷分散勉強会
負荷分散勉強会負荷分散勉強会
負荷分散勉強会Yuji Otani
 
スキニーなシステム開発にぴったりの契約形態
スキニーなシステム開発にぴったりの契約形態スキニーなシステム開発にぴったりの契約形態
スキニーなシステム開発にぴったりの契約形態Eiwa System Management, Inc.
 
20190222 osc2019tokyospring
20190222 osc2019tokyospring20190222 osc2019tokyospring
20190222 osc2019tokyospringtetsuromachida
 
サービスリニューアルからの チームの変遷
サービスリニューアルからの チームの変遷サービスリニューアルからの チームの変遷
サービスリニューアルからの チームの変遷Koki Watabe
 
20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operation20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operationYasuhiro Araki, Ph.D
 
AWSで動画共有サイトを作成して全社に公開
AWSで動画共有サイトを作成して全社に公開AWSで動画共有サイトを作成して全社に公開
AWSで動画共有サイトを作成して全社に公開ToruKubota4
 
Automation with SoftLayer and Zabbix
Automation with SoftLayer and ZabbixAutomation with SoftLayer and Zabbix
Automation with SoftLayer and Zabbixsoftlayerjp
 
AWSについて @ JAWS-UG 沖縄 CMS祭り!
AWSについて @ JAWS-UG 沖縄 CMS祭り!AWSについて @ JAWS-UG 沖縄 CMS祭り!
AWSについて @ JAWS-UG 沖縄 CMS祭り!Yasuhiro Horiuchi
 
今なぜサーバーレスなのか
今なぜサーバーレスなのか今なぜサーバーレスなのか
今なぜサーバーレスなのか真吾 吉田
 
JaSST'13 Kansai 継続的フィードバックによる品質運営
JaSST'13 Kansai 継続的フィードバックによる品質運営JaSST'13 Kansai 継続的フィードバックによる品質運営
JaSST'13 Kansai 継続的フィードバックによる品質運営智治 長沢
 

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

機敏な製品リリースを可能にする企業内の連携モデルを提示するScaled Agile Framework (SAFe) のご紹介
機敏な製品リリースを可能にする企業内の連携モデルを提示するScaled Agile Framework (SAFe) のご紹介機敏な製品リリースを可能にする企業内の連携モデルを提示するScaled Agile Framework (SAFe) のご紹介
機敏な製品リリースを可能にする企業内の連携モデルを提示するScaled Agile Framework (SAFe) のご紹介
 
スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:
スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:
スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:
 
20160629 aws well-architected
20160629 aws well-architected20160629 aws well-architected
20160629 aws well-architected
 
AWS における Microservices Architecture と DevOps を推進する組織と人とツール
AWS における Microservices Architecture と DevOps を推進する組織と人とツールAWS における Microservices Architecture と DevOps を推進する組織と人とツール
AWS における Microservices Architecture と DevOps を推進する組織と人とツール
 
20211109 JAWS-UG SRE keynotes
20211109 JAWS-UG SRE keynotes20211109 JAWS-UG SRE keynotes
20211109 JAWS-UG SRE keynotes
 
JAWS-UG三都物語_企業でのAWS導入のエントリーポイント
JAWS-UG三都物語_企業でのAWS導入のエントリーポイントJAWS-UG三都物語_企業でのAWS導入のエントリーポイント
JAWS-UG三都物語_企業でのAWS導入のエントリーポイント
 
【de:code 2020】 Apps on Azure AD - アプリケーション連携 WHY と HOW
【de:code 2020】 Apps on Azure AD - アプリケーション連携 WHY と HOW【de:code 2020】 Apps on Azure AD - アプリケーション連携 WHY と HOW
【de:code 2020】 Apps on Azure AD - アプリケーション連携 WHY と HOW
 
Web制作/SIerのためのAWS
Web制作/SIerのためのAWSWeb制作/SIerのためのAWS
Web制作/SIerのためのAWS
 
負荷分散勉強会
負荷分散勉強会負荷分散勉強会
負荷分散勉強会
 
スキニーなシステム開発にぴったりの契約形態
スキニーなシステム開発にぴったりの契約形態スキニーなシステム開発にぴったりの契約形態
スキニーなシステム開発にぴったりの契約形態
 
20190222 osc2019tokyospring
20190222 osc2019tokyospring20190222 osc2019tokyospring
20190222 osc2019tokyospring
 
161218 cybozu SRE
161218 cybozu SRE161218 cybozu SRE
161218 cybozu SRE
 
サービスリニューアルからの チームの変遷
サービスリニューアルからの チームの変遷サービスリニューアルからの チームの変遷
サービスリニューアルからの チームの変遷
 
20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operation20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operation
 
Social Enterprise Java Apps on Heroku Webinar
Social Enterprise Java Apps on Heroku WebinarSocial Enterprise Java Apps on Heroku Webinar
Social Enterprise Java Apps on Heroku Webinar
 
AWSで動画共有サイトを作成して全社に公開
AWSで動画共有サイトを作成して全社に公開AWSで動画共有サイトを作成して全社に公開
AWSで動画共有サイトを作成して全社に公開
 
Automation with SoftLayer and Zabbix
Automation with SoftLayer and ZabbixAutomation with SoftLayer and Zabbix
Automation with SoftLayer and Zabbix
 
AWSについて @ JAWS-UG 沖縄 CMS祭り!
AWSについて @ JAWS-UG 沖縄 CMS祭り!AWSについて @ JAWS-UG 沖縄 CMS祭り!
AWSについて @ JAWS-UG 沖縄 CMS祭り!
 
今なぜサーバーレスなのか
今なぜサーバーレスなのか今なぜサーバーレスなのか
今なぜサーバーレスなのか
 
JaSST'13 Kansai 継続的フィードバックによる品質運営
JaSST'13 Kansai 継続的フィードバックによる品質運営JaSST'13 Kansai 継続的フィードバックによる品質運営
JaSST'13 Kansai 継続的フィードバックによる品質運営
 

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