この春からIT業界で働くことになった新人エンジニアです！
現在受講している新入社員向けIT研修の様子を「新人エンジニア成長記」として発信中！
今回は第7回として、JavaでのWebアプリ開発プロジェクトを通じて、「コードを書く前に、もっとも大切だと実感したこと」についてお話しします。
それは、ズバリ「伝える力」でした。
ただコードを書くのではなく、チーム、顧客で認識を共有しながら開発を進める上で、「伝わる表現」「分かりやすい資料」がいかに重要かを痛感しました。
この記事を通して、未経験エンジニアが陥りやすい「伝わったつもり」の落とし穴と、チームでの情報共有をスムーズにするコツをお伝えします。
要件定義で直面した「明記しなければ伝わらない」問題
今回のプロジェクトでは、ただプログラムを書くのではなく、要件定義から外部設計、そして実装まで一貫して自分たちで担当しました。
最初の山場は、要件定義書の作成。
「顧客のニーズを正しく言語化し、誤解なく文書化する」という工程です。例として下記の画像のようなものが要件定義書になります。
私たちのチームは、ログイン機能に「IDとパスワードを入力してログインする」と要件に記載しました。
しかし、講師からのフィードバックは鋭いものでした。
「その文面だと、適当なIDでもログインできるって意味にもとれるよ？」
たしかに、「DB内のデータと完全一致しなければログインできない」とは一言も書いていなかったのです。
この一言で、「自分たちの中では当たり前だと思っていた前提」が、他人には通じないことを痛感しました。
外部設計で深まった「伝える力」の難しさ
要件定義の次は、外部設計フェーズへ。
ここでは、画面遷移図や画面定義書を作成しました。 例として下記の画像のようなものが画面遷移図、画面定義書になります。
画面遷移図 
画面定義書
しかし、ここでも「伝えることの難しさ」に直面しました。
特に印象的だったのが、画面遷移図の作成です。
チーム内の人、それぞれが図を作ってみたところ──
- 矢印の向きや形が人によって違う
- 「戻る」「次へ」などの言葉が曖昧
- 操作の流れも見る人によって解釈がバラバラ
どの図も、「自分には意味が通じる」けれど他の人には伝わらない、そんな状態でした。
メンバーの中には「自分の図はこれで伝わると思ったのに…」と戸惑う声もありました。
このままでは設計資料として成立しないと感じ、私たちはルールを話し合って統一することにしました：
- 操作名は「クリック」「入力」など動作を具体的に書く
- 遷移先は、矢印とラベルで明確にする
- 記号や表現のスタイルは全員で合わせる
この改善を経て、ようやく「見た人全員に同じ内容が伝わる」図になりました。
まとめ
今回のプロジェクトで私が強く感じたのは、「伝える力」の重要性です。具体的には、次の3つのポイントが大切だと学びました。
- 要件定義では、開発メンバーと顧客との間にある認識の違いを丁寧に言語化し、認識のズレをなくす力が求められること
自分たちの「当たり前」は他の人には伝わらないことを痛感しました。 - 外部設計では、曖昧な表現を排除し、誰が読んでも同じ理解ができるように図や文書を統一して作ることが重要であること。
ルールを決めずに進めると、混乱や手戻りが増え、開発効率が落ちてしまいます。 - 「これくらいは分かるだろう」という思い込みは非常に危険であること。
自分が伝えたつもりでも、相手に伝わっていなければ意味がありません。
この経験から、「伝えたつもり」と「伝わった」はまったく違うという現実を改めて認識しました。エンジニアは単にコードを書く技術者ではなく、良い成果を生み出すために、正確に意図を伝え、チームと顧客との間の共通理解を築くことが求められる存在です。
手戻りの少ない開発やスムーズな実装、信頼される設計書の土台には、確かな「伝える力」があります。だからこそ、私は今後も資料作成や認識のすり合わせをおろそかにせず、技術力と共に“伝える力”を磨き続けるエンジニアを目指していきます。
今回の内容が、同じ新人エンジニアの方などの参考になれば幸いです。
次回も、実践を通じて得た気づきや成長を記録していきますので、ぜひまた読みにきていただけたら嬉しいです！
コメント