Download as PDF, PPTX
More Related Content
Similar to ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜
ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜
- 1.
- 2.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10. 「分からないものを分かるようにする」戦略 正しいものを正しくつくる 分からないから選択肢を広く持つ → 決め打ちして間違えると時間的損失が⼤きい (時間あたりで得られる学びが少ない) 最も「分かる」のは想像ではなく現実に 直⾯した時 →いかに現実に近い状況を(コスパ良く)つくるか 「分かる」に使う距離(時間|予算)を段階的に → 学びを活かす「次」の設計=段階化 (サンクコストの最⼩化)
- 11.
- 12.
- 13.
- 14. Toshihiro Ichitani AllRights Reserved. Photo credit: Steven Penton on VisualHunt / CC BY プロダクトオーナーの視座を プロダクトの上限(ボトルネック)にしない
- 15. Photo credit: afagenon Visualhunt.com / CC BY-NC-SA "プロダクトオーナー”の⺠主化 PO⼀⼈の視座、視野から チームの視座、視野へ
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26. ジャーニースタイル プロセス スプリント <複数スプリント < ⽬的地 1週間 まとまった単位のテーマ に割り当てる期間 事業上の マイルストーン 段階(ジャーニー)の設計 ・到達したい⽬的地の把握から、逆算して 必要なジャーニーを割り出す ・各ジャーニーでの到達状態、指標の ⽬標値を⾔語化、定量化する ・ジャーニーを終える度にふりかえり、 ⽬的地にむきなおる。適宜、ジャーニー の延⻑(スプリント追加)、新しいジャー ニーの追加を⾏う (スプリントは固定、ジャーニーは可変) MVPの完成 製品の⾻格完成 (例) チームビルド
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39. 適者⽣存型アーキテクチャ アーキ Atomic Design→⾃チーム流の構造化 当初AtomicDesignでコンポーネント設計を⾏っていたが 「定義上の正解は何？沼」にはまる。 チームの外から定義を取ってつけようとするのではなく エンジニアとデザイナーの当事者でコンポーネント定義。 補⾜ ・レイヤー構造をチームで定義、名前付けする ・各レイヤーの責務をチームで決めること (特にロジックの責務を持ったレイヤーの認識揃える) ・CSSの構造をて定義したレイヤー構造に合わせる (ベースはFLOCSS) ・カタログ化はStorybookで
- 40.
- 41.
- 42. 適者⽣存型アーキテクチャ アーキ clickupでカンバン開発 補⾜ 開発メンバーがそれぞれの状況によって分断しがち (リモートワーク、複業) 同期イベントを最⼩限にして(※1)、状態管理を強めに= カンバン (※1)同期イベントが少ない= プロダクトについての共通理解を 育みにくい。だからこそプロダク トレビューの位置づけが重要。 (※2)Clickupのスロット管理が バックログの構造化に適している confidential confidential (※2)
- 43.
- 44.
- 45.
- 46. 謝辞 ともに考え、ともにつくるにあたるチームメンバーへ Takahashi Toshiaki Numata Keisuke OkadaTakumi Matsuda Yasuaki Kutsu Hirokazu Ogata Yuto Masuda Kyohei Abe Tadanori