ソフトウェア開発で、より早くより多く価値を届けたいと考えた時、エンジニアの増員は有力な選択肢です。もちろん、人月の神話などで語られるように、人を増やしただけ線形に生産力が向上するというシンプルな世界ではありません。それでも多くの現場でエンジニアの増員が行われます。自分のチームでも、とりあえずエンジニアを増員すれば、いくつかの問題が解決してくれるような気もします。雑談ベースでメンターなどにこういう話を出してみるわけですが、改めて「なぜエンジニアを増員したいのか」と問われると、これが意外と広がりのある議論であることがわかってきました。本記事では、エンジニアを増員するロジックについて、自分が思考を広げられた範囲で書いてみます。
作り切りの場合は明快
まずエンジニア増員のロジックを素朴に立てられるのは作り切りの場合です。ある程度の規模のものを丸々作り切らないといけないケースです。締め切りがあることも多いでしょう。そうした要求に対して、現状のベロシティでは期待する期日に完成しないとなれば、何か手を打たなければいけません。スコープと期日から動かすのが定石ではありますが、それでもダメだとなれば、ベロシティがどれほど伸びるかわからないにしても、人海戦術に頼っていく必要があるでしょう。
この場合のロジックは非常に明快です。今のペースでは間に合わない、他のパラメータも全て切り詰めた、それでも無理なので増員してください、ということです。この場合はスポットの増員になることが多いでしょう。このパターンは伝統的な危険なやり方で、スポットで入ったひとの割合が多すぎると、作り切った後に残されたメンバーがひどい目に遭うかもしれません。チームに仕事が流れ込む形を維持できるのが理想ですが、苛烈なサバイバルプロジェクトにおいて、こうした綺麗事を言っている余裕はないかもしれません。
利益に着目すると難しい
継続開発の場合はもっと話が難しくなるように思います。まず初めに考えつくのはお金の話です。素朴には、増員による人件費の増加より、売上の増加が大きい期待があれば、その増員は投資として成立することになります。利益が増える期待があるなら投資したら良い、当たり前だと思います。
しかし、どれほどのサービスがこのロジックを立てられるでしょうか。継続開発ということは、サービスのコア機能は十分に揃っていて、機能の追加、改善、整理などを通してサービスを伸ばしていくフェーズにあるということです。この状況において、開発のスピードが上がるほど利益が増加すると主張できるのは珍しいケースだと思います。ベロシティ、施策のサイズとインパクト、ユーザー行動のKPI、売上といった一連のパラメータが密に接続され、予測可能でなければ説明できないからです。これは途方もないことです。
また、利益に着目するならエンジニアの増員は手段のひとつに過ぎません。システムとして売り上げが立つスキームが完成しているなら、エンジニアの人件費に投資するより、広告や営業に投資した方が売上の増加が期待できる場合も多いでしょう。「"利益を増やしたいから"エンジニアを増員する」は必然性がなく、もしかしたら背後に別の課題があるのを取り違えているのかもしれません。
システムの変化するスピードに着目すると……？
少し視点を変えて、システムの変化するスピードに着目してみましょう。ソフトウェアには常に壊れたり陳腐化する方向に向かっています。ミドルウェアは古くなり、かつて栄えた言語は気づけば落ち目になります。エンジニアはそれよりも速いスピードでシステムを進化させ続ける必要があります。さもなくば、競争力で負け、ユーザーが減り、優秀なエンジニアが減り、サービスは緩やかに死んでいきます。
そうならないように十分な投資をしたいと考えると、エンジニアの増員は有力な選択肢になります。スコープを動かすのが難しく、EOLやセキュリティパッチが迫ってくることを考えると期日もあり、システムを変化させられるのはエンジニアだけとなると、利益に着目した場合よりはだいぶロジックは強固に見えます。
この場合に難しいのは、品質のターゲットをどこに置くかということです。素朴に考えると、品質のターゲットを可能な限り下げて人件費を圧縮し、利益率を上げるのが短期・中期的には最適な戦略に見えます。その結果EOLがやってきたものから助け上げるようなメンテナンス体制になってしまいます。これが多くの現場の現実ではないかと思います。
この状況から脱するひとつの方法として、CTOなどが外から働きかけることが考えられます。素朴に考えると最低ラインに収束する品質ターゲットを、採用や技術ブランディング、グローバルなテクノロジーマネジメントの観点を入れて引き上げるということです。たとえば「全てのミドルウェアは最新のLTS以上のバージョンを利用する」といったことです。システムの品質、利益率、外部要請の3つでうまく綱引きさせることで、システムを積極的に変化させる道が開けないものかと考えています。
こうした取り組みを受け入れエンジニアを増員するには、当然そのサービスが余剰人員を張れる状態になければいけません。これ以上エンジニアを増やすと赤字になるという状況で、ミドルウェアのバージョンを上げるために人は増やせないわけです。それ自体が事業の健全性を測るものさしとなり、利益率の低い事業を潰していくことにつながるのかもしれません。世知辛いですね。
このあたりについては、現実には各チームで余剰人員を張るのは大変なので、コストセンター的にプラットフォームチームを組成するパターンも教えてもらいました。確かに、典型的なシステムの進化であれば、ドメインと直交する形で進められる可能性はあるなと思います。一方で、本当にやりたいのはドメインにベッタリくっついた難しいところなんだよな〜という思いもあり、まだまだどうしたら良いかわかりません。少人数で大儲けできてたら一番良いのですが……そんなにうまくはいきませんね……。
残りの議論とまとめ
以上のようなことを考えたわけですが、「増員」で思い浮かぶような急成長している企業がこういう細かい勘定をしている印象があまりなく（そういう会社にいたことがないので完全に憶測ですが）、もっと大胆に異常な増員をしているように感じるので、そこにどういうロジックがあるのかは純粋に気になりました。「作り切り」のロジックで急拡大させて、そのまま継続開発チームとして配置していく感じになるのでしょうか……？
何はともあれ、これまでよりは強固なロジックでエンジニアの増員について主張できるようになったと思います。ビジネスモデルや経営に絡む話のはずで、そういった方面に興味を持つきっかけにもなりそうです。引き続き考えていこうと思います。
