「要件定義できます」の中身を疑う
エンジニアのスキルシートや職務経歴書に「要件定義」と書かれていることは珍しくありません。
しかし、実際にプロジェクトで「要件定義をお願いします」と言われたとき、本当にそれに応えられるエンジニアがどれだけいるか。私個人として30年近くSIの現場を見てきた立場から率直に言えば、「要件定義できます」と「実際にできる」の間には、かなりの距離があるケースが多いと感じています。
その原因は、エンジニア個人の能力の問題ではありません。「要件定義」という言葉自体が、業界の中であまりにも広い意味で使われていることが根本にあります。
要件定義と変更仕様書は違う
結論から言うと、多くのエンジニアが「要件定義」と呼んでいる作業は、厳密には 変更仕様書の作成 、つまり基本設計に近い工程です。
要件定義（本来の意味）：業務をシステムに変換する仕事
本来の要件定義とは、顧客の業務課題をシステム要件に変換する工程です。新しい業務システムの構築や、これまで手作業だったプロセスをシステム化するときに行います。
この工程では、顧客は「業務の言葉」で話します。「月末の締め処理に3日かかっている」「得意先ごとに単価テーブルが違って管理が煩雑だ」「紙の申請書をなくしたい」。こうした言葉を受けて、それをシステム要件に変換しなければなりません。
ここが本質的に難しいのは、 顧客は業務のプロであってシステムのプロではなく、エンジニアはシステムのプロであって業務のプロではない からです。顧客が語る業務の言葉には「当たり前すぎて言語化されない前提」が大量に含まれています。一方で、システム化に必要な情報は大幅に抜け落ちている。
この仕事は、本質的にコンサルタントの領域です。業務分析をし、現行フローを可視化し、あるべき姿を顧客と描き、そこからシステム要件を導き出す。エンジニアとしてのキャリアの延長線上に自然と到達するものではなく、ビジネスドメインの知識という別の軸が必要になります。
変更仕様書の作成：既存システムに何かを追加・変更する仕事
一方、多くのエンジニアが現場で「要件定義」と呼んでいるのは、既存システムに対する機能追加や変更の仕様を整理する作業です。
「この画面にこの検索条件を追加したい」「このバッチの実行タイミングを変えたい」「この帳票にこの項目を出したい」。顧客がシステムの文脈で話をしていて、それをシステムの仕様変更として整理する。
これは重要な仕事ですし、高いスキルが要求されます。しかし、工程の性質としては 基本設計に近い ものです。顧客の要望を仕様に落とし込む作業であり、業務からシステム要件を「起こす」作業とは本質的に異なります。
この混同がなぜ問題なのか
「要件定義」と「変更仕様書の作成」の混同は、以下のような形で実害を生んでいます。
ひとつは、エンジニア本人のキャリア認識のズレです。変更仕様書の作成経験を「要件定義ができる」と認識したまま、本来の意味での要件定義が求められるプロジェクトに参画してしまう。顧客は業務の言葉で話すのに、エンジニアはシステムの言葉で受け取ろうとする。両者の間に翻訳者がいないまま進むプロジェクトがどうなるかは、経験者なら想像がつくでしょう。
もうひとつは、プロジェクトのアサインメントの問題です。「要件定義経験あり」のエンジニアを調達したつもりが、実際には変更仕様の整理しか経験がなかった。プロジェクトが佳境に入ってからこのギャップが発覚すると、取り返しがつきません。
エンジニアが目指すべき上流スキルの現実的な道筋
では、エンジニアは上流工程に関わることを諦めるべきなのか。そうではありません。大事なのは、 自分が今どこにいて、次に何を目指すかの解像度を上げる ことです。
ステップ1：変更仕様の整理を高いレベルでこなす
まず目指すべきは、既存システムに対する変更仕様の整理を、正確かつ網羅的にできるプロフェッショナルになることです。
具体的には、3つの力を高いレベルで発揮できることが求められます。
ひとつめは、顧客の「こうしたい」という要望を受けて、既存システムへの影響範囲を正確に見極める力。たとえば「会員ステータスの定義を見直したい」という一言の裏に、認証・決済・履歴集計・帳票出力といった波及領域を即座にマッピングできる力です。
ふたつめは、変更が他の機能やデータに及ぼす副作用を事前に洗い出す力。ある集計ロジックを修正したとき、月次バッチの実行時間が伸びて翌朝の帳票配信に間に合わなくなる、といった連鎖を顧客に渡す前に潰しておく力です。
みっつめは、複数の実現アプローチを提示し、コストと効果のトレードオフを説明できる力。「DB構造を変えれば3日で実装できるが、既存連携10システムの改修が連鎖する」「画面側で吸収すれば改修範囲は限定的だが、運用フローに負荷が残る」といった選択肢を整理し、判断材料として顧客に渡せる力です。
これは設計や実装の経験を積んだエンジニアだからこそ発揮できるスキルです。コンサルタントにはできません。たとえば顧客から「この処理をリアルタイム化したい」と言われたとき、現行のDBトランザクション設計や既存APIのレスポンス契約まで踏まえて、「その方向で進めると呼び出し元の複数システムに改修が連鎖して非現実的」「代わりに5分間隔の準リアルタイム構成にすれば、コストを抑えつつ業務要件は満たせる」と即座に判断できる。これは、システムの内部構造を深く理解している人間にしか出せない答えです。
高いレベルでこれをこなせる人材こそ、現場が本当に求めているエンジニアです。なお、変更仕様の整理は最終的にPLが担う「翻訳」の中核を成す作業でもあります。仕様変換を含むPLの翻訳力の全体像はこれからのPLに求められる「翻訳力」とはで扱っています。
ステップ2：担当システムの業務理解を深める
変更仕様の整理で力をつけたエンジニアが次に意識すべきは、システムの裏側にある業務への理解を深めることです。
「この画面は誰がいつどんな場面で使うのか」「このデータはどの業務プロセスから生まれるのか」「この帳票を受け取った人は何を判断するのか」。こうした問いを自分に投げかける習慣をつけることで、仕様の整理精度が格段に上がります。なぜなら、変更による業務影響を事前に予測できるようになり、後出しの修正依頼や運用上のトラブルを大きく減らせるからです。
顧客先に常駐しているなら、業務部門の人と雑談する機会を意識的に作ってみてください。驚くほど多くの「仕様の背景」が見えてきます。
たとえば経理担当者との立ち話で「月末は紙の伝票が2部署を経由してから入力される」と聞いて初めて、「なぜ月初にデータ入力が集中するのか」というシステム挙動の理由が腹落ちする。こうした業務の実態を知っているかどうかで、「月初のバッチ実行タイミングを後ろ倒しすれば足りる」のか、「そもそも紙の運用を前提としたデータ取り込み設計を見直すべき」なのか、提案の方向性がまったく変わってきます。仕様書には書かれない情報こそ、上流の判断を変える材料になります。
ステップ3：本来の要件定義に挑む（ただし覚悟を持って）
業務理解が深まったエンジニアが、本来の意味での要件定義に参画するチャンスが来ることがあります。しかしそこには、エンジニアスキルの延長ではなく、ビジネスドメインの知識を自ら積み上げてきた結果としての覚悟が必要です。
そして、コンサル経験のあるPMやビジネスアナリストと組んで進めるのが現実的な形です。一人で全部やろうとせず、自分の強み（技術とシステム理解）と、相手の強み（業務分析と合意形成）を組み合わせてプロジェクトを回す。この協働ができるエンジニアは、間違いなく市場で強い存在になります。
「できます」ではなく「何ができるか」を語れるエンジニアへ
この記事で伝えたいのは、要件定義を「できる・できない」の二択で語ることの危うさです。
「要件定義できます」とひとくくりに言うのではなく、「既存システムのこの領域であれば、顧客との仕様整理から設計への落とし込みまで対応できます」「業務フローの分析から入る新規案件では、コンサル的なリードが別に必要です」と言える。
この正直さと解像度の高さこそが、プロジェクトマネージャーや顧客から信頼されるエンジニアの条件です。
まとめ
エンジニアとしての着実なキャリアの積み方は、まず変更仕様の整理のプロフェッショナルになり、その上で業務理解を深め、いずれ本来の要件定義に挑める力を養うことです。そして何より、「何ができるか」を正確に語れること。それが、現場で信頼される条件だと私たちは考えています。
スーパーソフトウエアが考える「任される」の意味
スーパーソフトウエアでは、エンジニアに「何でもできる」ことを求めていません。自分の強みと限界を理解し、できることを確実にやり切る。その上で、少しずつ守備範囲を広げていく。その積み重ねの先に「任される」領域が自然と広がっていく。それが私たちの考えるキャリアの形です。
大規模SIプロジェクトの現場で、正直に、着実にスキルを広げていきたいエンジニアを募集しています。
この記事のテーマについて、もっと話を聞いてみたい方へ：
- カジュアル面談を申し込む — 30〜45分のオンライン面談
- 募集職種を見る — 上流SE・要件定義系の求人一覧
- SESエンジニアが上流工程に進むためのロードマップ — SES形態のまま上流工程・PL役割へ動く5ステップ
- これからのPLに求められる「翻訳力」とは — PLが日々向き合う3つの翻訳の解説
- 他のキャリア記事を読む — PL／上流工程／キャリアに関する他の記事
