ってなんだろう、というのを考えている。
プロジェクトが肥大化・遅延して、もっと早くリリースするためにできることを探しているシチュエーション。
まず前提として、作るもののスコープを絞るというのがある。これは意識しているところが多いのではないか。 絞るのはいいけど、そのあと回収されるのか？みたいな不安や疑問への答えかたの方が難しい。
結局のところ、やりたいことが溜まっている状況では、スコープを切って順次リリースすることにしても、全部をやり切るのにかかる時間はあまり変わらない。 もちろん小さく分割された問題は不確実性が相対的に低くなるので、そういうメリットはある。 ここではもっと根本的な物量に言及しているつもり。
では次に何ができるか。採用で人を増やす。 ただし、人を増やして速くなるには、かなり良い条件が整っている必要がある。人が増えれば速くなるということは普通はない。
この条件を網羅的に言語化しきれればいいんだが、正直あんまりできる気はしない。 「並行に動かせるプロジェクトが明確にあり、人が増えれば単純に並行数が増やせる」みたいな状況は、人が増えると速くなる可能性がありそう。 ただし、並行で動かせるというのがまやかしでなく、本当に並行して独立に動かせる必要がある。 これは1プロダクト内だとそう簡単な話ではない。
そこで、多少のオーバーヘッドを許容することを考える。 手戻りなどのオーバーヘッドを許容すれば、並行で動かせるプロジェクトは増える。 オーバーヘッドが損益分岐点を下回らなければ成功だ。(ここでは人件費は一切考えていない。単に時間だけに焦点を当てている。)
オーバーヘッドといってもいろいろな種類のオーバーヘッドがある。 作ったものが想定と違って手戻りになる。一部のロールがちょっと暇になってしまう時期が発生する。最重要プロジェクトのスケジュールを後続のプロジェクトが喰い荒らしてしまう。
ここで大事なのは、自分たちの置かれている状況を鑑みて、どんなオーバーヘッドならどこまで受け入れられるのかを考えることだ。 このあたりは技術的負債と同じ考え方で、どんなコストを払ってどんな利得を得るのかに自覚的であることがまずは大切だ。
一部のロールが暇になるというオーバーヘッドは恐れる必要はなく、むしろガンガン受け入れるべきだと思っている。
というか、理想的には暇になることはオーバーヘッドですらないという世界を目指すべきだ。 開発者はみな自立してボトムアップに行動できるので、暇があれば改善をすればいい。 改善の対象は何でもいいが、典型的なのはコードの品質だろう。
これが当たり前にできる開発組織はかなり強い組織だ。暇がなければボトムアップな打ち手が実行されることは少なくなり、じわじわと首が絞まる。 自立したハイスキルな開発者で構成された開発組織においては、このオーバーヘッドは簡単に回収できるコストであり、トータルではやく開発することに直結する。
すこし話題が逸れたので戻す。 どういうフォーメーションで動き、どういうコストを払って、どう速度を稼ぐかは、チームやプロジェクトの内容によって大きく左右される。 そもそも人にはそれぞれに得意不得意があり、人数で簡単にカウントできるような仕事を我々はしていない。 大切なのは、その時々でベターな選択を、メンバーが自覚的に選択できることだ。
そのためには、プロジェクトへの深い理解とコミットメントを各メンバーがもつことが必要だ。 ひとつのプロジェクトに関わるメンバーが増えるということは、ここからやや遠ざかる力学がある。 ひとつのプロジェクトにたくさんの人を関わらせることのデメリットはここにある。 人を増やしてはやさを求めるなら、オーバーヘッドを受け入れて並行数を増やすアプローチしかないのではないか。
プロジェクトは並行させずにクリティカルなプロジェクトに集中せよというのが一般的なプラクティスで、それは正しいと思う。 もしこのプラクティスを優先した方が良いという状況になったとしたら、それが今の組織やコードベース、プロダクトの限界だと受け入れた方がいいのだと思う。 その場合、採用より内部のスケールアップに力を注いだ方がいい。リアーキテクチャとか教育とか。 これは暇を恐れない話にも繋がる。個のパワーが高く、個のパワーを阻害しない、というのが結局一番速い。
それはそれとして、採用には人を増やして開発をはやくする以上の目的があるので大切。
