「要件定義って何から手をつければいいの？」「お客様の話を聞いてまとめるだけ、ではうまくいかない…」上流工程に初めて挑戦するSEから、よく聞かれる悩みです。
要件定義は、システム開発プロジェクトの成否を最も大きく左右する工程です。ここでの認識ズレや漏れは、後工程で何倍ものコストとなって跳ね返ってきます。逆に、要件定義を質高くこなせるSEは、業界で長期的に重宝される人材になれます。
この記事では、金融系の大規模システム開発で要件定義を担当してきたテンファイブのメンバーの実務知見をもとに、初心者SEが押さえるべき要件定義のやり方を体系的に解説します。
要件定義とは何か・なぜ重要か
要件定義とは、「ユーザーが本当に欲しいシステム」を言語化し、開発側と合意するプロセスです。具体的には以下を明確化します。
- システムで実現したい業務（業務要件）
- システムが提供すべき機能（機能要件）
- 性能・セキュリティ・可用性などの品質基準（非機能要件）
- 制約条件・前提条件
- スコープ（やること・やらないこと）
要件定義がなぜ重要かというと、開発の手戻りコストはフェーズが進むほど指数関数的に増大するからです。要件定義段階で見つけた問題の修正コストを「1」とすると、設計段階では「5」、コーディング段階では「10」、テスト段階では「20」、本番稼働後では「100」以上というデータもあります（バリー・ベームの研究より）。
つまり、要件定義に時間をかけることは「ケチる」のではなく「投資する」べき領域なのです。
要件定義の基本的な流れ（ステップ1〜5）
ステップ1: ヒアリング準備
いきなりお客様に会いに行ってはいけません。事前準備が要件定義の質の8割を決めます。
事前にやるべきことは以下です。
- お客様の業界・ビジネスモデルの理解
- 既存システムの構成・課題の把握
- 現行業務フローの仮説作成
- ヒアリング項目リストの作成
- ステークホルダー（誰が意思決定者か）の整理
特に金融系の場合、業務用語・規制・帳票の知識がないと話についていけません。簿記や証券外務員の基礎、保険業法など、最低限の業務知識は事前に学習しておきましょう。
ステップ2: ヒアリング実施
ヒアリングのコツは「聞く」より「引き出す」ことです。お客様自身も「何が欲しいか」を完全には言語化できていないケースがほとんどです。
効果的な質問の型を3つ紹介します。
1. As-Is / To-Be型
「いま、この業務はどのように行っていますか？（As-Is）」「将来的にはどうしたいですか？（To-Be）」と現状と理想を分けて聞く。
2. 5W1H型
誰が（Who）、いつ（When）、どこで（Where）、何を（What）、なぜ（Why）、どのように（How）を網羅的に確認する。
3. 例外シナリオ型
「うまくいかないケースはありますか？」「イレギュラーな対応はどう処理していますか？」と異常系を掘り下げる。
ヒアリングは1回で終わらせず、2〜3回に分けて深掘りしていくのが鉄則です。
ステップ3: 業務フロー・データフロー整理
ヒアリング内容をもとに、現行業務フロー（As-Is）と新業務フロー（To-Be）を可視化します。
使用するツール・記法は以下が一般的です。
- BPMN（ビジネスプロセスモデリング表記）
- アクティビティ図
- DFD（データフロー図）
- ユースケース図
ここで重要なのは「業務とシステムを分けて記述する」ことです。「誰の業務か（人 or システム）」「どこで情報が分岐・統合されるか」を明確にすることで、後工程の設計が格段にスムーズになります。
ステップ4: 要件の抽出・分類
業務フローから要件を抽出し、以下の3カテゴリに分類します。
1. 機能要件
システムが提供すべき機能。例：「顧客情報を登録できる」「取引履歴を検索できる」「月次レポートをPDF出力できる」。
2. 非機能要件
性能・可用性・セキュリティ・運用性などの品質基準。IPA（情報処理推進機構）の「非機能要求グレード」を参考にすると抜け漏れを防げます。
3. 制約条件
予算・納期・既存システム連携・法規制・社内規定など、開発の前提となる縛り。
抽出した要件には必ず「要件ID」を付与し、トレーサビリティ（後工程の設計書・テストケースとの紐付け）を確保しましょう。
ステップ5: 要件定義書の作成・合意
最後に、これまでの内容を要件定義書としてまとめ、お客様と正式に合意します。
合意プロセスで重要なのは以下の3点です。
- 「やること」だけでなく「やらないこと」も明記する
- 曖昧な表現（「迅速に」「適切に」など）は数値・条件で具体化する
- 議事録・変更履歴を残し、誰が・いつ・何に合意したかを追跡可能にする
要件定義書への押印・承認をもって、後工程へ進む権利が発生します。
要件定義書の書き方・必須項目
要件定義書には決まった様式はありませんが、一般的に以下の項目を盛り込みます。
| 章 | 内容 |
|---|---|
| 1. プロジェクト概要 | 背景・目的・スコープ・体制 |
| 2. 業務要件 | As-Is業務、To-Be業務、業務フロー |
| 3. 機能要件 | 機能一覧、機能詳細、画面・帳票・外部I/F |
| 4. 非機能要件 | 性能、可用性、セキュリティ、運用 |
| 5. システム構成 | 概念構成図、利用技術、外部連携 |
| 6. 制約・前提 | 開発期間、予算、法規制、前提条件 |
| 7. 用語集 | 業務用語、システム用語の定義 |
| 8. 課題・リスク | 未解決事項、想定リスク |
このうち特に手を抜きがちなのが「用語集」と「やらないことの明記」です。これらを丁寧に書くだけで、後工程のトラブルは半減します。
要件定義でよくある失敗パターン
失敗1: ヒアリングしすぎて要件が肥大化する
「念のため」「あったらいいな」を全部要件に入れると、予算・納期がパンクします。MoSCoW分析（Must / Should / Could / Won’t）で優先度を仕分けし、本当に必要なものに絞りましょう。
失敗2: 業務側と情シス側で意見が割れる
業務部門は「使いやすさ」、情シスは「保守性・セキュリティ」を重視するため、意見が対立しやすい構造があります。両者を別々にヒアリングするだけでなく、合同のワークショップで合意形成を進めるのが効果的です。
失敗3: 非機能要件を後回しにする
「とりあえず動けばいい」と機能要件ばかり詰めて、性能・可用性・セキュリティを軽視すると、後工程で大きな手戻りが発生します。非機能要件は機能要件と並行して定義しましょう。
失敗4: 決裁者不在のまま進める
現場担当者と合意しても、決裁者（部長・役員）から後でちゃぶ台返しされるケースは少なくありません。要件定義の初期段階で「最終承認者は誰か」を必ず確認しましょう。
失敗5: ドキュメントだけ立派で実態が伴わない
要件定義書のページ数を稼ぐことが目的化すると、現場で読まれないドキュメントが量産されます。「誰が・いつ・どう使うドキュメントか」を意識して、必要十分な粒度に整えましょう。
要件定義スキルを活かせる金融系案件
要件定義は、すべての業界で必要とされるスキルですが、なかでも金融業界では特に高い水準が求められます。
1. 業務が複雑で多層構造
銀行・証券・保険には、独自の業務フロー・帳票・規制が存在します。これらを正確にモデリングできるSEは、業界内で長く重宝されます。
2. 規制対応が要件に組み込まれる
金融商品取引法、銀行法、個人情報保護法、マネロン対策など、法令要件を漏れなく要件定義に組み込む経験が積めます。
3. ステークホルダーが多層的
業務部門、リスク管理部門、コンプライアンス部門、情シス、外部監査人など、多様な関係者との調整経験を積めます。
こうした経験を持つSEは、金融業界はもちろん、他業界に転じても「上流工程に強いSE」として高く評価されます。
テンファイブで上流工程のプロフェッショナルを目指しませんか
テンファイブは、金融IT特化のSES企業として、大手金融機関の要件定義・基本設計・PMO案件を豊富に保有しています。
- 要件定義経験を積みたい中堅SE
- コーディングからキャリアの幅を広げたい方
- 金融業務知識を活かしてSEとして専門性を高めたい方
それぞれのキャリアステージに合わせた案件をご紹介しています。「要件定義はやったことがないけれど挑戦したい」というご相談も歓迎です。
まずはお気軽に採用ページからお問い合わせください。あなたのキャリアの次の一歩を、テンファイブが伴走します。
採用情報更新中！
Wantedlyでメンバーのインタビュー公開中！ぜひご覧ください。
