46
46

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ジュニアエンジニアが学んだ「認識のズレ」を防ぐ開発の進め方

Last updated at Posted at 2025-06-13

エンジニアとして働き始めて半年、業務の中で痛い失敗を経験しました。しかし、この失敗から学んだことは今後の開発ライフを大きく変える重要な気づきとなりました。今回は、その体験談と学んだ教訓、そして実践的な改善策について共有したいと思います。

起きてしまった出来事

ある日、比較的大規模な改修タスクが私に割り当てられました。工数見積もりは約2週間という、新人の私にとってはかなりチャレンジングなものでした。

私なりにタスクの内容を理解し、実装計画を立案。GitHub issueに詳細を記載し、PMにもリンクを共有して開発をスタートしました。「きちんと計画を立てて、共有もしている。これなら大丈夫だろう」と思っていました。

しかし、開発最終日の前日、衝撃的な事実が判明します。私の理解とPMの想定していた実装内容に大きな齟齬があったのです。

「え?そこの機能も必要だったんですか?」
「いや、逆にその部分は今回の対象外です」

まさに青天の霹靂。急遽実装をやり直すことになりました。幸い修正範囲がそれほど大きくなかったため、なんとか期限内に完了できましたが、心身ともにかなりのダメージを受けました。

失敗から見えた根本的な問題

この失敗を振り返って気づいたのは、「共有したつもり」になっていたという点でした。

確かにGitHub issueにタスクを登録し、PMにリンクも送っていました。しかし、それだけでは全く不十分だったのです。一方的に情報を投げただけで、相手がその内容を正しく理解しているか、自分の理解が正しいかを確認していませんでした。

「実装計画を立てて共有する」だけでなく、「この理解で合っていますか?」と明確に確認を取るべきだったのです。

「認識のズレ」はなぜ生まれるのか

PMと開発者の間に認識のズレが生まれるのは、実は当然のことです。それぞれが持っている背景情報や専門知識に違いがあるからです。

PMの視点

  • プロジェクト全体の仕様や要件への深い理解
  • ビジネス要件や顧客ニーズの把握
  • スケジュールや優先度の管理

開発者の視点

  • 実装の技術的詳細への理解
  • コードベースの構造や制約の把握
  • 開発工数や技術的リスクの評価

この知識のギャップが「開発上の過不足」を生み出します

例えば:

  • 開発者の仕様理解に漏れがある → 「え!そこも開発しなきゃいけなかったんですか!」
  • 開発者が過剰に開発を進める → 「え!そこは必要なかったんですか!」

特にジュニアエンジニアは「どう開発を進めればいいか」という経験則が不足しているため、このような事態に陥りやすいのです。

具体的な改善策

1. タスク開始時の確認ポイント

タスクを受け取ったら、以下の点を必ず確認するようにしました:

実装計画の妥当性
「この実装計画で進めて問題ないでしょうか?理解に間違いはありませんか?」

ゴールの明確化
「最終的にどのような状態になっていればタスク完了と言えるでしょうか?」

テストケースの確認
「どのようなテストケースを考慮すべきでしょうか?エッジケースで気をつけるべき点はありますか?」

2. 定期的な進捗共有

実装中も定期的(1-2日に1回程度)に進捗を共有し、方向性が間違っていないかを確認するようにしました。これにより、仮に認識のズレがあっても早期に修正できます。

効率的な共有を支援するツール

Awesome Screenshot

Google Chromeの拡張機能で、画面キャプチャとその場での編集が可能です。矢印やテキストを追加できるため、視覚的に分かりやすい資料を素早く作成できます。実装予定の画面や機能を図解で説明する際に重宝しています。

こんな感じで使ってます

Qiita用.png

Claude(ブラウザ版)

AIツールですが、PM側から開発者への要件伝達にも活用できます。デザインが固まっていない段階で、PMが「こんな感じの画面を作ってほしい」と大まかな要件をClaudeに伝えるだけで、HTMLやReactコンポーネントのプロトタイプを生成してもらえます。これを開発者と共有することで、PMの頭の中にある完成イメージを具体的かつ視覚的に伝えることができます。
実際にPMの方にも試してもらったところ、技術的な知識がなくても直感的に使えて、かなり実用的なUIを生成してくれるとのことでした。開発者としても、言葉だけの説明より格段に理解しやすくなります。

「管理画面のUI作って 必要なのはユーザー、商品、クーポンのカラムと、ログイン画面とログアウトボタン。サイドバーで移動できる感じがいいかも」

上記のプロンプトで、こんな感じのUIをすぐに作成してくれます

qiita_4.png
qiita_3.png

まとめ:効率的な開発のために

今回の失敗から学んだ最も重要なことは、「認識のズレをなくす作業」が開発効率に直結するということです。

一見すると余計な手間に思えるかもしれませんが、後戻りや手戻りのリスクを考えれば、初期段階でのコミュニケーションコストは十分に見合うものです。

特にジュニアエンジニアの方には、以下を心がけることをおすすめします:

  • タスクを受け取ったら、理解した内容を必ず言語化して確認を取る
  • 実装中も定期的に進捗と方向性を共有する
  • 便利なツールを活用して、視覚的で分かりやすいコミュニケーションを心がける

当たり前のことかもしれませんが、実際にできているかどうかは別問題です。私自身、この経験を通じて改めてコミュニケーションの重要性を実感しました。

皆さんも効率的で安心な開発ライフを送っていきましょう!

46
46
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
46
46

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?