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