ソフトウェアの内製か購入か：ビジネスリーダーのためのコストとリスクのフレームワーク
新しい運用プラットフォームの評価を始めて三週間が経ちました。二社のベンダーから立派な提案書が届いています。エンジニアリング責任者は「これくらいなら数か月で自分たちで作れる」と繰り返し言います。CFOは金曜日までに数字を出せと迫っています。そしてあなたの頭のどこかには、以前あるチームが「数か月」と約束したまま十八か月に及ぶ書き直しに沈み込んでいった記憶が残っています。まさにこの瞬間こそ、ほとんどの内製・購入判断が実際に決まる場面です。スプレッドシートではなく、肩をすくめる仕草と締め切りによって。だからこそ、その判断の多くが誤った方向に進んでしまうのです。
内製か購入かという問いは技術的な決定に聞こえますが、実際には事業上の賭けです。あなたは時間、資金、組織の集中力を賭けて、今後三年から五年にわたって片方の道がもう一方よりも顧客と業務によりよく貢献するはずだという信念に投資しているのです。正しく判断できれば、ソフトウェアは背景に溶け込み、事業が成長していきます。判断を誤れば、今後二年間、合わない製品と戦い続けるか、誰も所有したがらないコードベースを維持し続けるかの日々を過ごすことになります。
誤った製品を購入してしまった企業のためにカスタムシステムを構築し、また過剰に自前開発してしまった企業のために既製ツールを統合してきた長年の経験から、この判断は通常五つの問いに集約されることがわかっています。どれも技術的な問いではありません。そのすべては、自社が実際に何をしているのかについて正直になれるビジネスリーダーであれば答えられるものです。
問い1：このプロセスは競争優位の源泉ですか、それとも必要最低限のものですか？
ここから始めましょう。あらゆる事業は数十のプロセスによって成り立っています。給与計算、会計、メール、カスタマーサポート、在庫追跡、営業パイプライン管理などです。これらのプロセスの一部はあなたが勝つための手段です。しかしその大部分は単に業務を回すための手段にすぎません。
プロセスが必要最低限のもの、つまり業界内のどの競合もほぼ同じやり方で行っているものであれば、ソフトウェアを購入してください。会計でQuickBooksを、メールでGmailを上回るイノベーションを起こすことはできません。これらの分野に特化してきたベンダーは、あなたがまだ考えたこともないような機能を洗練させるために十年と数億ドルを費やしてきたのです。自前で作ろうとするのは野心ではなく、エンジニアリングチームへの課税であり、本当に差別化に寄与する仕事からの気を散らす行為です。
しかしそのプロセスが本当にあなたが勝つ理由となっているもの、たとえば物流会社が競合より8パーセント安く提供できるようにする価格エンジンや、マーケットプレイスの中核となるマッチングアルゴリズム、競合が却下する融資を承認できるようにする与信モデルであれば、話は変わります。既製ソフトウェアはあなたを他社と同じに見せてしまいます。なぜならそれは他のすべての企業のために作られたものだからです。このような場合、カスタムソフトウェアはコストではありません。それが製品そのものなのです。
テストは単純です。このプロセスを競合に説明したら、羨ましがるでしょうか。もしそうなら、カスタム投資に値します。相手が肩をすくめるようなら、ツールを購入すべきです。
以前、中規模の卸売業者と仕事をしたことがあります。彼らは「うちのワークフローは誰にも理解できない」という理由でカスタムの倉庫管理システムが必要だと主張していました。二回のワークショップを経てわかったのは、彼らのワークフローは同規模の他の卸売業者と90パーセント同じだということでした。残りの10パーセント、つまり仕入先契約に紐づいた特殊な返品プロセスこそが真の差別化要因でした。正解は、フルカスタムのWMSを構築することではありませんでした。実績あるWMSを購入し、返品プロセスを扱う小さなカスタムモジュールを構築してそれと統合することでした。総コストはフルカスタム構築のおよそ五分の一で済み、十八か月ではなく四か月で稼働を開始できました。
問い2：基盤となるプロセスはどれほど安定しており、あなたは実際にどれほどよく理解していますか？
カスタムソフトウェアは、構築した時点で存在していた要件の化石です。もしその要件が六か月ごとに変わるのであれば、ソフトウェアは保守のトレッドミルになります。もし開始時点で要件を完全に理解できていなかったのであれば、ソフトウェアはあなたの最も初期で最も混乱した仮定を記念する記念碑になります。
既製品はこうしたボラティリティをあなたの代わりに吸収してくれます。税法が変われば、会計ベンダーがアップデートを配信します。新しい決済手段が主流になれば、Eコマースプラットフォームが追加してくれます。あなたはサブスクリプション料金を支払うことで、動く部分について他の誰かが心配してくれる状態を得ているのです。
カスタムソフトウェアを構築することが理にかなうのは、プロセスが安定していてよく理解されている場合、あるいはボラティリティ自体があなたの競争優位であってロードマップを自分で制御する必要がある場合です。事業がそもそもそのプロセスが何であるかをまだ模索している段階では、まず理にかなうことはありません。「作りながら反復すればいい」というのは俊敏に聞こえますが、実際には要件を最も辛い方法で発見するためにお金を払っているようなものです。つまり、何かを学ぶたびにリファクタリングしなければならないコードベースを抱えることになります。
有用な直感チェックはこうです。このプロセスが今日どのように動いているかを、すべてのエッジケースを含めて二ページで書き出したとき、運用部門の誰にも訂正されずに済みますか。もしそうでないなら、そのプロセスのために構築するほど理解できていません。柔軟な何かを購入し、一年間そのプロセスを走らせ、現実が本当に重要なことを教えてくれた後にこの問いを再検討してください。
問い3：定価ではなく、五年間の正直な総コストはいくらですか？
ここが、ほとんどの内製・購入分析が脱線するところです。チームはSaaS製品の年間サブスクリプション料金と、カスタム構築の一時的な開発見積もりを比較し、初年度はカスタム構築の方が安いことに気づいて勝利宣言をします。そして二年目がやってきます。
カスタムソフトウェアには、最初の見積もりに含まれることがめったにない三つのコストのバケツがあります。第一に、継続的な保守です。バグ修正、セキュリティパッチ、依存関係のアップグレード、インフラコスト、そしてコードベースを理解しており簡単には代替できないエンジニアたちです。妥当な目安として、年間の保守は当初構築コストの15から25パーセントが毎年、永続的にかかります。第二に、進化です。バージョン1では出荷しなかった機能、後から採用したツールとの統合、当初のUIが古く感じ始めたときの再設計です。第三に、機会費用です。エンジニアリングチームが社内ツールの保守に費やす時間はすべて、実際に収益を生み出すソフトウェアに費やしていない時間なのです。
既製ソフトウェアにもそれ自身の隠れたコストがあります。成長に伴って苦痛なほど拡大するシート単位のライセンス料。ツールをスタックの残りに接続するための統合作業。標準構成が完全に合わないときのカスタマイズ費用。トレーニングコスト。ベンダーが価格を引き上げたり買収されたりしたときの切り替えコスト。そして、自分が制御していないプラットフォームの上に事業プロセスを構築するという戦略的コストです。
厳密な五年間の総所有コスト分析は、通常次のようになります。購入経路については、年間サブスクリプションを取り、五倍し、統合とカスタマイズのコストを加え、トレーニングを加え、価格上昇のための20パーセントのバッファを加え、ベンダーが使えなくなった場合の移行の想定コストを加えます。構築経路については、初期開発見積もりを取り、古典的な過小評価を考慮して1.5倍し、保守と進化のために年間20パーセントを加え、それを所有するエンジニアの人件費込みのコストを加えます。それから、真顔で二つの数字を比較するのです。
ほとんどの場合、購入オプションの方が最初の三年は安く、構築オプションの方が四年目と五年目は安くなります。ただしカスタムシステムがしっかり作られていればの話です。しかし、安いことが要点ではありません。要点は、コミットする前に実際の数字を見ることです。
問い4：このプロジェクトは実際にどれほどのリスクを吸収できますか？
すべてのソフトウェアプロジェクトはリスクを伴います。カスタム構築には、超過のリスク、動かないものを出荷するリスク、それを理解していたエンジニアを失うリスク、そしてまったく間違ったものを構築するリスクがあります。既製品の購入には、ベンダーロックインのリスク、決して使わない機能に対価を払うリスク、もはや合わないワークフローを変更できないリスク、そしてベンダーが廃業したり方向転換したりするリスクがあります。
問題は、どちらのリスクを許容できるかです。プロダクトマーケットフィットを証明するために競争している資金潤沢なスタートアップは、コア製品そのもの以外に十八か月のカスタム構築を許容する余裕はありません。規制された金融機関は、来年データレジデンシー方針を変更するかもしれないSaaS製品の上でコンプライアンスワークフローを運用する余裕はありません。少人数のITチームを持つ中堅の製造業者は、独自のERPの唯一の保守者になる余裕はありません。
有用な枠組みは、プロジェクトが失敗した場合を想像することです。カスタム構築が十二か月遅れ、コストが二倍になったら、事業は生き残れますか。SaaSベンダーが価格を二倍にするか、その製品ラインを閉鎖したら、どれだけ早く移行できますか。最悪のケースが生き残れる経路が、通常は紙の上では期待値がわずかに悪く見えても正しい経路です。
よく推奨するパターンがあります。リスクが高く差別化されていない80パーセントについては購入し、真に差別化する20パーセントについてのみ構築するのです。このハイブリッドなアプローチは、信頼性が最も重要な場所では実績ある製品の信頼性と速度をもたらし、カスタム開発が実際に報われる場所のために高価でリスクの高いカスタム開発の仕事を留保します。両者の間の統合は実際の仕事ですが、限定された仕事です。そしてそれは、最もよくある二つの失敗モードからあなたを守ります。つまり、すべてを構築して何も出荷しないこと、あるいはすべてを購入して業界内の他のすべての会社と同じに見えることです。
問い5：このソフトウェアを所有する組織的能力がありますか？
この問いは、いかなる技術的課題よりも多くのカスタムソフトウェアプロジェクトを殺してきました。ソフトウェアを構築することは簡単な部分です。それを次の十年間所有することが難しい部分です。
カスタムソフトウェアを所有するということは、それを理解しているエンジニアを在籍させ、そのロードマップを優先順位付けするプロダクトマネージャーを置き、そのインターフェースを進化させるデザイナーを配置し、それをテストするQAを持ち、そのインフラを運用する運用担当者を確保することを意味します。目に見える新機能で支出を正当化できないときでも、毎年その保守のために予算を確保することを意味します。主要な製品ローンチの真っ最中に重大なバグが現れたときにトレードオフを行うことを意味します。そして、当初のチームが去ったとき、世界のどこにも存在しないコードベースを学ぶために誰か新しい人にお金を払わなければならないことを受け入れることを意味します。
従業員200人未満のほとんどの企業は、このコストを劇的に過小評価しています。ソフトウェアが一度構築されれば、あとは勝手に動くだろうと想像するのです。そうはなりません。ソフトウェアは記念碑ではなく、庭です。絶え間ない手入れが必要であり、そうでなければ雑草が生い茂り、安全でなくなり、やがて使えなくなります。
既製ソフトウェアは、この所有コストをベンダーに外部化します。それが、あなたが支払っているものの大きな部分です。サブスクリプション料金は単にソフトウェアに対するものではなく、数百人のエンジニアがあなたに代わってそれを生かし続けているという事実に対するものであり、あなたは後ろに孤児となったコードを残すことなく立ち去ることができるのです。
組織にローンチ後のソフトウェアを所有することに専念する小さなチームがなく、現実的に雇うこともできないのであれば、カスタム構築はしないでください。よく作られたシステムでも所有者なしには衰退し、事業を運営する衰退中のシステムはスローモーションの危機です。
実践的な意思決定フレームワーク
五つの問いをまとめれば、機能するフレームワークが得られます。単純な2×2のマトリクスを描いてください。一方の軸に、そのプロセスが競争優位にとってどれほど中心的であるかをプロットします。もう一方の軸に、そのプロセスがどれほど安定していてよく理解されているかをプロットします。
高い戦略的価値、高い安定性：これがカスタムのスイートスポットです。何が必要かがわかっており、必要なのは本物の優位性です。それを構築し、所有し、投資してください。
高い戦略的価値、低い安定性：これは危険地帯です。それが重要であることはわかっているが、まだそれがどうあるべきかはわかっていません。入手可能な最も柔軟なツールを購入し、その上で十二か月から十八か月運用し、プロセスが安定した後に構築の問いを再検討してください。
低い戦略的価値、高い安定性：これは教科書的な購入領域です。会計、人事、メール、標準的なCRM。よくサポートされた製品を選び、統合し、二度と考えないでください。
低い戦略的価値、低い安定性：ここでは、ソフトウェアで問題を解決したいという衝動に抵抗してください。プロセスで、あるいはスプレッドシートで、あるいは人で解決しようとしてください。それが真剣な投資に値するかどうかを判断できるほど十分に理解できるまでは。
このマトリクスの上にコスト、リスク、所有権の問いを重ねれば、通常は答えが明確になります。そうならないとき、その曖昧さ自体が情報です。それはそのプロセスが議論を正当化するほど重要ではないことを意味し、あなたは最も安価で妥当なオプションを購入して、より重要な決定に進むべきだということです。
優れた調達と優れたプロダクトエンジニアリングに共通するもの
私たちが一緒に働く最高のソフトウェアリーダーは、内製か購入かを一度きりの判断ではなく、継続的なポートフォリオの決定として扱います。彼らは定期的に社内ツールを監査し、それぞれが依然として受けている投資に値するかを問います。彼らは定期的にベンダー契約を監査し、いずれかがカスタム置き換えを正当化するほど重要になっているか、あるいはより安価なもので置き換えられるほど些細になっているかを問います。彼らは怠惰な二つのデフォルト、つまり「うちのチームは賢いから作るべきだ」と「作るのは難しすぎるから買うべきだ」に抵抗します。
正直な答えは、ほとんどの場合退屈なものです。コモディティを購入し、優位性を構築し、慎重に統合し、事業が変化するにつれて毎年その組み合わせを再検討することです。ソフトウェアにおける競争優位のほとんどは、単一の英雄的な決定からではなく、十年間にわたって正しい小さな決定を何度も何度も行う規律から生まれます。
もし特定の内製・購入判断を進めていて、コストモデルや統合アーキテクチャに第二の目を求めたいのであれば、それこそが経験豊富なパートナーが手助けできる種類の仕事です。構築か購入かをあなたに売り込むためではなく、コミットする前にトレードオフを明確に見えるようにするために。最良の結果は、どちらの方向に進んだとしても、三年目に振り返ってなお満足できる決定です。