こんにちは。新卒1年目エンジニアのyokochiです。
本配属から3か月が経とうとしております。
その中で私は、本配属から2か月で、Wedding Parkのサービスにまつわる10機能をリリースすることができました。今回は10機能のスピードリリースに至るまでの、自身の中でのスピードUPポイントやさらに伸ばせると感じたことについて書かせていただきます。
目次
- 配属後の主な業務
- 業務の流れ
- スピードアップポイント
- さらに伸ばせるところ
- まとめ
配属後の主な業務
研修期間が終わり、新たなチームへの配属後に私が主に行っていた業務は
「開発が完了している案件をリリースまで運ぶこと」でした。
そしてタイトルにも書かせていただいた「10機能のリリース」とは開発が完了している案件を10件リリースしたという意味合いになっております。
業務の流れ
基本的な業務の流れとしては以下のようになっております。
1. 仕様理解
開発されたものがどのような仕様に基づいて作成されたものなのかをキャッチアップする必要があるので、対象機能に対しての挙動や仕様などをはじめにキャッチアップします。
2. テスト観点の洗い出し
仕様上の挙動や分岐などを理解した上で、テストに必要な観点を洗い出します。
3. テスト仕様書の作成
テスト観点の洗い出しをもとにテスト仕様書を作成します。
4. テスト
仕様に基づいた正しい挙動が行われているかを確認します。
5. コード修正
テストで正しい挙動が行われていなかった場合、原因を解明し、修正箇所を特定します。コード修正を行い、再度テストを行い正しい挙動ができていることを確認します。
6. リリース
テストにおいて不具合が発生しなければリリースします。
スピードUPポイント
まず、スピード感を持ってリリースまで運ぶことを意識していた理由として、事業成果に貢献するために、チームミッションの達成にいち早く近づけることがありました。そのため、自身の業務のサイクルを早く回しスケジュールを巻きで進めていくことが理想でした。
実際に業務の中で、時間がかかると感じたのは以下の二つになります。
- 仕様理解/テスト観点の洗い出し
自身が調べた担当機能の仕様に抜け漏れがないかやテスト観点の網羅性が高いかどうかが不安で、かなり時間をかけて調べていました。 - コード修正
テストを行うことで不具合を発見することはできましたが、コード修正をして再びテストを行うことでテストにかける時間が多くなっていました。
つまり、コード修正自体に時間がかかるというよりもコード修正による差し戻しの発生に時間を奪われると感じました。
これらのスピードを早めるために行ったポイントが下記になります。
対象機能の仕様に詳しいディレクターの方や開発されたエンジニアの方にお話しを伺う
最初は、仕様理解やテスト項目の洗い出しにおいて「自分が認識している仕様やテスト観点は正しいのか？網羅性が高いのか？」という気持ちが多くあったためのかなり工数を割いていたと感じています。
そこで、ある程度の理解ができた状態もしくは仕様理解に詰まっている段階で
対象機能の仕様に詳しいディレクターや開発担当のエンジニアにお話しを伺いにいきました。これにより自身の認識に相違がないことを確認し、テスト観点で必要になりうる箇所をお聞きし網羅性の高いテストができるようになります。また、自分の認識が正しい場合は自信を持って次のフェーズに移ることができ、間違っている場合や考慮する点が足りない場合は次に何をすべきかが明確になります。不安感や悩んでいる時間から解放され、スピード感高く仕様理解やテスト項目の洗い出しをすることができました。
仕様理解やテスト仕様書作成の段階で不具合を早期発見する
開発完了後は下記の図のようなフローで進めており、テストを行った後に不具合を発見し、コード修正を施し、再度テストをしていました。一見テストの意義を果たしてはいるのですが、もっと早期に不具合を発見できていればテストを複数回行う必要もなくなる気がしました。
今回は、開発完了後にすぐにテストする流れではなく、私の仕様理解〜テスト仕様書作成までが設けられているので、その間で不具合を発見してコード修正をして、テスト仕様書に必要であれば反映させる方が効率的だと感じました。
そのため、以下のようなフローで進めるように途中で変更しリリースまで運びました。
実際に不具合がある前提で、仕様理解やテスト観点の洗い出しを行うことで、より注視して機能の挙動の確認を行ったり、ロジックの理解に努めたりして、仕様の理解が深まりました。
さらに伸ばせるところ
上記の業務や現在行っている開発業務の中でも、特にすぐに意識でき改善できると感じたのが下記になります。
コードレビュワーとのコミュニケーション
10機能のリリースでは、コード修正をする機会もありましたが差分としてはそこまで大きくありませんでした。ですが、差分が小さかったのにも関わらず自身の説明不足で本来不要であろうやりとりなどが増えてしまいコードレビューに時間がかかってしまったことがありました。そのほかにもコードレビューを充実させるためにより意識すべきだった点は下記のことだと考えております。
- 誰が見てもわかるMRを作成する
レビュワーにMRを見ていただく時に、自分がなぜこのような修正を加えたのか、どのコードを参考に修正をしたのか、どのMRと関係があるのかなどを正確に説明する必要があります。これをすることでレビュワーに調べさせたり不要なやりとり回数をふやりたりしないようし、スムーズにレビューできます。 - レスポンスはできる限り早く
当たり前ですが、レビュワーもレビュー以外のタスクが多く存在しているため、お忙しいです。
そんな中の自分のレビューを見てくださっているのでできる限り速いレスポンスにしてストレスをなくすことが大事だと感じました。 - レビュワーから質問やご意見の意図を理解する
レビュワーからいただく
「〇〇をこのように修正すればいいのでは？」
というご意見に対して
「そのように修正します！」
というだけでなく、なぜそのように修正した方が良いのかを考えて修正する必要があります。これを怠ると毎回同じようなご指摘をいただいて全く成長しないエンジニアになってしまいます。そして、
「本当に理解しているのかな？」
とレビュワーを不安にさせないように、
「確かに〇〇は△△なのでそのように修正した方がいいですね！」
というようにご指摘の意図を自分が理解していることをレビュワーに伝えるようなコメントをするのも大事です。
これらの点はこれからも意識的に行いストレスフリーなコードレビューを目指します！
まとめ
10機能のスピードリリースに至るまでに意識したことや伸ばせると感じたところについて書かせていただきました。
業務を加速させるためのスピードUPポイント
- 積極的に先輩方（担当案件に精通している方）にお話しを伺いにいく
- 不具合箇所の早期発見するために業務フローを修正
さらに伸ばせるところ
- コードレビュワーとの円滑なコミュニケーションを取れるようにする
上記のどの項目に関しても「決して一人で仕事しているわけではない」ということがわかる内容になっていることに気づきました。頼ることや思いやることを忘れないことが大事ですね！
最後までご覧いただきありがとうございました！
