はじめに
この記事では、私がエンジニア1年目に経験した初めてのプロジェクトでのミスと、そこから学んだことをシェアします。同じような境遇の方々にとって、少しでも参考になれば幸いです。
プロジェクト概要
受託開発のプロジェクトで、既存システムの機能拡張を担当しました。基本的には私一人で作業していましたが、途中から上司がサポートに入り、二人で取り組む形になりました。
自分のミスと学んだこと
1. PR管理方法の変更によるコミュニケーションロス
ミスの概要
PRの提出頻度を誤りました。当初はIssue単位でPRを出す予定でしたが、途中で機能単位に変更され、その後再びIssue単位に戻りました。PRの管理方法が二転三転したことで、混乱を招き、PRの確認が遅れてしまい、結果として開発全体の進捗にも悪影響が出ました。
解決策
まずは実際に進めてみて、その結果に基づいてフィードバックをもらうことが大切でした。お客様の要望に応えるのは当然ですが、お客さん的にも「やってみたら思っていたのと違った」は起こり得ます。そのため、お客様の反応が良くない場合は、早めに再確認をしておくと良いと思います。
また、進捗が遅れてから対応するのでは手遅れになることが多いので、早めの対応が時間の節約に繋がります。また、上司に相談することで、より効率的な方法を教えてもらえることもあります。
2. PRの重複指摘
ミスの概要
同時に二つのPRを出していた際、両方で同じ指摘を受けていました。レビュワーに余計な時間を取らせてしまいました。
解決策
指摘事項はどこかにメモとしてまとめ、PRを提出する前にチェックリストとして確認する習慣をつけました。以前のPRで指摘された内容を反映しておけば、次のPRでの修正が不要になり、効率が上がります。
また、指摘された内容が理解できない場合は、その場で確認することが大切だと思います。理解せずに放置すると、同じ指摘を繰り返されることになりかねないため、指摘の意図や背景の把握が大切だと思います。
指摘の意図を確認する際は、「相手にとってのメリット」を意識しました。「〜さんの設計思想や、指摘の意図を知ることで、同様の指摘を減らしたり、今後の開発にもその設計思想を反映することで、より良い設計のコードを作りたいと思います。」とすると、レビュワーの負担も軽減することを伝えられるので、相談しやすくなります。
3. 動作確認のパターン漏れ
ミスの概要
動作確認を行う際、自分が想定していたパターンのみを確認していましたが、パターンが複雑になると確認漏れが発生してしまいました。これが原因で、納期が迫った状況でミスが頻発し、信頼の低下につながってしまいました。
解決策
動作確認のパターンを事前にまとめておくことで、確認漏れを防ぎ、安心して確認作業を進めることができました。また、パターンを整理することで時間短縮にもつながりました。
4. 仕様の勘違いと大幅な手戻り
ミスの概要
仕様書の内容を誤解していたため、仕様変更を二度も行うことになり、既に開発した部分にも修正が必要となりました。その結果、本来不要だった工数がかかってしまいました。
解決策
「自分と相手の考えが一致していないこと」や「相手も人間でミスや勘違いがあること」を意識し続けることが重要でした。仕様書の内容に対して自分の解釈が正しいと思い込まず、会議の場で認識のすり合わせを行えるとベストだと思います。少しでも「おや？」となった箇所は、確認できるとベストかな、と思います(とはいえ、それが出来たら苦労しないのですが、、、)。
5. 迷ったら「一度作る」か「相談してみる」
ミスの概要
どこから作ればいいのか？、この設計で問題ないのか？、他にベストプラクティスはないのか？
設計や実装方法に迷った際、判断に時間をかけすぎたことで、進捗が滞り、報告する内容もなく一日が終わってしまいました。
解決策
迷ったら、一度試しに実装してみるか、相談してみることが大切だと思います。
既存の実装との兼ね合いから、想定通りの挙動をしないことは、よくあると思います。つまり、今の想定している実装方法そもそもが、不適切であるということです。
そのため、現在想定している実装のベストプラクティスを考えるより、一旦は実装してみる方が、結果的にうまくいきました。
また、進捗報告時にも、コーディングが進んでいないと、「進捗してない」ように映る可能性があります。それを避けるためにも、一旦実装するのは大切だと思いました。
また、相談も大切です。
自分が想定している設計方法では、実装に時間がかかる、コードのロジックが複雑になる。しかし、相談により良い設計を思いつくかもしれません。
ただ、この時に準備は徹底して行いました。「今悩んでいること」・「相談したいこと」・「現状の他の実装方法」・「現在想定の設計方法とその問題点」、最低この四つは準備 + 必要な資料のURLや、画面共有の準備までした上で、相談をしました。
ここでもたつくと、次の相談がしにくくなるため、準備は徹底した方がいいと思います。
終わりに
先輩のエンジニアであれば、私が犯したようなミスは未然に防いでいることが多いです。また、私よりも良い解決策も知っています。自分で考えた上で、「もっと良い方法はないか？」と尋ねることが大切だと感じました。
プロジェクトに初めて参加するエンジニアは、ミスをするのは仕方ないことだと思います。ただ、同じミスを防げるかが、大切だと感じました。
この記事が少しでも参考になれば幸いです。
もし、先輩エンジニアの方で、こうした方がいいというアドバイスがございましたら、ぜひ教えていただきたいです！