スキルシートで要件定義経験を書く方法①｜スキルログで整理する上流工程の伝え方
skilllogスキルシートで要件定義の経験を書くとき、「何を書けばいいのか分からない」と手が止まることはありませんか？
実際、「要件定義を担当」とだけ書いてしまい、何ができるのか伝わらないケースは少なくありません。
評価されるポイントはシンプルです。
どこまで考え、何を整理したか。
この記事では、スキルログを使った整理方法をベースに、要件定義経験の正しい書き方を解説します。
要件定義をカテゴリーごとに整理できる
スキルログでは、要件定義の経験を以下のように分類できます。
- プロジェクトの背景と目的の理解
- 要件収集
- 非機能要件の定義
- 制約条件の定義
- データベース設計
- 受け入れ基準の設定
- 変更管理プロセスの確立
- 要件定義書の作成とレビュー
- その他
このように分解することで、
「要件定義をやった」ではなく「どこまでできるか」が明確になります。
では、それぞれに何を書けばよいのか見ていきましょう。
関連記事：
制約条件の定義～受け入れ基準の設定について：スキルシートで要件定義経験を書く方法②｜スキルログで整理する上流工程の伝え方
変更管理プロセスの確立～その他について：スキルシートで要件定義経験を書く方法③｜スキルログで整理する上流工程の伝え方
スキルシートでの要件定義の書き方｜背景と目的の理解
ここは、
👉 上流工程に関われるかを判断される重要な項目です。
何を書けばいいのか
- 業務の現状（As-Is）
- 課題（問題点・非効率）
- システム化の目的（To-Be）
- 関係者との認識合わせの内容 など
| NG例 |
| ・プロジェクトの背景を理解 ・業務課題を整理 ❌ 抽象的で「何をしたか」が伝わらない |
| OK例 |
| 営業部門および業務管理担当者へのヒアリングを実施し、受発注業務がExcel管理により属人化していること、入力ミスが月20件以上発生していることを課題として特定。 現行業務フロー（As-Is）を可視化し、入力プロセスの標準化および入力チェック機能の導入によるミス削減を目的としたTo-Be像を整理。 関係部署と認識合わせを行い、要件定義の前提条件を確定。 |
書き方のポイント
✅「現状 → 課題 → 目的 → 合意」まで書く
✅ As-Is / To-Beを書くと一気にプロ感が出る
✅「整理した」だけでなく意思決定に関わったことを書く
スキルシート 要件定義 書き方｜要件収集のポイント
ここは、
👉 どれだけ主体的に業務を分解・構造化できたかが見られます。
何を書けばいいのか
- ヒアリング対象（誰に）
- 業務フローの分解
- 機能要件・画面要件・帳票要件
- ユースケース（利用シナリオ）
- 要件の優先順位整理 など
| NG例 |
| ・要件収集を担当 ・ヒアリングを実施 ❌ 作業しか書いておらず、成果が見えない |
| OK例 |
| 営業・経理・管理部門の各担当者に対してヒアリングを実施し、現行業務フローおよび課題・要望を整理。 業務プロセスを「受注登録」「承認」「請求」「入金管理」の単位で分解し、各工程ごとの入力項目・画面遷移・帳票出力要件を定義。 さらに、ユースケースを整理し、業務効率化に直結する必須機能と将来的な拡張機能を優先度別に分類。 |
書き方のポイント
✅「誰に・何を・どこまで分解したか」を書く
✅ 業務単位で分解していると評価が高い
✅ “要件を作った”ことが伝わる書き方にする
スキルシート 要件定義 書き方｜制約条件の定義
ここは、
👉 プロジェクト全体を理解し、現実的な設計ができるかが見られます。
何を書けばいいのか
- 技術制約（既存環境・インフラ）
- 予算・コスト制約
- スケジュール制約
- 外部連携や仕様制約
- 制約を踏まえた判断・設計内容 など
| NG例 |
| ・AWSを使用 ・制約条件を考慮 ❌ 理由・判断がなく、レベルが低く見える |
| OK例 |
| 既存基幹システムがAWS上で稼働しているため、同一環境での構築を前提としたアーキテクチャを設計。 予算上限500万円、開発期間3ヶ月以内という制約条件のもと、機能優先度に基づく段階的リリース計画を策定。 また、既存システムとのデータ連携において外部APIの仕様制約（バッチ連携・更新タイミング制限）を踏まえた設計を実施。 |
書き方のポイント
✅「制約」＋「理由」＋「どう対応したか」まで書く
✅ 技術だけでなくビジネス制約を書くと評価UP
✅ 制約の中で意思決定したことを書く
スキルシートで要件定義経験を書く際によくある質問
Q1. 要件定義の経験がなくても書ける項目はありますか？
直接担当していなくても、実装や保守を通じて要件定義の内容を理解し、判断の背景を説明できる経験があれば触れる価値があります。関わっていない項目は無理に書かず、実際に携わった範囲を正確に伝えることを優先しましょう。
Q2.「要件収集」と「制約条件の定義」、どちらを優先して書くべきですか？
案件で実際に深く関わった方、あるいは今後アピールしたい技術に近い方を優先してください。両方を浅く並べるより、どちらか1つを具体的な判断理由まで含めて書く方が説得力が増します。
Q3. 複数のプロジェクトで似た設計を担当した場合、まとめて書いてもいいですか？
基本的にはプロジェクトごとに分けて書くことをおすすめします。同じ設計項目でも案件によって規模・難易度・判断の背景が異なるため、まとめてしまうと個々の経験の深さが伝わりにくくなります。
Q4. このシリーズは全部読む必要がありますか？
いいえ、自分が実際に担当した設計項目に関する回だけで十分です。各回で扱う項目が異なるため、見出しを確認して必要な部分だけ参照してください。
まとめ
要件定義の経験は、「担当した」ではなく
どこまで考え、何を整理したかで評価が変わります。
背景・要件収集・制約条件のように分解し、具体的な業務や判断まで書くことで、「設計できるエンジニア」として伝わります。
もし、
- 自分の要件定義経験をどう書けばいいか分からない
- スキルシートを見直したい
- 上流工程の経験をうまく伝えたい
と感じている方は、スキルログを使って整理してみてください。
また、より具体的に整理したい方は、Web面談も可能です。
✉️ お問い合わせフォームよりお気軽にご相談ください。
なお、次の記事では
非機能要件・データベース設計・受け入れ基準といった、さらに評価に差がつくカテゴリの書き方を解説します。
「設計力」をしっかり伝えたい方は、ぜひ続けてご覧ください。
