1. 不確実な環境の中で 変化にどう対応すべきか 2019/12/13 株式会社アトラクタ 取締役CTO 吉羽龍太郎
2. 株式会社アトラクタについて ✤ 社名：株式会社アトラクタ 英文表記：Attractor Inc. / https://www.attractor.co.jp ✤ 設立：2016年12月 ✤ 所在：東京都港区 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメインモデリングなどが専門領域 2
3. 登壇 各種イベントでの登壇 コーチング オンサイト トレーニング アジャイル開発やDevOps に関するオンサイトコーチ ング アジャイル開発や組織づくり に関するオンサイト トレーニング 認定研修 認定スクラムマスター研修 Suitable for all categories 等の主催 business and personal 執筆・翻訳 技術書やドキュメントの 執筆や翻訳 などなど
4. 自己紹介 ✤ 吉羽龍太郎 (@ryuzee) ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ ✤ 野村総合研究所、Amazon Web Servicesなどを経てアトラクタを創業 開発プロセス/アジャイル開発/DevOps/クラウドコンピューティングが専門 ✤ Scrum Alliance Certified Team Coach (CTC) ✤ ✤ ✤ コーチングを受けることで認定スクラムマスター取得可能 Microsoft MVP for Azure 青山学院大学非常勤講師 4
6. 新刊 ✤ レガシーコードからの脱却 ―ソフトウェアの寿 命を延ばし価値を高める9つのプラクティス ✤ 2019/9/19 発売 3刷御礼 6
7. 今日の話 ✤ 以前とは比べ物にならないくらい変化が激しい現在の環境において、どのように対 処していけばよいかを考えます 7
8. 時価総額ランキング 2019 (6末) 2007 1. マイクロソフト (10265億ドル) 1. エクソンモービル (4685億ドル) 2. Amazon (9322億ドル) 2. GE (3866億ドル) 3. アップル (9106億ドル) 3. マイクロソフト (2936億ドル) 4. アルファベット (7510億ドル) 4. CITIグループ (2695億ドル) 5. Facebook (5509億ドル) 5. ペトロチャイナ (2618億ドル) 8
9. 現在のビジネス状況 ✤ ビジネスの変化がどんどんはやくなっている ✤ VUCA => Volatility (不安定) / Uncertainty (不確実) / Complexity (複雑) / Ambiguity (曖昧) ✤ ITはビジネス上の成果達成のための重要な要素に ✤ 多くのサービスがこの10数年以内に登場し既存のビジネスモデルに影響を与えた り、人の働き方を変えている。 ✤ GitHub (2008), Dropbox (2008), Evernote (2008), Airbnb (2008), Lyft (2012), MoneyForward (2012, Japan), Slack (2014), SORACOM (2015, Japan) 9
11. ビジネスの問題意識 ✤ あたるプロダクトを作りたい ✤ いまあるプロダクトをもっとよくしたい ✤ もっとマーケットの変化に柔軟に対応したい ✤ もっと頻繁にマーケットに製品を投入したい ✤ もっといろいろなことを試したい ✤ 顧客を増やし、繋ぎとめておきたい ✤ 使うべきところにお金を使いたい 11
14. 昔ながらのプロダクトやシステムの作り方 要求を全部あつめる 見積もる まとめて作る まとめて確認する 14
15. (1) 要求を全部集める 要求を全部あつめる 見積もる まとめて作る まとめて確認する 15
17. システムの機能の利用割合 いつも使う 7% よく使う 16% たまに使う 13% ほとんど使わない 19% まったく使わない 45% 64% の機能はほとんど、もしくは まったく使われていない。PC のプレインストールソフトウェ アなどを考えると想像がつく The Standish Group “Chaos” report 2002 17
18. 7つのムダ ✤ 作りすぎのムダ => 使わない機能 ✤ 手待ちのムダ => 仕様未決で開発待ち ✤ 運搬のムダ => 他部署への引き継ぎ ✤ 加工のムダ => ドキュメントの体裁 ✤ 在庫のムダ => 同時にたくさん着手 ✤ 動作のムダ => 不要な作業、遅い作業 ✤ 不良を作るムダ => バグ修正 18
19. つまり ✤ 最初に要求を全部集めても、それがあっている保証がない ✤ 一度機会を逃すと機能を追加するのが当面先になるので、とりあえず必要そうなも のをたくさん入れようとする力が働く ✤ ただしそうやって「必要かもしれない」と思って入れた機能は使われない ✤ これは価値を産んでいない(ムダ) ✤ 規模が大きくなると加速度的に保守の労力が上がり、速度が遅くなっていく 19
20. (2) 見積もる 要求を全部あつめる 見積もる まとめて作る まとめて確認する 20
21. 費用とスケジュール見積りは難しい 不確実性コーン 21
22. 見積もる人と作る人が違うとさらに難しい ✤ 作るチームが違えば、(本当は)見積りも変わってくる 22
23. (3) まとめて作る 要求を全部あつめる 見積もる まとめて作る まとめて確認する 23
24. 受渡し 設計チーム 開発チーム テストチーム ✤ フェーズごとに異なる役割の人たちで作っていく ✤ 途中で変更を加えにくい 運用チーム 24
25. (4) まとめて確認する 要求を全部あつめる 見積もる まとめて作る まとめて確認する 25
26. そこで起こること ✤ 頼んだものと違う ✤ バグだらけ ✤ 期日に間に合わない ✤ ただでさえ時間がかかったのにさらに時間がかかる ✤ ビジネスチャンスをどんどん逃す 26
27. 結果的にこうなっている… (プロジェクト成功率) ITプロジェクトの状況 21% 37% 42% 成功 問題あり 失敗 ✤ 失敗の理由 ✤ 不完全な要求 ✤ ユーザーの巻き込み不足 ✤ リソース不足 ✤ 非現実的な期待 ✤ 経営や管理職のサポート不足 ✤ 要求の変更 出典：Standish CHAOS Report 2010 27
28. 結果的にこうなっている… ✤ 62%の組織がスケジュールに間に合わない経験あり ✤ 49%の組織が予算超過の経験あり ✤ 47%が保守コストが予測を越えた経験あり ✤ 41%が期待されるビジネス価値やROIの実現に失敗した経験あり 出典：Tata Consultancy, 2007 28
29. Amazonが撤退した(主な)事業 ✤ 1999→2000 アマゾン・オークションズ ✤ 1999→2007 Zショップス ✤ 2011→2015 アマゾン・ローカル ✤ 2004→2008 検索エンジンA9 ✤ 2011→2015 テストドライブ(アプリの購入前試用) ✤ 2006→2013 アスクビル（Q&Aサイト） ✤ 2012→2015 ミュージック・インポーター ✤ 2006→2015 アンボックス(TVや映画の購入・レンタル) ✤ 2014→2015 ファイアフォン ✤ 2007→2012 エンドレス・ドットコム(靴とハンドバックのサイト) ✤ 2014→2015 アマゾン・エレメンツ ✤ 2007→2014 アマゾン・ウェブペイ(P2P送金) ✤ 2014→2015 アマゾン・ローカルレジスター(モバイル決済) ✤ 2009→2012 ペイフレーズ(合言葉による決済) ✤ 2014→2015 アマゾン・ウォレット ✤ 2010→2016 マイハビット(会員制タイムセール) ✤ 2015→2015 アマゾン・デスティネーションズ(宿泊予約) ベイン・アンド・カンパニーによる分析 29
30. 新規ビジネスビッグバン一発勝負(でいいのか？) 収益 リリース 期間は長い 回収できるか分からない 時間 0 累積損失額(投資額) ？ ？ 最初に使うお金が大きい ？ 30
31. すなわち従来のやり方は… ✤ バッチサイズが大きすぎる ✤ フィードバックサイクルが長すぎる ✤ そもそもサイクルが回っていない可能性すら ✤ リスクは後半ほど顕在化する ✤ 変化に対応できない ✤ このやり方でビジネスで成果を出せるのか？ 31
33. すばやいフィードバックサイクルを回したい Bu Learn ビジネスとして e M ild e r u s a 33
34. ビジネスとしてのフィードバックサイクル フィードバック リリース ✤ ビジネスとしてのフィードバック サイクルとは… ✤ 要求を出してから市場に出荷し てフィードバックを得るまで ✤ この流れはなるべく速くしたい (遅れを少なくしたい) 要求 開発 34
35. (再掲) 受渡し 設計チーム 開発チーム テストチーム ✤ バッチサイズが大きく、受渡しの回数が多いほど、遅れが大きくなる ✤ 間で必要な情報などが欠落していく ✤ 頼んだものと違うものができあがる。止めたくても止まれない 運用チーム 35
36. バッチサイズを小さくして頻繁にサイクルを回す 2週間 2週間 2週間 2週間 ✤ 大事な要求から順番に実現し続ける ✤ 何が今やるべき大事なことなのかビジネス側は優先順位判断をし続ける ✤ 要求の中身も優先順位もすべて変化する可能性があり、それに対応する 2週間 36
37. 頻繁にサイクルを回す組織的取り組み = DevOps ✤ Culture (文化) ✤ Lean (リーン) ✤ Automation (自動化) ✤ Measurement (測定) ✤ Sharing (共有) 37
38. 頻繁にサイクルを回す開発の方法 = Agile 38
39. 頻繁にサイクルを回すリリースの方法 = CD 継続的デプロイ・継続的デリバリー 39
40. 頻繁なサイクルを支えるインフラ = クラウド ✤ クラウドによって調達のリードタイムが激減 ✤ ビジネスの不確実性にあわせやすくなった ✤ ✤ ムダな初期投資が不要で、柔軟に変更ができる 最初にクラウドを検討する「クラウドファースト」の増加 40
41. 頻繁なサイクルを支える道具 = モダンなツールセット 41
42. 全部やる必要 ✤ 頻繁にサイクルを回す組織的取り組み = DevOps ✤ 頻繁にサイクルを回す開発の方法 = Agile ✤ 頻繁にサイクルを回すリリースの方法 = CD ✤ 頻繁なサイクルを支えるインフラ = クラウド ✤ 頻繁なサイクルを支える道具 = モダンなツールセット 42
43. 【重要】 成果を決める要素 問題設定力 開発力 チーム力 ✤ 適切な問題設定 ✤ ドメイン知識 ✤ 開発プロセス習熟 ✤ 明確なビジョン ✤ アーキテクチャ設計力 ✤ 心理的安全性 ✤ マーケットの理解 ✤ 開発言語 ✤ 透明性 ✤ 取捨選択 ✤ 性能 ✤ 検査と適応 ✤ 良いプロダクトバックログ ✤ セキュリティ ✤ ムダをなくす ✤ 優先順位付け ✤ インフラストラクチャー ✤ 学習 ✤ ステークホルダー管理 ✤ 自動化 ✤ リーダーシップ ✤ リスク・コスト管理 ✤ 品質・テスト ✤ オーナーシップ ✤ … ✤ … ✤ … 43
45. 最初にやるべきこと => 速さの前に品質 ✤ もしそれぞれのプロセスで漏れがあった場合、速いフィードバックサイクルをつくろ うとするとあちこちで問題が高速に発生する ✤ 品質を犠牲にして速度をあげようとすると却って遅くなる 45
46. 漏れがあるまま急がない ✤ 漏れがあるまま進めるとどうなるか… ✤ ダメな要求を渡せばゴミができあがる ✤ ダメな要求を渡せば開発チームが頻繁に確認しないといけなくなる ✤ プロダクトの品質に合わないコードを作ると後で直さないといけなくなる ✤ デプロイを雑にやると本番環境で障害対応しないといけなくなる ✤ これらが無限ループすると目も当てられない ✤ ビジネス側はチームの能力を超えた速度のプレッシャーをかけてはいけない 46
47. つまりまずやるべきことは品質の確保(自工程完結) ✤ プロダクトやシステムにはそれ固有の然るべき品質がある ✤ 医療用ロボットとWebサイトでは要求される品質は異なる ✤ 品質はコードだけに限らない ✤ 不良を次工程に回さない ✤ 自分の工程ではなく、相手の工程から見て十分な品質のものを受け渡す ✤ つまりプロセスの逆流を出来る限り避ける ✤ ただし一気にいろいろなことを変更してはいけない ✤ 混乱するし効果が分からない 47
48. 逆流を防ぐ 工程A 工程B OK NG 50% ✤ 50%の確率で前工程に差し戻されるケースを考えてみると ✤ 2回工程AをやればOKになるわけではない ✤ 累計で1回目：50% / 2回目：75% / 3回目：87.5% / 4回目：93.75% ✤ つまり逆流率が高ければ高いほど完成時期が予測できなくなる 48
49. 直行率を上げる 工程A 工程B NG 50% 工程C NG 20% ✤ このケースでの直行率は 0.5 * 0.8 = 0.4 = 40% ✤ つまり流れの中に不良率の高い工程があるとそれが全体の速度に影響する ✤ まず不良率の高い箇所を直す ✤ それがどこなのかはプロダクトやプロジェクトによって異なる ✤ 渡した要求がダメなこともある 49
50. 必ずしも開発チームが最大の問題とは限らない ✤ 「改善に終わりなし」とはいえ大きな問題から直したい ✤ 常に開発側に最大の問題があると言い切れない ✤ ビジネス側の不完全な要求、期日やスコープのプレッシャー、開発チームに対する 意味のない割り込みが最大の問題であることはよくある ✤ 組織や文化の問題 50
52. ケーススタディ(1) ボトルネックはどこ？ WIP: 2 2日/ 機能 WIP: 4 3日 / 機能 WIP: 6 2日/ 機能 WIP: 1 20日 / 機能 分析 開発 テスト QA / デプロイ Dev Ops $$$$ 52
53. ケーススタディ(1) ✤ このケースではリードタイムはとても長い。というのもQA/デプロイが20日も占めて いるから。さらに同時に1つしかデプロイできないのでスループットも低い。ここで Devチームの生産性を向上させても全体のリードタイムとスループットの向上はわ ずか 53
54. ケーススタディ(2)ボトルネックはどこ？ 不具合… 分析 デプロイ拒否 修正待ち… 開発 Dev テスト QA / デプロイ Ops $$$$ 54
55. ケーススタディ(2) ✤ このケースでは全体のリードタイムがソフトウェアの低品質によって引き起こされて いる。なのでデプロイを自動化してもデプロイできるフィーチャーの数は増えない 55
56. どう問題のある箇所を見つけるか ✤ 見えないものは改善できない ✤ => バリューストリームマッピング ✤ アイデアを思いついてから実際に顧客にそれを届けるまでのプロセスや成果物、所 要時間、待ち時間、バッチサイズ、手戻り率などを図解する ✤ 共通理解の形成と問題点の見える化 ✤ 思った以上にそのプロダクトやシステムに関わる人たちが自分たちのプロセスを理 解していないことが多い ✤ 図解した時点では仮説なので、改めてメトリクスを取得するのも良い 56
57. データの活用 ✤ データで共通理解を持ち、製品やプロセスの改善に活用する ✤ 以下のようなデータを測定することが多い ✤ ✤ ユーザー数、ユーザー増加数、機能別利用状況、売上、開発速度(ベロシティ)、不 具合数、デプロイ回数、変更量、リードタイム、失敗したデプロイ回数、障害からの 復旧時間(MTTR)、平均障害間隔(MTBF)、チケット数、可用性、パフォーマンス データ、リクエスト数、… ✤ 目的にあわせてメトリクスを取ること ✤ 不要になった項目は取るのを止めること(ムダ) データはいつでも誰もが簡単に見えないといけない 57
58. Opinion vs Fact (意見か事実か) Problem (問題) Solution (解決策) 計測 Fact (事実) デプロイ 仮説 Opinion (意見) 設計 58
59. 事実を起点に考える ✤ 「デプロイ自動化ができていない」 => これは問題か？ ✤ 「テスト自動化ができていない」 => これは問題か？ ✤ 「◯◯というソリューションができていない」は組織的な問題の兆候 ✤ ✤ 場の透明性と安全性の欠如が根底に ✤ 透明性と安全性を確保してから、原因となった事実を探る 定性的な事実も参考になる ✤ 「この作業は怖いしできればやりたくない」 59
60. 継続的な改善を続けよう ✤ 改善とは、自分たちの仕事を「安全」にする ✤ 改善とは、自分たちの仕事を「簡単」にする ✤ 忙しすぎると改善できない ✤ ✤ プロセスやツールの改善をしたり学習する時間の余裕が必要 強制的に立ち止まれる仕掛をつくる (人間は停止するのが苦手) 60
61. ツールの重要性を理解する ✤ 人的コストはもっとも高いコストの1つなので、安全で簡単なツールを使って手戻り やムダな時間(開発者の心理的ストレスも)を減らすことは重要 ✤ 適切な投資が必要 ✤ ただしツールを入れれば即さまざまな問題を解決するわけではない点は理解して おくこと 61
62. ときには価値観やスキルセットを変える必要も ✤ ✤ 変化が激しい状況では常にもっとよいやり方を模索する必要がある ✤ 古いやり方にこだわりつづけると仕事がなくなっていく ✤ 例えば ✤ オンプレミスかクラウドかに関係なく使える技術を持つ必要 ✤ クラウドネイティブアーキテクチャを設計できるようにする ✤ 自動化やDevOpsの流れに乗る 価値観を変える ✤ 個人の成果ではなくチームやビジネスとしての成果にフォーカスする 62
63. 短い周期で止まってふりかえる Token of Appreciation Timeline Happiness Radar Star Fish Story of Story WWW ※Fun Retrospectivesより 63
64. 短いサイクルほど改善を進めやすい 2週間 2週間 2週間 2週間 ✤ 直近のことであればどんなことがあったか覚えている（喉元すぎない） ✤ 短い期間しかないのでたくさんは変えられない。必然的に集中する 2週間 64
65. 漏れがなくなったら？ ✤ ✤ 流れを速くする活動 ✤ リードタイムを縮める ✤ プロセスタイム(処理時間)を縮める(ツールの活用も含む) ✤ 全体の工程を最適化する 流れる量を増やす活動 65
66. リードタイムを縮める ✤ リードタイム = プロセスタイム(処理時間) + 待ち時間 ✤ プロダクト全体のリードタイムは、それぞれの工程のリードタイムの合計 ✤ そのために ✤ 待ち時間を減らす => 人に何かをやってもらうまで待つのをなくせばよい ✤ ✤ クロスファンクショナルチーム化、権限の委譲 プロセスタイム(処理時間)を減らす ✤ ツールの活用、自動化、不要作業の削減、効率化 66
67. スループットを増やす ✤ ここまでの活動を持続的に継続しているとスループット は増えている ✤ 空いたキャパシティを全てを再投入しないこと ✤ 「Doing Twice the Work in Half the Time」 ジェフ・サザーランド 67
68. アジャイルマニフェスト だいじなことはアジャイルソフ トウェア開発宣言に書いてあった 68
69. アジャイルソフトウェア開発宣言 12の原則(抜粋) ✤ 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します ✤ 要求の変更はたとえ開発の後期であっても歓迎します ✤ 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします ✤ ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません ✤ アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持でき るようにしなければなりません ✤ チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分た ちのやり方を最適に調整します 69
