エンジニア1年目の失敗談
はじめに
この記事では、僕がエンジニア 1 年目として主に Flutter 開発業務に携わってきた中での失敗談を 4 つお話しようと思います。
1. コミュニケーションロスによる引き継ぎに失敗し、工数を無駄にした話
最初の失敗談は、エンジニアとして入社して間もない人ならやりがちなコミュニケーションロスから引き起こしたミスです。
入社して 2 つ目の調査課題を担当することになりました。
登場人物は以下の通り
僕：入社してまだ 1 ヶ月も経っていない
A さん：PjM
B さん：社内エンジニア
A さんから口頭で以下の話を受けました。
B さんが以前に対応して修正したはずの不具合が先祖返り（デグレード）しているかもしれない。
もしくは、勘違いで追加されていないだけかもしれない。
とりあえず、調査してみてください。追加されてないものだったら、僕さんが実装してくれないか。
入社間もない僕は B さんにその場で状況確認をしにいかずに、直ぐに調査を開始しました。
ここで最初の間違いをします。
この不具合修正を担当した B さんに状況確認もせず、そして直接の担当者から引き継ぎにを受けずに、A さんの報告から推測して行動を開始した ことです。
そして、調査を進めていくと、確かにデバッグビルドでの UI 確認でも修正されておらず、ソースコード上でも不具合箇所として指摘されている箇所に修正コードのようなものはありませんでした。
ここで、 多忙な B さんに VC で質問しに行きました。そこで、２つ目の間違いをします。
質問をしに行った際に、 課題背景（先祖返りの可能性も含め）を説明する前に調査した結果を説明し始めてしまい、 B さんの頭をキャッチアップさせられなかった ことです。
そのため、 B さんも困惑しながら僕の話を聞き、お互いで決まったことは「まだ実装されていない修正なら、僕がやってください」です。
そこで実装作業を進めていくと、すんなりと修正がうまくいきません。
まずプロジェクト全体の構造をしっかりと把握しておらず、「オブジェクト指向？聞いたことある」レベルの実務未経験の僕にはそんな簡単に直せるはずもありません。
そして、当時の僕は話したことのない人が多く、みんな忙しく仕事をしている（ように見えた）中で、簡単にヘルプを求めることができませんでした。
なおかつ、 何が分からないのかも言語化できない状況 でした。
参考資料：質問は恥ではないし役に立つ
最終的には、別の強強エンジニアの人が調査を行い、マージ漏れが原因で発生していたことを発見し、この問題は解決しました。
この修正タスクで費やした工数約 1.5 人日（12h）は無駄となりました。
2. 社内用のテスト投稿でデタラメな文字を入力した話
次の失敗談は、当時社内プロジェクトのサイトで使用している WordPress 関係の検証テストを行った際の恥ずかしい過ちの話です。
ある日の午後、「ローカル環境で適当なタイトルの投稿ページを作成して実際に投稿できているか確認してみて」と上司から依頼されました。
当時の僕は何か別作業に追われていて、この依頼をすぐに終わらそうと思いました。
また、「社内プロジェクトだし、本番環境ではなく、Docker コンテナ内に建てるローカル環境での検証テストだから、 適当にやればいい 」という気持ちがどこかにあったと思います。
Docker 内でコンテナを立ち上げ、Wordpress のサイトにアクセスし、新規投稿を押して、適当なタイトルを入力し、そして投稿。
ホームページにアクセスして確認してみると、ちゃんと投稿できていることを確認。
「○○ さん、問題なく投稿できていることを確認しました。」
そこから、何週間か後...
社内グループチャットにて、PjM から以下のような投稿がありました。
社内外関係なく、テスト環境やローカル環境に調査やテストデータとしてこうしたデータを入れるのは絶対にやめましょう。
実際に、こうしたテストデータを入れる会社がクライアントから切られるという話がありました。
一人一人の心掛けが大事です。
その投稿と一緒に添付されていた画像には、「ｓｄｆｓｄふぁｓ」とタイトルに入力されていました。
自分で何と入力したかを全く覚えていないですが、それ見た瞬間に「あっ、その犯人は僕だ」と思いました。
ただ、PjM からは「犯人探しをしているわけではないので、名乗りあげないでください」と追記があったので、その場で自分の誤りを認めて謝る機会はありませんでした。
また、別の上司は過去にこんな話があったことも共有がありました。
昔テストで「アホ」と入力し、何らかの形でクライアントに渡ってしまい、始末書を提出することになった同僚がいた
3. 自分がリリースした機能の影響で、端末によってアプリが白画面になる
ある程度業務に慣れてきた頃、端末のサウンドモードを検知してアプリ内の音量設定に反映させる課題がありました。
Flutter には便利な外部ライブラリが数多く存在し、こうしたネイティブ周りの機能も第三者が作成した外部ライブラリを使って解決することができることが往々にしてあります。
見つけたライブラリを使って実装し、僕の手元でも十分にテストを行い、要件に見合う動作が達成できていることを確認。
PjM やクライアントにも確認してもらう限り問題なかったため、無事にリリースされました。
それから数週間後、「特定の端末を持つユーザーからアプリ起動時に画面が真っ白になることが報告されている」という話を風の便りで聞きました。
この不具合の調査に僕はアサインされず、「ふーん、そうなんだ。怖いな。」と思いましたが、当時はその原因は僕の実装した機能だとは思ってもいませんでした。
当時は強強エンジニアの方がその調査を行っていて、原因を突き止めて、修正したものをすぐにリリースし、解決しました。
その後大分経ってから思い出して、その当時に修正されたコードを覗いてみると、修正箇所は僕が実装していたところでした。
原因は無駄な非同期処理実装を行っていて、古い端末によってはサウンドモード取得に失敗した場合に、 await したまま次の実行に移れずスプラッシュ画面から次の画面に遷移できなかったようです。
4. 口頭で受けた指示を実装したら、当初の要件と異なっていた場所で実装していた件
とある案件のクライアント展開間近にて、機能テスト実行中に実装漏れの要件が見つかりました。
ただし、この案件の機能を担当していたエンジニアはすでに帰宅済みで、まだ別作業で残っていた僕に白羽の矢が立ちました。
このバナーがそこに表示されるはずが表示されていない。バナー表示のロジックだけ追加してくれませんか？
簡単な実装だから、すぐできると思う
PjM から口頭で指示を受け、すぐに実装を開始しました。 要件を詰めたり、確認することもせず。
なぜなら、ものすごく簡単な実装なんだから。
ちゃちゃっと実装を終わらせ、検証アプリを作成し、PjM に展開。
「作業が完了したので、確認をお願いします。」
帰り支度を始めて、今日の振り返りをしていると、PjM から連絡がありました。
「僕さん、まだ帰宅しないでもらえますか？さっきのバナーの件、まだ追加されていないみたいです。」
まさか、さっき実装して自分の環境でも確認して、バナーが表示されていることを確認済み。
「本当ですか！？僕の環境ではちゃんとバナーが表示されていますよ？」
お互いに話し合い、問題の画面をビデオ画面に見せあって、ようやく気づきました。
PjM と僕で思っていたバナーの表示箇所が異なっていたことに。
終わりに
エンジニア 1 年目を振り返ってみると、これ以外にも細かいミスはけっこうしていたと思います。
でも、そうしたミスの多くは先輩エンジニアの方々のおかげで何事もなかったのように解決されてきいていたなと改めて感じます。
2 年目も仕事で色んな失敗をするだろうけれども、失敗を通じて色々学び、そしてより良いエンジニアになれるよう日々成長していけたら良いなと思います。
また、これから新人エンジニアとして働き始める人にとって僕の失敗談と学びが参考になれば、とても嬉しく思います。
Discussion