大規模になれば足を引っ張るエンジニアが増えていく
「アップルは、600人のエリート社員を動員して2年足らずで『iOS 10』を開発し大成功を収めました。対照的に、マイクロソフトは10,000人もの社員を動員し、5年以上もかけて『Vista』を開発したにもかかわらず、最終的にサポートを終了することになったのです」
マイクロソフトを擁護するつもりはないけれど、これapple to appleの比較になっているのかぁ、と。 作っているのはOSで人員の規模となっているけれど。
なんでもそうだけれど、比較が出てきたら疑ってみることは習慣にしたほうがいいです。
成功の鍵はアサイメント
それで、なぜこの記事を引用しているかというと、プロジェクトチームの要となるロールにはキーパーソンを置けるか置けないかでそのプロジェクトは大体勝負が決まるのです。
言い換えれば、鍵はアサイメントです。
「えっ、当たり前じゃん」と思ったら、今いるチームの要となるロールがどの役割で、ロールにふさわしいエンジニアが配置されているかを思い出してみてください。
現実にはスキル又はスキルレベルのいづれかに不足点があることの方が多いいのです。これはプロジェクトの立ち上げタイミングである需要とエンジニアが前のプロジェクトからリリースされて供給されるタイミングがプロジェクトで必要とするロールのスキルとレベルと一致することは滅多にないことを物語っています。
需要と供給がなぜ一致しないか
いつもデスマとまではいかないけれど不安定なチームでプロジェクトを運営しているとするとどうしてそのような事態になっているかを考える必要があります。
エンジニアの需要はプロジェクトが立ち上がるからです。プロジェクトの目的を達成するために必要なプロジェクトのチームとしてのスキルセットとスキルのレベルが需要全てです。
そうした需要に本来であればチームとしてスキルセットとレベルをチームとして共有しなければなりません。
規模が需給の不一致を増大する
この要求されるチームの規模が大きくなればなるほど、需要側に応えるための難易度は難しくなるのは想像できるでしょうか。
冒頭のアップルの600人でさえiOSのエンジニアを集めるのは容易ではありません。ただ、アップルの社内であるからこそできることです。では、マイクロソフトの10000人の規模ならどうでしょう。優秀なエンジニアを自社で10000人も集めることはマイクロソフトでさえ難しいことは想像できます。
大規模になれば足を引っ張るエンジニアが増えていく
でも、600人だとしたらどうでしょう。10000人の17分の1です。17分の1であれば精鋭だけのチームとなった可能性は高いのです。アップルもマイクロソフトもどちらのエンジニアも優秀だと思うのです。それでもその中で選りすぐりのエンジニアでなければプロジェクトのアウトプットは目指すものとは違うものができてしまうのです。
これはチームとしてのスキルセットとレベルには程遠いエンジニアが混ざり込み、プロダクトのすべての過程においてレベルの低い方で物事の判断が引っ張られてしまっているのです。
この人数で開発できる規模だったらVISTAはどんなOSになっていたでしょうか。それはまた別の話ですね。
