不確実性の高いプロダクト開発や、継続的な価値提供を行なっているサービスにおいては、フロー効率を重視するのが良いとされている。ある価値が早く顧客に届く方が、早くフィードバックを得られるとか、顧客が享受する価値の総量が大きくなるとか、様々な方向からメリットは説明され尽くしている。それには同意する。
開発プロセスの文脈でもフロー効率を重視するためのプラクティスは一般的だと思う。スクラムの言葉に従えば、スプリントゴールはなるべくシンプルにひとつにしようとか、ひとつのプロダクトバックログアイテムを複数人で片付けようとか、そういった話である。チームの付加価値生産性を最大化するために、こうしたやり方を採用するのは素朴には理にかなっていると思う。しかし最近、メンバーの育成や評価に対する責任が大きくなってきて、その立場から改めてこれらのプラクティスを考えると、手放しに最高とは言い切れないなと葛藤している。
ある仕事を進めるにあたって、そこになんらかリーダーを設置するのが合理的な判断であることが多い。プロジェクトリーダーとか、アーキテクトとか、PBIのキャプテンとか、組織や文脈によって色々な呼ばれ方をするだろうが、とにかくその仕事全体が一貫性を持って完了することに責任を負う人がいる方がうまくいきやすい。このポジションが多くのメンバーにとって絶好の経験資源となる。リーダーとして大きめの設計ができるとか、仕事全体のスケジュールを管理できるといったことは、グレード/等級を上げていくための必須の条件だからだ。育成に責任を負う立場としては、準備ができているメンバー全員にそうした経験資源を配りたくなる。
しかし、フロー効率重視はそうした経験資源の分配を難しくするように思う。まず理論上はフロー効率を重視すると全体で完了できる仕事の量は減る。すなわち経験資源が減る。加えて各個撃破でチームが動いていると、仕事がやってくる時に常にリーダーが上手いメンバーの手が空いていることになる。短期的な事業成果だけを追うなら常にうまいメンバーに任せたくなる。経験資源を配って育成するには、「遅くなる可能性があるけどここは育成に振りたいので飲んでください」と話をする必要がある。まとめると、フロー効率を重視すると、少ない経験資源を狙いを持って配るマネジメントの必要性がさらに高まると感じている。
おそらく銀の弾丸はなくて、そういう構造ですねというだけの話である。前提を共有できると事業責任者とも話はしやすいので、まずは言葉にしてみた。とはいえ、こういうことを特に考えるようになったタイミングでフロー効率重視の局面にいるから関連性を感じるだけで、マネージャーはいつも経験資源が足りなくてヒイヒイ言っている気もする。テックリードのようなポジションは常に限られているわけなので。ひと通り書いてあまり自信がない感じになってしまったが、とりあえず葛藤する脳内をダンプしたということで。
