今日は July Tech Festa 2017 ( #JTF2017 ) で発表をしてきたので，さっそく参加レポートをまとめた．運営の皆さま，お疲れさまでした！
発表資料
感想 / 補足など
今回は「急成長するサービスを支える DevOps 戦略と組織変革へのアプローチ」というタイトルで発表をした．タイトルが良かったのかもしれないけど，会場はほぼ満席で嬉しかった（空席が目立つ会場もチラホラあったため）．
発表内容としては大きく3点で，DevOps の話と組織変革の話をバランス良く混ぜることを意識した．特に「組織変革」の部分が重要で，組織課題が残っている状態でどんなに頑張ってもサービスは伸びないと思っている．「DevOps は文化である」ことはよく知られているのに，文化として根付かせるために変化を実践できている人は案外少ないのでは？
- 急成長を支える ( ≒ 守る ) ための DevOps 戦略
- 急成長を支える ( ≒ 攻める ) ための DevOps 戦略
- DevOps 戦略に必須だった組織変革へのアプローチ
また，今回は発表が45分間と長く，参加者とシンクロしながら発表したいなと思っていたため，最初にアイスブレイクとして「ノンバーバルなコミュニケーション」の例として「うなずく練習」をしてもらったりもした．ミーティングの場でも重要なスキルなので，是非意識してもらえると良いのでは！
関連記事
モニタリング + AWS Well-Architected Framework の話は，以下に記事を公開している．
「Aurora 事例祭り」で話した Aurora 移行の詳細は，以下の記事を公開している．
経営層を巻き込んだ話のインタビュー記事も公開している．
コミュニケーションに悩んでいる人には以下の記事が参考になるはず．
関連書籍
発表資料の中で大量の本を紹介した．特に厳選すると以下かな！
「構成ドリフト」と「スノーフレークサーバ」の話は Infrastructure as Code 本に載っている．
Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス
- 作者: Kief Morris,宮下剛輔,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/03/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
組織変革なら Fearless Change をオススメする！質疑応答のときに Fearless Change を監訳された川口さんとお話できてすごく嬉しかった！（ただ質疑応答はテンパって変な回答になってしまった…あああw）
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
- 作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典
- 出版社/メーカー: 丸善出版
- 発売日: 2014/01/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (16件) を見る
第1章にまとまってる「ラストマイル」の話は必読だと思う．
ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション
- 作者: ThoughtWorks Inc.,株式会社オージス総研オブジェクトの広場編集部
- 出版社/メーカー: オライリージャパン
- 発売日: 2008/12/27
- メディア: 単行本（ソフトカバー）
- 購入: 14人 クリック: 323回
- この商品を含むブログ (81件) を見る
写真
A00 : 「ITエンジニアリングの本質」を考える / @enakai00
- How Google Works
- Jupiter Network 紹介
- Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network
- 特徴の1個 : Clos トポロジー
- 第5世代 Jupiter Network
- Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network
- Google では Software Engineer がネットワーク管理の仕組みも考える
ネットワークの話は難しい部分も多かったが，直面する課題に対して考え続けるという思想こそが，エンジニアリングの本質なんだろうなと感じることができ，素晴らしかった．特に資料の最後にある「技術的制約に対する洞察力」があるからこそ，現在の常識を壊すことができているんだと思う．
www.slideshare.net
B10 : Web サービスの信頼性を守るための取り組み / @rrreeeyyy
- SRE : サイトの信頼性の全てに責任範囲を持つ
- Software Engineering
- 自動化スクリプト / ツール実装 / プロダクションコードも直す
- Systems Engineering
- 1回の作業で永続的な改善を生む作業
- アーキテクチャ設計
- Toil
- 繰り返し行われる手動オペレーション
- トイルを無くすことが重要
- Overhead
- 管理的な作業
- 採用/ 評価 / トレーニング
- Software Engineering
- プロジェクトごとに，1人 SRE がアサインされて，設計相談やレビューをする
- アプリケーションの負荷テストを実施する
- そもそも，エンジニアが負荷テストを実施している時点で，Toil なのでは？
- ロードバランサの改善
- ソフトウェアを自作するのも SRE の仕事
- GitHub - ryotarai/simproxy: Simple HTTP balancer (reverse proxy)
日本語訳の SRE 本は買ってあるけど，まだちゃんと読めていなかったため，理論的な部分と実践的な部分の話が聞けて，個人的には1番面白かった．エラーバジェットも実践しているという点も興味深かった．また，定義上は Overhead にあたり新卒研修も，改めて理解を整理できるだろうし，担当する SRE 側にも大きなメリットがあるだろうなと感じた．
C20 : 若手エンジニアの私が MBA（経営学修士）を取りに行った話 / @nari_ex
- 上司の薦めで，経営大学院に入学することになった
- 組織行動 (OB) と 人的資源管理 (HRM)
- 理論と実践は違う − フィードバックをもらったり，ストレングスファインダーを試して，自分を知る工夫をした
自己過信によって失敗が続き，自分を見つめ直す中で，マネジメントに興味が出て，上司の薦めで経営大学院に入学したという話だった．個人的には，話を聞いていて全体的に甘いなという印象を受けた．マネジメントに限った話ではないけど，理論武装しているだけではダメで，実践してこそ価値があると思っている．そもそもメンバーからの信頼が無ければマネジメントなんてできないため，まずはメンバーから信頼されるためにどうしたら良いか？を考えてみるのが良いのではないかなと感じた．あと結局のところ，ビジネスの成功や，メンバーの成長など，目に見える成果が出ていなければ，マネジメントは成功したとは言えない点も重要だと思う．MBA は非常に興味あるなー！
A40 : Kubernetes でクラスタリングして解決したことと新たに出てきた課題 / @koudaiii
- 新規サービスの立ち上げを早くするために Kubernetes を導入した
- rails c を実行するコンテナ，rake db:migrate を実行するコンテナなどもある
- 80個以上もあったチェック項目が，簡単になった
- Kubernetes によって，スケールも容易になった
僕のところだと ECS を使っているため，Kubernetes は全然詳しくないが，大規模な Kubernetes 導入事例として非常に面白かった．特にサービス数が 9 → 60 に増えているという伸びが，まさに Kubernetes 導入が成功だったことを示していると思う．Kubernetes のマスターも3台構成にして，SPOF を回避しているとのことだった．
まとめ
- July Tech Festa 初参加だった（なぜ7月開催じゃないのに July なんだろう…w）
- 発表できて良い経験になった
- LT と違って45分間もあると幅広く話せるなーと感じられた