改善を提案した。検討にかかり、来期に持ち越された。一人で始めて広げるための論点を3つ紹介する。
✓お勧めする人
- 組織を変えたいが権限がない
- 開発チームと関わる
- 現状が見えていない
−おすすめしない人
- 開発の手法そのものを学びたい
- 物語形式が苦手
著者について
市谷聡啓・新井剛
アジャイル開発の実践者・支援者
- 経歴
- ともに現場でアジャイル開発の導入と改善を支援してきた
- 実績
- 一人から始めてチームと組織へ広げる過程を物語形式で描いた
目的
やり方を変えたい。提案した。検討にかかり、来期に持ち越された。結局何も変わらない。
組織が悪いのではなく、許可を取ってから始めようとしている。本書を読む目的は、一人の範囲から動かす順序を知ることにある。
論点1 許可を取ってから始める改善は、始まらない
本書は一人の主人公が自分の手元から変えていく物語として書かれている。
- 承認を待つ … 検討にかかり、来期に持ち越される
- 一人で始める … 自分の範囲で試し、結果を見せる。周りが乗ってくる
営業組織でも同じことが言える。会議の進め方を変えたいなら、自分のチームの会議から変えて結果を見せる。
いちこ
勝手に変えると、怒られそうです。
シュン
自分の範囲ならいいんだよ。結果が出てから広げるほうが、話も通りやすいんだ。
論点2 見えていないものは、誰も直せない
本書が最初の一手として置くのが可視化だ。仕事が各自の頭の中にあると、誰が詰まっているか分からない。
- ボードに出す … todo / doing / done で並べる
- doingが溜まっている所 … そこが詰まり
案件の状況でも同じことが起きる。パイプラインを一覧にするだけで、止まっている場所が見える。
論点3 問題は役割の隙間で起きている
「それはそちらの仕事」で止めると、境界に落ちた問題が誰にも拾われない。
本書が越境と呼ぶのは、役割の外に少し出て関わることだ。越える人が一人いるだけで、隙間が埋まる。営業と開発の間の渡し方は ユーザーストーリーマッピング が具体的だ。
いちこ
越境というと、大げさに聞こえます。
シュン
実際は小さいんだ。開発の朝会に顔を出す、くらいのことだよ。
この本の限界と、次に読む本
物語形式で分量があり、開発の文脈が濃い。営業の読者は手法より進め方を取る読み方になる。期日と範囲の交渉なら アジャイルサムライ、組織の構造から考えるなら エンジニアリング組織論への招待 が隣に並ぶ。
Amazonで見る Amazonのアソシエイトとして、SaleStats Lab は適格販売により収入を得ています。
要件を形にするのほかの本
- ユーザーストーリーマッピング Jeff Patton
- はじめよう!要件定義 羽生章洋