関連スライド
各ページのテキスト
正しいものを正しくつくる へ⾄る道 なぜ、仮説検証型アジャイル開発へ辿りつくのか Ichitani Toshihiro 市⾕聡啓
市⾕ 聡啓 Ichitani Toshihiro (My KeyWord) 越境 正しいものを正しくつくる 仮説検証型アジャイル開発
Profile https://ichitani.com/
4刷 https://www.amazon.co.jp/dp/4798153346/
6⽉14⽇発刊 https://www.amazon.co.jp/dp/4802511191/
GuildHub 何の⼿がかりも無いプロダクトーナーに 正しいものを正しくつくる https://lp.guildhub.jp/ ベータ版が公開されたGuildHubを使って仮説キャンバスを作ってみる https://qiita.com/navitime_tech/items/2cb0d674c8d3a5f8a6a6
ソフトウェア開発 Photo on VisualHunt.com
SoR ソフトウェア開発 SoE Photo on VisualHunt.com
⼦供写真共有アプリ SoR ソフトウェア開発 SoE 仮想通貨 Photo on VisualHunt.com
⼦供写真共有アプリ MaaS VR SoR 婚活 決済 ソフトウェア開発 従業員満⾜度 RPA SI SoE 仮想通貨 介護ロボット Photo on VisualHunt.com
⼦供写真共有アプリ MaaS 婚活 SoR 決済 同じ”ソフトウェア開発” ソフトウェア開発 VR SI なのか？ 従業員満⾜度 RPA SoE 仮想通貨 介護ロボット Photo on VisualHunt.com
⾼まるプロダクトづくりの「多様性」 つくるプロダクトの多様 (“同じソフトウェアなのか？”) = プロダクトへの期待が多様ということ つくる技術の多様性 = 多様な期待に応えるためにそのすべも多様 つくる⼈間の多様性 = つくり⼿の働き⽅、働く場所も多様
働き⽅、働く場所の多様性の広がり 副業、複業の時代 ・昼間はSIerや⼤企業。夜や⼟曜は副業でサービス開発。 ・いきなりフリーランスというハードル以外の選択肢。 ・何でもって正業、副業とするか⾒分けがつかなくなる (複業) リモートワーク ・導⼊率11.5% (総務省、2018年7⽉調査) ・働く場所を問わない現場がこの5年で増えてきている。 ・週1リモートのような部分適⽤も。
分断による6つの問題 副業 時間の分断 稼働時間帯 があわない スクラムイベン トができない (同期しにくい) 同期 リモート ワーク 経験の分断 稼働時間に 偏りがある 1PBI開発あたりの コミュニケーショ ンコスト⾼い オーバー ヘッド 集まる⼈達の経験 の幅が広くなる 仕事のやり⽅が ⼈によって バラバラ やり⽅ 場所の分断 ⾮⾔語コミュニケー ションできない 相⼿の様⼦が わからない 背景⾒えずタスク 指向になりがち 伝わる内容、 分量が 圧倒的に少ない 異常検知が 働きにくい Whyが弱いため 間違いに気付き にくい 内容分量 「コミュニケーションの分断」 によって⾼まる複雑性 異常検知 No Why PBI…プロダクト バックログアイテム
多様性=プロダクト開発の 複雑性が不確実性を 連れてくる。 Photo on VisualHunt
「プロダクト開発=不確実性が⾼い」 ではない
不確実性 = 確実なことが⾔えない つまり、分析や計画づくりによって確実性を ⾼められるならば「不確実性が⾼い」とは呼べない =状況分析の解像度が粗いだけ 分析だけでは情報が⾜りず、解が算出できない。 ゆえに、仮説検証によって情報(理解)を増やし、 “確からしさ” を⾼める =不確実性の⾼い状況へのスタンス Photo on VisualHunt
不確実性に挑むべく、 我々が培ってきた実践知 Photo credit: Henry Sudarman on Visual hunt / CC BY-NC-ND
Do Agile Be agile Photo on VisualHunt
プロダクトオーナー 開発チーム スプリント バックログ プロダクト スクラムマスター バックログ インクリメント ステークホルダー
スプリント = 箱。箱を必要なだけ繋ぐ。 箱の⼤きさ(タイムボックス)の上限はチームで決めている。 スプリント デイリー スプリント スプリント プランニング スクラム レビュー レトロスペクティブ … ＋ スプリント … ＋ スプリント 「(箱)の数は⾜りているか、あるいは余りそうか？」の⾒⽴てを、 スプリントを終えるたびに⾏う (“着地の予測") …
アジャイルな開発のプロセス的な特徴 少しずつ反復的に開発を進めることで 必要とする⼈から必要なフィードバックを得て 調整し続けられる開発 「インクリメンタル」(少しずつ) 「イテレーティブ」(繰り返し) つまり「早く(少しだけ)形にできる」やり⽅
早く(少しだけ)形にできることの意義 ① フィードバックに基づく調整で、⽬的に適した ソフトウェアに仕⽴てられる ② 形にすることで早めに関係者の認識を揃えられる ③ つくるものやチームについての問題早く気付ける ④ チームの学習効果が⾼い ⑤ 早く始められる ⑥ 結合のリスクを早めに倒せる ⑦ Time to market が短い ⑧ サンクコストが⼩さくできる ⑨ 開発チームのリズムを整えられる https://www.slideshare.net/papanda/ss-79465986
「早く少しだけ形にする」 の難しさとは？ https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
早く形が⾒える、触れる 想像⼒頼みから体が使える だから、圧倒的に学びが増える Photo on VisualHunt
学びが次の不確実性を 連れてくる。 Photo on VisualHunt
トレードオフが成り⽴たない現実 予算も、期間も、ギリギリの判断、局⾯では トレードオフが効かない (“来⽉ローンチできなければ次の予算|資⾦が獲得できない”) 予算、期間の制約が無い! 勝った!! → たいてい、グダる。 「お⾦と時間をあるだけ使う」 (パーキンソンの法則) →「制約」を利⽤する。“期間制約を味⽅につける” ⼈の意識も有限のリソース。制約が集中を⽣む Photo credit: joiseyshowaa on VisualHunt.com / CC BY-SA
プロジェクト vs プロダクト ? プロジェクト = タイムボックスの切り⽅の1つ プロダクト = 成果物 ⼆項対⽴の概念ではない タイムボックスという時間的制約によって ⼈の意識と経営資源を集中投下し成果を⾼める
変化を受け⽌められる 余⽩をつくりながら、 余⽩が無ければ変化を受け⼊れられない。 いかにして無いところに余⽩を作り出すか？ 短いタイムボックスの中での 確実性は⾼める。 ⻑い距離で確実なことは⾔えない。 でも、短い距離でなら？成果の確度を⾼められる。 Photo credit: Arenamontanus on Visualhunt.com / CC BY
余⽩の戦略 スプリント強度を ⾼める戦術
プロジェクトレベル ・調整の余⽩ ・期間の余⽩ ・受け⼊れの余⽩ 余⽩の戦略 全体への 共通理解を統べる作戦 複数スプリントレベル スプリント強度を⾼める戦術 スプリントレベル ・背⾻駆動開発 ・状況をクリーンに保つ5つの条件 1. 受け⼊れ条件を定義している 2. ベロシティを計測し安定させている 3. 受け⼊れテストを実施している 4. 振り返りを実施しカイゼン継続 5. 実運⽤相当のデータが揃っている
⾃分たちの活動に”作戦名”をつける 活動 = まとまった機能群の開発、カイゼン… 距離感としては プロジェクト ＞ 複数スプリント ＞ スプリント 象徴的な名前付けで⽅針を分かりやすくする (“期間制約を味⽅につける”) Photo credit: mxmstryo on VisualHunt / CC BY
「つくる」のアジリティは⾼めれる。 ⼀⽅、「つくるもの」は⼤丈夫か？
何をつくるべきなのか仮説を⽴て 最⼤限選択肢を保ちながら検証を 進め、誤りを除去していく。
仮説検証型アジャイル開発 選択の幅最⼤ 仮説⽴案 （セットベース） (モデル化) 検証 計画 価値探索 （正しいものを探す） 評価 スプリントプ ランニング 検証 開発計画 MVP特定 (リリースプラ ンニング) 選択の振れ幅最⼩ （ポイントベース） スプリント 開発 アジャイル開発 （正しくつくる） スプリント レトロスペクティ ブ MVP検証 スプリント レビュー 「価値探索」 この活動がなければ何をつくるべきかが関係者の勘と経験にしか依らない。 開発チームもプロダクトどうあるべきという基準が持てない。 次の検証計画 (価値探索)へ
仮説検証型アジャイル開発とは 選択と向き合うこと
選択を”段階”にすることで不確実性を対処する 選択の幅最⼤ 仮説⽴案 （セットベース） (モデル化) 検証 計画 価値探索 スプリントプ ランニング 検証 開発計画 MVP特定 （正しいものを探す） 評価 ⽬的選択の 段階 コンセプトの検証 (リリースプラ ンニング) （ポイントベース） 開発 アジャイル開発 （正しくつくる） スプリント レトロスペクティ ブ 選択の振れ幅最⼩ スプリント MVP検証 スプリント レビュー 次の検証計画 (価値探索)へ 実体選択の ⼿段選択の 順序選択の 段階 段階 段階 ユーザーに とって有⽤ かつ必要最 ⼩限の範囲 の機能特定 機能設計、 プロダクトバックログ UIデザイン、 のリファインメント データ設計 例えば、⼿段選択の段階でコンセプトを 変える決定の影響の⼤きさは明らか
ボトルネックは常に移り変わる。 プロセスからフォーメーションへ。
ザ・プロダクトオーナー ワールド 選択の幅最⼤ 仮説⽴案 （セットベース） (モデル化) 検証 計画 価値探索 （正しいものを探す） 評価 ザ・開発チーム ワールド スプリントプ ランニング 検証 開発計画 MVP特定 (リリースプラ ンニング) 選択の振れ幅最⼩ （ポイントベース） スプリント 開発 アジャイル開発 （正しくつくる） スプリント レトロスペクティ ブ MVP検証 スプリント レビュー 次の検証計画 (価値探索)へ POは”つくる”に関⼼無く、開発チームは”考える”を丸投げの世界
間違ったものを 正しくつくる Do the Wrong things Right いくら型どおりに正しくつくっていても、 間違ったもの(⽬的に適さないもの)をつくっている限り ミッションは達成できない。 Photo credit: BeaLeiderman via VisualHunt.com / CC BY-NC-SA Toshihiro Ichitani All Rights Reserved.
プロダクトオーナーの視座を プロダクトのボトルネックにしない Toshihiro Ichitani All Rights Reserved. Photo credit: Steven Penton on VisualHunt / CC BY
"プロダクトオーナー”の⺠主化 PO⼀⼈の視座、視野から チームの視座、視野へ Photo credit: afagen on Visualhunt.com / CC BY-NC-SA
仮説検証をPOだけではなく チームで⾏う
プロダクトに関する基準をチームに宿す 検証結果と学びを共同所有する
参画者の多様性でもって プロダクトの不確実性に対抗する Photo on VisualHunt
プロダクトづくりにユーザーを巻き込み チームの視座、視野を⾼め広げる。
「役割による調整」から 仮説検証による学びを 中⼼とした”ともにつくる”へ
個⼈からチームへ、⾼まるのは ”これまでこうしてきたバイアス”、”同調圧⼒” ボトルネックは⼈のマインドセットへ Photo credit: jurek d. (Jerzy Durczak) on VisualHunt.com / CC BY-NC
⾃分たちの現状理解をアップデート(越境)し続ける 絶対的な正解など無い。(そんなことは多くの⼈が分かってる) それを踏まえて、⾃分たちの思考や⾏動に誤りが 混⼊していないか、気づいていない事に気づきたい Photo credit: Pro-Zak on Visual Hunt / CC BY-NC
越境のための問いを得る Photo credit: James Marvin Phelps via Visualhunt.com / CC BY-NC Toshihiro Ichitani All Rights Reserved.
⾃分たちが既存の思考や⾏動に最適化している 事実に気づきにくい (だから問いを⽤いる) (問い) ⾃分たちの意識に 囚われない ”問い” で 思考や⾏動に向き直る チームが”分かっている” 圏内
不確実性の⾼い状況ほど 回答可能な問いにばかり答えていても発⾒が⾜りない 回答不可能な問いをあえて置く Photo credit: Shandi-lee on Visualhunt.com / CC BY-NC-ND
正しいものを正しくつくれているか？
正しいものを正しくつくる へ⾄る道 なぜ、仮説検証型アジャイル開発へ辿りつくのか