要件定義とは何かを考えたら、実務経験が求められる理由が見えてきた

「将来的には要件定義や設計までできるエンジニアになりたい」

そう考えたとき、要件定義という仕事がかなり難しく感じられた。

コードを書ければできる仕事ではない。

むしろ、コードを書く前の世界を扱う仕事なのかもしれない。

現実の問題をシステムの言葉に変える

たとえば、ある会社で、

「この業務に時間がかかりすぎている」

という問題があったとする。

これだけでは、まだシステムは作れない。

誰がその作業をしているのか。

どの部分に時間がかかっているのか。

現在はどんな手順なのか。

どこまで自動化したいのか。

例外処理はどうするのか。

誰がどんな画面を使うのか。

何ができれば「解決した」と言えるのか。

こうしたことを一つずつ整理していく必要がある。

つまり、

現実の問題

↓

業務の理解

↓

問題の分解

↓

必要な機能の言語化

↓

システムの要件

という変換が必要になる。

アプリ開発経験だけでも足りない

最初は、アプリをたくさん作れば要件定義もできるようになるのではないかと思っていた。

しかし、それだけでも足りない。

自分が好きなように作る個人開発では、自分自身がユーザーでもあり、開発者でもある。

企業のシステムではそうはいかない。

実際の業務を行っている人がいて、その人たちの言葉を理解しなければならない。

さらに、本人たちも「何が必要なのか」を完全に説明できるとは限らない。

だから、

「何に困っているのか」

を聞き、

「つまりこういうことではないか」

と仮説を立て、

さらに具体化していく必要がある。

このとき重要になるのが、自分の言葉で考える能力なのだと思う。

技術を知らなくてもいいわけではない

一方で、業務を理解できるだけでもシステムは作れない。

この問題はデータベースでどう表現するのか。

APIにする必要があるのか。

処理量が増えたときに耐えられるのか。

既存システムとどう連携するのか。

どこまでを自動化すべきなのか。

こうした判断には技術的な経験が必要になる。

だから、

「業務理解」

「言語化」

「問題分解」

「技術理解」

が少しずつ重なっていく。

要件定義という仕事が、単なる文章作成ではないことが分かってきた。

なぜ3年、5年という実務経験が求められるのか

求人票を見ていると、「実務経験3年以上」「5年以上」といった条件をよく見かける。

以前は、その年数にどれほどの意味があるのだろうと思うこともあった。

でも今は少し理解できる。

3年間Pythonを書いたという意味だけではない。

その間に、

仕様変更を経験した。

予想外のデータを見た。

障害が起きた。

他人のコードを読んだ。

設計上の問題に出会った。

ユーザーから想定外の要望が来た。

自分の判断が間違っていたこともあった。

こうした大量の具体例が頭の中に蓄積されていく。

そして新しい問題に出会ったとき、

「あのときのケースに似ている」

と判断できるようになる。

これが経験なのだと思う。

自分の言葉で考えることを続けたい

そう考えると、毎日のように自分の考えを文章にしていることも、キャリアと無関係ではない。

分からないことを分からないままにせず、

「なぜだろう」

「つまりどういうことだろう」

「具体的には何が起きているのだろう」

と自分の言葉に変えていく。

それは、要件定義にもつながる思考なのではないか。

もちろん、文章を書いているだけで要件定義ができるようになるわけではない。

業務知識も必要だ。

技術知識も必要だ。

開発経験も必要だ。

だからこそ、それらを少しずつ接続していきたい。

知識を大量に集めるのではなく、

現実を理解し、

分解し、

言葉にし、

技術へ変換する。

その力を育てていきたい。