スキルシートで要件定義経験を書く方法｜9項目別のOK例と書き方のポイント
skilllog要件定義に関わってきたのに、スキルシートには「要件定義を担当」としか書けていない。上流工程の経験を正しく評価してもらえないと感じているエンジニアは多いはずです。
スキルシートで要件定義経験を伝えるコツは、要件定義を背景・目的の理解から要件定義書の作成まで9つの項目に分け、担当した項目ごとに「誰と・何を・どう決めたか」を書くことです。
この記事では、スキルログで分類できる要件定義の9項目それぞれについて、見られるポイント、書く内容、そのまま参考にできるOK例をまとめました。自分が担当した項目だけ拾い読みしても使えます。
まずは担当した項目を整理するところから始めると、書くべき内容が見えてきます。スキルログに登録すれば、この9項目に沿って経験を入力できます。
「要件定義を担当」の一行では、どこまで主体的に関わったのかが伝わりません。担当した項目を特定し、項目ごとに具体的に書きましょう。
| 項目 | 見られるポイント |
|---|---|
| 背景と目的の理解 | 上流工程に関われるか |
| 要件収集 | どれだけ主体的に業務を分解・構造化できたか |
| 制約条件の定義 | プロジェクト全体を理解し、現実的な設計ができるか |
| 非機能要件の定義 | 品質・運用を考えられるか |
| データベース設計 | 業務をデータに落とし込めるか |
| 受け入れ基準の設定 | 完成の定義を作れるか |
| 変更管理プロセス | プロジェクトをコントロールできるか |
| 要件定義書の作成とレビュー | ドキュメント品質と調整力 |
| その他（上流工程の実績） | プロジェクト推進に関わる経験 |
全項目を埋める必要はありません。担当した項目だけを、プロジェクトごとに書けば十分です。スキルシート全体の書き方は【見本あり】エンジニアのスキルシートの書き方完全ガイド｜項目・記載例・NG例【2026年版】で解説しています。
目的と要件をつかむ（背景と目的・要件収集・制約条件）
要件定義の入り口となる経験です。誰から何を聞き、どう整理したかを具体的に書きます。
背景と目的の理解
見られるポイント：上流工程に関われるかを判断される項目です。
書く内容：業務の現状（As-Is）、課題（問題点・非効率）、システム化の目的（To-Be）、関係者との認識合わせの内容
OK例
営業部門および業務管理担当者へのヒアリングを実施し、受発注業務がExcel管理により属人化していること、入力ミスが月20件以上発生していることを課題として特定。現行業務フロー（As-Is）を可視化し、入力プロセスの標準化および入力チェック機能の導入によるミス削減を目的としたTo-Be像を整理。関係部署と認識合わせを行い、要件定義の前提条件を確定。
- 「現状 → 課題 → 目的 → 合意」まで書く
- As-Is / To-Beを書くと一気にプロ感が出る
- 「整理した」だけでなく
要件収集
見られるポイント：どれだけ主体的に業務を分解・構造化できたかが見られます。
書く内容：ヒアリング対象（誰に）、業務フローの分解、機能要件・画面要件・帳票要件、ユースケース（利用シナリオ）、要件の優先順位整理
OK例
営業・経理・管理部門の各担当者に対してヒアリングを実施し、現行業務フローおよび課題・要望を整理。業務プロセスを「受注登録」「承認」「請求」「入金管理」の単位で分解し、各工程ごとの入力項目・画面遷移・帳票出力要件を定義。さらに、ユースケースを整理し、業務効率化に直結する必須機能と将来的な拡張機能を優先度別に分類。
- 「誰に・何を・どこまで分解したか」を書く
- 業務単位で分解していると評価が高い
- “要件を作った”ことが伝わる書き方にする
制約条件の定義
見られるポイント：プロジェクト全体を理解し、現実的な設計ができるかが見られます。
書く内容：技術制約（既存環境・インフラ）、予算・コスト制約、スケジュール制約、外部連携や仕様制約、制約を踏まえた判断・設計内容
OK例
既存基幹システムがAWS上で稼働しているため、同一環境での構築を前提としたアーキテクチャを設計。予算上限500万円、開発期間3ヶ月以内という制約条件のもと、機能優先度に基づく段階的リリース計画を策定。また、既存システムとのデータ連携において外部APIの仕様制約（バッチ連携・更新タイミング制限）を踏まえた設計を実施。
- 「制約」＋「理由」＋「どう対応したか」まで書く
- 技術だけでなく
ここまでの項目で、自分が担当したものは見つかったでしょうか。担当した項目と案件をスキルログに登録しておくと、応募のたびに書き直す手間が省けます。
品質と完成を定義する（非機能要件・データベース設計・受け入れ基準）
「何をもって完成とするか」を決めた経験です。数値や判定基準をセットで書くと伝わります。
非機能要件の定義
見られるポイント：品質・運用を考えられるかが評価されるポイントです。
書く内容：パフォーマンス（処理速度）、セキュリティ（認証・権限）、可用性（止まりにくさ）、運用・監視要件
OK例
同時接続数やレスポンス時間（3秒以内）などのパフォーマンス要件を定義し、システム負荷を考慮した設計を実施。また、権限管理・認証方式の設計や、運用部門と連携した監視・障害対応フローを含む非機能要件の整理を担当。
- 数値や条件を書く
- セキュリティ・運用まで含める
- 「品質を担保する視点」を出す
データベース設計
見られるポイント：業務をデータに落とし込めるかが見られます。
書く内容：テーブル設計、カラム設計、リレーション設計、業務との紐づけ
OK例
業務要件をもとにユーザー・受注・商品テーブルを設計し、受注データとユーザー情報の関連性を考慮したリレーション設計を実施。また、データの整合性と拡張性を考慮し、将来的な機能追加を見据えたカラム設計を行った。
- 業務 → データの流れを書く
- リレーションを書くとレベルUP
- 「設計意図」を入れる
受け入れ基準の設定
見られるポイント：完成の定義を作れるかが見られます。
書く内容：テスト観点、正常系・異常系、成功条件、判定基準
OK例
各機能に対する受け入れ基準を定義し、正常系・異常系を含むテスト観点を整理。ユーザー確認時の判定基準（エラー表示・処理時間・入力制御）を明確化し、品質担保に貢献。
- 「何をもってOKか」を書く
- ユーザー視点を入れる
- 品質への貢献を書く
進め方と成果物（変更管理・要件定義書・その他）
プロジェクトを前に進めた経験です。調整した相手と、残した成果物を書きます。
変更管理プロセス
見られるポイント：プロジェクトをコントロールできるかが見られるポイントです。
書く内容：要件変更の対応フロー、承認プロセス、影響範囲の整理、関係者調整
OK例
要件変更時の申請・承認フローを整備し、変更内容の影響範囲（画面・帳票・データ連携）を整理。関係部署との調整を行い、スケジュールおよび開発工数への影響を踏まえた上で対応方針を決定。
- 「変更にどう対応したか」ではなく
要件定義書の作成とレビュー
見られるポイント：ドキュメント品質と調整力が見られます。
書く内容：要件定義書の作成、レビュー実施、フィードバック対応、関係者との合意形成
OK例
要件定義書の作成を担当し、業務要件・画面仕様・非機能要件を整理。関係部署とのレビューを複数回実施し、業務要件の抜け漏れや認識差異を解消。フィードバックを反映し、最終的な要件として合意形成を行った。
- 「作った」だけでなく
その他（上流工程の実績）
見られるポイント：プロジェクト推進に関わる経験を書きます。
書く内容：課題管理、ステークホルダー調整、進行管理、会議ファシリテーション
OK例
プロジェクトにおける課題管理を担当し、進捗遅延や仕様変更に対する対応策を整理。関係部署との定例会議をファシリテーションし、課題の優先順位付けおよび意思決定を支援。
- 「参加」ではなく
要件定義経験の書き方でよくあるNG例
「要件定義を担当」「ヒアリングを実施」で終わっている書き方は、関わり方の深さが伝わりません。
- 「ヒアリングを実施」→ 誰に、何を聞き、どう整理したかを書く
- 「非機能要件を定義」→ レスポンス時間などの数値や条件を書く
- 「要件定義書を作成」→ 何を整理し、誰とレビューしたかを書く
- 「仕様変更に対応」→ 影響範囲の整理や合意の取り方まで書く
まとめ
スキルシートで要件定義経験を書くときは、9つの項目から担当したものを選び、項目ごとに「誰と・何を・どう決めたか」を具体的に書きます。数値や判定基準、調整した相手まで書くと、上流工程を任せられるエンジニアとして評価されやすくなります。
スキルシートで要件定義経験を書く際によくある質問
Q1. 要件定義の経験がなくても書ける項目はありますか？
要件定義の会議に同席して議事録をまとめた、仕様の確認を担当したなど、一部でも関わった経験があれば書く価値があります。関わっていない項目は無理に書かず、実際に携わった範囲を正確に伝えましょう。
Q2. 9項目のうち、どれを優先して書くべきですか？
案件で実際に深く関わった項目を優先してください。特に非機能要件や受け入れ基準は、上流工程の経験として評価されやすい項目です。
Q3. 複数のプロジェクトで似た要件定義を担当した場合、まとめて書いてもいいですか？
基本的にはプロジェクトごとに分けて書くことをおすすめします。案件によって関係者や規模、判断の背景が異なるため、分けて書く方が経験の幅が伝わります。
Q4. 基本設計の経験はどう書けばいいですか？
基本設計も項目に分けて書くと伝わります。スキルシートで基本設計経験を書く方法｜15項目別のOK例・NG例と書き方のポイントで、項目ごとのOK例をまとめています。
ここまでの内容を踏まえて、まずは自分が担当した要件定義の項目を書き出すところから始めてみましょう。
