システム開発の重心を定める

SoR(Systems of Record):記録と信頼性のシステム
- 定義と目的: 企業の基幹業務を支え、データの正確性、堅牢性、安定性、信頼性を最優先するシステム。
- 重視する点: データ整合性、トランザクション処理、コンプライアンス、セキュリティ、長期的な安定稼働。
- 代表的なシステム例: 会計システム、人事システム、在庫管理システム、基幹業務システム(ERP)。
SoE(Systems of Engagement):つながりと体験のシステム
- 定義と目的: 顧客やユーザーとの接点を持ち、顧客体験(UX)やエンゲージメントの向上、市場への迅速な対応を目的とするシステム。
- 重視する点: ユーザー体験(UX)、UIデザイン、応答性、俊敏性、拡張性、パーソナライゼーション。
- 代表的なシステム例: 顧客向けWebサービス、モバイルアプリ、ECサイト、CRM、マーケティングオートメーション。

🎯 何を決めるか？

システム開発の重心を、SoR/SoE どちらに寄せるか決めます。
これは要件定義の成果物とプロセスの方向性を決めることと同じです。

👤 誰が決めるか？

プロジェクトマネージャー(PM)の責任で決定します。

❓ なぜ「重心」を決める必要があるのか？

要件定義の成果物とプロセスを決めるために必要です。以下の性質があるためです。

観点	SoR	SoE
不確実性の扱い	早期に収束させる	前提として受け入れる
合意の基準	正しさ・網羅性	使えること・納得感
判断材料	規程・業務実態・過去	仮説・試行・利用反応
要件の確定	上流で固める	段階的に固める

🔍 どうやって決めるか？

多くのシステムは、純粋な SoR/SoE ではなく、両方の要素を併せ持つ「ハイブリッド型」です。その場合でもどちらに「より」重心を置くか、あるいはどの機能がSoR的で、どの機能がSoE的かを明確にすることで、開発アプローチを適切に調整します。

どちらの型に寄せるかは、プロジェクト目的や、システムの取り扱う業務の性質によって決めます。以下の手順を推奨します。

「クイック診断」で簡易に見極める
いくつかの問いに答えることで、SoR と SoE どちらに重心を置くべきか見極めます。このページで提供している「クイック診断」を利用してください。
特別に重視するポイントを見極める
プロジェクトは本質的に独自性を持ちます。システムの重心を見極めたら、「特別に重視すべきポイント」があるか、見極めます。
多くのシステムはハイブリッド型なので、SoR 寄りの中に SoE の部分があったり、逆もあったりします。
その中で、特に注意が必要なリスクポイント(機能や制約など)を見極め、その後のプロセス計画に活かします。
重心をチームで共有する
決定した内容は、チーム全体で共有し、理解を揃えます。次の一文が共有の例です。

本プロジェクトの要件定義は、SoR に重心を置いて進める。
ただし、〇〇機能は SoE なので注意する。

📊 クイック診断

以下の問いに答えることで、SoRとSoEのどちらに重心を置くべきかを見極めます。
完璧な答えを出す必要はありません。「どちらに寄せて進めるべきか」の初期判断を目的とします。

診断の進め方

以下の設問に 現時点で正直に 回答する
「SoE寄り」「SoR寄り」どちらに多く当てはまるかを確認する
結果を踏まえ、以降の要件定義の進め方・成果物の重点を決める

プロジェクトの目的(最上位のビジネス目標)は何か？
- 業務効率化、コスト削減、コンプライアンス遵守が主か？(SoR寄り)
- 顧客満足度向上、新規顧客獲得、市場シェア拡大、ブランド価値向上が主か？(SoE寄り)
このシステムの主要な利用者は誰か？
- 社内の業務担当者、管理者か？(SoR寄り)
- 外部の顧客、エンドユーザーか？(SoE寄り)
システムが最も重視すべき「品質特性」は何か？
- データの正確性、整合性、堅牢性、セキュリティか？(SoR寄り)
- 使いやすさ、応答性、魅力的なUI/UX、柔軟性か？(SoE寄り)
システムが扱うデータの性質はどうか？
- 機密性が高く、厳密な管理と監査が求められる基幹データか？(SoR寄り)
- ユーザー行動データ、パーソナライズ情報など、変化が速く多様なデータか？(SoE寄り)
既存システムとの連携はどうか？
- 既存の基幹システムとの厳密なデータ連携が必須か？(SoR寄り)
- 外部サービスやAPIとの柔軟な連携が主か？(SoE寄り)
開発後の運用・保守において、最も懸念されるリスクは何か？
- データ破損、システム停止、法規制違反など、事業継続に関わるリスクか？(SoR寄り)
- ユーザー離れ、競合優位性の喪失、市場ニーズとの乖離か？(SoE寄り)
開発アプローチとして、どちらがより適しているか？
- 計画を重視し、堅実に進めるウォーターフォール型か？(SoR寄り)
- 変化に柔軟に対応し、迅速なリリースと改善を繰り返すアジャイル型か？(SoE寄り)

💡 よくある質問

SoRとSoEの比率が半々の場合、どう判断すればよいか？

どちらか一方に完全に寄せる必要はありません。機能単位で重心を分けて考えることが有効です。例えば、「データ管理機能はSoR寄り、UI/UX部分はSoE寄り」のように分類し、それぞれに適したプロセスを適用します。

診断結果が予想と異なる場合はどうすればよいか？

診断はあくまで初期判断のツールです。結果に違和感がある場合は、ステークホルダーと対話し、プロジェクトの本質的な目的や制約を再確認してください。最終的には、チームの合意が最も重要です。

プロジェクト途中で重心が変わることはあるか？

あります。特に、市場環境の変化や経営方針の転換があった場合です。その際は、改めて診断を行い、必要に応じて開発アプローチや成果物の重点を見直すことを推奨します。

次のページ → 📄要件定義書の構成を決める

システム開発の重心を定める 📋 このプロセスの概要 SoR 型か SoE 型、どちらに寄せるか？ 📚 SoR と SoE の基本理解 🎯 何を決めるか？ 👤 誰が決めるか？ ❓ なぜ「重心」を決める必要があるのか？ 🔍 どうやって決めるか？ 📊 クイック診断 💡 よくある質問