楽天的なアントレプレニア
僕らディベロッパーが何かの開発を依頼されるとき、開発内容の説明を受けた後、大抵いつまでにできるかと見積もりを答えなくてはならない。僕はこれが、ディベロッパーをやっていて、一番いやな作業の一つだ。できるならそういう見積もりは誰か別の人がやってほしいと思う。
開発者が10人以上いるような大きなプロジェクトなら、見積もりはプロジェクトマネージャがやるのが普通なので、チームのメンバーの一人としてプロジェクトに参加していたとして、見積もりを要求されることはあまりない。大きなプロジェクトの場合、個々のディベロッパーの能力の差はかなり大きいだろう。それにもかかわらず、プロジェクトマネージャが「独断と偏見」で見積もりを立てて、それが結構正確にできてしまうのは、なぜか？
これを読んでいる人なら、直感的に理解していると思うが、統計学で「中心極限定理」といわれる法則があるからだ。個々のディベロッパーごとにかける時間のばらつきがあっても、全体でかける時間のばらつきの平均はディベロッパーの平方根に逆比例するという法則だ。つまり、10人のディベロッパーがいるプロジェクトで、見積もりを出したとして、プロジェクト全体としてかかる時間のばらつきは、10の平方根、つまり大体一人一人のディベロッパーがかける時間のばらつきの3分の1ぐらいになる。
プロジェクトマネージャがマネージャとしてやっていくための能力として重要なものは、何かの開発案件を与えられて、それを実装するための作業量をかなり正確に推定できることだと思う。そして、その能力を使って、プロジェクトマネージャはチーム内の平均的レベルのディベロッパーなら、これくらいの時間で作業を完了できると見積もれる。そして、多様なレベルのディベロッパーで構成されるチームで作業を行うとしても、このように、平均的レベルのディベロッパーを前提として見積もりをたてる方法でも、中心極限定理のおかげで、かなり正確に見積もれるのだ。
さらに、世の中には、いろいろと見積もりの取り方の方法論がある。プログラムステップ法、ユースケース法、ファンクションポイント法、画面数カウント。僕の考えでは、どれもこれも考え方は同じで、開発する対象をできるだけ小さなサブユニットに分けて、それぞれを別々に「独断と偏見」で見積もり、後はそれを足し合わせるだけ。違うのは、サブユニットに分ける方法だけ。それぞれのサブユニットの個々の見積もりを単独で見ると、かなりの誤差があるだろう。しかし、ここでも、すべてを足し合わせてやると、中心極限定理が効いてくる。結果、かなり正確な見積もりが可能になる。
ところで、僕が今までに従事した開発プロジェクトで、メンバーが5人以上いるようなものは実はそれほどないし、大体はリーダーとしてのプロジェクトへの参加だった。結果、僕自身が見積もりを立てなくてはならない。小心者の私は大体、過小見積もりしてしまう。小心者なら、マージンを付けて多めに見積もりしそうだと思う人もいるかもしれない。だが、とにかくその場をしのぎたい一心で、僕に見積もりを聞いているボスをハッピーにさせようという感情が働き、過小見積もりしてしまうのだ。
「その場」と書いていることから分かるように、僕が見積もりを聞かれる現場は、現場での口頭ベースであることが多い。例えば議事録なども取らないようなインフォーマルな現場。そういう現場が僕にそういう反応をさせてしまう。取りあえず、この場でボスをハッピーにさせておけば、後に、多少「その場」でいった期間より、多くの期間がかかると分かったとしても、忘れているだろうと。
最近気付いたが、このような、その場しのぎのいい加減な僕のやり方で、今まであまり問題になったことがない。これについて、よく考えてみた。今までに僕が開発に関与した現場は、ほとんどがスタートアップの『いけいけどんどん』だったから問題がなかったのだと思う。スタートアップをやろうと思うような人は、超楽天的でなければできない。過去の失敗にくよくよするような性格の人には無理だと思う。
何かのサービスなり製品を作ろうと考えるとき、そんなもの売れるわけがないとか、作れるわけがないとか、できる前に競合他社にマーケットをもっていかれてしまうとか、そんな悲観的なことは考えない。とにかく、そのサービスや製品は絶対に市場に受け入れられると信じ込める人でなければいけない。そういうボスなので、多少の見積りのずれも気にせず、許してくれるのかなと思う。まー、僕の今までのシステム開発で、時間的には多少後ろにずれることはあったかもしれないが、すべて高品質で、かつフレームワークがしっかりしていてエンハンスしやすく、変更に強いシステムを作ることに最終的には成功してきたので、問題なかったのだろう。