逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践

1.

2.

3.

3刷決定!! https://www.amazon.co.jp/dp/4798153346/

https://www.amazon.co.jp/dp/4798153346/

4.

5.

6.

なぜ、私はいまここにいるのか？

7.

2003年〜

8.

(⽇本におけるアジャイルとは) 挑戦と、敗北の歴史 XPへの憧れと、その遠さ「スゴく良いのだけど、この⽬の前の在庫管理システム開発プロジェクトではどうしたらいいの?!」問題 2006年頃の顧客との協調と不調、灰⾊の時代⾒える化しよう！アジャイル=PFだった時代〜 AEPという光明「アジャイルサムライ」という突破⼝、越えられない壁⼤いなる前進、スクラムの盛り上がり、POの向こう側問題マジョリティの時代へ突⼊〜次の世代スクラムの春(と修羅)、コミュニティは減退(世代交代がなかった?) 新しい時代をつくるのは⽼⼈ではない

9.

2017年頃〜現在

10.

⼆極化する現場前進する現場は、アジャイルという⾔葉さえ不要スクラムの実践から、⾃分たちの開発への進展。組織として、アジャイルがまとう価値観を広げていく取り組み。進化、発達の最前線には、若く少数の組織。歴史深い組織でも、アジャイルに踏み出すデジタルトランスフォーメーション、新規事業という旗印。 SoR中⼼であった事業組織が、”アジャイル開発” に取り組む。「既存のベンダー頼み」から、⾃⼒で、外部のちからを借りて。 “アジャイル”とは、変⾰そのものを表す⾔葉。ただし… 逆境からのアジャイルではある。

11.

今起きていることと、⼀筋の望みと 15年分の積み重ねを、数ヶ⽉で再⽣できるか？・チーム、関係者としての振る舞い⽅についての理解、当然ゼロから。・2012年頃の「期待マネジメント」のやりようが、未だ現役。・「”アジャイル開発” でやれば、なんだかスゴイものができる」 (↑この期待調整の15年だったと⾔っても過⾔ではない) ・さらに ”アジャイル” への万能的な期待。「アジャイルでやれば新規事業も上⼿く⾏く！」・そもそも「ソフトウェア開発」⾃体の理解が不⾜している。 (役割定義したら明⽇からPOとして振る舞えるかって？) ・アジャイル開発、ソフトウェア開発云々の前に、お互いを尊重し、信頼しあえる関係性へ、⼀歩⼀歩…。その遠さよ。

12.

今起きていることと、⼀筋の望みと・「カイゼン・ジャーニー」で世の中を知る。寄せられる反応から、それぞれの状況を知る。

13.

14.

今起きていることと、⼀筋の望みと・「カイゼン・ジャーニー」で世の中を知る。寄せられる反応から、それぞれの状況を知る。・⼆極化は進んでいるが、⼀⽅で「越境しよう」という意思のある⼈も少なくない。 … なぜ、私はいまここにいるのか？

15.

⾃分の状況をより良くしたいと果敢に越境せんとする⼈をエナジャイズする(⼒を添える)

16.

17.

基本は、リーン製品開発リーン製品開発では、「セットベース」という考え⽅が基本。正解を誰も持っていない、不確実な環境においては選択肢を闇雲に早期に絞りきると⾃分たちで可能性を捨ててしまっていることに気づけない。構想段階検証段階ソリューション設計段階アイデアの幅デザイン思考等で広げるソリューションの幅⽅向性を定める仮説検証結果を踏まえて絞る ※選択肢は、ユーザーや顧客にサービス、事業を届けるところで再び広がっていく。このサイクルを繰り返す

18.

ベンチャーの場合 = セットが広すぎる採⽤の失敗 ☓ ◯ ◯ ◯ 選択肢採⽤の基準がゆるく、絞りきれていない。何でもありになりがちで、後々でも思いつきで⽅向性が変わる ☓ ☓ 基準が無い、ゆるいため、ダメなアイデアでも先に進めてしまう。

19.

⼤企業の場合 = ポイントベース却下の失敗 ◯ ◯ ◯ ☓ 選択肢採⽤の基準が厳しすぎる。不確実なことでも予めの検討を詳細に求められれる。途上で、組織的判断でアイデアが死ぬ。 ☓ ◯ ☓ ☓ 基準が厳しすぎるため、検証しないと判断できないことも却下される。

20.

21.

仮説検証の「精度」と「頻度」のマネジメント検証の頻度精度よりも頻度を重視バランスのとれた頻度と精度頻度よりも精度を重視検証の精度 (1)精度よりも頻度を重視 (2)頻度よりも精度を重視 (3)バランスのとれた頻度、精度数多くの検証を得て、集中すべき領域・テーマが判断できている段階。⼀定の検証を得て、領域は絞れたが実現⼿段の⽅向性が決めきれない。検証⼿段の精度(作り込み)よりも試⾏する回数(幅)を選びたい。現実に実⾏した場合とほぼ同レベルの検証結果を得たいため、検証⼿段を作り込む(MVP)。より確度の⾼い検証結果を得るために運⽤プロダクトほどではないが、ユーザーがサービスの体験が味わえる程度のプロトタイプを作り込む。集中すべき領域・テーマがまだ無い段階。

22.

検証すべき対象とは何か？仮説と⼀⼝に表現しても、その中⾝にはレベルがある。ソリューションの「本質」「実体」「形態」、それぞれが検証の対象。か課題の仮説かたかたち機能の仮説 UIの仮説本質どんな状況の⼈たちの、どんな問題を解決するのか = 本質的な価値実体本質的な価値が利⽤者にもたらされるために必要な機能とは何か=機能性形態利⽤者が機能を使えるために最適なUIとは何か = ユーザビリティ品質本質だけ、実体だけ、形態だけ、それぞれを個別に最適化しても価値は⾼まらない。本質と実体と形態が必然性から繋がることで、価値になる。

23.

“越境する事業”のイメージ⼤企業が既存事業の⽐較にならない規模の新規事業をやる意義とは？サービスの SoE中⼼グロースが使命 1サービス =事業 =組織そのもの新たな顧客接点づくりへの越境少数、若い組織歴史深い組織 (ベンチャー) (⼤企業) 事業拡⼤のため注⼒してなかったSoR への踏み込み SoR中⼼ … ⻑い歴史とともに充実するSoR

24.

リーンやアジャイルのマインドや思考、⽅法を組織に⽣やすために、SoEプロジェクトを使う (コアとなるチームをつくる→ひととおり経験する) サービスの SoE中⼼グロースが使命 1サービス =事業 =組織そのもの少数、若い組織 Venture ⼤企業の新規事業 (逆境からのアジャイル) 新たな顧客接点づくりへの越境 Startup 歴史深い組織 (ベンチャー) (⼤企業) 事業拡⼤のため注⼒してなかったSoR への踏み込み SoR中⼼ … ⻑い歴史とともに充実するSoR

25.

“越境の逆流” SoEでの実践知を既存事業変⾰への橋頭堡にするサービスの SoE中⼼グロースが使命 1サービス =事業 =組織そのもの少数、若い組織 Venture ⼤企業の新規事業 (逆境からのアジャイル) 新たな顧客接点づくりへの越境 Startup 歴史深い組織 (ベンチャー) (⼤企業) 事業拡⼤のため注⼒してなかったSoR への踏み込み SoR中⼼ … ⻑い歴史とともに充実するSoR

26.

27.

或るプロジェクトの話

28.

われわれはなぜここにいるのか新しい事業展開を牽引するサービスの開発・SoR中⼼から、SoEへの越境・何をつくるべきか？ = 仮説検証・どのようにしてかたちにしていくか？ = アジャイル開発歴史深い組織が、アジャイルに踏み出すただ、リーンに探索し、アジャイルにサービスをつくるという話ではなく、牽引する事業開発チームの⽴ち上げが求められる。事業開発チーム = 従来のやり⽅、あり⽅にとらわれない変⾰の中核事業開発とチーム開発のダブルミッション

29.

最初の⼀歩(SoE⽴ち上げ)を潰してしまったら組織がアップデートする芽を数年単位で摘むことになる (という気概を背負って臨む)

30.

仮説検証によるコンセプトの叩き上げ・どのような状況に置かれている⼈たちのどんな問題を、どうやって解決するのか？・それは本当に必要なことなのか？を検証する

31.

モデル仮説キャンバスによる仮説⽴案インタビューや観察を通じた状況の把握(エスノグラフィー) 現実 ※終結段階で仮説キャンバス及び必要な粗いプロダクトバックログが揃う現実モデルプロトタイプ検証プロトタイプ制作⾏動フローベースで仮説のupdate と調整必要な仕組みの設計

32.

現場を観る、⼈を観るインタビューは聞くのではなく観る。現場に在庫を置く場所はあるか？冷蔵庫の⼤きさはどのくらい？開店前の仕込みのスピード感。電波の状況は？この質問にこの⼈はどんな顔をして答えた？本当に⾃分ごとか？﹅﹅﹅﹅﹅﹅この⼈がこのアプリを使っているところが想像できるか？⾔語化されていること以上に、間合いから学びを得る

33.

現場には、全員で⾏け。⼈から聞かされた基準では、それ以上のモノはできないどれだけ⾔語化して、どれだけ会話したところで、⼈から聞かされるだけでは、それ以上のモノをつくることはできない。 (⾔語化されているものしかつくれない) ⾃分で聴いて、⾒て、感じたことを⾃分の体に覚えさせる。⾝体の記憶に、⾃分の想像と解釈が交わることで、仮説が⽣まれる。⾃分だけの仮説の、⾃分だけの解釈。だから、検証にはチームで⾏く。

34.

https://lp.canvas.guildworks.jp/

https://lp.canvas.guildworks.jp/

35.

仮説から形あるものへ変換する⼊り⼝をつくる・開発可能にするべく、ソフトウェアの要求レベルを詳しくする = スプリントで扱えるレベルのプロダクトバックログに整える (必要にして、最⼩限の要求詳細化作戦) ・プロダクトとともにチームもレディに、チームビルディング。

36.

必要にして最⼩限の要求詳細化作戦「絵に書いた餅はスプリントで⾷べられない」過去のポストモーテムを活かす常にチームビルディング

37.

必要にして最⼩限の要求詳細化作戦壱「絵に書いた餅はスプリントで⾷べられない」・要求仕様の粒度は結成するチームと関係者の練度でもって決める (ただ詳細であれば良いわけではない) → たいてい、機能⼀覧→ユーザーストーリー→機能分割・詳細で中⾝が嵩⾼いほど、⼈は受け取れなくなる、読み取れなくなる、読取り誤る・もっとも理解が深まるのは⽣成過程をともにすること → バックログリファインメントを⼀緒にやる、規模⾒積もりを⼀緒にやる、ともにつくる

38.

必要にして最⼩限の要求詳細化作戦弐過去のポストモーテムを活かす・キックオフの前に、メンバーそれぞれの過去のプロジェクトでの学びを棚卸しする。・インセプションデッキ「やらないことリスト」で、あり⽅・やり⽅のレベルでやりたくないことをあげる。 (過去、苦い思いになったのはどんなことでしたか) ・過去のプロジェクトをふりかえり、地雷にだった事案を「眠れなくなりそうな問題」として、共通の理解にしておく (とにかくwebpackerでハマった…とか)

39.

必要にして最⼩限の要求詳細化作戦参常にチームビルディング・遠い距離は縮めるしかない。縮めるには時間をともにするしかない。・単純接触効果 (接触回数が警戒⼼を解く) → 関係者は、仮説検証の段階から頻繁に濃密な時間をともにする (仮説検証を通じてお互いの間合いを知る) ・偶発性にゆだねるだけでは、単純接触効果は上がらない → 「ソフトウェア開発は演出」(意図的に仕組む)

40.

ほぼゼロから開発可能なPBL取り出しまで最短で2ヶ⽉⻑くても3ヶ⽉

41.

つくり、形にしながら共通理解を深める時間・開発は反復的に。スクラムベース(1週間スプリント)。・今回のPJならではの課題「全員リモートワーク」 ※同席と⽐べることに意味はない。リモートでの最適化⽬指す。・開発チームもフルリモートワーク(は、ギルドでは珍しくない)。プロダクトオーナー、関係者もフルリモートワーク。かつ、顧客の拠点が、四国と関東に分かれている。

42.

43.

間違ってもすぐに正せる = レジリエンス性(復元⼒)を⾼める取り組み

44.

間違っても即正せる開発間違うなら、早めに間違っておく最初から「何でもって完成なのか」をあわせるデザイナーとの「ともにつくる」プロダクトオーナー、関係者との「ともにつくる」

45.

間違っても即正せる開発間違うなら、早めに間違っておく・1週間スプリント = 認識がズレても、間違っている期間は最⻑1週間・最初から統合し続ける = 早く間違えられる = 早く正せる ①「デザインワークをマージすると事故が起こる」問題 → デザインワークを貯めない、2スプリント⽬からマージする ②「本番相当データを投⼊したときに想定外が起きる」問題 → 1スプリント⽬から実データを投⼊する = 1スプリント⽬からデータを揃えないといけない … データ起因の想定外仕様を早期に検出できる (「そう⾔えば、こういう例外もありまして…」) ※SoRと関連が深い開発ほど実データを最初投⼊。(⻤⾨になりやすいから) ※逆境からのアジャイルの場合はSoE開発でも、SoRが絡みやすい。

46.

間違っても即正せる開発最初から「何でもって完成なのか」をあわせる・「認識がズレている→戻す」から「共通理解を最初に置く」へ → 受け⼊れ条件ありきで、スプリント開発を駆動する・「プロダクトオーナーが受け⼊れ条件を書けない」問題主にエンジニアリング知識、経験の不⾜により⼗分に定義できない → 仮説検証を実施しているので、どうあると良いのかの基準を開発チームの⽅が保有している (POより詳しくさえある) = 受け⼊れ条件がスラスラ書ける・それでも間違うときは間違う → スプリント毎の受け⼊れテストで、認識のズレを即検知→即修整

47.

間違っても即正せる開発デザイナーとの「ともにつくる」・間違わない順番でつくる ① デザイナーのアウトプットを開発チームが受け⽌める → アウトプットが機能仕様と合致してない (漏れる、抜ける)

48.

コードを最終的に引き受けるプログラマーが”詳細”の管理者 (もっとも詳細な意思決定はプログラマーに委ねられる)

49.

間違っても即正せる開発デザイナーとの「ともにつくる」・間違わない順番でつくる ① デザイナーのアウトプットを開発チームが受け⽌める → アウトプットが機能仕様と合致してない (漏れる、抜ける) ② 開発チームのアウトプットをデザイナーが受け⽌める → 機能仕様の実現は、プログラマーが担保する = レイアウトのアウトラインは、開発チームとデザイナーが話し合ってすりあわせておく (情報設計先⾏) → プログラマーが実装した機能にデザイナーがUIを作り込む = デザイナーが⼿元でソフトウェアを動かせる必要がある (コンテナベースの開発は必須)

50.

機能開発とデザインの”千⿃⾜”プロセス Sprint0 Sprint1 Sprint2 Sprint3 … アプリ(サイト)構造開発チーム機能の実装機能の実装機能の実装各ページのイメージ (ワイヤー/Prott) デザイナー UIの作り込み ※同じものを⾒てつくる ※Sprint開始前にAtomic Desinに則り共通コンポーネントの定義と実装を差し込みたい UIの作り込み ※プログラマー→デザイナー→プログラマーで再度受け⽌めて確認・マージ (プロダクトが⾏きつ戻りつ”千⿃⾜”の軌跡)

51.

間違っても即正せる開発プロダクトオーナー、関係者との「ともにつくる」・⽂字どおり「ともにつくる」 ① 基本は週1のイベント (レビュー/計画 + レトロスペクティブ) ② プロダクトバックログの共同所有 → 「進み」は、傭兵チーム(ギルドワークスチーム)が稼ぐ → 簡単なPBLは、内製チームが1つずつ全員で倒していく ③ チャンスがあればとにかく「ともにつくる」(モブプロ) →東京で同席で、傭兵チーム + 内製チーム(関東/四国) →リモートで、傭兵チーム + 内製チーム(関東/四国) →今治で同席で、傭兵チーム + 内製チーム(関東/四国) →リモートで、内製チーム(関東) + 内製チーム(四国)

52.

53.

ユーザー体験が完結するMVPの開発に (デザインがあたっていて、実データで動いていて、受け⼊れテスト済) 2ヶ⽉あるレベルの規模感に対する期間としてギルドワークス史上最速

54.

まだ、やり残していることがあるのでは？カイゼン・ジャーニー/⻄⽅

55.

われわれはなぜここにいるのか新しい事業展開を牽引するサービスの開発・SoR中⼼から、SoEへの越境・何をつくるべきか？ = 仮説検証・どのようにしてかたちにしていくか？ = アジャイル開発歴史深い組織が、アジャイルに踏み出すただ、リーンに探索し、アジャイルにサービスをつくるという話ではなく、牽引する事業開発チームの⽴ち上げが求められる。事業開発チーム = 従来のやり⽅、あり⽅にとらわれない変⾰の中核もう⼀つのミッション = 変⾰への越境

56.

リアル・カイゼン・ジャーニー (四国編)

57.

変⾰への越境リアル・カイゼン・ジャーニー (A⾯) ・アジャイルなマインドセットとやり⽅を組織として取り⼊れるチャンス・⼈は現実の変化 = 成果を⽬の当たりすると⼼が動く・⼩さくとも⾃分たち⾃⾝の成果をあげるように！ジャーニー⾃分たちでアジャイルな取り組みでの成果出せた! → 組織からの期待に応えられた → 周囲の巻き込みを広げる成果の質 → 次の取り組みを⼀歩進める ※まだ、最初の成果を出す段階関係の質思考の質⾏動の質

58.

まず、内製チームが「⾃分たちは何をする⼈たちなのか？」に答えれるように。

59.

変⾰への越境むきなおり合宿・情報システム部⾨としてのふりかえり → 現状の⾃分たちの良さ、抱えている問題を吐き出す・ゴールデンサークルは描く☓2回 → 最初にあがるWhyは、たいてい⽇常の延⻑になる → 「本当に私達が実現したいことと合ってるのか？」 = 2回⽬でありたい姿に向き合う・どうやってやるかを全員で背負う → ⼀⼈で背負っても、やればやるほど疲弊するだけチームで背負う = 背負うものを⾒えるように = カンバン

60.

めでたし、めでたし …とはいかない。カイゼン・ジャーニー/⽯神

61.

⼤企業の新規事業は 2回戦う

62.

⼤企業の新規事業は2回戦う ① 最初の関⾨は、プロダクトの⽅向性を⾒定めること・仮説検証の世界に、正解があるわけではない。・正しくないものをつくらない = 何もつくらない!? ・事業をつくりだすミッションのプレッシャーは変わらない

63.

⼤企業の新規事業は2回戦う ② 最⼤の問題は、コンセプトをまとめた後にくる・⼤企業ならでは、社内関係者の調整という関⾨ (リアル・カイゼン・ジャーニー(B⾯)) ・チームで乗り越えるしかない。

64.

不確実性の⾼い状況を果てしなく先読みしてもムダ。何が来たとしても、互いの持ち味を活かして、状況に適応できるレジリエンスの⾼いチームを⽬指す

65.

66.