チームの開発速度は最遅のメンバに引っ張られる

プロジェクトは有限の時間の中で要件を実現する営みで期限までにdeliverableを届けることが出来たらそれでお仕舞。それがプロジェクト。プロジェクト全体でそうしたしくみなっているのだから、プロジェクトの中の手続きがステップを踏んで進むような作業をするなら、殊更、一つひとつの作業の粒は人かが制御できる単位まで展開され、分解されるのです。であれば、その小さな一つひとつの作業の期間も短くなり、そうした作業の連鎖が一つのプロジェクトという工期と言うような関係を持つのです。

チームを組むとプロジェクトが達成しなければならない要件を実現するために必要なスキル持つ様々なキャリアの背景のエンジニアをアサインすることになります。エンジニア一人ひとりが個別の経験を積み上げてきているので一様ではないことに注意しなければなりません。

アサインした時に注意すること、つまり、エンジニアの個々について把握するまでは、ですが、期待するスキルレベルか否か、チームに課す品質を作り込むことが出来るか、意思疎通が出来るかどうか、などは面接では知ることもできないもので、ある意味ギャンブルだったりします。だから、価値を届けるための開発スピードを最優先に考えるアジャイルでは開発チームは継続することを求めているわけです。

時間は限られている、一つひとつの作業は日単位、場合によっては時間単位で作業が予定されているもので、そうした場合に問題になるのがエンジニアの仕事のスピードです。別にメンバの作業が最速である必要はないけれど、思い出してほしいのはエンジニアは例え同じプロジェクトを経験してきたとしても役割、担当するプログラムは一人ひとり違うし、仕事に対する考え方、先天的な性格も作用して、似たような作業をしていてもそのアウトプットまでに係る時間は様々なのです。

そして、チームの開発速度は最遅のメンバに引っ張られる。

これはつまり、WBSを組むときにそうした最遅のメンバを含めてチームの開発速度を知っておかないとあとあと痛い目にあう可能性があるということを示唆しているのです。こレに対する策は、早期にメンバの背景、価値観、このプロジェクトでの開発スピード、品質状況、そして本人の性格を知る機会を作ることです。期待するロールに対して期待通りにアウトプットを出してもらいたいなら、その期待を明示し、その期待に応えられるかプロジェクト開始時点でサーベイするほかないのです。

アジャイルで言うとスプリントゼロのようなものだし、ウォーターフォールならプロトタイプや検証のようなタスクを活用してサーベイするのがいいでしょう。それでそれ以降のWBSに対して調整を掛ければいいわけですから。

でも、プロジェクト立ち上げ時にあれもこれもサーベイするのは現実的ではないかもしれません。メンバの数にも左右されるでしょう。そうするとなにがしかの基準で最低限確認しておきたい項目に絞ることが必要になります。

ワタシはアウトプット原理主義なので先のスプリントゼロでチームのベロシティを計ると言いつつ、チームのスピードに影響する事柄について選択するというようにしています。いつも言っている(と思う)けれど、明示するアウトプットの品質レベルが出せるかと作業のスピードです。この2つ観点でチームビルディングを進めていいのかどうかを考えます。この2つの観点はどちらも作業をしてもらうエンジニアのプロセスのフォローとアウトプットに対する品質の観点でとても手間が掛かるのでその手間をプロジェクト期間中耐えられるかと言う負荷の判断につながるからです。

でも、どっちか一つ選んで、と言われると、アウトプットの品質はプログレスやポイントごとに介入すればいいので割と心理的に抵抗は少ないです。作業をしてもらうスピードはそのエンジニアに100%依存するので介入することができない、実はこの時点にエンジニアの性格や価値観が紛れ込んでスピードに作用するのでそうしたパラメータもあるのですがそこはネグっても、作業のスピードって大事なぁ、と最近は特に感じます。

いや、スーパーカーみたいなスピードはいらないですよ。スケジュールに辻褄が合うとか、緊急時にダッシュが効くか、とかそうした程度です。おもに前者、でですが。