読者です 読者をやめる 読者になる 読者になる

開発リソース不足について思うこと

もしあなたがベンチャー企業に勤めているとしたら、まず間違いなく開発リソースが不足していると思います。多くのベンチャー企業において開発者は足りていないはずです。
 
おそらく多くのベンチャー企業というものは、売上が十分あるわけでもなく、資金が潤沢にあるわけでもなく、でも実現したい世界があり、そのために作りたいものがあり、作ったら今度は追加したい機能があり、追加したら今度は改善したい機能があり、また追加したい機能があり、改善したい機能があり、いつのまにか負の遺産があり、それを解決したい欲求があり、そんな中機能追加があり…という感じだと思います。
 
 
 
そんな中、経営陣や開発リーダーが口を揃えて言うのが、この有名なセリフ、
 
「開発リソースが不足しているから、採用を強化しよう!」
 
です。
 
 
 
このセリフ、一見何の問題も無いように聞こえるので異議を唱える人は少ないかもしれません。ですが、開発リソースが不足しているという問題を解決するための手段としては実は危険なのではないかと考えており、警鐘を鳴らす意味でこのポストを書いてみることにしました。
 
 
 
 
 
さて、人手が足りなくなりやすいというのは事実だと思いますが、ではどれくらい人手が足りなくなりやすいのかと言うとこれは自明ではないので、考えてみることにします。
 
 
まず、機能を追加開発することを考えます。機能は時間経過とともにどんどん増えていくもので、経過時間Tに比例して機能数が増えていくとすれば、機能数Nは
    N = aT (aは比例定数)
として表せます。つまり機能の実装にかかる総コストは、機能1つの実装に必要な平均的な開発リソースをFとすれば、
    NF
となります。これをTで微分すると、ある特定の瞬間において機能追加のために必要な開発リソースCが求まり、
    C = dNF/dT = aF
となります。
 
 
また、機能は作っておしまいということはほぼ無く、使われていく間に改善させていかなければなりません。ある特定の瞬間において機能を改善するために必要な開発リソースKはその時点で存在する機能数Nに比例するので、
    K = bN (bは比例定数)
と表せます。
 
 
つまり、ある特定の瞬間において新機能の開発と機能の改善に必要な開発リソースは
    C + K = aF + bN = aF + abT
となります。
 
 
言い換えると、開発開始(≒起業したタイミング)から時刻Tまでに必要な開発リソースは、上記を経過時間Tで積分して
    aFT + abT**2 (**2 は2乗の意)
となるわけです。
 
 
 
 
 
必要な開発リソースの総量の支配項が経過時間Tに比例するのではなく、Tの2乗に比例してしまうんですね。
 
 
 
これはどういうことかと言うと、「経過時間に比例した数の開発者を採用しなければ、開発リソース不足に陥る」ということです。
 
 
 
 
まぁとんでもなく回りくどい言い方をしましたが、簡単に言えば、
  • 機能数に比例した数の開発者が必要
  • 機能数は時間に比例して増える
  • つまり時間に比例した数の開発者が必要
ということです。
 
 
 
 
 
なので、2次関数を知っている人ならすぐに想像できるかと思いますが、あっという間に「やりたいことがたくさんあるのに全然追いつかない」という状況になります。負の遺産を解消する余力なんてあるはずもありません。機能を追加・改善しようと思ったら開発リソース不足になるのが当たり前なのです。
 
 
 
 
 
 
 
 
 
 
 
さて、ここでもう一度この発言を見てみます。
 
「開発リソースが不足しているから、採用を強化しよう!」
 
 
 
ちょっと見え方が変わっていませんか? まるでお風呂の栓を閉めずにお湯を入れている人が「お湯が足りないからバケツでもお湯を入れよう!」と言っているように聞こえませんか?
 
「忙しさの解決のためにはエンジニアを採用すべし」と盲目的に考えてしまうことが危険なことであるというのは経験的にもその通りだと思っていて、そういう状況下でエンジニアを増やして「あ~、忙しさが解消されたわ~。幸せだわ~。」って言ってる人を見たことが無いのですよね。
 
 
 
 
では採用強化じゃない方法で開発リソース不足を補うにはどうすれば良いのか?
 
 
これは上述の方程式の中での仮定のうち1つ以上を覆すしかありません。明示的にあるいは暗黙に何を仮定したかというと、
  • 機能数が時間経過に比例して増える
  • 全ての機能は改善する必要がある
  • 開発者がこなせる作業の量は一定である
  • 経過時間に比例した開発者数の確保は困難である
  • 比例定数aとbが小さくない値である
などです。
 
これらの仮定のいずれかが間違っていると断言することができれば開発リソース不足は解消できる可能性があります。
 
例えば2つ目の仮定が間違っていて、「実は改善する必要のない機能もある」とか。
 
例えば最後の仮定が間違っていて、「実はaとbは限りなく小さい値で、必要な開発者数は確かにTに比例するんだけど、その値が1を超えるのは10年後で、2を超えるのは14年後であるから、この先10年間は開発者は1人だけで十分」とか。
 
 
 
 
 
 
 
私見ではありますが、これらの仮定を覆すための方法が「リーンスタートアップ(機能数を時間経過に比例させず、改善に重きをおく)」だったり、「ピボット(機能を捨てることで、改善すべき機能の数を減らす)」だったり、「めっちゃ売り上げる(そして開発者数を時間に比例させて採用する)」だったりするのかな、と考えています。
 
 
 
 
 
 
僕個人としては、「機能数が時間経過に比例して増える」という仮定を覆すのが良いと考えています。「やるべきことを精査し、やらぬべきことをもっと精査する」というのが開発リソース不足解決のための第一歩で、極限までやるべきことを絞った上でその機能をリーンに改善していく、というのが最良なのではないかな、と。
 
 
もちろん、言うは易し行うは難しではありますが。
 


リーン・スタートアップ

リーン・スタートアップ

  • 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
  • 出版社/メーカー: 日経BP社
  • 発売日: 2012/04/12
  • メディア: 単行本
  • 購入: 24人 クリック: 360回
  • この商品を含むブログ (94件) を見る