エンジニアの時間の機会費用：自作するか、既製品を購入するか

「自分で建てるか、既成の物件を買うか」という決断は、往々にして最初から誤った比較に基づいて議論されることが多い。一方には毎月のサービス料金の請求書があり、もう一方にはゼロという数字がある。というのも、自分で建てる場合は「チームの時間しかかからない」とみなされるからだ。 その「時間」こそが、コスト計算の中で最も高額な項目なのです。ただ、誰もその「時間」に対して請求書を送ってこないため、どこにも計上されていないだけなのです。

この記事では、単純な試みを行う。その期間に価格を設定し、明確な仮定に基づいた5年間のモデルを構築し、その数字が何を示しているかを確認する。どのモデルにもどこかしら誤りはあるが、誤りが明確に見えるモデルの方が、検証できない誤った直感よりはましである。

まず、エンジニアの時給はいくらですか

単に時給を労働時間で割ったものではありません。エンジニア1時間あたりの実際のコストには、給与、保険、機器、デスク、ソフトウェア、採用、管理費が含まれます。そして最も重要なのは、コードを書かない時間、つまり会議、面接、休暇、資料の閲覧、レビュー待ちなどの時間です。 一般的な換算方法は、総給与の1.5倍から2倍を、出勤時間ではなく実際の労働時間で割ることです。

具体的な数字は場所によって異なりますので、私が代わりに推測することはしません。ここからはすべて「エンジニア時間」で計算します。最後のステップで、ご自身の単価を掛け算してください。

5カ年計画

あるシステムについて、当初の見積もりが「2週間で完了」――つまり80時間――だったと仮定する。これと並べて、同じ機能を持つ既製のサービスを比較してみる。以下の仮定に基づく：

360時間という数字は、自社開発案を貶めるためにでっち上げたものではありません。後ほど、これを項目ごとに分解して説明します。また、年間72時間の保守作業は、初期開発コストの20％に相当します。これは、稼働中の社内向けソフトウェアでは一般的な水準です。

損益分岐点、そしてその感応度はどの程度か

2つの曲線の間の距離は、60ヶ月間で496時間、つまり毎月約8時間分のエンジニア作業時間に相当します。これが損益分岐点となる価格です。上記の仮定条件下では、月額8時間分のエンジニア作業時間よりも安価なサービスであれば、自社で実施するよりも外部委託した方がコスト面で有利となります。

一般的なインフラツールの大半において、毎月8時間のエンジニアの作業時間は十分に余裕のある時間です。だからこそ、「自分で書けば安上がりだ」という直感は、これほど頻繁に間違っているのです。

しかし、モデルがどこで破綻するかを把握して初めて、そのモデルは信頼できるものとなる。仮定を一つずつ変えてみよう：

最も注目すべきは最後の行です。上記のモデルは、賃料が固定されていることを前提としています。多くのサービスは利用量に応じて課金されるため、初年度に契約した料金が、4年目にも同じままというわけではありません。

なぜ「2週間」が360時間になるのか

「2週間で完了」という見積もりは、実行可能なバージョン――デモとして機能し、処理フローが正しく、データが整っているもの――については、ほぼ常に当てはまります。それは間違いではありません――ただ、あなたが尋ねている質問とは別の質問に対する答えなのです。

その差は、見積もり会議では誰も言及しないような事柄にある。たとえば、不完全なデータ、ユーザーがボタンを2回押してしまうこと、悪意のある者が悪用を試みること、権限の割り当て、午前3時に何が起きたかを突き止めるのに十分なログ、そして他の誰かが手を出せるようなドキュメントなどだ。 そのどれもが面白くはないし、だからこそ、どれも見積もりには盛り込まれなかったのだ。

大雑把だが使える修正方法：当初の見積もりに3を掛ける。これは技術者の見積もりが不正確だからではなく、質問が体系的に誤解されていたためである。

上記の4つのモデル項目は含まれていない

待機コスト。9ヶ月間開発に費やすということは、その機能が9ヶ月間リリースされないことを意味する。もし開発中のものが収益源の妨げになっているなら、実際のコストは360時間だけではなく、360時間に加えて9ヶ月分の収益の遅れも加わるのだ。

調整にかかるコスト。独自に記述したコードはレビューが必要であり、担当者を配置する必要があり、アーキテクチャ会議への出席が必要であり、ライブラリのアップグレード時にその存在を誰かが覚えておく必要があります。このコストは、コード行数ではなく、チームの人数に応じて増加します。

セキュリティとコンプライアンスの観点。自作の認証システムとは、自分でパッチを当てなければならない認証システムのことです。業務が何らかの基準に関連している場合は、その準拠性も自分で証明しなければなりません。

撤退コスト。この項目は双方に存在し、最も見落とされがちなものです。既成のサービスを解約するにはどれくらいの費用がかかるのでしょうか？他の10カ所に深く根付いた自社開発システムを廃止するには、どれくらいの費用がかかるのでしょうか？この問いは極めて重要であり、独立した軸として取り上げる価値があります。

決定の枠組み：2つの軸、1つではない

よく言われるアドバイスとして、「これが顧客に当社を選んでもらう理由になるか」と自問することが挙げられます。この問いは良いものですが、それは半分に過ぎません。残りの半分はこうです。「もし3年後にこの決定が間違っていたと判明した場合、それを撤回するのにどれほどのコストがかかるか？」

最も危険なのは右上のコーナーです。一見何の違いもないように見えても、あなたをきつく縛りつけてしまう要素があります。決済、認証、データストレージです。 「コア部分じゃないし」と軽く考えて購入してしまいがちですが、3年後にはシステムの半分がそのベンダーの言語で書かれていることに気づき、もう切り離せなくなっていることに気づくでしょう。この領域では、購入すること自体は正しい選択であることが多いですが、コストがまだ低い初期段階で、最初から独自のインターフェース層を間に挟む必要があります。

「既製品を買う」という選択が間違いだったとき

よく見られる4つの失敗パターン（頻度の高い順）：

• 根を下ろしてしまったら、条件は変わってしまう。去ることができる立場にある人間として交渉することはできない。
• 規模が計算式を覆す。サービスの価格モデルは、平均的なユーザーを想定して設計されている。その水準を超えれば、もはや必要のない利便性に対して金を払っていることになる。
• プロバイダーが事業方針を変更したり、姿を消したりする。製品が買収されたり、廃止されたり、あるいは別の顧客層向けに転換されたりする。
• あなたのニーズは、彼らが販売しているものから徐々にずれていきます。そして、その製品を回避するためにコードを書き、結果として当初の利点を自ら失ってしまうのです。

正しく自作すれば、コアでなくても

2つの公開例は、いずれも逆算が成立する規模のものだ。

Dropboxは2015年から2016年にかけて、ユーザーデータの大部分をAmazon S3から自社構築のインフラへ移行しました。同社のIPO目論見書によると、その後の2年間で約7,500万ドルのコスト削減が実現したとのことです。 ストレージは、顧客がDropboxを選ぶ主な理由ではありませんが、その規模では、1テラバイトあたりの数パーセントの差が、チームを構築するコストを上回るほどの大きな金額になります。

37signalsは2022年から2023年にかけてクラウドから撤退し、年間約200万ドルのコスト削減を実現したと発表しました。同社はまた、その条件として、負荷が比較的安定しており、運用チームは小規模ながら優秀で、急激なスケール調整の必要がないことを明言しています。

共通点は「自分で建てた方が安くなる」ということではありません。共通点は、両者とも、何が必要かを正確に把握できるまで、既成品を購入する選択肢を十分に検討した上で、ようやく建設に着手したという点です。これこそが正しい順序であり、これは、自己建設を決断する大多数の人々のやり方――つまり、先に建ててから理解しようとする――とは正反対です。

二分法が見落としている第三の道

• オープンソースを自社で運用する。購入も、開発も不要だ。制御可能でロックインされないが、その代わり、運用は自前で対応しなければならない。これは通常、「購入か自作か」という議論で見落とされがちな空白の領域である。
• 購入して再ラッピングする。サービスを利用するが、独自のインターフェース層を介して呼び出すだけだ。初期段階で数日余分にかかるが、プロジェクトからの「撤退コスト」を1週間分の作業に換算できる。
• 先に購入し、後で開発する。真のニーズが明確になるまで既製品を利用し、その後で構築するかどうかを決定する。これこそが、Dropboxや37signalsが実践してきた手法だ。
• 既製品の上に薄いレイヤーを構築する。差別化を図る部分は自分で担当し、退屈な部分は他人に任せる。

チームの規模による計算の変更

一人で作業する場合、機会費用はほぼすべてを占めます。サブシステムに費やす時間はすべて製品開発に充てられない時間であり、メンテナンスを担う人も他にいません。購入すべき閾値は、直感よりもはるかに低いはずです。

数十人のチームとなると、連携にかかるコストやメンバーが離脱するリスクが浮上してくる。たった一人しか理解できない独自開発のシステムは、いつか返済期限が訪れる負債のようなものだ。

大規模な組織になると、その規模がすべてを覆し始める――そして、まさにその段階になって初めて、新しい内部システムを運用するための専門チームを立ち上げることに意味が生まれる。

それを再検討可能な決定にする

「買うか、作るか」という決断の多くは一度下されると、誰も見直そうとしないが、その決断の前提となる仮定はすべて変化していくものだ。この状況を改善するのに役立つ、3つの手軽な方法がある：

• 決定時の仮定を記録しておく――所要時間、レンタル料金、使用予定年数など。一文で十分だ。
• 実際のメンテナンス時間を計測してください。計測しなければ、その20％という数字が自分にとって正しいか間違っているか、決してわかりません。
• 12ヶ月後に見直しを行うスケジュールを組んでください。変更するためではなく、仮定と現実を照らし合わせるためです。これこそが、次回の見積もりを今回よりも正確にする唯一の方法です。

まとめると

自社開発は無料というわけではありません。単に請求書が出ないだけです。エンジニアの労働時間に換算し、5年間にわたって計算すると、損益分岐点に達するレンタル料金は、直感的に思うよりもはるかに高くなるのが一般的です。上記のモデルでは、月に約8時間のエンジニア労働時間に相当します。

しかし、その数字そのものよりも、それを生み出す習慣の方が重要です。時間に価値をつけ、仮定を明確にし、差異の軸の横に撤退コストの軸を追加し、見直しの日程を決めておきましょう。決定が間違っている可能性は依然としてありますが、5年間にわたって知らぬ間にコストが膨らんでいくのではなく、気づける形で間違えることになるでしょう。