Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

正しいものを正しくつくるへ至る道

3.705 Aufrufe

Veröffentlicht am

なぜ、仮説検証型アジャイル開発へ辿り着くのか

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

正しいものを正しくつくるへ至る道

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

×