プロジェクトの要件や仕様の複雑さと開発の複雑さは必ずしも1対1ではないと思っている。なので、複雑だからビッグバンリリースしてもしょうがないよねと言っている開発メンバーを見かけるとモヤモヤする。
まとめて開発しないと意味がないと言われたりするが、深堀りしてみるとそうでもないことが多い。単純に提供したい価値が100%の状態にするにはその方法しかないだけだったりする。そうすべきかどうかは状況次第で、短期間で50%の価値を提供できるならそれで良い、ということもありえる。そういうオプションを持っている人と持っていない人で意思決定の方針が変わりそう。
もちろん、公開時のインパクトだったり、ユーザのフォローのコストだったりで一概にそうとは言えないかもしれない。ただ、機能の公開とデプロイは別の話なので、やはり開発タスクの分割を実施しないのは悪手な気がしてる。
複雑と感じるタスクには
- 複雑なもの
- 複数のものの組み合わせで巨大なもの
の2種類がある。そして後者は適切な判断によって複数の単純なタスクに分解できる。
複雑かそうでないかを判断するには、適切な選球眼を身に着けていなくてはならない。自分が課題分割を勧めて、次から改善できる人と何回注意しても変われない人がいるのは、単純な注意力の違いではないからだと思う。
まれに巨大なスコープをやり遂げる人もいるが、かなりその人のスキルに依存するので再現性がない。分割しないと必ず失敗するというわけでもないため、それで成功体験を積んだ人も一定数いる。指摘しても課題感を共有できないので、こういう人と仕事するのは難しい。
結局、チームで安定して高いクオリティのアウトプットを出し続けるためには課題分割のスキルがかなり重要。ただその意思決定はPMだったり自分がいない別部署のMTGだったりして、開発者は知らぬ間に振り回されることが多い。
自分の経験上、課題分割 のスキルが無いのに課題解決を指示する立場になった人は、自分ごととして学ぶ機会が減るので後からそのスキルが身につくことは少ない。過去に何度かそういう人と一緒に仕事をしたことがあるが、改善を期待できない以上は自分から離れるしかないなと割り切り始めている。
