大規模スクラムや階層構造が詰むやつ.
現場の知見を重視して作られる良くある構造:
密なチーム→全チーム共通ヘッド→スケールしない
密なチーム→スケールしない→多チーム自律→feature単位の部分最適化
密なチーム→スケールしない→代議階層構造→チーム密にする意味ない命令型 or 浮世離れしたミッションコマンド
現場課題はいま直面してる問題をひっぱって来がち.
長期的だったり、構造的な問題はそう簡単にでてこない (分野専門家の仕事).
短期的価値 ----- 長期的価値
顧客・現場 ------- 専門家
短期も長期も解決する策を出すのがPOの仕事.
現場課題を直接制で、長期課題を専門家意見で見出す
見出したら解決策を考える.
関連する現場と専門家でスクラム組んで進める.
組織構造
特定価値に取り組むスクラムで基本的に仕事してる.
ディレクターは取り組む価値を決定して、チームを組成することの最終責任をもつ.
規模がどれだけ膨らんでも価値候補の数は一定までセレクションされるので検討数は無問題.
ディレクターが(代議制の)階層構造を持たないので、ディレクション担当だけど職人と近いのが構造上の利点.
どんなに現場と専門家がまともな課題あげても、最終決定がザルから意味がない.
チームへはほぼ全てを託す, じゃないとこの構造が破綻する.
ディレクターがチームと共に働き出すと、チーム数 = ディレクター負荷になる.
明らかに稼働が限界を超える.
ただこれだとディレクターと現場に交流がなくて、ディレクターが浮世離れする.
価値が根源なので受益人 (例: ユーザ) と常に実際に会うのは大前提として、ソリューションの浮世離れが怖い.
「資源がないとエネルギーが作れないのは大問題だ！ 」とか言い出したら「永久機関でも作れってか…w」となるのがオチ.
ディレクターの仕事は期待値の最大化ゆえ、実現可能性は必須事項.
それは施策と深くリンクしてて、現場が非常によく知ってること.
ゴール設定から初期PBI設定までがディレクターの範囲？
施策決定ってつまり初期PBの完成なので、理屈はあってる.
プロトタイピングチームからスクラムチームへの発展.
ここからチームに自走してもらうか、PO (というかfeature owner) 含むチームに自走してもらう.
価値には連続性がある.
おんなじチームがプロダクトゴールを更新する場合、強い連続性があると考えられる.
ディレクターが決定した価値は誰かが当然取り組む.
既存チームの新しいプロダクトゴールか、チームの分割や合併か、完全新規かは場合によりけり
連続性がその判断基準. まえのゴールが中途半端じゃ意味ないし、逆にゴール書き換えが必要でこの価値が見出されたって場合もある.
現状の分割を跨いで価値を生む必要があると判断されるかもしれないし、逆にチームが2つの直交する価値を持ってるのかもしれない.
プロトタイピングでは、関係しそうなシニアを集めて高速で試し、その上で現在チームとの関係性を整理する.
価値を先行させた上で現実にチームで進められるかのジャッジ.
ディレクション
ディレクション: 価値の期待値を最大化する施策を最終決定すること. ここでの価値とは、短~長期的かつ継続的に、顧客・組織・株主・社会が受け取る価値を指す.
