はじめに
おつかれさまです〜！
フロントエンドとバックエンドのエンジニアをしております。佐々木です。
今回は、エンジニア4年目が終わりに近づいているので、4年間の成功失敗を振り返りたいとおもいます！
主に、失敗事例をどのように捉え、次に何をするのかを書いているので、FBがあれば是非いただけるとありがたいです〜🙏
成功 ≒ Y:やったこと
- 業務要件、システム要件定義の中で、資料を用いたお客様への改善提案ができるようになってきた。(現在進行形)
- フロントとバックエンドそれぞれの要件からテストまで一人称で出来るようになった
- Webサーバー、APサーバー構築ができるようになった
失敗 ≒ W: わかったこと
- システムを作るだけでは、本質的なお客さんの課題解決にならないことを知った
- 実装したコードの動作確認において、正常系（想定通りの動作）のみをチェックし、異常系（エラーケース）の確認を怠っていた
- テスト実施者によって問題が発見され、後から修正作業が必要となり、結果的に余分な工数が発生してしまう
- 設計の詳細が不十分なまま実装を始めてしまい、開発しながら設計を考えることになった結果、設計書の更新が後手に回ってしまった
- 「とりあえず実装」をやめる
- 設計者と実装者は基本セットが望ましいと知った
- コードを書くスピードが遅い
- 他の人に仕様に関して質問されると、コード見て調べればええやん...と思ってしまっていたこと
- これが起因して、沢山質問を受けてしまい、1日の3分の2をMTGで失ってしまった
失敗(W:わかったこと)の背景、次にやること
- システムを作るだけでは、本質的なお客さんの課題解決にならないことを知った
- 今まではエンド→ベンダー→弊社の立ち位置で仕事をしたり、弊社チームの中だけで仕事をすることが多かったので、指示されたシステムを作ることで評価いただいていた
- 今はエンド→弊社という立ち位置(厳密には違うけど)で仕事をしているため、よりお客さんに近い立ち位置で仕事をすることが多くなっため、お客さんが抱えている課題の解決が評価に繋がることを知った
- SES業界の中で、直エンドで仕事をいただけることは難しいと思うが、『エンドのお客様と利用者の課題解決』を軸にしてMTGの場で改善提案を実施することが大切だと知った。
- 実装したコードの動作確認において、正常系（想定通りの動作）のみをチェックし、異常系（エラーケース）の確認を怠っていた。
- 実装を作る工数と動作確認の工数を分けて考えることができておらず、実装を作る工数で上長に見積もりを出してしまっていたため、動作確認に十分な時間が取れなかった
- 上長に適切な見積もりを出せるように、機能開発に必要な画面(コンポーネント)、ロジック、APIなど、それぞれの動作確認工数も考慮する
- 設計の詳細が不十分なまま実装を始めてしまい、開発しながら設計を考えることになった結果、設計書の更新が後手に回ってしまった
- 設計者と実装者が違うため、資料だけでは読み取れないものがあったため、自分で設計考えながら実装した方がはやいなとなってしまっていた
- 効率性を考えると、設計者と実装者は一致させたい
- 仮に別れる場合は、より詳細で伝わる設計書を作成する
- システム独自の、普段使わない言い回しは避ける
- 外部システムの仕様がわかる資料を必ず貼る
- TBDや論点が残ってる場合は、必ず吹き出しなどでわかるようにしておくなど
- 「とりあえず実装」だと、設計に手戻ったり、調整ごと(他システムとの調整)が後手に回ってしまうことがある
- 実装中に設計上の問題が発生した場合には設計に戻り、設計書を更新してから実装に戻る
- コードを書くスピードが遅い
- 早く成果物を出すためにはとにかく手を動かすことだと考えてしまっていた
- どう作るかを頭の中だったりメモに残してから作業すると、作業スピードが格段に上がる
- すぐに手を動かさず、作りをイメージしてから作業に取り組む
- 他の人に仕様に関して質問されると、コード見て調べればええやん...と思ってしまっていたこと
- コードから読み取って！と言いまくっていたら質問や問題が多発して自分の作業時間がなくなってしまった
- メモベースでもいいから、「自分のために」共通管理している場所にドキュメントを残す