はじめに
こんにちは！ラクスル事業部AM(エリアマーケティング)チームでフロントエンドエンジニアをしている渡邉、小泉です。 私達のチームはラクスルのポスティング・新聞折込サービスの開発・運用しています。
今回の記事では、チームで感じている課題に対して行った、ある取り組みについて紹介させていただきます。
AMチームの開発体制について
ラクスル事業では基本的にバックエンド、フロントエンドが分かれており、AMチームでも担当領域が明確に分かれています。そのため、日々の開発タスクも各領域ごとにそれぞれ担当しています。
また、フロントエンドとバックエンドのコードは、別々のリポジトリで管理されており、フロントエンドのGitHubリポジトリにバックエンドエンジニアがコミットすること、またその逆も今までほぼありませんでした。
開発体制はこのような状態でしたが、各エンジニアが「お互いの領域で開発をしてみたい」という意志や、今後のチームのパフォーマンスを考えたときに「エンジニアが垣根をこえて開発を行えた方が良いのでは？」という意見が度々チーム内での話の中で上がっていました。
バックエンドとフロントエンドで分けることにより生じた課題
担当領域に境目があることにより、チームは以下のような問題に度々直面していました。
- バックエンドとフロントエンドでタスク量に差が出てしまう
- フロントエンドとバックエンドで依存関係があるタスクの場合、一方のブロッカーになってしまう
- お互いのコードベースに関する知識が欠ける
バックエンドとフロントエンドでタスク量に差が出てしまう
リポジトリの構造上バックエンドエンジニアの担当領域が広く、社内システムの運用も含まれるため、『バックエンドのタスクが相対的にフロントエンドより多くなりがち』という状況にAMチームは度々ぶつかっていました。
具体的な内容を挙げますと、ECサービス用のAPI実装はもちろん、ECサービスに伴う社内メンバー用の管理画面2つに加え、DB周りの調整、さらには社内独自で使用しているbot等もバックエンドエンジニアが担当しています。それに加え、リプレイス前のシステム修正依頼もサーバー側の内容が多い状態です。
これにより、バックエンドエンジニアが忙しく機能開発を行なっている間、フロントエンドエンジニアの手が空いてしまい、フロントエンジニアは改善系のタスクなど別の開発をするケースが頻繁に起きていました。
もちろんリファクタリングやUI改善なども大事なことですが、機能開発をチームで最短でデリバリーする必要があるケースも多いので、ここを改善できないかとチーム内で話し合いを行なっていました。
フロントエンドとバックエンドで依存関係があるタスクの場合、一方のブロッカーになってしまう
それぞれの領域のタスクが他方のタスクを止めてしまうことは、担当領域を明確に分けている開発チームではよくあることかもしれません。
一例ですが、バックエンドのAPI実装を行うまでフロントエンド側からのAPI繋ぎこみができないことがあります。我々AMチームではこのような状況に度々直面しており、より早くデリバリーするために改善の余地があることをチーム内で認識していました。
もちろん、モックなどを使いフロントから進めることもできるのですが、先ほど挙げたタスク量の差のこともあり、APIインターフェースの実装も含めてフロントエンドエンジニアが行うことができれば、チームとしてより早くアウトプットをすることが可能になります。
お互いのコードベースに関する知識が欠ける
お互いのコードについて読む機会が少なく、設計や仕組みに対する解像度が低いことも、我々のチームにとっての一つの弊害となっていました。
これにより開発可能な領域が狭まり、結果的に障害発生時に素早く対応できるエンジニアが限られてしまうなどの問題が発生していました。
フロントエンドエンジニアもバックエンドエンジニアも、エンジニアとして境界線がなく日々開発することでプロダクトコード全体の解像度が高まり、チーム内で対応できる守備範囲が広がることは、チームにとってだけでなく各エンジニアにとっても良い影響があると感じ始めました。
どう取り組んだか
具体的には、以下のような取り組みを行いました。
- スプリントプランニングで垣根を越えられそうなタスクにタグをつける
- モブプロ、ペアプロの実施
- モブプロの場合、目的を設定する
- Wikiを書く
スプリントプランニングで垣根を越えられそうなタスクにタグをつける
スプリントプランニングの際に、タスクの中でフロントエンド・バックエンドの垣根を越えられそうなものがないか話し合いました。可能性があるタスクについてはどのように取り組むのが良いか（モブプロをするのか個人が担当するのか等）話し合い、タスクの割り振りをしました。
また、すぐに識別できるように該当のタスクにはClickUpでタグを付けました。この取り組みによりチーム全体の認識が一致し、その後の作業が進めやすくなりました。
モブプロ、ペアプロの実施
ほとんどのタスクで、はじめからモブプログラミング（モブプロ）もしくはペアプログラミング（ペアプロ）を採用しました。
理由としては、サービス固有の知識の共有やコードの具体的な読み方、QAでの視点などを口頭で伝授し合うためです。特に、初めてこの取り組みのために行ったタスクでは、設計やコード全体の仕組みといったプロジェクトの初歩的な知識から共有して進めました。
ペアやモブでの作業は一見時間がかかるように見えましたが、次回以降のタスクの進行がスムーズになると感じました。
モブプロの場合、目的を設定する
ペアプロやモブプロでの作業に時間がかかるのは、ある程度は仕方のないこと、とは言えモブプロとなると全員で５人や６人といった大人数となるので、効率的に進める工夫が必要になってきます。
そこで、モブプロを行う際はある程度テーマを決めてその部分にフォーカスしてモブプロを行い、それ以外の部分はペアプロにしたり、個人タスクに切り替えることで、全体の作業効率を向上させました。
例えば、テーマに「フロントエンドのテストの書き方」を設定した場合は、テスト以外の部分はフロントメンバーが実装しておき、テストの部分のみモブプロで実装を進めるといった流れです。
Wikiを書く
プロジェクトごとに、Github上にコードに関するWikiを作成しました。ペアプロやモブプロでの共有のみだと、細部の情報が抜け落ちることがあるためです。
また、バックエンドではそれまでWikiが存在しなかったため、何を「良いコード」と定義するかが明確に決まっていなかった部分がありました。メンバー同士で話し合いつつWikiの作成することでこれらの問題を解消し、チーム内でのコーディングの迷いやブレを減らすことができました。
やってみて変わったこと・わかったこと
この取り組みを通して、私たちのチームはいくつかの変化や発見がありました。
GOOD
まず初めに、簡単なタスクであれば、フロントエンドエンジニアでもバックエンドのタスクを担当できるようになりました。これは、元々の大きな目的の一つだったので、この時点でこの取り組み自体に意義があったと言えます。
更に、それぞれの領域を跨いだ作業をすることによって、担当領域以外に関してより理解を深めることができました。これにより、従来の領域のタスクを行うにしても、相手側のコードを想像しやすく、より相手の使いやすいコードを実装できるようになったと思います。
今回の取り組みで、より多くのペアプロ・モブプロを体験したことからも発見がありました。今回のように知識が乏しい状態での共同作業はその時は時間がかかっても、後々のことを考えれば効率的で意味のある行為だとわかりました。
また、こちらは副次的にですが、同じ領域担当のメンバー同士でもコーディングの考え方や方法が異なっている箇所があり、普段では見ることのできない同僚のテクニックを共有し学習し合うことができました。
MORE
ただ良いことだけでもありませんでした。
モブプロは体力の消耗が激しく、全員が集中を続けるには相当のエネルギーが必要だとわかりました。議論が白熱してしまうことも多々あり、長時間ぶっ続けで作業を行なってしまうこともありました。
そのため、モブプロを行う際は、適度に休息を入れたり、あまり長時間の作業にならないように調整する必要があると学びました。
また、モブプロ・ペアプロでは無く個人が別領域のタスクを実装する場合でも問題がありました。本来の領域担当者と同じ生産性が出せるわけではなく、予定より実装に時間がかかってしまったり、エネルギーが取られてしまい、実装者が疲れ切ってしまうということがありました。
その対策として、今後は『できる限り気軽に同僚に質問を投げたり、モブプロ・ペアプロをお願いするようにする』という認識を合わせて、やっていこうということになりました。
感想
エンジニアが垣根をこえて開発を行えるようにすることで、今あるチームの問題を改善しよう！ということで始めた取り組みでしたが、結果として当初感じていた問題をある程度改善することができ、更にチームやチームメンバーにとって副次的な良い効果も得ることができました。
今回の取り組みにより、以前と比べて柔軟なチームとなりましたが、まだまだ完璧な状態ではないと感じる部分もあります。そのため、これからも工夫を続けていき、チームがより良い状態になるように努めていきたいと思っています。
