スキルシートで要件定義経験を書く方法②｜スキルログで整理する上流工程の伝え方
skilllogスキルシートで要件定義の経験を書くとき、「どこまで書けば評価されるんだろう」と悩むことはありませんか？
「要件定義を担当」とは書いているものの、それだけで自分のレベルがちゃんと伝わっているのか、不安に感じる人も多いと思います。
実は、ここで差がつくのは非機能要件や設計まわりの経験です。
このあたりが書けているかどうかで、作業ベースで動くエンジニアなのか、設計まで考えられるエンジニアなのか、評価は大きく変わります。
本記事では、
- 非機能要件の定義
- データベース設計
- 受け入れ基準の設定
といった観点をもとに、スキルログを使って要件定義の経験をどう整理し、どう書けば伝わるのかを解説します。
要件定義をカテゴリーごとに整理できる
スキルログでは、要件定義の経験を以下のように分類できます。
- プロジェクトの背景と目的の理解
- 要件収集
- 非機能要件の定義
- 制約条件の定義
- データベース設計
- 受け入れ基準の設定
- 変更管理プロセスの確立
- 要件定義書の作成とレビュー
- その他
このように分解することで、「要件定義をやった」ではなく「どこまでできるか」が明確になります。
では、それぞれに何を書けばよいのか見ていきましょう。
関連記事：
プロジェクトの背景と目的の理解～非機能要件の定義について：スキルシートで要件定義経験を書く方法①｜スキルログで整理する上流工程の伝え方
変更管理プロセスの確立～その他について：スキルシートで要件定義経験を書く方法③｜スキルログで整理する上流工程の伝え方
スキルシート 要件定義 書き方｜非機能要件の定義
ここは、
👉 品質・運用を考えられるかが評価されるポイントです。
何を書けばいいのか
- パフォーマンス（処理速度）
- セキュリティ（認証・権限）
- 可用性（止まりにくさ）
- 運用・監視要件 など
| NG例 |
| ・非機能要件を担当 ・パフォーマンス対応 ❌ 内容が不明で評価されない |
| OK例 |
| 同時接続数やレスポンス時間（3秒以内）などのパフォーマンス要件を定義し、システム負荷を考慮した設計を実施。 また、権限管理・認証方式の設計や、運用部門と連携した監視・障害対応フローを含む非機能要件の整理を担当。 |
書き方のポイント
✅ 数値や条件を書く
✅ セキュリティ・運用まで含める
✅ 「品質を担保する視点」を出す
スキルシート 要件定義 書き方｜データベース設計
ここは、
👉 業務をデータに落とし込めるかが見られます。
何を書けばいいのか
- テーブル設計
- カラム設計
- リレーション設計
- 業務との紐づけ など
| NG例 |
| ・DB設計を担当 ❌ レベルが伝わらない |
| OK例 |
| 業務要件をもとにユーザー・受注・商品テーブルを設計し、受注データとユーザー情報の関連性を考慮したリレーション設計を実施。 また、データの整合性と拡張性を考慮し、将来的な機能追加を見据えたカラム設計を行った。 |
書き方のポイント
✅ 業務 → データの流れを書く
✅ リレーションを書くとレベルUP
✅ 「設計意図」を入れる
スキルシート 要件定義 書き方｜受け入れ基準の設定
ここは、
👉 「完成の定義」を作れるかが見られます。
何を書けばいいのか
- テスト観点
- 正常系・異常系
- 成功条件
- 判定基準 など
| NG例 |
| ・テスト対応を実施 ❌ 作業レベルで止まっている |
| OK例 |
| 各機能に対する受け入れ基準を定義し、正常系・異常系を含むテスト観点を整理。 ユーザー確認時の判定基準（エラー表示・処理時間・入力制御）を明確化し、品質担保に貢献。 |
書き方のポイント
✅ 「何をもってOKか」を書く
✅ ユーザー視点を入れる
✅ 品質への貢献を書く
まとめ
スキルシートで要件定義の経験を書く際は、
👉 非機能要件・DB設計・受け入れ基準のような設計領域を書くことで評価が大きく変わります。
作業ではなく、
👉 品質や設計にどう関わったかを書くことが重要です。
もし、
- 自分の要件定義経験をどう書けばいいか分からない
- スキルシートを見直したい
- 上流工程の経験をうまく伝えたい
と感じている方は、スキルログを使って整理してみてください。
また、より具体的に整理したい方は、Web面談も可能です。
✉️ お問い合わせフォームよりお気軽にご相談ください。
なお、次の記事では
変更管理プロセス・変更管理プロセス・上流工程の実績の見せ方を解説します。
上流工程として評価されたい方は、ぜひ続けてご覧ください。
