大きな開発こそ小さくリリースしよう

この記事は Ateam Lifestyle Inc. Advent Calendar 2021 19日目の記事です。

はじめに

現在、株式会社エイチームライフスタイル
D2C事業部にてデザイナーをしております@Shion84です。

2021年はいろんな開発にチャレンジさせていただきました。
その中でも規模の大きい開発の担当をさせていただいた際には、
とても多くの失敗と学びがありました。

簡単にご説明しますと

• やらなければいけない実装
• 今後を考えるとやっておいたほうが良い実装

をまとめて実行しようとしてしまった結果
レビューイ/レビューアー双方の疲弊や、大幅なリリースの遅れを生んでしまいました。
自身を含め、同じ失敗を誰も繰り返さないために
「開発時に気をつけたいこと」のお話を記事にさせていただきたいと思います。
どなたかの参考になれば嬉しく思います。

この記事で伝えたいこと

大きな開発は、小さなリリースの連続に変換すべし

• 巨大なプルリク1つではなく、細かいプルリクを多くレビュー依頼しよう
  • 実装したらリリース or developブランチにさっさとmerge

絶対にissue単位で実装をすべし

• 差分が小さいからといって、別のissueを同じプルリクに乗せるのはダメ
  • 本筋とは別の実装を加えると、影響範囲が広がる

なぜ伝えたいのか？

事業のスピードが上がる

• 小さく区切ることで差分が少なくなる
  • diffが少ないほど見る範囲や責務が明確になるのでレビューアーが見やすくなる
    • 負荷ががさがるので高速にリリースできる

安全性の確保

• 「本当に必要な機能」に予定通り時間をかけることができる
  • 時間をかけることが正義ではないが、影響範囲や検証を十分にできる
    • 結果的にお客様に迷惑がかからない

体験談

ここから話すことが、私が実際に実装をしていたときの話です。
(少しフェイクを入れて、抽象的にしています)

以前から積み上がっていた過去の負債をリファクタリングをしたいと思っているときに
Aというサイト全体に関わるissueを依頼されました。

長くスケジュールのある実装をするなら、できる範囲で不要なコードを消していこうと同じプルリク内であれこれ実装をし始めました。

気づいたときにはdiffは凄まじい数になり、影響範囲も膨大に
コミットも汚くなってしまっていました...
レビューを依頼した際のレビューアーの全てを悟った菩薩のような顔が忘れられません。

そしてスピード感は落ち、抜け漏れも生まれ、ジリ貧になってしまいました。

これではいかん...

大きな開発こそ小さくリリースしよう

一気にやろうとすると自分もメンバーも疲弊してしまい
事業のスピードは落ち、最悪の場合 お客様にも迷惑をかけてしまうかもしれません。
改めて、開発をする際は

• 必要なものに絞る
• 要件定義
• タスクの細分化
• マイルストーンを引く
• 丁寧にコミットしながら実装

これを着実にすることが大切なことなのだと思います。
「やったほうがいいこと」を本当にやるのかは慎重に判断をしましょう！

まとめ

「大きなことをするためには、小さく始めよう」
というテーマでお話させていただきました。
余談としては、おそらくこれは開発に限った話ではなく
すべての業務や、人間関係、更には人生にも言えることだと思います。
この記事を読んでくださった方の今後のためになったら幸いです。

明日12月20日（月）は @ponco さんの記事です。
お楽しみに！