新人エンジニアが初めて要件定義の会議に出て分からなかったこと4つ
はじめに
こんにちは、たけとりと申します。
私は現在、Webエンジニアとして業務システムの開発に携わっています。
2025年に現在の会社へ転職し、エンジニアとしてはまだ1年目ですが、先日初めて要件定義の会議に参加させてもらいました。
もちろん会議を主導していくのは先輩エンジニアやPMで、私は簡単な資料作成や、顧客への簡単な説明を担当する立場で同席しました。
しかし実際に会議に参加してみると、正直な感想は…
「何を話しているのか、ほとんど分からない！」という気持ちでした。
技術の話が分からないというより、そもそも以下のように分からないことだらけでした。
- 話の流れが見えない
- 出てくる言葉が分からない
- なぜその話をしているのか分からない
この記事では、エンジニア1年目の私が 要件定義の会議に参加して実際に困ったことを、実体験をもとにまとめています。
同じように「会議についていけない…」と感じている新人エンジニアの参考になれば嬉しいです。
実際に困ったポイント4つ
①要件定義の「全体の流れ」が分からない
まず一番困ったのが、要件定義がどんな流れで進むのか分からなかったことです。
要件定義の会議は、基本的に以下のフローでさまざまな話題が出てきます。
しかし当時の私は、この流れを理解していませんでした。
そのため会議中はずっと「今は何を決めているフェーズなのか？」「この話はどこにつながるのか？」といったことが分からない状態でした。
後から振り返ると、全体像を知らないと会議の話は「点」にしか見えません。
その結果、話を聞いているのに内容が頭に残らないという状態になっていました。
②顧客の業務がまったく分からない
今回一番焦ったのが、業務知識の不足でした。
顧客との会話では、当たり前のように業務用語が出てきます。
今回の会議では、製造業の顧客から、次のような言葉が普通に使われていました。
- 棚卸
- 在庫引当
- バックオーダー
- 検収
しかし今まで製造業とは縁遠かった私は、初めて聞く単語ばかりでした。
言葉の意味がわからないと会議に全くついていけず、その都度慌てて検索していました。
たとえば「在庫引当」を調べると、「注文に対して在庫を確保する処理」のことだと分かり、ようやく会議の話が理解できるようになりました。
さらに厄介だったのが、業務の流れが頭に描けないことです。
顧客の業務知識が全くないので、
- この業務はなぜ必要なのか
- どのタイミングで使われるのか
- システムがどこで関わるのか
こういった点が頭の中でつながらず、理解が難しい状態でした。
結果として、要件の話を聞いてもピンとこないまま時間だけが過ぎるということが多かったです。
③自社サービスのことも理解できていなかった
もうひとつ大きな反省点が、自社サービスの理解不足です。
今回の案件では、自社のパッケージサービスをベースにシステムを構築していました。
しかし私はまだ経験が浅く、以下の点を十分に理解できていませんでした。
- どんな機能があるのか
- どこまで標準機能なのか
- どこからカスタマイズなのか
サービスを理解するためには、実際に画面を操作し、動作確認をして、必要なコードを読む。
そんな地道な理解の積み重ねが必要だと実感しました。
顧客に説明する立場になる前に、自分がちゃんと説明できる状態になっていないと、要件定義の会議で話についていくのは難しいです。
④要件定義は「コミュニケーション」が一番難しい
新人の私は、会議で発言する立場ではありませんでした。
それでも、先輩たちのやり取りを見ていて、コミュニケーションの難しさを強く感じました。
顧客の要望は、一回聞いただけでは認識がズレることが多いです。
そのため先輩たちは、
- 言い換えて確認する
- 認識が合っているかを何度も確認する
ということを丁寧に繰り返していました。
さらに難しいのが、「なぜその機能が必要なのか？」という背景までヒアリングすることです。
場合によっては、以下の判断や交渉も必要になります。
- 不要な機能を提案しない
- 仕様をシンプルにする
要件定義は単に要望を聞くだけのフェーズではありません。
要件を整理し、必要なものを決めていく仕事でした。
これは技術力というより、経験と業務理解がものを言う世界だと感じました。
要件定義の会議に参加してよかったこと
最初は「ついていけない」と感じることも多かったですが、参加してよかったことも確実にありました。
①顧客の業務をイメージできるようになった
開発だけをしていると、システムの利用者を具体的にイメージする機会は多くありません。
しかし要件定義の会議では、
- 顧客がどんな業務をしているのか
- どんな課題を解決したいのか
- システムがどの場面で使われるのか
を直接知ることができます。
その結果、「誰のためのシステムなのか」をより具体的に考えられるようになりました。
②自社サービスの理解が深まった
会議を通して、自社サービスの理解もより深まりました。
これまでは「発注機能」「見積機能」といったバラバラの機能として理解していました。
しかし要件定義の議論を聞くことで、それらの機能が業務フローの中でどう使われるのかが見えるようになりました。
③開発への理解も深まった
要件定義の議論を聞くことで、以下の理解が深まりました。
- 主要なマスタ
- データ同士の関係
- 業務フローとデータのつながり
その結果、開発を行う際にも
「なぜこのデータが必要なのか」
「この処理はどの業務で使われるのか」
といった背景を理解しながらコードを書くことができるようになりました。
新人エンジニアが勉強しておくと楽になること
今回の経験から、要件定義に関わるためには技術以外の知識も大切だと感じました。
業務知識を知る
顧客の業務を理解するためには、以下の学習が役立ちます。
- 業務知識の本を読む
- 実際の業務フローを学ぶ
私が実際に読んだおすすめの本がありますので、参考になれば嬉しいです。
簿記を勉強する
簿記を学ぶことで、企業の会計を知ることが出来ます。
簿記3級では商業簿記（卸売業・小売業の会計処理）の基本を、簿記2級では商業簿記に加えて工業簿記（製造業の会計処理）を学びます。
私の場合、顧客は製造業が多いので、簿記2級まで勉強する必要があると感じています。
簿記3級だけでも会計の基本用語を学べますので、興味がある方は勉強してみると役立つと思います！
まとめ：要件定義で困ったのは「技術以外」だった
エンジニア1年目で要件定義の会議に参加して、一番困ったのは技術に関する知識ではありませんでした。
むしろ難しかったのは、以下のような技術以外の部分でした。
- 要件定義の流れを知らない
- 業務知識がない
- 自社サービスを理解していない
- コミュニケーションの難しさ
正直、最初は「全然ついていけない…」と感じます。
私自身も、会議の内容を完全に理解できたとは到底言えません。
それでも、要件定義の会議に参加したことで、少しずつ分かってきたことがあります。
- 顧客の業務
- システムの役割
- エンジニアに求められるスキル
開発だけをしていると見えない「システムが使われる現場」を知れるのは、とても大きな経験だったと感じています。
