経営視点 / 約20分

Build vs Buy: 自作するか、買うか

なぜこれを学ぶか

「エンジニアなら作れる」は落とし穴です。作れることと作るべきことは違います。認証・決済・メール送信…何を自作し、何をSaaSに任せるか。

判断の原則: その機能は事業の競争優位に関わるか？ 関わるなら自作（Build）、関わらないならSaaS等を購入（Buy）。決済・認証・メール配信は「差別化にならないが失敗が許されない」= 買う領域の代表です。

自作コストは開発費だけではありません。保守・監視・セキュリティパッチ・障害対応 の総額（TCO）で考えます。「1週間で作れる」認証基盤も、保守を含めると年間数百万円のコストになります。

SaaSにもリスクがあります: ベンダーロックイン、料金の変動、サービス終了。APIインターフェースを自社側に薄く持たせ、交換可能性を残す設計が賢明です。

「自分では選べない技術」への対応もこの文脈です。過去のBuild/Buy判断が今の制約を作っています。制約を嘆くのではなく、当時の判断の背景を聞く と学びになります。

重要ポイント

Build vs Buy を数値で判断する練習です。機能のオブジェクトを受け取り、それが 'build'（自作）か 'buy'（購入）かを判定する関数を書いてください。ルール: isCore（競争優位に関わる）が true なら 'build'、false なら 'buy' を返します。

function buildOrBuy(feature) // feature = { name, isCore }

模範解答（読んで理解したら、自力で書き直してみましょう）

function buildOrBuy(feature) {
  return feature.isCore ? 'build' : 'buy'
}

このレッスンの内容をどの程度理解できましたか？