仕事ができるエンジニアはだいたい段取りがうまい。達成したいゴールがあるときに、AとBとCをやる必要があって、Bはわからないことが多いから先にやろうとか、AとCは並行してできるからCを誰かにお願いしようとか、とにかく目標を達成するための道のりをうまく計画できる人が多い。こういう作業をそつなくこなせるかが、ジュニアと一人前を区別する重要な指標のひとつと言える。そしてこの段取りをうまくできない人に対して、細かい計画を立ててあげて指示をするのがマイクロマネジメントだと思う。
スクラムにおけるスプリントプランニングは、この段取りをチームでやると思うとよく腹落ちする。達成したいゴールとしていくつかのプロダクトバックログアイテムを置いて、その達成に必要な作業を半日から1日で終わるサイズのタスクにみんなで分解して、不明点を一緒に洗い出して、どういう順番でやっていくか計画を立てる。まさに段取りだ。これがスクラムがマイクロマネジメント手法だと言われがちな由縁だろう。自分で段取りができてしまうエンジニアからすると、わざわざチームで集まって細切れにしなくても、大きい単位で渡してくれたらいい感じにしまっせ、という気持ちになるのも理解できる。そうした方がリソース効率は上げやすいし自由な感じがする。
こうした方法を取るメリットは大きく2つあると思う。ひとつはマイクロマネジメントを形式的にできることだ。シニアメンバーも含めて一緒に詳細な計画を立てて回ることで、チームの総合的な段取り力を大きく、かつ確実に底上げできる。ジュニアメンバーが多いほど有効に機能するだろう。もうひとつのメリットはフロー効率の最適化をしやすいことだ。ある目的を達成するための作業を、一度バラしてチームのものとして一覧することで、多少コストがかさんでも最速で価値を届けるための方法を見つけやすくなる。
こういう特徴を考えると、急成長しているSaaSの開発なんかとスクラムは非常に相性が良さそうに見える。組織の拡大が早いのでシステムに詳しくないメンバーの割合が高いし、仮説検証による製品発見が重要になるのでフロー効率を上げる必要がある。反対に、一定のスコープを目指して作り切るような仕事をしているチームでは、スクラムによる恩恵は感じにくいかもしれない。インクリメンタルな結果を求められなければ、フロー効率を高める意味もイテレーティブにやる意味も主張しづらい（本来は不確実性を下げたりチームの学習を促すためにやるべきだとは思うが）。シニアメンバーだけでチームが構成されている場合も、スプリントプランニングを簡素化するといったチューニングは検討しても良いだろう。POが期待する成果が出ていれば、細かいやり方に口出しされる筋合いはない。
