1. DevOpsの基本 2016/1/26 Ryuzee.com Ryutaro YOSHIBA (a.k.a @ryuzee)
2. 吉羽 龍太郎 (Ryutaro YOSHIBA) アジャイル開発、DevOps、クラウドコンピューティング、インフ ラ構築自動化、組織開発を中心としたコンサルティングおよびト レーニングの専門家。 プロフィール 1973年生まれ。麻布高校、中央大学法学部法律学科卒業 後新卒で東洋情報システム(TIS)入社。その後野村総合研 究所に転じ証券会社をはじめとして各種Web系システム 開発においてアジャイル開発を実践。2009年に野村総合 研究所出身者を中心としたコンサルティング会社の起業 に参画しアジャイル開発のコンサルティングを提供。 2013年4月にAmazon Web Services(AWS)に転じ、AWS に関する有償コンサルティング部門であるAWS Professional Servicesの日本チーム立ち上げを推進。トッ プコンサルタントとしてグローバルで表彰を受けるとと もに日本チーム全体をリード。2016年1月開業 表彰 2014年楽天テクノロジーアワード Ruby賞 / デブサミ (Developers Summit)2013 ベストスピーカー賞(3位) / デ ブサミ(Developers Summit)2011 ベストスピーカー賞(2 位) / インストールマニアックス3 優秀賞 / インストール マニアックス2 奨励賞 資格 認定スクラムプロフェショナル / 認定スクラムマスター / 認定スクラムプロダクトオーナー / AWS 認定ソリュー ションアーキテクト – アソシエイト / AWS 認定デベロッ パー – アソシエイト / AWS 認定システムオペレーション （SysOps）アドミニストレーター – アソシエイト。元 Microsoft MVP for VisualStudio ALM
3. 提供サービスのご紹介 Ryuzee.comにて提供する主なサービスをご紹介します。 Cloud Architecting支援 アジャイルコーチング Agile開発については多くの誤解があり、 また経験の無いチームが自力で行うのは 難易度が高いものです。当方ではオンサイ トでAgile開発での企画∼開発まで全工程 を支援します。例えばプロジェクト立ち上 げに際しての集合研修、ふりかえりや計画 ミーティングのファシリテーションな ど。 ビジネスの成長やシステムの利用状 況に柔軟に対応できるのがクラウド の特性ですが、一方でシステムアー キテクチャがレガシーであればその メリットを享受できません。本支援 ではマイクロサービス化を始めとし て、柔軟で結合度の低いクラウドネ イティブアーキテクチャの構築を支 援します。 DevOps実践支援 技術顧問・執筆・講演 DevOpsには組織とツールの2つの要 技術顧問として定期的に訪問した 素があります。サイロ型の組織構造 り、Agile・DevOps・クラウドに関 のDevOps型組織への転換(組織デザ する講演をいたします。またWeb・ イン、採用プロセス、評価プロセ 書籍・雑誌など各媒体向けの執筆・ 翻訳を行ないます。 ス)、ツールによるデプロイ・プロビ ジョニング・運用・監視の自動化な ど幅広い側面で支援します。 詳細は http://www.ryuzee.com/service.html をご参照ください
4. 現在のビジネス状況 • ビジネスの変化がどんどんはやくなっている • ITはビジネス上の成果達成のための重要な要素に • 多くのサービスがこの10年以内に登場し既存のビジネス モデルに影響を与えたり、人の働き方を変えている。 GitHub (2008), Dropbox (2008), Evernote (2008), Slack (2014), Uber (2010), Airbnb (2008) , SORACOM (2015, Japan)
5. ムダ いつも使う よく使う 7% 16% 64% の機能はほとんど、もし まったく使わない くはまったく使われてい 45% たまに使う ない。PCのプレインス 13% トールソフトウェアなど を考えると想像がつく ほとんど使わない 19% The Standish Group “Chaos” report 2002
6. 7つのムダ • 作りすぎのムダ • 手待ちのムダ • 運搬のムダ • 加工のムダ • 在庫のムダ • 動作のムダ • 不良を作るムダ
7. うちのチーム1スプリン トですごい量の新機能作 れるんだぜ！ 使わない機能を作ってしまうのを避けなければならない。 作り過ぎるとコスト、複雑度、アプリやバグ調査のための時間などが増え てしまう。
8. 本当に顧客が望 んでいるものを 予測したり、そ の機能が使われ るか、ビジネス 価値向上の余地 があるかを予測 するのは難しい。 h6p://hrnabi.com/2015/11/05/9552/
9. 事前に正しいことを知るのは難しい。 素早い変化についていける能力を持つことが重要
10. すばやいフィードバックサイクルを作る これはスタートアップに限らない d Learn Bu il s a e M e r u
11. ウォーターフォール (Vモデル) 要件定義 受け入れテスト ェ ウ ト フ ソ る す 基本設計 までに 作 動 る 入 に 。 手 る か アが か が 間 て 時 っ 違 長い 間 詳細設計 が 求 要 … て く づ そし 気 に と こ た い コーディング/単体 システムテスト 結合テスト
12. すなわち巨大なウォーターフォールは 変化の早い領域では機能しない
13. アジャイル開発がメインストリームに State of Agile Survey 2014 (c)VersionOne
14. 現在の課題 • よいソフトウェアを顧客に届けることはビジネスにとって極めて重要 • しかし届ける速度は遅く、間違いがおこりやすい (特にトラディショナ ルな企業や大企業…) • これによってビジネス上の機会やお金を失う • 他にも自分たちには問題が • ITがボトルネックになっている
15. DevOpsの起源 • Agile 2008 ConferenceでPatrick Debois氏 (veeweeや sahara等のOSSツールの作者)が、 Agile Infrastructure & Operations というテーマで発表 • 2009年のO Reilly Velocity ConferenceでFlickr のエンジニアJohn AllspawとPaul Hammondが行っ た発表 10+ Deploys per Day: Dev and Ops Cooperation at Flickr.
16. 動画は必見 h6ps://www.youtube.com/watch?v=LdOe18KhtT4
17. OpsはDevのような考え方をし DevはOpsのような考え方をする しかし……
18. DevとOpsの間でのコンフリクト • ミッションや責任の違い (それは誰が決めたのか謎だし合 理的かはわからないが…) • それは自分の仕事じゃないです、という台詞の誘発 (誰が そんなこと言ってるんだ?) • サイロ型組織 • そしてオーバーヘッドが生まれる
19. アプリとサーバをちゃんと動か すのがおまえの責任だろ。おれ のせいにするな なんでアプリをもっとちゃんとした 品質で作らないんだよ。夜間コール がんがん受ける身にもなれよ
20. 同じような話があなたの組織にもある？ • このコードは僕が書いたんじゃないので分かりません • このタスクは○○さん担当なので僕を責められても… • これは規則で決まってるんです。なので従わなきゃいけま せん… • 他の部門がいつも遅いんで、そのせいで遅れるんです… • 他の仕事があるんで…
21. 実際のところ、ソフトウェア開発上の問題の多 くは、技術的というより社会学的なものである ‒トム・デマルコ/ティモシー・リスター「ピープルウェア」より引用
22. サイロによるオーバーヘッド • 他の部門とのコミュニケーションにかなり多くの時間を 使っている • (もちろんコミュニケーションは重要だが、問題は中身が 手続き論に終始しがちなこと) • 結果として顧客にとって直接的に 価値になることに時間が使えていない
23. 時間の4分の1以上が会議に費やされている ならば、組織構造に欠陥があると見てよい ‒ピーター・F. ドラッカー
24. • チームは他の部門に引き継ぎすることなくソフトウェア を直接顧客に届けられる能力を持っていた方がよい • 可能であれば組織構造を変え、密結合な組織間の関係を 疎結合に
25. Werner Vogels, CTO, amazon.com You build it, You run it h6ps://www.flickr.com/photos/interopevents/6217288899/
26. 2ピザルール チームのサイズを 2枚のピザでみんなが満腹になるサイズに保つ
27. • Amazonではamazon.com用のサーバを調達する手 続きをAPIに置き換えた • そうすることで、コミュニケーションオーバーヘッドを削 減しプロビジョニングまでの時間を短縮
28. ところでずっと組織の話してるけど DevOpsの話はマダー？
29. DevOpsは銀の弾丸ではない 皆様!! 弊社の最新ツールを導 入すると簡単にDevOpsを達 成できますよ 笑えない冗談…
30. DevOpsはフレームワークではない みんな、他の会社のCEOから聞 いたんだけどその会社DevOps を導入して成功したらしいよ。 すぐうちもやろう！すぐそれもっ てきて！予算つけるから！ 笑えない冗談…
31. DevOpsは自動化ではない DevOps?? やっとかよ。待ち くたびれたな。早速自動化コー ド書こうぜ。自動化しなきゃい けないものが沢山あるんだ それだけでは不十分…
32. DevOpsは文化とツールを活用することで、 ビジネスの成功を目指すものであり、 ビジネスのためのアジリティを向上させ、 リスクを低減するものである。
33. DevOpsの構成要素 CLAMS • Culture (文化) • Lean (リーン) • AutomaJon (自動化) • Measurement (測定) • Sharing (共有)
34. リーンシンキング • 組織をまたがるバリューストリームに注目する • もしチームがサイクルタイムを減らせたとしても必ずしも 全体のリードタイムが短くなるとは限らない • ボトルネックが存在する可能性がある… • 制約理論(ToC)を学ぶとよい
36. ケーススタディ(1) ボトルネックはどこ？ WIP: 2 2日/ WIP: 4 3日 / WIP: 6 2日/ WIP: 1 20日 / 機能 機能 機能 機能 分析 開発 テスト QA / デプロイ Dev $$$$ Ops このケースではリードタイムはとても長い。というのもQA/デプロイが20日も占めているから。さら に同時に1つしかデプロイできないのでスループットも低い。ここでDevチームの生産性を向上させて も全体のリードタイムとスループットの向上はわずか
37. ケーススタディ(2) ボトルネックはどこ？ 不具合… デプロイ拒否 修正待ち… 分析 開発 Dev テスト QA / デプロイ $$$$ Ops このケースでは全体のリードタイムがソフトウェアの低品質によって引き起こされて いる。なのでデプロイを自動化してもデプロイできるフィーチャーの数は増えない
38. トヨタ生産方式(TPS) では… 前工程は神様 後工程はお客様 • 前工程がきちんとした品質のものを届けてくれる(のに感謝) • 顧客とは実際のエンドユーザーだけでなく、内部の後工程も指す • 品質を作りこむ。そして不良を次工程に回さない
39. なぜDevOpsが必要か • ビジネスが速い速度で変化するから • ただ、なぜ自分の組織でDevOpsが必要なのかは自分 たちで明らかにする必要がある • DevOpsがトレンドで流行しているから というのは 最悪な答え • 自分たちの目的を見つける
40. 組織構造はアーキテクチャに影響を与える コンウェイの法則 organizaJons which design systems ... are constrained to produce designs which are copies of the communicaJon structures of these organizaJons - M. Conway Microservicesに関心があるかもしれないが、それを実 現できるかどうかは自分の組織構造に大きく依存。過度な 幻想を抱かないこと
41. DevOps実現の典型的なステップ • 全体のプロセスを見る • ビジネスとITの関係における問題や課題を見つけるととも に、全体を遅くしているボトルネックを探す • フロー、あるべき姿、状況確認のためのメトリクス、スケ ジュール、体制などを計画する • これらをPDCAサイクルで繰り返す • すなわちDevOpsはアジャイルなやり方で実現していくべき
42. やるべきことに優先順位をつける • こうやったらよさそうというものは沢山見つかるかもし れないがリソースや費用の制約、日々の仕事もあるので 一度に全部はできない。 • 一度に沢山のことを変えるのは自分やチームや組織を混 乱させる。またどれに効果があったのかもわかりにくい ので避ける。
43. 継続的にプロセスを改善し続ける h6ps://www.flickr.com/photos/gkirk/3351943143/ • 全体のバリューストリームと自分たちのまわりの両方に注意を 払う。ふりかえりはどんな開発手法を採用しているかに関係な く有効 • ゴールに向かって進んでいるかをメトリクスを使って確認する
44. リーダーシップとスポンサーシップが必要 全員がリーダーであること。そしてDevOpsは組織にかな り関係があるため経営からのスポンサーシップが必須。自 分のまわりを改善するだけでも効果はあるかもしれないが、 システム全体を改善するともっと大きな利益があるはず
45. すごいチームを作る 多様性は改善を加速する
46. 十分なスキルを確保する • スキルマップを作るとチームでデプロイできる能力がある か、リスクがなにか、学習すべき項目は何かが分かる。 Ruby RSpec 阿部 ○ ◎ 坂本 ◎ ○ 長野 ★ 鈴木 ・ 高橋 ・ ・ 片岡 △ △ HTML5 jQuery Fluentd Elastic MongoDB Search ・ △ ・ △ ◎ ◎ ★ AWS Chef Circle CI Git 応 ◎ リテー ション △ △ ◎ ★ ◎ ◎ ◎ ◎ △ ◎ ○ ○ △ ◎ ○ ◎ △ ◎ △ ◎ ファシ △ ◎ △ 設計 障害対 ◎ ○ ○ ○ ◎ ・ ◎ ・ ○ ◎ ★：エース / ◎：得意 / ○：一人で出来る / △：助けがあればできる / 空欄：できない / 今後習得したい：・
47. ツールの導入 • なぜそのツールを導入するかの理由を明確に • メジャーなツールを選ぶ • 同時に沢山のツールを導入しない • 利用者を教育する • 自分たちでメンテナンスする
48. どのツールから始めるか まずはバージョン管理、テストの自動化、継続的 インテグレーションのような基本的な技術要素か らはじめる
49. (再掲)DevOpsの構成要素 CLAMS • Culture (文化) • Lean (リーン) • AutomaJon (自動化) • Measurement (測定) • Sharing (共有)
50. Thanks for coming!! Any questions?
