Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践
Similaire à 逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践 (20)
Plus de toshihiro ichitani
Plus de toshihiro ichitani (20)
逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践
- 1. Toshihiro Ichitani All Rights Reserved. 逆境から新規事業をスタートアップする 「仮説検証型アジャイル開発」の実践 Ichitani Toshihiro 市⾕聡啓 逆境から、不確実性に向き合いながら 組織としての越境へ向かう道
- 2. Toshihiro Ichitani All Rights Reserved. Ichitani Toshihiro 市⾕聡啓 ソフトウェア開発17年 SIer→サービス→受託→起業 仮説検証とアジャイル開発 ギルドワークス株式会社 代表 株式会社 エナジャイル 代表 ⼀般社団法⼈ 越境アジャイルアライアンス代表理事 DevLOVE コミュニティ ファウンダ 0 → 1 @papanda
- 4. Toshihiro Ichitani All Rights Reserved. スタートアップや事業会社での 新規事業、新規サービスの⽴ち上げ 事業会社での現場改善、仮説検証コーチ ギルドワークス 「正しいものを正しくつくる」 Why What
- 5. Toshihiro Ichitani All Rights Reserved. Golden Circle What How Why Start with Why.
- 7. 2003年〜
- 9. 2017年頃〜現在
- 11. 今起きていることと、⼀筋の望みと 15年分の積み重ねを、数ヶ⽉で再⽣できるか？ ・チーム、関係者としての振る舞い⽅についての理解、当然ゼロから。 ・2012年頃の「期待マネジメント」のやりようが、未だ現役。 ・「”アジャイル開発” でやれば、なんだかスゴイものができる」 (↑この期待調整の15年だったと⾔っても過⾔ではない) ・さらに ”アジャイル” への万能的な期待。 「アジャイルでやれば新規事業も上⼿く⾏く！」 ・そもそも「ソフトウェア開発」⾃体の理解が不⾜している。 (役割定義したら明⽇からPOとして振る舞えるかって？) ・アジャイル開発、ソフトウェア開発云々の前に、 お互いを尊重し、信頼しあえる関係性へ、⼀歩⼀歩…。その遠さよ。
- 16. Toshihiro Ichitani All Rights Reserved. Golden Circle What How Why How can "why” be realized?
- 19. ⼤企業の場合 = ポイントベース 却下の失敗 選択肢採⽤の基準が厳しすぎる。 不確実なことでも予めの検討を 詳細に求められれる。 途上で、組織的判断でアイデアが死ぬ。 ◯ ☓ ◯ ◯ ☓ ☓ ☓ ◯ 基準が厳しすぎるため、検証しないと 判断できないことも却下される。
- 20. Toshihiro Ichitani All Rights Reserved. 求められるのは、 採⽤の失敗を抑えながら、製品開発を⾏う⼿段。 仮説の確からしさを検証しながら、漸進する開発。 仮説検証型アジャイル開発 ①正しくない仮説を採⽤しないよう「検証に基づく意思決定」を前提とする ②状況に応じて、仮説検証の「精度」と「頻度」を調整する
- 26. Toshihiro Ichitani All Rights Reserved. Golden Circle What How Why 仮説検証型アジャイル開発 Real Story
- 27. 或るプロジェクトの話
- 28. われわれはなぜここにいるのか 新しい事業展開を牽引するサービスの開発 ・SoR中⼼から、SoEへの越境 ・何をつくるべきか？ = 仮説検証 ・どのようにしてかたちにしていくか？ = アジャイル開発 歴史深い組織が、アジャイルに踏み出す ただ、リーンに探索し、アジャイルにサービスをつくるという 話ではなく、牽引する事業開発チームの⽴ち上げが求められる。 事業開発チーム = 従来のやり⽅、あり⽅にとらわれない変⾰の中核 事業開発とチーム開発のダブルミッション
- 37. 必要にして最⼩限の要求詳細化作戦 壱 「絵に書いた餅はスプリントで⾷べられない」 ・要求仕様の粒度は結成するチームと関係者の練度 でもって決める (ただ詳細であれば良いわけではない) → たいてい、機能⼀覧→ユーザーストーリー→機能分割 ・詳細で中⾝が嵩⾼いほど、⼈は受け取れなくなる、 読み取れなくなる、読取り誤る ・もっとも理解が深まるのは⽣成過程をともにすること → バックログリファインメントを⼀緒にやる、 規模⾒積もりを⼀緒にやる、ともにつくる
- 39. 必要にして最⼩限の要求詳細化作戦 参 常にチームビルディング ・遠い距離は縮めるしかない。縮めるには時間をともに するしかない。 ・単純接触効果 (接触回数が警戒⼼を解く) → 関係者は、仮説検証の段階から頻繁に濃密な時間を ともにする (仮説検証を通じてお互いの間合いを知る) ・偶発性にゆだねるだけでは、単純接触効果は上がらない → 「ソフトウェア開発は演出」(意図的に仕組む)
- 42. Toshihiro Ichitani All Rights Reserved. 「⾮同期、コミュニケーションレスで お互いの認識はズレる」が前提 (「リモートだから、頻度を増やそう」はアンチパターン)
- 45. ・1週間スプリント = 認識がズレても、間違っている期間は最⻑1週間 ・最初から統合し続ける = 早く間違えられる = 早く正せる ①「デザインワークをマージすると事故が起こる」問題 → デザインワークを貯めない、2スプリント⽬からマージする ②「本番相当データを投⼊したときに想定外が起きる」問題 → 1スプリント⽬から実データを投⼊する = 1スプリント⽬からデータを揃えないといけない … データ起因の想定外仕様を早期に検出できる (「そう⾔えば、こういう例外もありまして…」) ※SoRと関連が深い開発ほど実データを最初投⼊。(⻤⾨になりやすいから) ※逆境からのアジャイルの場合はSoE開発でも、SoRが絡みやすい。 間違うなら、早めに間違っておく 間違っても即正せる開発
- 46. ・「認識がズレている→戻す」から「共通理解を最初に置く」へ → 受け⼊れ条件ありきで、スプリント開発を駆動する ・「プロダクトオーナーが受け⼊れ条件を書けない」問題 主にエンジニアリング知識、経験の不⾜により⼗分に定義できない → 仮説検証を実施しているので、どうあると良いのかの基準を 開発チームの⽅が保有している (POより詳しくさえある) = 受け⼊れ条件がスラスラ書ける ・それでも間違うときは間違う → スプリント毎の受け⼊れテストで、認識のズレを即検知→即修整 最初から「何でもって完成なのか」をあわせる 間違っても即正せる開発
- 47. ・間違わない順番でつくる ① デザイナーのアウトプットを開発チームが受け⽌める → アウトプットが機能仕様と合致してない (漏れる、抜ける) デザイナーとの「ともにつくる」 間違っても即正せる開発
- 49. ・間違わない順番でつくる ① デザイナーのアウトプットを開発チームが受け⽌める → アウトプットが機能仕様と合致してない (漏れる、抜ける) ② 開発チームのアウトプットをデザイナーが受け⽌める → 機能仕様の実現は、プログラマーが担保する = レイアウトのアウトラインは、開発チームとデザイナー が話し合ってすりあわせておく (情報設計先⾏) → プログラマーが実装した機能にデザイナーがUIを作り込む = デザイナーが⼿元でソフトウェアを動かせる必要がある (コンテナベースの開発は必須) デザイナーとの「ともにつくる」 間違っても即正せる開発
- 50. 開発チーム デザイナー Sprint0 Sprint1 Sprint2 Sprint3 … アプリ(サイト)構造 各ページのイメージ (ワイヤー/Prott) ※同じものを⾒てつくる 機能の実装 UIの作り込み UIの作り込み 機能の実装 機能の実装 ※プログラマー→デザイナー→プログラマーで 再度受け⽌めて確認・マージ (プロダクトが⾏きつ戻りつ”千⿃⾜”の軌跡) 機能開発とデザインの”千⿃⾜”プロセス ※Sprint開始前にAtomic Desinに則り共通コンポーネント の定義と実装を差し込みたい
- 51. ・⽂字どおり「ともにつくる」 ① 基本は週1のイベント (レビュー/計画 + レトロスペクティブ) ② プロダクトバックログの共同所有 → 「進み」は、傭兵チーム(ギルドワークスチーム)が稼ぐ → 簡単なPBLは、内製チームが1つずつ全員で倒していく ③ チャンスがあればとにかく「ともにつくる」(モブプロ) →東京で同席で、傭兵チーム + 内製チーム(関東/四国) →リモートで、 傭兵チーム + 内製チーム(関東/四国) →今治で同席で、傭兵チーム + 内製チーム(関東/四国) →リモートで、 内製チーム(関東) + 内製チーム(四国) プロダクトオーナー、関係者との「ともにつくる」 間違っても即正せる開発
- 55. われわれはなぜここにいるのか 新しい事業展開を牽引するサービスの開発 ・SoR中⼼から、SoEへの越境 ・何をつくるべきか？ = 仮説検証 ・どのようにしてかたちにしていくか？ = アジャイル開発 歴史深い組織が、アジャイルに踏み出す ただ、リーンに探索し、アジャイルにサービスをつくるという 話ではなく、牽引する事業開発チームの⽴ち上げが求められる。 事業開発チーム = 従来のやり⽅、あり⽅にとらわれない変⾰の中核 もう⼀つのミッション = 変⾰への越境
- 57. 変⾰への越境 リアル・カイゼン・ジャーニー (A⾯) ・アジャイルなマインドセットとやり⽅を組織として 取り⼊れるチャンス ・⼈は現実の変化 = 成果を⽬の当たりすると⼼が動く ・⼩さくとも⾃分たち⾃⾝の成果をあげるように！ジャーニー ⾃分たちでアジャイルな取り組みでの成果出せた! → 組織からの期待に応えられた → 周囲の巻き込みを広げる → 次の取り組みを⼀歩進める ※まだ、最初の成果を出す段階 関係の質 思考の質 ⾏動の質 成果の質
- 59. ・情報システム部⾨としてのふりかえり → 現状の⾃分たちの良さ、抱えている問題を吐き出す ・ゴールデンサークルは描く☓2回 → 最初にあがるWhyは、たいてい⽇常の延⻑になる → 「本当に私達が実現したいことと合ってるのか？」 = 2回⽬でありたい姿に向き合う ・どうやってやるかを全員で背負う → ⼀⼈で背負っても、やればやるほど疲弊するだけ チームで背負う = 背負うものを⾒えるように = カンバン 変⾰への越境 むきなおり合宿
- 61. ⼤企業の新規事業は 2回戦う
- 63. ⼤企業の新規事業は2回戦う 最⼤の問題は、コンセプトをまとめた後にくる ・⼤企業ならでは、社内関係者の調整という関⾨ (リアル・カイゼン・ジャーニー(B⾯)) ・チームで乗り越えるしかない。 ②
- 65. Toshihiro Ichitani All Rights Reserved. Golden Circle What How Why Start with Why again !
- 66. Toshihiro Ichitani All Rights Reserved. 「カイゼン・ジャーニー」 を通じて、⽇本中の現場や 仕事場にそれぞれの越境 ストーリーが紡がれるのを 後押ししたい。 (そして私はその物語を読みたい)
- 72. ⽇本中に、アジャイルな現場を。