ボクココ

サービス開発を成功させるまでの歩み

エンジニアの生産性は人数で変わるのかについて

ども、@kimihom です。

“エンジニアの人数とプロダクト開発の生産性は比例しない” とよく言われる。実際私はこれは正しいと思っていて、今まさに1人エンジニアで高い生産性を実現している。本記事では人数とプロダクト開発の関係について自分の考えをまとめてみる。

1人なら開発以外で必要なあらゆることが省略できる

開発と言ってもたくさんの"決めごと"が必要になる。設計やレビューは特にその中で大切なものとして扱われる。人数が多ければ多いほど、設計書を事細かに書くことは重要だ。そして設計書だけでなく、コミュニケーションロスによって設計者が意図したものがそもそも完成しないということも頻繁に発生してしまう。人数が多いと、開発する能力に加え、相手に正しく設計の中身を正しく伝え理解する能力が求められる。

おっと、ここで1人で開発すれば設計能力が不要になるということではない点に注意だ。1人でも正しく設計する能力は当然求められる。しかし、それをドキュメントに事細かに書き起こしたり、合意形成をとったり、ドキュメントを正しく読んで実装するといった作業は不要になる。自分の書いたメモやページを元に構築していけばいいので、そのあとのあーだこーだいう時間を一気に省略して一番大事な「開発」に取り組み始めることができるのだ。このように、開発スタート時点で大きな差が生まれる。

レビューやペアプロなど、1人エンジニアの環境ならそもそも不要だ。経験豊富なエンジニアはどこにどんなコードを書くべきかわかっているし、もし途中で間違えたとしてもすぐに修正していくことで 、そもそも 問題が発生しにくいコードを書くことができる。誰かからとやかく言われるレビューやペアプロと違って、自分が身をもって経験した失敗なので、自分のスキルとしてどんどん蓄積していくことができる。"コードを書くことでプログラミングを学ぶ"のだ。当たり前のことだけど、経験豊富な人がプログラミングをしないようなケースが増えてきているように感じるのであえて書いてみた。

コードを書かないエンジニアはただのエンジニアだ。

例えばプロジェクトの途中で仕様変更があったとしよう。1人で全てを作ってきたエンジニアの場合、システムの全てをコードレベルで把握しているため、どこをどう直すべきかが一瞬で頭の中で組み立てて修正を始めることができる。実際にそのような素早い修正能力は、特に生産性において重要なことだ。人数の多いチームで見たこともないソースがあちこち出てくると、どこをどう直すべきか、開発した1人1人が話し合わないといけないし、その度に今まで蓄積したドキュメントを更新しないといけないし、修正した分をレビューしなければならない。どちらの方が素早く行動できるのか、一目瞭然だろう。

人数の多さでプロダクトの質はどう変わるか

人数の多さは開発効率以外にも影響を受ける場合がある。プロダクトそのものの質だ。

少人数で考えられたプロダクトは、最初に作ろうとした思いやターゲットが明確に浮かび上がっている。そんな思いがなければそもそも作り始めることすらできなかったことだろう。

しかし、人がどんどん増えてくると開発当時の思いを持った人が少なくなってきて、"とりあえず便利そうな機能作る" 程度のプロダクト開発メンバーが揃ってきてしまう。途中から増えてきた社内メンバーであるエンジニアやデザイナー、PM は、サービスに対する思いを実現するよりも目の前の仕事をこなして給料を得るという考えに至る人が出てくる。

てなるとプロダクトは人数に比例してどんどん Fat になっていって、誰のためのサービスだかわからなくなる。たとえ人数が増えて多少開発効率が上がったとしても、プロダクトが改善されていかなければ、その時間とお金は無駄になる。実際そんな無駄に人が多いプロジェクトで失敗することは、何回かプロジェクトをやってきたことのある方なら1度や2度あるはずだ。

それでも大人数で上記課題をクリアできる方法がある。"独裁者レベル" の決定権を持つ人が指揮をしていく方法である。その独裁者の"思い"が完全に詰まったプロダクトでなければ、ゼロからでも作り直させる。従業員はとても辛いことだけど、それくらいの独裁者でなければプロダクトは中途半端に仕上がって、市場に誰も受け入れられない結果を招くことになる。そんな独裁者レベルの人の企業に務めるエンジニアってのは完全に奴隷みたいなもんで、上から言われたことを100%守らないといけないような、そんな辛い仕事が待っている。それは確かにサービスを成功させる上で大事なファクターではあるんだけど、そもそも仕事に辛さが出てしまうようでは何のために働いているのかもわからん状況が生まれてしまう。

だからこそ、少人数で意思決定できるくらいのスモールチームが今後より求められてくると思う。少人数のチームならそんな意思決定を一人ひとりができるし、誰か他人によってそれが折り曲げられたり言いづらかったりすることが発生しない。それでいて自分から作りたい理想のプロダクトを磨き上げることができるので、運営元もユーザーもハッピーになれるプロダクトが生まれる。

そんな訳で、少人数で開発することでプロダクトの成功確率も上がると私は考えている。

終わりに

今回の記事は、私が今まで経験したプロジェクトの中でどのプロジェクトが良くてどのプロジェクトが悪かったのかを振り返って、人数の大小は大きな影響を与えているという思いから書かれたものである。

大人数のプロジェクトしか経験したことない方は、ぜひ少数のチームでやってみてほしい。逆に少数のチームでしかやったことない方は、大人数のプロジェクトを一度でも経験してみるといいと思う。そうすれば今回の記事がどうだったのかを身をもって体験できることだろう。

今回の話は「優秀な」少人数のエンジニアという前置きを置いている通り、優秀でない限り当然開発効率は落ちる。優秀になるためには、とにかくプログラミングをし続けて経験するしかない。だからエンジニアは開発手法に頼ったりしないでプログラミングをするということを意識していってほしいなと思う。

さてプログラミングを、はじめましょう。