スパイダープラスの本田です。
最近は設計をしたり設計のレビューをする機会などが増え、アーキテクチャについて考えたりする時間が多くなってきたので、今までの学習や経験からの気づきをまとめてみたいと思います。
はじめに：ユーザー体験とシステムアーキテクチャの密接な関係
近年のプロダクト開発では「デザインファースト」「ユーザー体験中心」といったアプローチが主流となっています。美しいUIや直感的な操作性は確かに重要ですが、どんなに洗練されたデザインも、システムが遅い、頻繁に落ちる、データが消えるといった問題があれば、その価値は一瞬で失われてしまいます。
今回は、非機能要件を早期に考慮したアーキテクチャ選択が、優れたユーザー体験の実現に不可欠であることを書いていきます。特に、多くの開発現場で見過ごされがちな「結果整合性」という選択肢について、その価値と実現方法について整理したいと思います。
なぜ非機能要件は後回しにされるのか
「当たり前品質」という落とし穴
品質管理の世界では『狩野モデル』における『当たり前品質』という概念があり、システム品質の文脈で考えると、以下のような要素が該当します。これは「あって当然、なければ大きな不満を生む品質」のことです。システム開発において、以下のような要素は典型的な当たり前品質です：
- システムが落ちない（可用性）
- ストレスのない速度で応答する（適切なレスポンス速度）
- データが消えない・壊れない（データ整合性）
ユーザーにとって、これらは「できて当たり前」なのです。しかし皮肉なことに、「当たり前」だからこそ、開発時には後回しにされがちです。
非機能要件が後回しになる現実
開発現場でよく聞かれる声があります：
「まずは動くものを作ろう。性能改善は後からでもできる」
この考え方自体は間違いではありません。特に新規プロダクトの仮説検証フェーズでは、機能が価値を生むかどうかを素早く確認することが重要です。しかし、仮説検証・技術検証と、本番システムの設計は分けて考える必要があります。
多くのプロジェクトでは、以下のような理由で非機能要件が後回しになりがちです：
- 目に見える機能開発が優先される組織的な力学
- 非機能要件の定量化・効果測定の難しさ
- 検証時の技術選択との差から発生する変更コスト （特に本番稼働後は、データ移行やダウンタイムの問題が発生）
後回しにすることで生じる課題
非機能要件を敬遠した結果、以下のような問題が発生することがあります：
- ビジネス機会の損失：人気商品のセール開始時にシステムがダウン
- ユーザー離脱：ページ読み込みに3秒以上かかると50%のユーザーが離脱
- ブランド価値の毀損：頻繁なエラーや遅延による信頼性の低下
せっかくユーザー体験を重視してデザインを作り込んでも、システムの基本的な品質が担保されていなければ、本末転倒な結果になってしまう恐れがあります。
競争力の源泉としての非機能要件
一方で、非機能要件を適切に満たしているサービスは、それだけで強力な競争優位性を持ちます：
- とある動画配信サービス：高い可用性が生む「いつでも見られる」という信頼
- とある大手ECサイト：わずかな遅延が売上に直結するという認識のもと、徹底的な高速化
- 世界的な検索エンジン：検索結果の表示速度が、他社との大きな差別化要因
「当たり前品質」の徹底が、実は最大の差別化要因になる時代なのです。
非機能要件とアーキテクチャ選択：バランスの取れたアプローチ
非機能要件がユーザー体験に与える影響
非機能要件は、直接的にユーザー体験を左右します：
レスポンスタイム(*)
- 100ミリ秒：瞬時と感じる
- 1秒：思考の流れが保たれる限界
- 10秒：注意を保てる限界
可用性
- 99.9%（スリーナイン）：年間8.76時間の停止
- 99.99%（フォーナイン）：年間52.56分の停止
- わずか0.09%の差が、ユーザーの信頼を大きく左右
データ整合性
- 注文が重複する、残高が合わない
- 一時的でも、ユーザーの混乱と不信を招く
技術選定の前に明確にすべきこと
アーキテクチャを選択する前に、以下を明確にする必要があります：
- ビジネス要求の整理
- どの機能にリアルタイム性が必要か
- どのデータに厳密な整合性が必要か
- 想定されるトラフィック規模とその成長率
- ユーザーシナリオの分析
- ユーザーはどの程度の遅延を許容するか
- 一時的な不整合に気づくか、影響はあるか
- サービス停止時の代替手段はあるか
- トレードオフの理解
- すべてを満たすことはできない
- 何を優先し、何を妥協するか
例えば、ECサイトを考えてみましょう。同じサイト内でも、機能によって求められる品質は全く異なります。
- レビュー機能: 「多少の表示遅延や、いいね数の反映の遅れは許容できる（結果整合性でOK）。それよりも、書き込み・読み込みがサクサクできる体験が重要。」
- 決済機能: 「残高や注文内容は1円、1個の間違いも許されない（強整合性が必須）。多少レスポンスが遅くなっても、データの正確性が最優先。」
このように、機能ごとの特性を見極めることが重要です。
ここまで非機能要件の重要性を見てきました。実際のシステム設計では、 これらの要件間でトレードオフが発生します。
特に重要なのが「データの整合性をどう扱うか」という問題です。 現代のWebサービスは、スケールするために分散システムを採用は当たり前になっていますが、そこには避けられない制約があります。
以下では、分散システムにおけるデータ整合性の選択肢と、それがビジネスに 与える影響について、CAP定理を起点に具体的に検討していきます。
CAP定理：分散システムの基本的な制約
CAP定理とは
分散システムには避けられない制約があります。CAP定理は、以下の3つの特性のうち、同時に満たせるのは2つまでであることを示しています：
- C (Consistency：一貫性)：すべてのノードが同じデータを見る
- A (Availability：可用性)：システムは常に応答する
- P (Partition tolerance：分断耐性)：ネットワーク分断に耐える
現実のインターネット環境では、ネットワーク分断は必ず発生するため、実質的にはCかAかの選択になります。
※ より発展的なPACELC（平常時のレイテンシと一貫性のトレードオフも考慮）もありますが、基本的な考え方は同じであり、ここではCAP定理として説明します。
CPシステムとAPシステム
CPシステム（一貫性＋分断耐性）
- 特徴：データの正確性を保証、分断時は一部のリクエストを拒否
- 例：銀行システム、在庫管理システム
- ユーザー体験：「ただいま混雑しています」エラーなどが発生しうるが、間違ったデータが表示されるということがない
APシステム（可用性＋分断耐性）
- 特徴：APシステム：可用性を優先し、ネットワーク分断時でも 可能な限り応答を返す（ただし一時的な不整合を許容）
- 例：SNS、動画配信サービス
- ユーザー体験：いつでも使えるが、情報が少し古い可能性がある
強整合性 vs 結果整合性：適材適所の選択
強整合性の特徴とトレードオフ
強整合性は、従来のRDBMSが提供してきた一貫性モデルです。
メリット
- プログラミングモデルがシンプル
- データの状態が予測可能
- トランザクションによる安全性
デメリット
- スケーラビリティの課題（水平スケール時にコストとレイテンシが増加）
- レスポンスタイムへの影響（ロック待機）
- 可用性の低下（ノード障害時の影響大）
適したケース
- 金融取引：口座残高の正確性が絶対
- 在庫管理：在庫数の過不足は許されない
- 予約システム：ダブルブッキングは避けるべき
結果整合性の特徴とトレードオフ
結果整合性は、一時的な不整合を許容し、最終的に整合性を保証するモデルです。
『最終的に整合性が保たれる』の『最終的』とは：
- 一般的には数秒〜数分程度
- ビジネス要件に応じて許容範囲を定義
- 例：SNSの「いいね」数は1分以内、在庫表示は10秒以内など
メリット
- 高速なレスポンス（ローカル処理で完結）
- 高い可用性（部分的な障害に強い）
- 優れたスケーラビリティ（水平スケール容易）
デメリット
- プログラミングモデルの複雑化
- 一時的な不整合への対処が必要
- デバッグ・テストの難しさ
適したケース
比較表
| 観点 | 強整合性 (Strong Consistency) | 結果整合性 (Eventual Consistency) |
|---|---|---|
| データ | 常に最新・正確 | 一時的な不整合を許容 |
| レスポンス | 遅くなる可能性（ロック等） | 高速（ローカルで応答） |
| 可用性 | 低下する可能性（分断時） | 高い（部分障害に強い） |
| スケール | 垂直スケールが中心 | 水平スケールが容易 |
| 実装複雑度 | シンプル | 複雑（非同期処理等） |
| 適した用途 | 銀行システム、在庫管理 | SNS、レコメンデーション |
※ なお、強整合性とスケーラビリティの両立を目指すNewSQL（Cloud Spanner、Aurora DSQLなど）という選択肢もありますが、この記事ではその前段階として、基本的なCAP定理と整合性モデルの理解に焦点を当てたいため割愛させていただきます。
最適な選択のための観点
以下のような質問に答えることで、より適切な選択ができます：
- ビジネス影響の評価
- 一時的な不整合でユーザーや事業に実害があるか？
- その影響は許容可能な範囲か？
- パフォーマンス要求
- ミリ秒単位のレスポンスが必要か？
- 同時接続数やスループットの要求は？
- 将来の拡張性
- ユーザー数が10倍、100倍になる可能性は？
- グローバル展開の予定は？
- チームの能力
現実の課題：結果整合性という選択肢
なぜ結果整合性が検討されないのか
多くの開発現場で、結果整合性という選択肢が検討されない理由があります：
技術的慣性
知識の偏り
心理的障壁
- 「データの不整合」という言葉への恐怖
- 複雑性への漠然とした不安
選択肢を広げることの重要性
しかし、すべてを強整合性で実装する必要はありません。システムの中で：
- コア機能：強整合性で確実性を担保
- 周辺機能：結果整合性で体験を向上
このような使い分けが、システム全体の価値を最大化します。
CQRSの基本概念
CQRS（Command Query Responsibility Segregation）は、書き込み（Command）と読み取り（Query）を分離するアーキテクチャです。
このアーキテクチャにより：
- 書き込みと読み取りで異なるスケーリング戦略を選択可能
- Commandは即座に受け付けられる
- Read Modelは非同期で更新される
- 読み取りは常に高速
CQRSによる結果整合性の実装例
ECサイトでの超簡易的な実装例を考えてみましょう：
商品閲覧（Query）
const product = readModel.getProduct(productId);
カート追加（Command）
sendCommandToQueue('AddToCart', { userId, productId }); onEvent('ProductAddedToCart', (event) => { updateCartView(event.userId, event.productId); });
この設計により：
- ユーザーは即座にフィードバックを得る
- システムは高負荷に耐える
- 一時的にカート表示が遅れても、UXへの影響は最小限
アーキテクチャの進化：マイクロサービスとの関連
マイクロサービスアーキテクチャは、異なる非機能要件を持つ機能を分離する手段として有効です。
例えば、ECサイトを以下のように分割：
- 商品カタログサービス：AP型（高速な検索・閲覧）
- 在庫管理サービス：CP型（正確な在庫数）
- レコメンドサービス：AP型（リアルタイム性重視）
- 決済サービス：CP型（金銭の正確性）
各サービスが最適な整合性モデルを選択することで、システム全体として最高のユーザー体験を実現できます。
※なお、マイクロサービス間でのデータ整合性は別の課題です。 例えば、在庫サービス（CP型）と注文サービス（AP型）の間では、 Sagaパターンや分散トランザクションなどの考慮が必要になります。
複雑性への対処
開発者の負担が増える現実
結果整合性を採用すると、システムの複雑性が増し、開発者のやることが増えるのは事実です。
AIが変えつつある開発体験
結果整合性は確かに開発でやることを増やしますが、近年、AIがその「面倒だが定型的な作業」を肩代わりしてくれるようになりました。例えば、冪等性担保やリトライロジックといった定型的なコードは、AIコーディング支援ツールがかなりの部分を生成してくれます。また、複雑な非同期処理のテストケースをAIに洗い出させることで、考慮漏れを防ぐことも期待できます。
これにより、開発者は本来注力すべき「ビジネスロジック」と「アーキテクチャ設計」に集中できる時代になりつつあり、高い品質を維持しつつ、結果整合性の恩恵を享受できる可能性が高まっています。
まとめ：ビジネス価値を最大化するアーキテクチャ選択
本記事では、システムアーキテクチャの選択がプロダクトのビジネス価値に与える影響について書いてみました。
重要なポイント
- 非機能要件は「当たり前品質」：軽視されがちだが、ユーザー体験の基盤
- CAP定理の理解：すべてを満たすことはできない、トレードオフの認識
- 強整合性と結果整合性：それぞれに適した用途がある
- 選択肢を知ること：デフォルトに縛られず、最適な選択を
アーキテクチャ設計をしっかり行うことはデザインファーストな進め方とは対立しません。むしろ、両方を適切に考慮することで、真に優れたユーザー体験を持つプロダクトが生まれると思います。
技術的な選択肢を理解し、ビジネスに最適な判断に貢献をすることが、これからのエンジニアに求められる重要なスキルの一つではないでしょうか。
最後に、スパイダープラスでは仲間を募集中です。スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。最後までご覧いただき、ありがとうございます。
コメント