受託開発とSaaS開発の方法論の違い
IT業界では、受託開発と自社でのSaaS開発という２つの主要なビジネスモデルが存在します。
しかし、この２つは表面的には同じシステム開発に見えるものの、異なる利益構造を持っており、有効な方法論も異なります。
本記事では、なぜ受託開発で「成功」とされる手法が、SaaS開発では「失敗要因」となるのか、その根本的な違いを解説します。
🟦 利益構造の違い
🟠 受託開発
受託開発では、納品すれば売上が立つというシンプルな構造です。
顧客の受け入れテストをパスできればプロジェクトは成功とみなされ、報酬が支払われます。
🟠 SaaS開発
一方、SaaS開発では、リリース後の継続利用が売上につながる構造です。
リリースはスタート地点に過ぎず、ユーザーが継続して価値を感じ続けることが重要です。
🟦 利益構造の違いが生む開発文化の差
🟠 品質に対する考え方
受託開発では、将来発生する負債を顧客に押し付けることができます。
受託開発では、初回開発よりも保守・改修契約の方が利益率が高いケースがあります。
その場合、初回の品質を意図的に「完璧すぎない」レベルに調整することすら経済的に合理的となります。（これはエージェンシースラックとよばれる現象です）
SaaS開発では、すべての負債が自社に返ってきます。
運用を考慮しない設計は、ビジネス成長時の致命的なボトルネックとなります。
🟠 DevOpsの観点
受託開発では運用を考慮して品質を高めるインセンティブが薄いため、DevOps（開発と運用を統合し、継続的な改善を行う手法）の観点が欠如しがちです。
SaaS開発ではDevOpsの観点が必須です。
継続的なリリースと安定した運用が売上に影響するためです。
🟠 時間軸の違い
受託開発では「短期での納品成功」を目指します。プロジェクトには明確な期限があり、その期限内で要件を満たすシステムを納品することが最優先となります。
SaaS開発では「長期での事業成功」を目指します。継続的な改善とスケーラビリティを重視し、長期間にわたってユーザーに価値を提供し続けることが重要です。
🟠 「ドメイン知識」の違い
受託開発ではドメイン知識の管理は顧客側の責務となります。開発者は必要最小限の理解で実装を進め、プロジェクトが完了すれば、そのドメイン知識は忘れてしまっても問題ありません。
SaaS開発では機能が増えるにつれてドメイン知識が青天井に複雑化していきます。開発者が自らドメイン知識を体系化し、整理していく必要があり、プロダクトが続く限りその知識を維持し続ける必要があります。
🟠 ドキュメントに対する考え方の違い
受託開発ではドキュメントは納品物として作成されます。顧客への説明責任を果たすための証跡として機能し、プロジェクト完了後は参照されないことが多くなります。
SaaS開発ではドキュメントはシステムを継続して維持していくために作成されます。ドメイン知識を整理し、チーム内の共有知とするためのものであり、長期間にわたって参照・更新され続けます。
🟦 最適な方法論の違いの例
上記の違いに基づいて、最適な方法論も異なります。ここではその一例を上げます。
🟠 増員・人海戦術について
受託開発での有効性
- 納品期限が迫った際の最後の手段として有効
- 受け入れテストをパスすることだけが目標なら機能する
- 短期間での人員追加によるリカバリが可能
SaaS開発での危険性
- 無計画に大量増員を行っても生産性は向上しません（いわゆるブルックスの法則と呼ばれます）
- 参考書籍： 人が増えても速くならない ～変化を抱擁せよ～
- 急激な増員により品質管理が困難になり、技術的負債の蓄積から悪循環に陥るリスクが高まります
- 参考記事： Webバックエンドの複雑さと負のスパイラル
🟠 自動テストについて
受託開発での位置づけ
- 一度の納品で終わるシステムでは「過剰」とみなされることがある
- 手動テストで受け入れテストをパスできれば十分
SaaS開発での必要性
- 継続的な改善を行うために、自動テストを整備するインセンティブがある
- 機能追加のたびに回帰テストを全て手動で行うのは現実的ではない
🟦 受託開発に最適化された思考パターン
長年受託開発に従事すると、その利益構造に最適化された思考パターンが形成されます。
🟠 ①リリース後の問題に対する想像力の欠如
- 「納品したら終わり」という思考
-
リリース後に起こりうる問題とその解消コストの高さに想像が至らない。（DevOps観点の欠如）
- 問題を先回りで解消しようとしない
🟠 ②ウォーターフォール思考
「設計 → 実装 → テスト → 運用」の各工程を明確に分離が可能だと考えている。結果、以下の思考に繋がる。
- 各工程で異なる担当者を割り当てようとする。
- 複雑化したシステムとそれに伴う不確実性と向き合うには、設計と実装を行き来しながら作り上げるアプローチも可能だが、それらを適切にコントロール・遂行できない
- 開発と運用を分けようとする
- 開発と運用のフィードバックが絶たれる（DevOps観点の欠如）
- テストのシフトレフトの観点・ノウハウがない
🟠 ③「上流・下流」文化の持ち込み
「上流・下流」の概念に囚われおり、「マネージャー」と「メンバー」を役割の違いではなく階級の違いだと思いこんでいる。結果、以下の思考に繋がる。
- マネージャーが上、メンバーが下だと思いこんでいる
- 下流工程を軽視する
- マネージャーになることがゴールになっている
- 強すぎる上意下達意識
- ドメイン知識を持ったメンバーの意見を軽視する
- ドメイン知識や判断材料を持たないまま意思決定を行おうとする（後述の⑥に繋がる）
- 情報をせき止めてメンバーとの間に情報の非対称性を生み出す
この価値観の下では次の④⑤の傾向が強まる。また、③④⑤が互いにこの傾向を強め合う
🟠 ④自ら手を動かさない
- 実装などの 「泥臭い」作業はメンバーに委託する
- 政治的な立ち回りに力を注ぐ
- 手を動かさないため・・・
- ドメイン知識が身につかない
- 技術的な問題解決能力が成長しない（実行力がない）
- 技術による問題解決を戦略に組み込めない
- ソフトウェアエンジニアリングの力学を表面的にしか理解していない
これらにより「⑤問題解決手法の貧困」に繋がる
🟠 ⑤問題解決手法の貧困
- 困難への対処法が増員（人海戦術）や外注に偏る
- ビジネスコアとなる機能を外部に委ねることは、ビジネス上の競争優位性の放棄を意味する。
- 増員（人海戦術）の危険性は前述した通り
- 強すぎる上意下達意識によりビジネスサイドと交渉ができない
🟠 ⑥意思決定の質の低下
③④⑤の複合的な結果として以下に繋がります。
- 戦略的な判断ができず、場当たり的な対応が続く
- 長期的な競争力の構築ができない
🟠 文化の再生産メカニズム
これらの思考パターンは、組織内で自己強化のメカニズムを形成します
- 昇進への優位性: 政治的な立ち回りに長けているため、組織内で影響力を持ちやすい
- 評価制度の歪み: 受託開発的な価値観に基づいた評価制度が策定され、この文化が正当化される
- 採用・育成の偏り: 同じ価値観を持つ人材の採用と育成が繰り返される
この悪循環により、組織はSaaS開発に必要な技術的柔軟性と継続的学習能力を失っていきます。
🟦 まとめ
受託開発とSaaS開発は、利益構造の根本的な違いにより、異なる方法論が必要です。
受託開発で成功した手法をSaaS開発に盲目的に適用することは、長期的な失敗につながる可能性があります。
重要なのは、それぞれの文脈を理解し、適切な方法論を選択することです。受託開発の経験が長い技術者やマネージャーは、自身の思考パターンを見直し、SaaS開発に適した新しいアプローチを学ぶ必要があります。
システム開発という表面的な類似性に惑わされることなく、ビジネスモデルの違いから生まれる本質的な差異を理解することが、成功への第一歩となるでしょう。
（余談）最後まで読んで頂きありがとうございます！
内容に共感頂けたら いいね or SNSで共有 頂けると励みになります 🙏
Discussion