More Related Content
What's hot (20)
Similar to 逆境から新规事业をスタートアッフ?する「仮説検証型アシ?ャイル开発」の実践 (20)
More from 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. ?本中に、アジャイルな现场を。