外部委託で開発をするというときに EM が考えていること

外部委託して開発をするかというときにエンジニアリングマネージャーが考えていること

「外注して開発しましょう」それは通常は善意と共に、突然やってくる。 開発組織が忙しいことはわかっている。だから、手を煩わせず事業の成長をつくりたい。

あなたは、その相談を受けたエンジニアリングマネージャー (以下、EM) だ。さあ、何を考え、どのように回答するだろう？

この記事では、内製の開発組織の EM が外部委託しての開発を検討するときにどのようなことを考えるのか、とくにその単発での開発に限らず組織への影響をどのように考えるのか、そしていつ外部委託を活用すべきでどのようなときには利用することが問題となるのかを説明する。

想定読者としては、もちろん EM をやっている人や EM を将来やってみたい人を想定しているが、もしかしたら事業責任者や開発者経験の少ないプロダクトマネージャーの役にも立つかもしれない。

外部委託しての開発の可否について話す前に、まず開発組織の開発実施可否についてどのように考えるかを説明し、その中で実現手段として外部委託して開発をするということへどのように考えるかを説明する。

内製組織の投資判断

開発の投資判断は相対評価による優先順序付けが基本

投資判断をするというときに最も一般的な判断のやり方はROIによる判断だろう。それを実施するコストに対して得るものを計算して、得られるものがコストを上回ると想定できるのなら、やる価値があると考える。

これは開発リソースが無限に調達できるという仮定に立てば有効な考え方だ。しかし通常開発組織が置かれている状況はそうではない。常にやりたいことは自分たちのキャパシティを超えて存在している。そのため、そこには取捨選択が発生し、限られた中でなにをするのかを考えることが求められる。

こうした中で判断をしていくときに有効なのは、個々の妥当性の判断よりも生み出す価値の相対的な比較になる。全部やれるならやればよいが、そうではない。社内の開発能力というのは限界があり、その有限の中で相対的により効果的で価値のあることへ投資をしていく必要がある。なにかを選択した瞬間に比較すべきは人件費でなく、同時に捨てた別の機会なのだ。

保有するソフトウェア資産の数を少なく保つことが集中投資を実現する

そして、相対評価をするときには新しく施策として開始するものだけを考えるわけではなく、今保有しているソフトウェア資産を持ち続けるコストというのを中心に考えている。

現代のインターネットサービスの開発を前提にすると、作りきりで終わりという開発はほぼ存在しない。ソフトウェアの開発を継続するときには、そのソフトウェアについて熟知している体制が必要になる。ソフトウェアという資産と同時に、そのソフトウェアを開発することができるドメインの理解や開発資産の理解がある人やチームというのも組織能力を構成するコアの資産になる。この点は資産として見えにくいので、よく見過ごされるが組織にとってのケイパビリティとしてかなり重要な要素になっている。

保有しているソフトウェア資産を持ち続けるために必要なコストには、ソフトウェアを維持できるチームを継続することであったり、ソフトウェア自体を時間の経過に対して更新し続けることが含まれている。

そのため、保有するソフトウェア資産の数が増えることは組織のケイパビリティにとっては能力を分散させる要素が増えることを意味する。選択と集中というのはここでも重要で、重要なことを前に進めるためには開発組織のケイパビリティを集中的に投資したいと EM は考えるが保有するソフトウェア資産が増えることはこれに逆行する。

外部委託をして開発をすることをどう解釈するか

通常、ビジネスの視点から見るとソフトウェアの開発という行為は人件費・業務委託費と交換でプロダクト・ソフトウェアが手に入る取引に見える。外部委託もケイパビリティの選択肢の一つであることに間違いはない。ただ、そこで得られるものに対して、重要なものを毀損するかもしれないリスクをゼロに見込んでしまう。すると、残るのは得られるものだけだから、合理的に「あり」だろうという結論になりやすい。

さて、前段で説明した内製開発組織のロジックの中ではどのように考えるのだろうか。人件費・業務委託費と交換でプロダクト・ソフトウェアが手に入る取引であることに間違いはない。

それはつまり将来の保有するソフトウェア資産が増えることを意味する。保有するソフトウェア資産の数が増えることは開発組織にとってはケイパビリティの分散につながるのであった。ここで問題になるのは、将来のケイパビリティの投資の分散を踏まえてもやるくらいに重要な開発なのかだ。

開発組織の投資判断は相対比較だと説明をした。今外部委託で開発をしようとしているものははたしてその最重要グループに入っているだろうか。ここで、冒頭の外部委託をしたいよくある背景へ戻ろう。

「外注して開発しましょう」それは通常は善意と共に、突然やってくる。 開発組織が忙しいことはわかっている。だから、手を煩わせず事業の成長をつくりたい。

内製の開発組織を持ちながらあえて外部委託して開発をしたいという場合、それは内製組織を投入して開発をしたい中心の案件ではないことが多い。

ここがもっとも重要な点になる。この記事のテーマに反して、実は重要なことは外部委託をしての開発の是非ではない。重要なのは、本当に重要だと評価をしていない施策を実行することの是非なのだ。そのため、最初に EM が聞き返すべきは「それは本当に重要なのか」「重要なのだとしたら、他の何とトレードオフで優先できるのか」であり、最初の回答は「重要なのであれば、内製組織での投資を含めてどのように実現できるかを検討する」となる。

そこで二の足を踏むような施策を無理に手を出すことは保有するソフトウェア資産が増え、将来のケイパビリティの分散へつながる。やめよう。

ここまでが原則で考えたときに EM が外部委託の相談をされたときに頭で考えることだ。もちろん、個別の事情や状況というものは存在し、この前提の上で都度考えていくことになる。

詳細のトピックについての補足

続きの記事では、よくある疑問や反論を取り上げて内製組織を投資するには至らない場合に外部委託で実現をトライするときに起きる問題について細かな補足をしていく。

たとえば、「レビューや契約でガードをすることで問題を避けることができるか」や「寿命を限定するなど、ソフトウェア資産をいずれ捨てるなら問題はないか」といったトピックについて説明をする。

最後にここまで読んでもらうとわかると思うが、外部委託で開発をすること自体に是非はない。良い開発会社とうまく開発をやっていくのなら、外部委託であってもよいソフトウェア開発をすることはできるし、そうでない場合には問題も起きるというだけの話だ。