1. DevOps for Business 2017/6/6 株式会社アトラクタ 取締役最高技術責任者/アジャイルコーチ 吉羽龍太郎
2. 吉羽龍太郎 @ryuzee ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ 野村総合研究所、Amazon Web Servicesなどを経て創業 ✤ アジャイル開発/改善/自動化/クラウド関連のコンサルティングとトレーニングを提供
3. 株式会社アトラクタのご紹介 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ ✤ アジャイル開発 / 改善 / 自動化 / チーム育成 / クラウドコンピューティング / ド メインモデリングなどが専門領域 https://www.attractor.co.jp/
4. スライドは後で入手できますので、 スライドに書いてあることをメモする必要はありません。 写真撮影は構いませんがシャッター音はでないように。
5. 今日の話 ✤ ✤ DevOpsという単語はとてもメジャーになってきましたが、その背景や現状の やり方の問題点を振り返り ビジネスサイドの人がどのように対処していけばよいかを考えます
6. 時価総額ランキング 2016 2006 1. アップル (6091億ドル) 1. エクソンモービル (4470億ドル) 2. アルファベット (5434億ドル) 2. GE (3840億ドル) 3. マイクロソフト (4487億ドル) 3. マイクロソフト (2940億ドル) 4. Amazon (3969億ドル) 4. CITIグループ (2730億ドル) 5. Facebook (3683億ドル) 5. ガスプロム (3680億ドル)
7. 現在のビジネス状況 ✤ ✤ ✤ ✤ ビジネスの変化がどんどんはやくなっている VUCA => Volatility (不安定) / Uncertainty (不確実) / Complexity (複雑) / Ambiguity (曖昧) 多くのサービスがこの10年以内に登場し既存のビジネスモデルに影響を与えた り、人の働き方を変えている。GitHub (2008), Dropbox (2008), Evernote (2008), Slack (2014), Airbnb (2008) , SORACOM (2015) ITはビジネス上の成果達成のための重要な要素に
8. ビジネスサイドの願い ✤ あたるプロダクトを作りたい ✤ いまあるプロダクトをもっとよくしたい ✤ もっとマーケットの変化に柔軟に対応したい ✤ もっと頻繁にマーケットに製品を投入したい ✤ もっといろいろなことを試したい ✤ 顧客を増やし、繋ぎとめておきたい
10. 昔ながらのプロダクトやシステムの作り方 要求を全部あつめる 見積もる まとめて作る まとめて確認する
11. (1) 要求を全部集める 要求を全部あつめる 見積もる まとめて作る まとめて確認する
13. システムの機能の利用割合 いつも使う 7% よく使う 16% たまに使う 13% まったく使わない 45% ほとんど使わない 19% 64% の機能はほとんど、もしく はまったく使われていない。 PCのプレインストールソフ トウェアなどを考えると想 像がつく The Standish Group “Chaos” report 2002
14. 7つのムダ ✤ 作りすぎのムダ => 使わない機能 ✤ 手待ちのムダ => 仕様未決で開発待ち ✤ 運搬のムダ => 他部署への引き継ぎ ✤ 加工のムダ => ドキュメントの体裁 ✤ 在庫のムダ => 同時にたくさん着手 ✤ 動作のムダ => 不要な作業、遅い作業 ✤ 不良を作るムダ => バグ修正
15. つまり ✤ ✤ 最初に要求を全部集めても、それがあっている保証がない 一度機会を逃すと機能を追加するのが当面先になるので、とりあえず必要そう なものをたくさん入れようとする力が働く ✤ ただしそうやって「必要かもしれない」と思って入れた機能は使われない ✤ これは価値を産んでいない(ムダ) ✤ 規模が大きくなると加速度的に保守の労力が上がり、速度が遅くなっていく
16. (2) 見積もる 要求を全部あつめる 見積もる まとめて作る まとめて確認する
17. 費用とスケジュール見積りは難しい 不確実性コーン
18. 見積もる人と作る人が違うとさらに難しい ✤ 作るチームが違えば、(本当は)見積りも変わってくる
19. (3) まとめて作る 要求を全部あつめる 見積もる まとめて作る まとめて確認する
20. 受渡し 設計チーム 開発チーム テストチーム ✤ フェーズごとに異なる役割の人たちで作っていく ✤ 途中で変更を加えにくい 運用チーム
21. (4) まとめて確認する 要求を全部あつめる 見積もる まとめて作る まとめて確認する
22. そこで起こること ✤ 頼んだものと違う ✤ バグだらけ ✤ 期日に間に合わない ✤ ✤ ただでさえ時間がかかったのにさらに時間が かかる ビジネスチャンスをどんどん逃す
23. すなわち従来のやり方は… ✤ バッチサイズが大きすぎる ✤ フィードバックサイクルが長すぎる ✤ そもそもサイクルが回っていない可能性すら ✤ リスクは後半ほど顕在化する ✤ 変化に対応できない ✤ (※ もちろん変化がない領域であれば問題はないし、そういう場合ではオフ ショア開発が有効に機能することもある）
24. (新規ビジネス)ビッグバン一発勝負 収益 リリース 期間は長い 回収できるか分からない 時間 0 累積損失額 ？ ？ 最初に使うお金が大きい ？
26. ビジネスとして すばやいフィードバックサイクルを回したい d Learn Bu il s a e M e r u
27. ビジネスとしてのフィードバックサイクル フィードバック ✤ ✤ リリース 要求 ✤ 開発 ビジネスとしてのフィードバック サイクルとは… 要求を出してから市場に出荷して フィードバックを得るまで この流れはなるべく速くしたい (遅れを少なくしたい)
28. (再掲) バッチサイズと受渡し ◯◯チーム ✕✕チーム △△チーム ▲▲チーム ✤ バッチサイズが大きく、受渡しの回数が多いほど、遅れが大きくなる ✤ 間で必要な情報などが欠落していく ✤ 頼んだものと違うものができあがる。止めたくても止まれない
29. 簡単に試せます 作業者 管理者 ✤ コイン渡しゲーム ✤ 20枚のコインを用意します ✤ 管理者 作業者 管理者 作業者 顧客 作業者 管理者 ✤ 自分の手元に来たコインを全てひっく り返して次の人に渡します まとめて20個でやったとき、5個づつ やったとき、1個づつやった時に全て の作業が完了する時間、最初に成果物 ができる時間はどうなるでしょう？
30. バッチサイズを小さくして頻繁にサイクルを回す 2週間 2週間 2週間 2週間 ✤ 大事な要求から順番に実現し続ける ✤ 何が今やるべき大事なことなのかビジネス側は優先順位判断をし続ける ✤ 要求の中身も優先順位もすべて変化する可能性があり、それに対応する 2週間
31. 頻繁にサイクルを回す開発の方法 = Agile
32. 頻繁にサイクルを回すリリースの方法 継続的デプロイ・継続的デリバリー
33. が、その前にやるべきこと ✤ ✤ もしそれぞれのプロセスで漏れがあった場合、速いフィードバックサイクルを つくろうとするとあちこちで問題が高速に発生する 品質を犠牲にして速度をあげようとすると却って遅くなる
34. 漏れがあるまま急がない ✤ 漏れがあるまま進めるとどうなるか… ✤ ダメな要求を渡せばゴミができあがる ✤ ダメな要求を渡せば開発チームが頻繁に確認しないといけなくなる ✤ プロダクトの品質に合わないコードを作ると後で直さないといけなくなる ✤ デプロイを雑にやると本番環境で障害対応しないといけなくなる ✤ これらが無限ループすると目も当てられない ✤ ビジネス側はチームの能力を超えた速度のプレッシャーをかけてはいけない
35. つまりまずやるべきことは品質の確保(自工程完結) ✤ プロダクトやシステムにはそれ固有の然るべき品質がある ✤ 医療用ロボットとWebサイトでは要求される品質は異なる ✤ 品質はコードだけに限らない ✤ 不良を次工程に回さない ✤ 自分の工程ではなく、相手の工程から見て十分な品質のものを受け渡す ✤ つまりプロセスの逆流を出来る限り避ける ✤ ただし一気にいろいろなことを変更してはいけない ✤ 混乱するし効果が分からない
36. 逆流を防ぐ 工程A 工程B NG 50% ✤ 50%の確率で前工程に差し戻されるケースを考えてみると ✤ 2回工程AをやればOKになるわけではない ✤ 累計で1回目：50% / 2回目：75% / 3回目：87.5% / 4回目：93.75% ✤ つまり逆流率が高ければ高いほど完成時期が予測できなくなる OK
37. 直行率を上げる 工程A 工程C 工程B NG 50% NG 20% ✤ このケースでの直行率は 0.5 * 0.8 = 0.4 = 40% ✤ つまり流れの中に不良率の高い工程があるとそれが全体の速度に影響する ✤ まず不良率の高い箇所を直す ✤ それがどこなのかはプロダクトやプロジェクトによって異なる ✤ 渡した要求がダメなこともある
38. 必ずしも開発チームが最大の問題とは限らない ✤ 「改善に終わりなし」とはいえ大きな問題から直したい ✤ 常にビジネス側ではなく、開発側に最大の問題があると言い切れない ✤ ビジネス側の不完全な要求、期日やスコープのプレッシャー、開発チームに対 する意味のない割り込みが最大の問題であることはよくある
39. どう問題のある箇所を見つけるか ✤ 見えないものは改善できない ✤ => バリューストリームマッピング ✤ ✤ ✤ ✤ アイデアを思いついてから実際に顧客にそれを届けるまでのプロセスや成果物、 所要時間、待ち時間、バッチサイズ、手戻り率などを図解する 共通理解の形成と問題点の見える化 思った以上にそのプロダクトやシステムに関わる人たちが自分たちのプロセス を理解していないことが多い 図解した時点では仮説なので、改めてメトリクスを取得するのも良い
40. データの活用 ✤ データで共通理解を持ち、製品やプロセスの改善に活用する ✤ 以下のようなデータを測定することが多い ✤ ✤ ユーザー数、ユーザー増加数、機能別利用状況、売上、開発速度(ベロシ ティ)、不具合数、デプロイ回数、変更量、リードタイム、失敗したデプロ イ回数、障害からの復旧時間(MTTR)、平均障害間隔(MTBF)、チケット数、 可用性、パフォーマンスデータ、リクエスト数、… ✤ 目的にあわせてメトリクスを取ること ✤ 不要になった項目は取るのを止めること(ムダ) データはいつでも誰もが簡単に見えないといけない
41. Opinion vs Fact (意見か事実か) Problem (問題) Solution (解決策) 計測 Fact (事実) デプロイ 仮説 Opinion (意見) 設計
42. 事実を起点に考える ✤ 「デプロイ自動化ができていない」 => これは問題か？ ✤ 「テスト自動化ができていない」 => これは問題か？ ✤ 「◯◯というソリューションができていない」は問題の兆候 ✤ ✤ 場の透明性と安全性の欠如が根底に ✤ 透明性と安全性を確保してから、原因となった事実を探る 定性的な事実も参考になる ✤ 「この作業は怖いしできればやりたくない」
43. 継続的な改善を続けよう ✤ 改善とは、自分たちの仕事を「安全」にする ✤ 改善とは、自分たちの仕事を「簡単」にする ✤ 忙しすぎると改善できない ✤ ✤ プロセスやツールの改善をしたり学習する時間の余裕が必要 強制的に立ち止まれる仕掛をつくる (人間は停止するのが苦手)
45. ツールの重要性を理解する ✤ ✤ ✤ 人的コストはもっとも高いコストの1つなので、安全で簡単なツールを使って 手戻りやムダな時間(開発者の心理的ストレスも)を減らすことは重要 適切な投資が必要 ただしツールを入れれば即さまざまな問題を解決するわけではない点は理解し ておくこと
46. 短い周期で止まってふりかえる Token of Appreciation Timeline Happiness Radar Star Fish Story of Story WWW ※Fun Retrospectivesより
47. 短いサイクルほど改善を進めやすい 2週間 2週間 2週間 2週間 ✤ 直近のことであればどんなことがあったか覚えている（喉元すぎない） ✤ 短い期間しかないのでたくさんは変えられない。必然的に集中する 2週間
48. 漏れがなくなったら？ ✤ ✤ 流れを速くする活動 ✤ リードタイムを縮める ✤ プロセスタイム(処理時間)を縮める(ツールの活用も含む) ✤ 全体の工程を最適化する 流れる量を増やす活動
49. リードタイムを縮める ✤ リードタイム = プロセスタイム(処理時間) + 待ち時間 ✤ プロダクト全体のリードタイムは、それぞれの工程のリードタイムの合計 ✤ そのために ✤ 待ち時間を減らす => 人に何かをやってもらうまで待つのをなくせばよい ✤ ✤ クロスファンクショナルチーム化、権限の委譲 プロセスタイム(処理時間)を減らす ✤ ツールの活用、自動化、不要作業の削減、効率化
50. 工程の最適化：工程をなくす(Eliminate) Before 工程A After 工程A 工程B 工程C 工程C
51. 工程の最適化：工程を統合する(Combine) Before After 工程A 工程B 工程A 工程C
52. 工程の最適化：順番を変える(Rearrange) 手戻り Before 工程A 工程B 工程C After 工程C 工程A 工程B
53. 工程の最適化：単純化する(Simplify) 工程B1 Before 工程A 工程B 工程C 工程B2 After 工程A 工程B 工程C
54. スループットを増やす ✤ ✤ ✤ ここまでの活動を持続的に継続しているとスループット は増えている 空いたキャパシティを全てを再投入しないこと 「Doing Twice the Work in Half the Time」 ジェフ・サザーランド
55. アジャイルマニフェスト だいじなことはアジャイル ソフトウェア開発宣言に書いて あった
56. アジャイルソフトウェア開発宣言 12の原則(抜粋) ✤ 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します ✤ 要求の変更はたとえ開発の後期であっても歓迎します ✤ 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリース します ✤ ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません ✤ アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持でき るようにしなければなりません ✤ チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分 たちのやり方を最適に調整します
57. DevOpsとは結局何なのか？ ✤ 変化するビジネス環境に対応するために ✤ 漏れをなくす ✤ リードタイムを縮める ✤ スループットを増やす ✤ 継続的で関係者全員が関与する活動のこと ✤ ツールだけの話ではないし、プロセスだけの話でもない ✤ 開発者だけでなく、ビジネス側も継続的な関わりが必要
