1. マネジメント向け アジャイル開発概要 2020/1/20 株式会社アトラクタ 取締役CTO 吉羽龍太郎
2. 自己紹介 ✤ 吉羽龍太郎 (@ryuzee) ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ ✤ ✤ 野村総合研究所、Amazon Web Servicesなどを経てアトラクタを創業 開発プロセス/アジャイル開発/DevOps/クラウドコンピューティングが専門 ✤ Scrum Alliance Certified Team Coach (CTC) ✤ Microsoft MVP for Azure 青山学院大学非常勤講師 2
4. 時価総額ランキング 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億ドル) 4
5. 企業寿命の短命化 = サービス/ビジネスモデルの短命化 5
6. Netflixのピボット ✤ 1997年創業。DVDレンタルサービス ✤ 2001年に従業員の1/3を解雇 ✤ 2007年にDVDレンタルサービスからストリーミングサービスに移行 ✤ 2011年新ブランド展開と値上げに失敗し80万人が解約 ✤ 2015年日本展開 ✤ 2017年会員数1億人 すべての会社がこのような形でピボットできるわけでは決してない 6
7. 事業のポートフォリオを再検討する必要 数年前の事業構造 (0) 現在失われた数字 (-20) 数年後の数字予測 (-45) 5 10 5 10 10 10 15 30 20 20 20 10 25 20 15 10 10 20 10 5 10 10 A B C D 他 A B C D 他 A B C D 他 ✤ 既存の事業がシュリンクしつつあり、体力があるうちに失われる数字をカバーするものを作る必要 ✤ 失われたものをまとめてカバーするものを一発で作るのは極めて難しい（不可能） ✤ 多数の取り組みを素早く回して、ポテンシャルのあるものを見極めていく必要 ✤ 素早い投資判断。素早い実行。素早い撤退。うまくいけば素早く追加投資 7
8. 問題の分類（クネビンフレームワーク） Created in 1999 by Dave Snowden 問題を把握するために試行錯誤（探 索）を行い、それによって状況を把握・ 理解する領域。そのあとに次の対応を 考えていく。この場合、うまくやる方法 はあとからわかることになる 正解が1つではないものの、比較的予 測しやすい領域。状況を専門家が分析 して理解し、取り得る手を検討して進め ていく。うまくやる方法は複数あるため それをグッドプラクティスとして活用し ていく 革新的なことが求められる領域で正し い答えもわからないので、まず行動し てから理解していくしかない領域。既存 の知識が役に立たないこともある 正解が存在し変化の少ない領域。状況 を理解・分類し、ベストプラクティスに 基づいて進めていく 8
9. 問題の分類（クネビンフレームワーク） SOE(モード2) SOR(モード1) 問題を把握するために試行錯誤（探 索）を行い、それによって状況を把握・ 理解する領域。そのあとに次の対応を 考えていく。この場合、うまくやる方法 はあとからわかることになる 正解が1つではないものの、比較的予 測しやすい領域。状況を専門家が分析 して理解し、取り得る手を検討して進め ていく。うまくやる方法は複数あるため それをグッドプラクティスとして活用し ていく 革新的なことが求められる領域で正し い答えもわからないので、まず行動し てから理解していくしかない領域。既存 の知識が役に立たないこともある 正解が存在し変化の少ない領域。状況 を理解・分類し、ベストプラクティスに 基づいて進めていく 9
10. 問題の分類（クネビンフレームワーク） SOE(モード2) 問題を把握するために試行錯誤（探 索）を行い、それによって状況を把握・ 理解する領域。そのあとに次の対応を 考えていく。この場合、うまくやる方法 はあとからわかることになる 予測可能性低 革新的なことが求められる領域で正し い答えもわからないので、まず行動し てから理解していくしかない領域。既存 の知識が役に立たないこともある SOR(モード1) 正解が1つではないものの、比較的予 測しやすい領域。状況を専門家が分析 して理解し、取り得る手を検討して進め ていく。うまくやる方法は複数あるため それをグッドプラクティスとして活用し ていく 予測可能性高 正解が存在し変化の少ない領域。状況 を理解・分類し、ベストプラクティスに 基づいて進めていく 10
11. 問題の分類（クネビンフレームワーク） SOE(モード2) 問題を把握するために試行錯誤（探 索）を行い、それによって状況を把握・ 理解する領域。そのあとに次の対応を 考えていく。この場合、うまくやる方法 はあとからわかることになる 新規事業の創出は 通常こちら側の領域 に属する。 (VUCAな環境の影響) 革新的なことが求められる領域で正し い答えもわからないので、まず行動し てから理解していくしかない領域。既存 の知識が役に立たないこともある SOR(モード1) 正解が1つではないものの、比較的予 測しやすい領域。状況を専門家が分析 して理解し、取り得る手を検討して進め ていく。うまくやる方法は複数あるため それをグッドプラクティスとして活用し ていく 正解が存在し変化の少ない領域。状況 を理解・分類し、ベストプラクティスに 基づいて進めていく 11
12. 従来型の開発手法(ウォーターフォール)の例 要求を全部あつめる 見積もる まとめて作る まとめて確認する 12
13. 従来型の開発手法(ウォーターフォール)の例 複雑で変化の激しい領域でこのやり方をするとどうなるか？ 要求を全部あつめる 見積もる まとめて作る まとめて確認する 13
15. そもそも顧客の欲しいものが分からない 15
16. 結果的にムダなものを大量に作ることになる いつも使う 7% よく使う 16% たまに使う 13% ✤ 米国スタンディッシュグループの調査 ✤ まったく使わない 45% ほとんど使わない 19% 2002年実施 ✤ 64%の機能はほとんど、もしくはまったく 使われない ✤ 一方でiPhone発売時にはテキストのコ ピーペースト機能すらなかった 16
17. 7つのムダを排除する(開発手法に関係なく) ✤ 作りすぎのムダ => 使わない機能 ✤ 手待ちのムダ => 仕様未決で開発待ち ✤ 運搬のムダ => 他部署への引き継ぎ ✤ 加工のムダ => ドキュメントの体裁 ✤ 在庫のムダ => 同時にたくさん着手 ✤ 動作のムダ => 不要な作業、遅い作業 ✤ 不良を作るムダ => バグ修正 17
18. つまり ✤ ✤ 複雑で変化の激しい環境においては ✤ 最初に要求を全部集めても、それがあっている保証がない ✤ 時間をかけたからといって、環境の変化を予測できるわけでもなく精度も上がらない 一方で組織の予算プロセスなどの制約によって ✤ ✤ 一度機会を逃すと機能を追加するのが当面先になるので、とりあえず必要そうなものをたくさ ん入れようとする力が働く ただしそうやって「必要かもしれない」と思って入れた機能は使われない ✤ これは価値を産んでいない(ムダ) ✤ 規模が大きくなると加速度的に保守の労力が上がり、速度が遅くなっていく 18
19. 複雑で変化の激しい環境での見積り精度？ 不確実性コーン 過去に経験のない新しいものを作るような場合、見積り精度は低い 19
20. 見積もる人と作る人が違うという問題 ✤ 企業は標準的な見積り基準や手法を用意して、見積り精度を上げようとする ✤ 各チームの生産性が等しいことをベースにしているが、実際はそんなことは決してない ✤ 機能しているチームとそうでないチームでは何倍も生産性が違う(チームを壊してはいけない) 20
21. 分業(とアウトソース)による弊害 設計チーム 開発チーム テストチーム 運用チーム ✤ フェーズごとに異なる役割の人たちで作っていく。責任感の欠如を誘発しやすい ✤ 何かを伝えるためには詳細な文書が必要になる。だがそれでもコンテキストは欠落する ✤ 途中で変更を加えようとすると手間がかかるため、変更を抑止するインセンティブが働く 21
22. 最後にまとめて確認をするとどうなるか ✤ 頼んだものと違う、思ったものと違う、必要なのはこれじゃない ✤ 使おうとしても問題が多くて動かない ✤ そもそも欲しかった時期は過ぎてしまった、組織のビジネス計画 のスケジュールには間に合わない ✤ …… ✤ 長い時間と費用をかけて作っても、それが価値を生んでいない ✤ ビジネスチャンスをどんどん逃す 22
23. つまり複雑で変化が激しい領域で従来型を使うと？ ✤ 以下のような問題が起こる ✤ バッチサイズが大きすぎて、有効性が分からないムダなものをたくさん作ってしまう ✤ 計画を守ることが重視されて、変化のインセンティブがない。体制上も変化しにくい ✤ 作ったものにフィードバックできるタイミングが遅く、回数も少ない ✤ ✤ そもそもフィードバックしても取り入れられないこともある ✤ リスクは後半ほど顕在化するが、その時点で多額のお金を消費してしまっている ✤ 作っているものの有効性が検証できるまでにかかる金額と時間が大きすぎる 結果として、市場での競争優位性は得られない 23
24. 実際のところ新規ビジネスを成功させるのは難しい… ✤ 失敗の確率（スタートアップの場合） ✤ 投資がすべて水の泡になる => 30-40% ✤ 期待したROIを達成できなかった => 70-80% ✤ 宣言どおりの結果がでなかった => 90-95% 90%!? failure defined as return on investment Why Companies Fail--and How Their Founders Can Bounce Back (http://hbswk.hbs.edu/item/6591.html) 24
25. スタートアップ失敗の理由 ニーズがない 資金が尽きた 適切じゃないチーム 競合に負けた 価格・コスト 不親切な製品 ビジネスモデル欠如 稚拙なマーケティング 顧客無視 時期を逸した フォーカスの欠如 チームと投資家の不仲 ピボットが裏目 情熱の欠如 地理的拡大の失敗 投資家の関心が得られない 法律面での課題 ネットワークの未活用 燃え尽き ピボット失敗 23% 42% 29% 19% 18% 17% 17% 14% 14% 13% 最大の問題はニーズのないものを作ること 13% 13% 10% 9% 9% 8% 8% 8% https://www.cbinsights.com/research/startup-failure-reasons-top/ 8% 7% 0% 12.5% 25% 37.5% 50% 25
26. Amazonが撤退した(主な)事業 ✤ 1999→2000 アマゾン・オークションズ ✤ 2011→2015 アマゾン・ローカル ✤ 1999→2007 Zショップス ✤ 2011→2015 テストドライブ(アプリの購入前試用) ✤ 2004→2008 検索エンジンA9 ✤ 2012→2015 ミュージック・インポーター ✤ 2006→2013 アスクビル（Q&Aサイト） ✤ 2014→2015 ファイアフォン ✤ 2006→2015 アンボックス(TVや映画の購入・レンタル) ✤ 2014→2015 アマゾン・エレメンツ ✤ 2007→2012 エンドレス・ドットコム(靴とハンドバックのサイト) ✤ 2014→2015 アマゾン・ローカルレジスター(モバイル決済) ✤ 2007→2014 アマゾン・ウェブペイ(P2P送金) ✤ 2014→2015 アマゾン・ウォレット ✤ 2009→2012 ペイフレーズ(合言葉による決済) ✤ 2015→2015 アマゾン・デスティネーションズ(宿泊予約) ✤ 2010→2016 マイハビット(会員制タイムセール) ベイン・アンド・カンパニーによる分析 26
27. 失敗を受け入れる ✤ 「実験はその性質からしても失敗しやすいものですが、それでもや るべきだと思います。何十回も失敗するかもしれませんが、一つ大 きな成功をすれば十分取り返せるのですから」 ✤ 「継続して実験を行わない会社や、失敗を許容しない会社は、最終 的には絶望的な状況に追い込まれます。(略)一方、常に賭け続けて むしろ賭け金を引き上げていくような会社は、実は社運そのものを 賭けるようなことはしないので、勝ち残ります」 ✤ 「失敗は、当社が他社と一線を画している分野だと思います。当社 は、おそらく世界一失敗に適した場所です。(略)失敗と革新は対の関 係にあり、切り離すことはできません」 27
28. 新規ビジネスビッグバン一発勝負で良いか？ 収益 リリース 期間は長い 回収できるか分からない 時間 0 累積損失額(投資額) ？ ？ 最初に使うお金が大きい ？ 28
29. 新規ビジネスビッグバン一発勝負で良いか？ 収益 リリース 期間は長い 0 回収できるか分からない => ビジネスの作り方そのものを変えていく必要時間 累積損失額(投資額) ？ ？ 最初に使うお金が大きい ？ 29
30. 新規ビジネスビッグバン一発勝負で良いか？ 収益 リリース 期間は長い 0 回収できるか分からない => クラウドとアジャイルの適切な活用 累積損失額(投資額) 時間 ？ ？ 最初に使うお金が大きい ？ 30
32. 2001年に、ケント・ベック、マーティン・ファウラーら、 17人によって採択された Agileソフトウェア開発の原則を指す
33. アジャイルソフトウェア開発宣言と12の原則 プロセスやツールより人と人同士の相互作用を重視する 包括的なドキュメントより動作するソフトウェアを重視する 契約上の交渉よりも顧客との協調を重視する 計画に従うことよりも変化に対応することを重視する 早期からの継続的なデリバリー 動作するソフトウェアが指標 変化を歓迎する 持続可能なペース 期間に区切って頻繁にデリバリー 技術的卓越 毎日のコラボレーション シンプルに保つ 信頼とモチベート 自己組織化したチーム フェイス・トゥー・フェイス 継続的なプロセス改善 33
34. アジャイルソフトウェア開発宣言と12の原則 プロセスやツールより人と人同士の相互作用を重視する 包括的なドキュメントより動作するソフトウェアを重視する 契約上の交渉よりも顧客との協調を重視する 計画に従うことよりも変化に対応することを重視する この原則に準拠した開発方法を総称して「アジャイル」と呼ぶ 早期からの継続的なデリバリー 動作するソフトウェアが指標 変化を歓迎する 持続可能なペース 期間に区切って頻繁にデリバリー 技術的卓越 毎日のコラボレーション シンプルに保つ 信頼とモチベート 自己組織化したチーム フェイス・トゥー・フェイス 継続的なプロセス改善 34
35. さまざまなアジャイル開発手法 日本の製造業に源流を持つア ジャイル開発手法の1つ。 野中郁次郎氏ほかの論文を参 考にジェフ・サザーランド氏、ケ ン・シュエイバー氏が開発 VersionOne 13th Annual State of Agile Report 35
38. メンローイノベーション社での アジャイル開発の様子
40. アジャイル開発に共通するBMLのサイクル 1〜4週間 1〜4週間 1〜4週間 1〜4週間 ✤ 大事な要求から順番に実現し続ける ✤ 作る(Build)、測定する(Measure)、学習する(Learn)の繰り返し ✤ 何が今やるべき大事なことなのかビジネス側は優先順位判断をし続ける ✤ 要求の中身も優先順位もすべて変化する可能性があり、それに対応する 1〜4週間 40
41. アジャイル開発に共通するBMLのサイクル つまり1度作ったら終わりではなく、ずっと作り続ける 1〜4週間 1〜4週間 1〜4週間 1〜4週間 ✤ 大事な要求から順番に実現し続ける ✤ 作る(Build)、測定する(Measure)、学習する(Learn)の繰り返し ✤ 何が今やるべき大事なことなのかビジネス側は優先順位判断をし続ける ✤ 要求の中身も優先順位もすべて変化する可能性があり、それに対応する 1〜4週間 41
42. クロスファンクショナルで持続するチーム ✤ 運搬のムダ、手待ちのムダを避けるために、チームですべてのことを行う。チームは長く維持する ✤ これによって待ち時間が減り、素早い対応が可能になる。チームの能力は継続的に向上する ✤ すなわち複雑で変化が激しい領域で戦うには、内製化が必須といえる ✤ 持続するチームであるがゆえに能力の底上げに定常的に時間を使える（道場、ペア作業、研修など） 42
43. 小さなチームでオーバーヘッドを減らす ✤ 開発チームは1チームあたり3人〜9人 ✤ 人数が増えるとコミュニケーションの オーバーヘッドが増える ✤ Amazonでもこれを超えるとチームを分 割している ✤ 規模拡大が必要な場合、チーム内の人数を増 やすのではなく、チームの数を増やす ✤ コミュニケーションの円滑さとスピードこそが 成果達成の短期化につながる 43
44. 職能別組織からサービス別組織へ 同じ事業分 野のチーム の集合 Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds Henrik Kniberg & Anders Ivarsson Oct 2012 同一職能の 集まり 同じ関心を もつ人のコ ミュニティ スクラム チーム 44
45. アジャイルではマネージャーの役割が変化する 45
46. ボトルネックや外部依存があると成果達成が遅くなる LT 2日 LT 6日 LT 2日 分析 開発 テスト Dev LT 20日 LT 20日 審査・承認 QA / デプロイ $$ Ops ✤ このプロセスのボトルネックは開発ではなく、リリースに向けたプロセスにある ✤ プロセスを見える化(バリューストリームマップ)した上で、変化に強いプロセスと体制に改善する 46
47. Werner Vogels, CTO, amazon.com You build it, You run it 47
48. 品質に対する考え方を変える必要 ✤ 「〜性」要求 = 非機能要件 ✤ ✤ 「〜ができる」という要求 = 機能要求 ✤ ✤ ✤ 安全性、信頼性、効率性、有効性、拡張性、機密性、安定性、保守性など 非機能要求と機能要求を満たしている度合い = 品質 どこをベースラインにするのかはトレードオフ ✤ 対象のプロダクトによって明確に違う。全社統一の基準にはなりえない ✤ 変化が激しい環境においては、Time to Marketの速度が極めて重要 ビジネスサイドにとっての品質 = バグの有無よりもそのプロダクトを利用してビジネス上の成果が あげられるかどうか 48
49. 問題発見の時期をシフトレフトし継続的に取り組む つまりテスト自動化を始めとした技術基盤が欠かせない Capers Jones, Applied Software Measurement: Global Analysis of Productivity and Quality 49
50. 従来型とアジャイル型の価値観の違い 予測型プロセス 経験型プロセス プロジェクトの成功率 高くしたい 高くなくてもいい プロダクトの収益 スコープ外 高くしたい ポートフォリオの成功率 スコープ外 高くしたい リードタイム 長くても良い 短くする 既存プラクティスの適用 適用する 適用性を検証する 新規プラクティスの適用 避ける 適用性を検証する フィードバックサイクル ない場合もある 短くしたい 50
51. アジャイル導入時に遭遇した課題 63% 企業文化がアジャイルの価値観とあわない 47% 45% 43% 41% アジャイル開発手法の経験が不足 マネジメントからのサポートが不足 組織が変化に抵抗する ビジネスサイド/顧客/プロダクトオーナー不在 34% 34% 31% トレーニング不足 従来型開発手法がすでに普及 一貫性のないアジャイルプラクティスとプロセス 20% 19% 15% ツールやデータなどの分散 コラボレーション不足 コンプライアンスとガバナンス 0 20 VersionOne 11th Annual State of Agile Report 40 60 80 51
52. まとめ ✤ ビジネスのライフサイクルが短期化し、既存ビジネスが縮小していく ✤ その分新しいビジネスを作り出して、ポートフォリオの構成を変えていく必要がある ✤ 複雑で変化の激しい環境下においては、事前に正確な予測はできない ✤ 多くの取り組みは失敗するが、失敗を受け入れる必要がある ✤ 失敗するなら小さく・素早く ✤ それに適しているのがアジャイル開発 ✤ クロスファンクショナルなチームのもとで、短い期間に区切って評価しながら繰り返していく ✤ 品質保証の考え方も従来とは変わる 53
