ビルド対バイの意思決定をどのように行いますか?

Question

Accepted Answer

**ビルド対バイ**は、何かを社内で開発するか、既存の製品またはサービスを採用するかを尋ねます。構築する本能は強く、しばしば間違っています。構築の実際のコストは、最初のバージョンだけでなく、長年のメンテナンスを含みます。決定は、それがビジネスの*コア*であるかどうかにかかっています。

## なぜ重要なのか

```text
LEAN BUY when:                     LEAN BUILD when:
- It's NOT your core differentiator  - It IS your core value/differentiator
- A mature solution exists           - No good solution fits your needs
- Speed-to-market matters            - You need deep control/customization
- You lack expertise to maintain it  - Long-term cost of buying is prohibitive
- TCO of buying < building+upkeep     - Vendor lock-in is an unacceptable risk
```

## 具体的な例

独自の認証システムを構築してはいけません。アイデンティティは難しく、セキュリティ上重要であり、あなたの差別化要因ではありません。実績のあるプロバイダーを購入/統合してください。推奨エンジンが製品を特別にするものである場合は、コア推奨エンジンを*構築*してください。あなたを*あなた*にするものを構築し、残りは購入してください。

## 真のコストを数える

チームは構築を慢性的に過小評価します。最初のバージョンはライフタイムコストの20%です。メンテナンス、セキュリティパッチ、エッジケース、およびオンコールがそれを大きく上回ります。スプリントで配信できるデモではなく、数年にわたる総所有コストを数えます。

## 落とし穴

「ここでは発明されていない」は解決済みの問題を再構築することになり、盲目的な購入はベンダーロックインと適合しないツールにつながります。ケースごとに意図的に決定してください。

## なぜ重要なのか

社内で間違ったものを構築すると、差別化されていない作業に数年の エンジニアリングの努力が消費されます。

これを正しく行うことは、実際にビジネスを勝たせるものに希少なエンジニアリング時間を集中させます。