「これ、自分たちで作りますか。それともSaaSを入れますか」
チームの技術判断で、いちばん後戻りしにくいのがこの問いでしょう。
作れば自由が手に入り、買えば時間が手に入ります。
どちらにも理屈が立つので、議論は好みの押し付け合いに滑り落ちやすいものです。
判断を人の好みから引きはがすために、先人が置いた軸を二つだけ持っておくと足場になります。
その機能は競争優位に効いているか
最初の軸は、機能が事業の差別化に効いているかどうかです。
Martin Fowler は2010年の記事「Utility Vs Strategic Dichotomy」で、ソフトウェアをユーティリティ（utility）と戦略的（strategic）の二つに分けました。
ユーティリティは、給与計算のように「やらないと会社が回らないが、競合との差にはならない」領域を指します。
戦略的なのは、競合より優れている理由そのものを担っている領域です。
前者は買い、後者は作る、というのがこの分け方の結論でした。
この分類は、技術的な難しさを基準にしていません。
社内で最も高度な作りをしている仕組みが、事業から見れば単なるユーティリティということは普通に起こります。
なお同記事は、戦略的と呼べるのはおおむね5%程度だとも書いていました。
作らなかった場合、その時間を何に使えるか
二つめが機会費用の軸になります。
AWS のアーキテクチャブログは「事業を差別化するソフトウェアを作り、それ以外は買う」という原則を紹介したうえで、判断には経済学の機会費用が大きく関わると整理していました。
Let's Architect! Understanding the build versus buy dilemma（AWS）
見落としやすいのは、比べる相手がライセンス費用ではないことです。
内製の本当のコストは初期開発だけでなく、運用・障害対応・仕様変更・人が抜けたときの引き継ぎまで含めた総額です。
そして同じ人員を戦略的な領域へ振り向けていたら何が進んだのか、という手放した未来のほうが本命の比較対象になります。
「作れるか」と「作る価値があるか」は、別の問いとして扱うべきでしょう。
買うと決めたら、業務のほうを寄せる
買う判断で最もこじれるのが、導入後のカスタマイズです。
Fowler は、ユーティリティ領域ではパッケージを買い、業務プロセスのほうをソフトウェアに合わせるべきだと書いていました。
ユーティリティのパッケージを大幅に作り込むのは、自前で作るのと同じくらい無駄だ、という指摘も添えられています。
差別化していない領域で自社固有の手順を守り続けても、そのこだわりは競争力に変換されません。
逆に言えば、業務を寄せられない領域なら、そもそもユーティリティではなかったのかもしれません。
この裏返しは、導入前の判断を見直す材料としても使えます。
比較表より「戻れるか」を先に見る
比較表を作ると、機能の丸の数で決めたくなります。
けれど実務で先に確かめたいのは、次の3点のほうでしょう。
- 撤退の道: データを自分たちの形式で取り出せるか、移行にどれだけかかるか
- 接合部: 自社の認証・権限・既存データとどこで噛み合うか
- 責任の所在: 落ちたとき誰が復旧し、誰が顧客へ説明するか
機能差は時間とともに埋まりますが、取り出せないデータと、説明できない障害は埋まりません。
そして決めた理由は、比較表ではなく記録のほうへ残しておくことが大切です。
半年後に「なぜ買ったのか」を説明できる状態にしておくと、揺り戻しの議論が短く済みます。
最後に
作るか買うかの判断は、技術の好みではなく事業の差別化と機会費用で決まる問題でした。
差別化しているなら作り、していないなら買って業務を寄せます。
そして買う側では撤退の道と責任の所在を、作る側では運用まで含めた総額を先に見ます。
私もテックリードを目指して学んでいる側なので、この2軸を口に出して確認するところから始めたいと考えています。
以上です。
コメントを残す