こんにちは。フロントエンドを担当している古谷です。
今回は、ラクスルテレビCMオンラインストアを開発開始からリリースするまでの進め方についてご紹介します。
こちらの記事は、以前行われた 【ラクスル×KCF】FrontendNight というイベントにて 本編には惜しくも入れられなかった部分を中心に構成しています。
イベントで発表したこちらの資料もあわせてご覧ください。
Storybookを使って安心しながら開発を進める ラクスルテレビCMオンラインストア開発
こちらの資料では、「進める際のリスクがなにかをしっかりと想定すること、そのための対応手段の選択肢を増やすために技術力をあげていくことが大事。」とまとめています。
この発表では主にツール、技術の選定にフォーカスして発表していました。
この記事では、進め方について、実際のPRの画面を交えながら紹介していきます。
速度を保ちつつ開発する進め方
こちらも、上記資料と同じくどんなことが起きたら開発がうまく回らないかを考えていました。
以下の不安があり、それらに対して対策を打っていました。
- 技術選定はうまくいっても速度が出ないのではないか
- 仕様や実装の変更による手戻りが多いのではないか
速度が出ない問題にはどう対処したか
基本的なことではありますが、PRの単位を小さく保つこと、そして丁寧にすることがあげられます。
こちらが実際のPRです。
(※ 小さくとかいてあるわりに、Files changed が15なのは、Snapshotで多くのコンポーネントに影響が出ているからです。)
PRのテンプレートを作った
おそらく多くのプロジェクトで行っていると思いますが、PULL_REQUEST_TEMPLATE.md の形式を整えます。 チケット番号、実装したものの概要は書くとして、それ以外になぜその実装にしたのかという理由を書くことが大切です。
また、(実装者が想定している)影響範囲を書いておくことで、全体把握をしているという信頼関係の構築がしやすくなると思っています。 リリース前だからこそできることですね。
## 概要 簡潔に何ができるようになるかを書きます。 また、その背景や対応するチケットがあれば貼ってください。 その実装にした理由をコミットメッセージに加えてこちらに書いてください。 その他、レビューを厚めにしてもらいたい点があれば書いてください。 ## 影響範囲 Storybookのスクリーンショットなどわかりやすいものがあれば貼ってください。 Propsの変更など大きな変更があれば書いてください。 ## TODO * [ ] storybook * [ ] このPRをmergeするために必要な残タスクがあれば列挙します ## このPRでやらないこと このPRでは対象外にすることを書きます。 チケット、ISSUE、FIXMEを使って管理してください。
スクリーンショットを乗せるようにした
フロントエンドの開発では、スクリーンショットを乗せることでPRを中心にコミュニケーションが回ります。 スクリーンショットを乗せることで、仕様に沿った動きをしているかどうか、挙動の認識があっているかを一目でわかることが大切です。
レビューイはスクリーンショットを撮るために、当然手元で実装物を再現させる必要があります。
動作確認してからPRを出すのは当然ですが、複数パターン考えられるものを撮ったりするうちに、考慮漏れに気づいたり、モバイルサイズにした時に思わぬ挙動を見つけたりするのではないかと思います。私もこの段階で考慮漏れに気づくことがありました。
手元での動作確認は基本の所作ですが、 スクリーンショットを撮るということをフローに入れるだけで、うっかりは少なくなるはずです。
レビュアーも手元で再現させるのは当然ですが、PRで見るべき箇所がわかりやすいのでレビューしやすくなります。
やらないことを明記した
開発期に関しては、PRをためてしまい脳内バッファを消費することがないように、多少中途半端であってもmergeしてしまうことが大切と考えます。
また、完成度の高い物を作っても直前に変わる可能性もあるため、過度な作り込みは厳禁です。
とはいえ、中途半端なものがリリースされてしまっては問題なので、PRに明記することとチケットやコード内 FIXME などで残すようにしています。
ここで、想定している「ここでは積み残している事」を共有する事で、レビュー時に実装者の考慮漏れを見つけることができますし、積み残しを個人のタスクからチームのタスクに開放することが出来ます。
手戻りを発生させないようにどうしたか
手戻りの原因は沢山あると思いますが、一つはエンジニア以外とのコミュニケーション不足で起こるものがあると思っています。
これに関しては、PRにスクリーンショットを貼ることである程度対応ができました。
PRに貼るスクリーンショットをアニメーションGifにしておくと、連携したチャットツール(Slack)にPRに貼られた画像が流れます。Slackに動く画面が流れれば、エンジニア以外も実装している内容に関して興味が持てるようになります。
このPRの動くスクリーンショットと、Slackの絵文字コミュニケーションとあわされば、実装中のものに対して誰でもリアクションが出来る状態が保たれます。
※ 価格データなどはランダムなものを使っています
※ 実際のSlackの画像を編集しています
これによって成果物をベースとしたチーム全体の認識共有に繋がったと思います。 対面での進捗報告や、確認環境へのデプロイも大切ですが、もっと周囲がフォローしやすい形に持っていく事で、実装の認識の齟齬を発生しにくくすることができました。
まとめ
ラクスルテレビCMオンラインストアの初期開発では、PRをこまめに出すことと動くスクリーンショットを貼ることを心がけました。
まわりの関心を引きつけつつ、抜けもれなく開発を進めていました。
フェーズやチーム構成によって最適な進め方は違うと思いますが、参考になると幸いです。
ラクスルでは、新サービス開発をリードするフロントエンドエンジニアを募集しています。
