SES（システムエンジニアリングサービス）における要件定義は、受託開発の要件定義と同じ言葉を使いながらも、役割・責任・立ち位置が大きく異なる工程です。
この違いを曖昧にしたままプロジェクトを進めると、認識齟齬・責任問題・炎上に直結します。
本記事では、契約形態の前提から実務上の注意点までを整理し、SESにおける要件定義を正確に解説します。
「SES」という言葉の前提整理（最重要）
まず押さえるべきなのは、SESという言葉自体が法的な契約類型を指すものではないという点です。
実務上「SES」と呼ばれているものには、以下が混在します。
- 準委任契約
- 労働者派遣契約
- 請負契約（またはそのグレーゾーン）
そのため、SES要件定義を語る際は、
「この案件は、契約上どの形態なのか」
を必ず確認する必要があります。
本記事では、一般にSESとして最も多い「準委任契約」を前提に説明します。
準委任契約における要件定義の基本的な位置づけ
成果完成義務ではない
準委任契約では、請負契約のような「成果物を完成させる義務」は原則としてありません。
ただし、これは責任がないという意味ではありません。
求められるのは「善管注意義務」
準委任では、
- 業務を適切に遂行すること
- 専門家として合理的な注意を払うこと
いわゆる善管注意義務が課されます。
つまり、
- 結果が出なかっただけ → 直ちに契約違反ではない
- 業務の進め方が不適切 → 責任を問われる可能性あり
という構造になります。
SESにおける要件定義の役割とは何か
「決める人」ではなく「支援する人」
準委任型SESの要件定義において、エンジニアの立場は原則として以下です。
- 要件を最終決定する立場ではない
- 顧客や発注者の意思決定を技術的に支援する立場
具体的には、
- 要望の整理・構造化
- 技術的観点からの実現可否説明
- 抜け漏れやリスクの指摘
- 要件定義書・決定事項一覧などのドキュメント作成支援
を担います。
ここで重要なのは、「提案」と「決定」を明確に分けることです。
SES要件定義でも成果物は存在する
「準委任＝成果物がない」と誤解されがちですが、これは不正確です。
実務上、要件定義では以下の成果物が作られます
- 要件定義書
- 機能要件一覧
- 非機能要件一覧
- 決定事項／未決事項一覧
- スコープ境界の整理資料
ただし重要なのは、
それらの完成を保証する契約責任ではなく、
作成・整理・合意形成を適切に支援する責任
であるという点です。
SES要件定義で扱う主な内容
業務要件
- 現行業務（As-Is）
- あるべき業務（To-Be）
- 業務フロー・関係者整理
顧客自身が業務を言語化できていないケースも多く、ヒアリング力・整理力が強く求められます。
機能要件
- 必須機能と任意機能の切り分け
- 画面・帳票・バッチ・連携
- 実装優先度の整理
ここでは「全部必要です」と言われがちですが、本当に必要かどうかを問い直す役割もSESの重要な仕事です。
非機能要件（特に重要）
SES要件定義で軽視されやすい一方、最も炎上につながりやすい領域です。
- 性能・レスポンス
- セキュリティ
- 可用性・障害対応
- 運用・保守・監視
非機能要件は「言われていないからやらない」ではなく、論点として提示し、決定してもらうことが重要です。
SES要件定義で起こりやすいトラブルと対策
要件が際限なく増える
対策
- 要件一覧の常時可視化
- 追加要件は「別枠」で管理
- 変更履歴を残す
「それはSESが決めた」と言われる
対策
- 決定者を明文化
- 議事録・承認メールを残す
- 口頭合意を合意としない
SESなのにPM的な責任を負わされる
対策
- 契約上の立場を定期的に言語化
- 「支援範囲」と「決定範囲」を明確にする
SES要件定義で評価されるエンジニアの特徴
- 技術を「判断材料」として説明できる
- 曖昧な要望を文章に落とせる
- 勝手に決めない
- 論点を先回りして提示できる
- 境界線を丁寧に引ける
SESの上流工程では、技術力よりも思考整理力・対人調整力が評価を左右します。
まとめ
SESにおける要件定義は、
- 成果物完成を保証する工程ではない
- 顧客の意思決定を支援する工程である
- 責任範囲を明確にし続ける工程である
と言えます。
要件定義を正しく理解し、「支援」と「決定」の線を引けるSESエンジニアは、
- 炎上を避け
- 信頼を得て
- 単価・ポジションを上げやすい
という明確なメリットがあります。
以上、SESの要件定義についてでした。
最後までお読みいただき、ありがとうございました。
