プログラミングで人が多ければ良いは通用しません
こんにちは、本間です。
今回は工数という考え方について考察します。私はもとより、ほとんどのエンジニアはこの考え方を好んでいないように思われます。それはタイトルにある通り、人が多ければその分早く終わるとは限らないためです。優秀でないエンジニアを多数入れるということは、メンテナンスしづらい(バグを含む)コードを生み、かえってプロジェクトを遅らせる原因にもなるためです。
優秀なエンジニア1人 > 普通のエンジニア10人
10人必要な工数のプロジェクトで最も早くできるのは、10人のうち最も優秀な人が1人で設計し、開発することです。あくまで単一のシステムを作る場合は最も優秀なエンジニアが全て頭の中に入った実装を実現する手段が最も早く、そして品質の良いものができあがります。それは誰とも相談や承認を得る必要がないし、どこのコードがどこに影響が出るなど全て頭の中でイメージさえできていれば良いからです。その一人さえ分かっていれば設計書を書く必要もありません。
複数人で開発すると、合意を取りながら開発することになります。これが非常に時間のかかる作業です。あーでもない、こーでもない、と言い合っている間に一人で開発する場合はもう着手し始めています。優秀なエンジニアは正しい設計が一人でできるために、そうした時間は必要ありません。
そして何より複数のエンジニアが入ると、一貫した機能や思想をサービスに反映することができません。たくさんの人の思いが入ってしまった多機能なサービスはいいサービスになりにくい性質を持っています。
“これできます？”とか”これどのくらいかかります？”という質問
ありがちなエンジニアとビジネスの人との会話を例にして、より良いエンジニアのプロジェクトの立ち位置を考えてみます。
まず「これできます？」という質問はエンジニアにはあまりしない方がいいように思います。正直な所、どんだけ時間をかけてもいいならできないことは余程のことでない限り、ありません。むしろそのような質問の時は大抵できることが多いです。ただ、気が乗らないとかそんなことに時間をかけても仕方がないとエンジニアが思っていた時は回答に困ります。どう答えようか色々考えていると曖昧な答えになって、聞いている側も「どっちなんだよ」と思ったりしてお互いがアンハッピーな感じになります。
「どのくらいかかります？」は先ほどの課題を解決するにはいい質問で、エンジニアも普通に答えを返すことが多いです。ただし、やる価値がないと思っている内容に関してその質問が来た時に返答が困ることになります。むしろこの質問はやる前提で聞かれているため、やりたくないと言わせない感があってエンジニアを困らせる原因の一つとなります。
エンジニアを企画段階から入れるべき
上記の工数や聞き方の話を踏まえて、私は少数のプロジェクトを組み、エンジニアを企画段階から入れるべきだと考えます。その段階ではまだエンジニアの意見を言うことができる段階です。決まったことだからやってと言われてやるエンジニアは大抵モチベーションが低いし、やらせれる感があっていいプロダクトができない可能性が高いです。
特に新しいものを最初に作ってリリースした際に、エンジニアこそが何が良くて何が悪いアプリやサービスなのかは使ってみてすぐにわかります。本当にいいものであったら それは Slack のように大成功を生むプロジェクトになる場合があります。
これもエンジニアが納得した上で作らないと、このような素晴らしいプロダクトは生まれることはありません。
言ったことをただ作ってくれる人、くらいなイメージで仕事を振るようなことだけは避けた方がいいと感じています。プログラミングは人が多ければ良いというほど単純なものではないのですから。
P.S. ここまで書くと私が優秀なみたいな感じに見えてしまうかもしれませんが、決してそんなことはなくて、そうなろうと努力している最中だということをご承知ください。