なぜバックエンドを重視するのか
SaaS開発において、バックエンドは他のレイヤーよりも重視すべきだと思っています。
本記事では、バックエンドを重視する必要性とメリット、軽視することで生じるリスクについて考えます。
なお、受託開発やSIerでは収益構造が異なるため、本記事の内容は適用されない場合があります。
詳細については受託開発とSaaS開発の方法論の違いをご覧ください。
🟦 バックエンドの複雑さと重要性
🟠 複雑さを引き受けるレイヤー
バックエンドは、システム全体の複雑さを引き受ける中核的なレイヤーです。
バックエンドには以下のような多岐にわたる複雑さが集約されます
- 認証・認可
- バリデーション
- データ永続化（DB・ストレージ）
- パフォーマンス
- セキュリティ
- 外部サービスとの通信
これらの複雑さと、軽視した場合のリスクについてはWebバックエンドの複雑さと負のスパイラルで詳しく説明しています。
🟠 ドメイン知識の形式知化
バックエンドでは、ドメイン知識を自らの手で整理・体系化・形式知化する必要があります。
「形式知化」とは、暗黙的な知識を明文化し、チーム全体で共有可能な形にすることです。
ドメイン知識は「自社独自の知識の領域」であるため、インターネットで検索しても答えは見つかりません。
自らの手で構築していく難しさがあります。
🟠 青天井に増大する複雑さ
機能追加とともに、バックエンドの複雑さは青天井に増していきます。
この複雑さをコントロールできなければ、開発効率は低下し、最終的にはビジネスの停滞につながります。
🟦 バックエンドを軽視することのリスク
バックエンドを軽視すると、フロントエンドやインフラに比べて、チームの崩壊やビジネスリスクに繋がる可能性が高くなります。
具体的には以下のような問題が発生します
- 開発の停滞
- チームのモチベーション低下
- 離職率の増加
- ドメイン知識の流出
- 最終的なビジネスの停滞
これらの詳細な因果関係についてはWebバックエンドの複雑さと負のスパイラルで詳しく説明しています。
🟦 バックエンドを重視することのメリット
🟠 フロントエンドの安定化
バックエンドが安定していれば、フロントエンドも安定しやすくなります。
フロントエンドに問題が発生するのは、多くの場合、バックエンドが破綻しドメインロジックがフロントエンドに漏れ出した時です。
バックエンドの品質を維持することがフロントの品質維持にも繋がります。
🟠 競争力の源泉
ドメイン知識が製品としての競争力を生み出します。この知識を適切に管理・活用できるかが、SaaSの成功を左右します。
🟠 リリース速度の向上
多くのプロジェクトでは、バックエンドの開発が最も時間を要します（所謂クリティカルパス）
つまり、バックエンドの開発効率向上は、リリース速度に直結します。
🟠 好循環の創出
バックエンドを重視することで、以下の好循環が生まれます
- 開発が滞りにくくなる
- チームのモチベーションが維持される
- 離職が減る
- ドメイン知識が蓄積される
- さらなる開発効率の向上
🟦 なぜバックエンドは軽視されるのか
🟠 理解不足
組織や責任者が、前述の複雑さ・重要さを理解していないケースがあります。
よくあるのは受託開発やSIerの文化・方法論をSaaS開発に持ち込んでしまうことです。
詳しくは受託開発とSaaS開発の方法論の違いの「受託開発に最適化された思考パターン」を参照してください。
🟠 問題の顕在化にラグがある
立ち上げ期のチームやプロダクトでは、前述の問題はまだ顕在化しません。
一見順調に見えてしまうため、以下のような問題が発生します。
- 誤ったマネジメント手法や意思決定が成立してしまう
- 手遅れになってから問題が顕在化する
- 先回りで問題提起をしても理解されない
🟠 多数決に弱い
多くのチームで、前述したような複雑さと向き合える人は少数派です。
多数決的な文化では、「正しい意見が通らない」または「後回しにされる」ことがあります。
🟠 リソース不足
バックエンドエンジニアは目先のタスクや問題解決に忙殺され、政治的な立ち回りにリソースを割けません。
🟠 流行りの指標との相性の悪さ
例えばFour Keysの一部である「デプロイ頻度」「変更失敗率」が指標に置かれると問題が生じます。
永続化層（DB等）の改修が絡むような課題は、難易度と工数が大きい傾向があります。
前述の指標の元では、そうした重要な課題への対応インセンティブが減少します。
🟠 悪循環の形成
これらが複合した結果、「大変な割に評価されないポジション」となりがちです。
- 大変だからやらない
- やらないからスキルが身につかない
- 担い手が居なくなる → 悪循環へ
🟦 まとめ
SaaS開発において、バックエンドは以下の特徴を持つ重要なレイヤーです
- システムの複雑さを引き受け、ドメイン知識を形にし、継続的な価値提供を支える中核です。
- 軽視すれば、チームの崩壊やビジネスの失敗といった深刻なリスクに繋がります。
- 「バックエンドは大変だから外注」はNGです。
- 大変かつ重要だからこそコアメンバーで開発・維持していく必要があります。
- 重要さを考慮するとバックエンドを特別扱いする戦略も選択肢に入る。
- バックエンド専任のエキスパートを配置する
- 特に重要な機能だけ、シニアや責任者が手を動かす
- 開発に関わる全員がバックエンドの重要性を理解し、大変かつ重要度の高い問題に向き合える文化を作ることが重要です。
Discussion