Embed Size (px)
Citation preview
Toshihiro Ichitani All Rights Reserved.
逆境から新規事業をスタートアップする 「仮説検証型アジャイル開発」の実践
Ichitani Toshihiro
市⾕聡啓
逆境から、不確実性に向き合いながら 組織としての越境へ向かう道
Toshihiro Ichitani All Rights Reserved.
Ichitani Toshihiro
市⾕聡啓ソフトウェア開発17年SIer→サービス→受託→起業仮説検証とアジャイル開発
ギルドワークス株式会社 代表 株式会社 エナジャイル 代表 ⼀般社団法⼈ 越境アジャイルアライアンス代表理事 DevLOVE コミュニティ ファウンダ
0 → 1 @papanda
Toshihiro Ichitani All Rights Reserved.
スタートアップや事業会社での 新規事業、新規サービスの⽴ち上げ 事業会社での現場改善、仮説検証コーチ
ギルドワークス
「正しいものを正しくつくる」
Why
What
Toshihiro Ichitani All Rights Reserved.Golden Circle
What
How
Why
Start with Why.
なぜ、私はいまここにいるのか？
2003年〜
挑戦と、敗北の歴史XPへの憧れと、その遠さ
2006年頃の顧客との協調と不調、灰⾊の時代
「スゴく良いのだけど、この⽬の前の在庫管理システム開発 プロジェクトではどうしたらいいの?!」問題
⾒える化しよう！アジャイル=PFだった時代 〜 AEPという光明
「アジャイルサムライ」という突破⼝、越えられない壁
⼤いなる前進、スクラムの盛り上がり、POの向こう側問題
マジョリティの時代へ突⼊〜次の世代
(⽇本におけるアジャイルとは)
スクラムの春(と修羅)、コミュニティは減退(世代交代がなかった?) 新しい時代をつくるのは⽼⼈ではない
2017年頃〜現在
⼆極化する現場前進する現場は、アジャイルという⾔葉さえ不要
スクラムの実践から、⾃分たちの開発への進展。 組織として、アジャイルがまとう価値観を広げていく取り組み。 進化、発達の最前線には、若く少数の組織。
歴史深い組織でも、アジャイルに踏み出すデジタルトランスフォーメーション、新規事業という旗印。 SoR中⼼であった事業組織が、”アジャイル開発” に取り組む。 「既存のベンダー頼み」から、⾃⼒で、外部のちからを借りて。 “アジャイル”とは、変⾰そのものを表す⾔葉。ただし…
逆境からのアジャイル ではある。
今起きていることと、⼀筋の望みと
15年分の積み重ねを、数ヶ⽉で再⽣できるか？・チーム、関係者としての振る舞い⽅についての理解、当然ゼロから。 ・2012年頃の「期待マネジメント」のやりようが、未だ現役。 ・「”アジャイル開発” でやれば、なんだかスゴイものができる」 (↑この期待調整の15年だったと⾔っても過⾔ではない) ・さらに ”アジャイル” への万能的な期待。 「アジャイルでやれば新規事業も上⼿く⾏く！」 ・そもそも「ソフトウェア開発」⾃体の理解が不⾜している。 (役割定義したら明⽇からPOとして振る舞えるかって？) ・アジャイル開発、ソフトウェア開発云々の前に、 お互いを尊重し、信頼しあえる関係性へ、⼀歩⼀歩…。その遠さよ。
今起きていることと、⼀筋の望みと
・「カイゼン・ジャーニー」で世の中を知る。 寄せられる反応から、それぞれの状況を知る。
今起きていることと、⼀筋の望みと
・「カイゼン・ジャーニー」で世の中を知る。 寄せられる反応から、それぞれの状況を知る。
・⼆極化は進んでいるが、⼀⽅で「越境しよう」 という意思のある⼈も少なくない。
… なぜ、私はいまここにいるのか？
⾃分の状況をより良くしたいと 果敢に越境せんとする⼈を
エナジャイズする(⼒を添える)
Toshihiro Ichitani All Rights Reserved.Golden Circle
What
How
Why
How can "why” be realized?
基本は、リーン製品開発リーン製品開発では、「セットベース」という考え⽅が基本。 正解を誰も持っていない、不確実な環境においては選択肢を闇雲に早期に絞りきると ⾃分たちで可能性を捨ててしまっていることに気づけない。
構想段階
検証段階ソリューション設計段階
アイデアの幅 ソリューションの幅デザイン思考等で広げる 仮説検証結果を踏まえて絞る
⽅向性を定める
※選択肢は、ユーザーや顧客にサービス、 事業を届けるところで再び広がっていく。 このサイクルを繰り返す
ベンチャーの場合 = セットが広すぎる
採⽤の失敗
選択肢採⽤の基準がゆるく、 絞りきれていない。 何でもありになりがちで、 後々でも思いつきで⽅向性が変わる
◯
☓
☓
◯
◯
☓
基準が無い、ゆるいため、ダメなアイデア でも先に進めてしまう。
⼤企業の場合 = ポイントベース
却下の失敗選択肢採⽤の基準が厳しすぎる。 不確実なことでも予めの検討を 詳細に求められれる。 途上で、組織的判断でアイデアが死ぬ。
◯ ☓
◯◯
☓☓
☓
◯
基準が厳しすぎるため、検証しないと 判断できないことも却下される。
Toshihiro Ichitani All Rights Reserved.
求められるのは、 採⽤の失敗を抑えながら、製品開発を⾏う⼿段。
仮説の確からしさを検証しながら、漸進する開発。
仮説検証型アジャイル開発①正しくない仮説を採⽤しないよう「検証に基づく意思決定」を前提とする ②状況に応じて、仮説検証の「精度」と「頻度」を調整する
仮説検証の「精度」と「頻度」のマネジメント
精度よりも頻度を重視
頻度よりも精度を重視
バランスのとれた頻度と精度
検証の頻度
検証の精度
(1)精度よりも頻度を重視 集中すべき領域・テーマがまだ 無い段階。
検証⼿段の精度(作り込み)よりも 試⾏する回数(幅)を選びたい。
(2)頻度よりも精度を重視 数多くの検証を得て、集中すべき 領域・テーマが判断できている段階。
現実に実⾏した場合とほぼ同レベルの検証結果を得たいため、検証⼿段を作り込む(MVP)。
(3)バランスのとれた頻度、精度 ⼀定の検証を得て、領域は絞れたが 実現⼿段の⽅向性が決めきれない。
より確度の⾼い検証結果を得るために 運⽤プロダクトほどではないが、 ユーザーがサービスの体験が味わえる程度のプロトタイプを作り込む。
検証すべき対象とは何か？仮説と⼀⼝に表現しても、その中⾝にはレベルがある。 ソリューションの「本質」「実体」「形態」、それぞれが検証の対象。
か
かた
かたち
本質
実体
形態
本質だけ、実体だけ、形態だけ、それぞれを個別に最適化しても価値は⾼まらない。 本質と実体と形態が必然性から繋がることで、価値になる。
課題の仮説
機能の仮説
UIの仮説
どんな状況の⼈たちの、 どんな問題を解決するのか = 本質的な価値
本質的な価値が利⽤者に もたらされるために必要な 機能とは何か=機能性
利⽤者が機能を使えるために 最適なUIとは何か = ユーザビリティ品質
歴史深い組織 (⼤企業)
少数、若い組織 (ベンチャー)
SoE中⼼
SoR中⼼
…
1サービス =事業
=組織そのもの
事業拡⼤のため 注⼒してなかったSoR
への踏み込み⻑い歴史とともに
充実するSoR
“越境する事業”のイメージ
サービスの グロースが使命
新たな顧客接点 づくりへの越境
⼤企業が既存事業の⽐較にならない規模の新規事業をやる意義とは？
歴史深い組織 (⼤企業)
少数、若い組織 (ベンチャー)
SoE中⼼
SoR中⼼
…
1サービス =事業
=組織そのもの
サービスの グロースが使命
事業拡⼤のため 注⼒してなかったSoR
への踏み込み⻑い歴史とともに
充実するSoR
新たな顧客接点 づくりへの越境
Startup
Venture
⼤企業の 新規事業
リーンやアジャイルのマインドや思考、⽅法を 組織に⽣やすために、SoEプロジェクトを使う
(コアとなるチームをつくる→ひととおり経験する)
(逆境からのアジャイル)
歴史深い組織 (⼤企業)
少数、若い組織 (ベンチャー)
SoE中⼼
SoR中⼼
…
1サービス =事業
=組織そのもの
サービスの グロースが使命
事業拡⼤のため 注⼒してなかったSoR
への踏み込み⻑い歴史とともに
充実するSoR
新たな顧客接点 づくりへの越境
“越境の逆流”
Startup
Venture
SoEでの実践知を既存事業変⾰への橋頭堡にする
⼤企業の 新規事業
(逆境からのアジャイル)
Toshihiro Ichitani All Rights Reserved.Golden Circle
What
How
Why
仮説検証型アジャイル開発 Real Story
或るプロジェクトの話
われわれはなぜここにいるのか新しい事業展開を牽引するサービスの開発・SoR中⼼から、SoEへの越境 ・何をつくるべきか？ = 仮説検証 ・どのようにしてかたちにしていくか？ = アジャイル開発
歴史深い組織が、アジャイルに踏み出すただ、リーンに探索し、アジャイルにサービスをつくるという 話ではなく、牽引する事業開発チームの⽴ち上げが求められる。 事業開発チーム = 従来のやり⽅、あり⽅にとらわれない変⾰の中核
事業開発とチーム開発のダブルミッション
最初の⼀歩(SoE⽴ち上げ)を 潰してしまったら
組織がアップデートする芽を 数年単位で摘むことになる
(という気概を背負って臨む)
仮説検証によるコンセプトの叩き上げ・どのような状況に置かれている⼈たちのどんな問題を、どうやって 解決するのか？ ・それは本当に必要なことなのか？を検証する
仮説キャンバスによる仮説⽴案 インタビューや観察を通じた 状況の把握(エスノグラフィー)
⾏動フローベースで 必要な仕組みの設計
プロトタイプ制作 と調整
プロトタイプ検証 仮説のupdate
※終結段階で仮説キャンバス及び 必要な粗いプロダクトバックログが揃う
モデル
現実
モデル
現実
現場を観る、⼈を観るインタビューは聞くのではなく観る。 現場に在庫を置く場所はあるか？冷蔵庫の⼤きさはどのくらい？ 開店前の仕込みのスピード感。電波の状況は？ この質問にこの⼈はどんな顔をして答えた？本当に⾃分ごとか？ この⼈がこのアプリを使っているところが想像できるか？
﹅ ﹅ ﹅ ﹅ ﹅ ﹅
⾔語化されていること以上に、間合いから学びを得る
現場には、全員で⾏け。⼈から聞かされた基準では、それ以上のモノはできない
⾃分で聴いて、⾒て、感じたことを⾃分の体に覚えさせる。 ⾝体の記憶に、⾃分の想像と解釈が交わることで、仮説が⽣まれる。 ⾃分だけの仮説の、⾃分だけの解釈。だから、検証にはチームで⾏く。
どれだけ⾔語化して、どれだけ会話したところで、⼈から聞かされる だけでは、それ以上のモノをつくることはできない。 (⾔語化されているものしかつくれない)
仮説から形あるものへ変換する⼊り⼝をつくる・開発可能にするべく、ソフトウェアの要求レベルを詳しくする = スプリントで扱えるレベルのプロダクトバックログに整える (必要にして、最⼩限の要求詳細化作戦)
・プロダクトとともにチームもレディに、チームビルディング。
必要にして最⼩限の要求詳細化作戦「絵に書いた餅はスプリントで⾷べられない」
過去のポストモーテムを活かす
常にチームビルディング
必要にして最⼩限の要求詳細化作戦 壱「絵に書いた餅はスプリントで⾷べられない」・要求仕様の粒度は結成するチームと関係者の練度 でもって決める (ただ詳細であれば良いわけではない) → たいてい、機能⼀覧→ユーザーストーリー→機能分割
・詳細で中⾝が嵩⾼いほど、⼈は受け取れなくなる、 読み取れなくなる、読取り誤る
・もっとも理解が深まるのは⽣成過程をともにすること → バックログリファインメントを⼀緒にやる、 規模⾒積もりを⼀緒にやる、ともにつくる
必要にして最⼩限の要求詳細化作戦 弐
過去のポストモーテムを活かす
・キックオフの前に、メンバーそれぞれの過去のプロジェクト での学びを棚卸しする。
・インセプションデッキ「やらないことリスト」で、 あり⽅・やり⽅のレベルでやりたくないことをあげる。 (過去、苦い思いになったのはどんなことでしたか)
・過去のプロジェクトをふりかえり、地雷にだった事案を 「眠れなくなりそうな問題」として、共通の理解にしておく (とにかくwebpackerでハマった…とか)
必要にして最⼩限の要求詳細化作戦 参常にチームビルディング・遠い距離は縮めるしかない。縮めるには時間をともに するしかない。
・単純接触効果 (接触回数が警戒⼼を解く) → 関係者は、仮説検証の段階から頻繁に濃密な時間を ともにする (仮説検証を通じてお互いの間合いを知る)
・偶発性にゆだねるだけでは、単純接触効果は上がらない → 「ソフトウェア開発は演出」(意図的に仕組む)
最短で2ヶ⽉ ⻑くても3ヶ⽉
ほぼゼロから開発可能なPBL取り出しまで
つくり、形にしながら共通理解を深める時間・開発は反復的に。スクラムベース(1週間スプリント)。 ・今回のPJならではの課題「全員リモートワーク」 ※同席と⽐べることに意味はない。リモートでの最適化⽬指す。 ・開発チームもフルリモートワーク(は、ギルドでは珍しくない)。 プロダクトオーナー、関係者もフルリモートワーク。 かつ、顧客の拠点が、四国と関東に分かれている。
Toshihiro Ichitani All Rights Reserved.
「⾮同期、コミュニケーションレスで お互いの認識はズレる」が前提(「リモートだから、頻度を増やそう」はアンチパターン)
間違ってもすぐに正せる = レジリエンス性(復元⼒)を
⾼める取り組み
間違っても即正せる開発間違うなら、早めに間違っておく
デザイナーとの「ともにつくる」
プロダクトオーナー、関係者との「ともにつくる」
最初から「何でもって完成なのか」をあわせる
・1週間スプリント = 認識がズレても、間違っている期間は最⻑1週間
・最初から統合し続ける = 早く間違えられる = 早く正せる ①「デザインワークをマージすると事故が起こる」問題 → デザインワークを貯めない、2スプリント⽬からマージする
②「本番相当データを投⼊したときに想定外が起きる」問題 → 1スプリント⽬から実データを投⼊する = 1スプリント⽬からデータを揃えないといけない … データ起因の想定外仕様を早期に検出できる (「そう⾔えば、こういう例外もありまして…」) ※SoRと関連が深い開発ほど実データを最初投⼊。(⻤⾨になりやすいから)
※逆境からのアジャイルの場合はSoE開発でも、SoRが絡みやすい。
間違うなら、早めに間違っておく
間違っても即正せる開発
・「認識がズレている→戻す」から「共通理解を最初に置く」へ → 受け⼊れ条件ありきで、スプリント開発を駆動する
・「プロダクトオーナーが受け⼊れ条件を書けない」問題 主にエンジニアリング知識、経験の不⾜により⼗分に定義できない → 仮説検証を実施しているので、どうあると良いのかの基準を 開発チームの⽅が保有している (POより詳しくさえある) = 受け⼊れ条件がスラスラ書ける
・それでも間違うときは間違う → スプリント毎の受け⼊れテストで、認識のズレを即検知→即修整
最初から「何でもって完成なのか」をあわせる
間違っても即正せる開発
・間違わない順番でつくる ① デザイナーのアウトプットを開発チームが受け⽌める → アウトプットが機能仕様と合致してない (漏れる、抜ける)
デザイナーとの「ともにつくる」間違っても即正せる開発
コードを最終的に引き受ける プログラマーが”詳細”の管理者
(もっとも詳細な意思決定はプログラマーに委ねられる)
・間違わない順番でつくる ① デザイナーのアウトプットを開発チームが受け⽌める → アウトプットが機能仕様と合致してない (漏れる、抜ける)
② 開発チームのアウトプットをデザイナーが受け⽌める → 機能仕様の実現は、プログラマーが担保する = レイアウトのアウトラインは、開発チームとデザイナー が話し合ってすりあわせておく (情報設計先⾏)
→ プログラマーが実装した機能にデザイナーがUIを作り込む = デザイナーが⼿元でソフトウェアを動かせる必要がある (コンテナベースの開発は必須)
デザイナーとの「ともにつくる」間違っても即正せる開発
開発チーム
デザイナー
Sprint0 Sprint1 Sprint2 Sprint3 …
アプリ(サイト)構造
各ページのイメージ (ワイヤー/Prott)
※同じものを⾒てつくる
機能の実装
UIの作り込み UIの作り込み
機能の実装 機能の実装
※プログラマー→デザイナー→プログラマーで 再度受け⽌めて確認・マージ (プロダクトが⾏きつ戻りつ”千⿃⾜”の軌跡)
機能開発とデザインの”千⿃⾜”プロセス
※Sprint開始前にAtomic Desinに則り共通コンポーネント の定義と実装を差し込みたい
・⽂字どおり「ともにつくる」 ① 基本は週1のイベント (レビュー/計画 + レトロスペクティブ) ② プロダクトバックログの共同所有 → 「進み」は、傭兵チーム(ギルドワークスチーム)が稼ぐ → 簡単なPBLは、内製チームが1つずつ全員で倒していく ③ チャンスがあればとにかく「ともにつくる」(モブプロ) →東京で同席で、傭兵チーム + 内製チーム(関東/四国) →リモートで、 傭兵チーム + 内製チーム(関東/四国) →今治で同席で、傭兵チーム + 内製チーム(関東/四国) →リモートで、 内製チーム(関東) + 内製チーム(四国)
プロダクトオーナー、関係者との「ともにつくる」間違っても即正せる開発
2ヶ⽉
ユーザー体験が完結するMVPの開発に
あるレベルの規模感に対する期間として ギルドワークス史上最速
(デザインがあたっていて、実データで動いていて、受け⼊れテスト済)
カイゼン・ジャーニー/⻄⽅
まだ、やり残していることがあるのでは？
われわれはなぜここにいるのか新しい事業展開を牽引するサービスの開発・SoR中⼼から、SoEへの越境 ・何をつくるべきか？ = 仮説検証 ・どのようにしてかたちにしていくか？ = アジャイル開発
歴史深い組織が、アジャイルに踏み出すただ、リーンに探索し、アジャイルにサービスをつくるという 話ではなく、牽引する事業開発チームの⽴ち上げが求められる。 事業開発チーム = 従来のやり⽅、あり⽅にとらわれない変⾰の中核
もう⼀つのミッション = 変⾰への越境
リアル・カイゼン・ジャーニー (四国編)
変⾰への越境リアル・カイゼン・ジャーニー (A⾯)
・アジャイルなマインドセットとやり⽅を組織として 取り⼊れるチャンス
・⼈は現実の変化 = 成果を⽬の当たりすると⼼が動く
・⼩さくとも⾃分たち⾃⾝の成果をあげるように！ジャーニー ⾃分たちでアジャイルな取り組みでの成果出せた! → 組織からの期待に応えられた → 周囲の巻き込みを広げる → 次の取り組みを⼀歩進める ※まだ、最初の成果を出す段階
関係の質
思考の質
⾏動の質
成果の質
まず、内製チームが 「⾃分たちは何をする⼈たちなのか？」
に答えれるように。
・情報システム部⾨としてのふりかえり → 現状の⾃分たちの良さ、抱えている問題を吐き出す
・ゴールデンサークルは描く☓2回 → 最初にあがるWhyは、たいてい⽇常の延⻑になる → 「本当に私達が実現したいことと合ってるのか？」 = 2回⽬でありたい姿に向き合う
・どうやってやるかを全員で背負う → ⼀⼈で背負っても、やればやるほど疲弊するだけ チームで背負う = 背負うものを⾒えるように = カンバン
変⾰への越境むきなおり合宿
カイゼン・ジャーニー/⽯神
めでたし、めでたし …とはいかない。
⼤企業の新規事業は 2回戦う
⼤企業の新規事業は2回戦う最初の関⾨は、プロダクトの⽅向性を⾒定めること・仮説検証の世界に、正解があるわけではない。 ・正しくないものをつくらない = 何もつくらない!? ・事業をつくりだすミッションのプレッシャーは変わらない
①
⼤企業の新規事業は2回戦う最⼤の問題は、コンセプトをまとめた後にくる・⼤企業ならでは、社内関係者の調整という関⾨ (リアル・カイゼン・ジャーニー(B⾯)) ・チームで乗り越えるしかない。
②
不確実性の⾼い状況を 果てしなく先読みしてもムダ。
何が来たとしても、互いの 持ち味を活かして、状況に適応できる レジリエンスの⾼いチームを⽬指す
Toshihiro Ichitani All Rights Reserved.Golden Circle
What
How
Why
Start with Why again !
Toshihiro Ichitani All Rights Reserved.
「カイゼン・ジャーニー」を通じて、⽇本中の現場や仕事場にそれぞれの越境
ストーリーが紡がれるのを 後押ししたい。
(そして私はその物語を読みたい)
逆境からのアジャイルを エナジャイズする
エナジャイズ…元気づける、勇気づける、後押しする
逆境からのアジャイルを エナジャイズする
エナジャイズ…元気づける、勇気づける、後押しする
逆境だからこそ起きた変化が 与える影響は⼤きい
⽇本中に、アジャイルな現場を。
楽しいジャーニーを、始めましょう。
