“要件定義経験あり”が、要件定義とは限らない

採用をさせていただいている中で「要件定義経験あります」

という職務経歴書をよく見ます。

面談や面接で詳しくお話を聞いていくと、実態はかなり違うことがあります。 

例えば、

・既存仕様の修正

・項目追加

・画面文言変更

・API項目定義

・設計書更新

これらも、現場によっては「要件定義」と表現されることがあります。

もちろん、それ自体が悪いわけではありません。

ただ、本来の要件定義とは、

“もっと曖昧なところ”から始まるものだと感じています。

現実の現場では、ユーザーから最初に出てくるのは、

「業務を効率化したい」

「入力ミスを減らしたい」

「確認工数を減らしたい」

といった“目的”です。

しかし、

何を

どう変えれば

どこが最適なのか

までは整理されていない。

そこで必要になるのが、

「業務を分解する力」

 です。

 例えば、

「この確認作業、本当に必要ですか？」

「このExcel管理、なぜ別管理なんですか？」

「承認者が2人いる理由は？」

「例外運用はどのくらいありますか？」

 と、業務を掘り下げていく。

 すると初めて、

・本当の課題

・ボトルネック

・属人化

・無駄な運用

 が見えてきます。

つまり、要件定義とは、

 “ユーザーの言葉を、そのまま仕様にすること”

 ではなく、

 “ユーザー自身も整理できていない業務を、構造化すること”

だと思います。

さらに難しいのは、

業務だけ理解しても、システムは作れないこと。

例えば、

・データ整合性

・性能

・権限

・拡張性

・保守性

・運用負荷

を考慮しないと、

“使いづらいシステム”になります。

だから現場で本当に必要とされるのは、

 「業務」と「システム」

両方を理解して橋渡しできる人

 です。

私たちは、単なる“実装者”ではなく、

・なぜその仕様なのか

・なぜその業務なのか

・なぜその運用なのか

 を考えられるエンジニアと一緒に働きたいです😊

今の市場では、AIや自動化によって、

単純実装の価値は少しずつ変わり始めています。

だからこそ今後さらに価値が上がるのは、

 “曖昧なものを整理できる人”

 です。