要件定義やベンダー折衝の経験は、職務経歴書では「要件定義を担当」の一行で終わってしまいがちです。しかし、実際にやってきたことを分解して言葉にすると、転職市場で評価されやすい具体的な強みになります。
要件定義が「初めて」だったときに感じた違和感
要件定義を初めて担当したとき、最も強く感じた違和感は「システム会社がそこは決めてくれるんじゃないのか」という思い込みでした。発注者側としては、やりたいことを伝えれば、なんとなくシステムができると考えていましたが、それでは時間をかけて質の低いものができてしまうことを実際に体感しました。
この経験から分かるのは、要件定義は「依頼する力」ではなく「自分の中で仕様を組み立てる力」だということです。曖昧なまま依頼すると、ベンダーは「決めてもらえなかった部分」を自己判断で埋めるしかなく、結果として発注者の意図とずれたものができあがります。
要件定義で実際に作っていた資料の一覧
違和感に気づいたあとは、自分が考えられる最小レベルまで要件を資料化することを意識しました。具体的には、次のような資料を複数の観点から作成しています。
| 資料 | 目的 |
|---|---|
| ユースケースのリスト | 誰が、どの場面で、何をするかを網羅する |
| ワークフロー図 | 業務の流れと判断分岐を可視化する |
| ケース別の挙動資料 | 例外ケースごとにシステムがどう動くべきかを定義する |
| テスト仕様書 | 完了条件と確認観点を事前に固定する |
仕様書やワークフローの整理だけでなく、各データがどの状態からどの状態へ遷移するかという感覚は、要件定義そのものよりも、日常的にExcelの関数を組んできた経験から培われたと感じています。データの状態管理という視点を持てると、ベンダーへの依頼内容も具体的になり、実装後の手戻りが減ります。
ベンダー折衝でトラブルが起きる本当の原因
ベンダー折衝というと「相手とどう交渉するか」のイメージが強いですが、実際にトラブルが発生する場合、その多くは発注者側の意思決定や要件定義、スケジュール管理に原因があります。
スケジュール遅延が起きそうな場面では、トラブルが表面化する前に、意思決定者と「最低限ここまでできていればよい」というMVPの範囲を先に握っておきます。発注者側でこの範囲をコントロールできていれば、ベンダー側の対応にも余裕が生まれ、行き違いが起きにくくなります。
細かな要件定義への参画と、発注者側起因での遅延を発生させないことが、ベンダーとの関係を良好に保ちながら進行管理するPMの役割だと考えています。
ベンダー起因の不具合にどう対応したか
一方で、ベンダー側の過失で不具合が発生した場合は、対応の優先順位を明確にすることを意識しています。実装中に品質の問題を見抜くのは難しく、多くはテスト工程で発覚します。
あるとき、不具合の説明資料をベンダーに作らせてしまっていることに気づきました。説明資料の作成自体に時間がかかり、修正対応が後回しになっていたのです。そこで、説明は最小限にとどめ、修正対応を最優先するよう依頼を変えたところ、不具合件数を減らすことができました。
それでも大きな不具合が継続して発生する状況があったため、その発生頻度と継続期間をベンダーに報告し、体制そのものの見直しを依頼しました。意見ははっきりと主張しつつ、まずは修正対応を完遂させ、対応してくれたことに感謝を伝えることで、長期的な信頼関係を築くようにしています。
転職市場でこの経験をどう言語化するか
要件定義やベンダー折衝の経験を伝えるときは、「担当した」という事実だけでなく、次の3点をセットで説明すると具体性が増します。
- どんな違和感や課題に気づいたか（例：依頼すればできると思っていたが、質の低いものが時間をかけてできた）
- その課題に対してどんな工夫をしたか（例：ユースケースリスト、ワークフロー図など複数観点での資料化）
- トラブル発生時にどう対応し、何が改善したか（例：説明対応を減らし修正対応を優先したことで不具合件数が減った）
「要件定義を担当した」だけでは伝わらない経験も、課題・工夫・結果という3点で分解すると、職種を問わず評価されやすい実務経験として伝えられます。
まとめ
要件定義・ベンダー折衝の経験は、担当した範囲を一行で書くのではなく、気づいた課題、工夫した資料化、トラブル対応の3点で分解すると言語化しやすくなります。
- 要件定義は「依頼する力」ではなく「自分の中で仕様を組み立てる力」
- ユースケース・ワークフロー・挙動資料・テスト仕様書など複数観点で資料化する
- ベンダー折衝のトラブルは発注者側起因が多く、MVPの先行合意で防ぎやすい
- ベンダー起因の不具合は対応の優先順位を明確にし、信頼関係を築きながら改善する
キャリア・DX人材としての相談
local-navi.jpでは、DX人材としてのキャリアの整理、要件定義・ベンダー折衝の実務経験の言語化について相談を受けています。
まずは小規模な相談から、自分の経験をどう伝えられるかを一緒に整理することも可能です。
合わせて読みたい: 事業会社のDX推進とコンサルの違い｜転職・キャリアで選ぶポイント
この記事で比較したい転職エージェント・転職サービス
記事テーマに合わせて、相性を確認しやすい転職エージェント・転職サービスを掲載しています。求人内容や成果条件は変動するため、登録前に公式サイトで最新情報を確認してください。
