この記事は freee Engineers Advent Calendar の1日目です。
こんにちは。freee株式会社でフロントエンドエンジニアをしている @ymrl です。freeeでは給与計算freeeの開発をしています。
僕はフロントエンドエンジニアを名乗っていますが、実際はサーバーサイドの開発もしています（freeeではフロントエンドとサーバーサイドの担当に線引きをしていません）。しかし自分としてはフロントエンドのほうが得意だし、UIを作るのが心底楽しいし、サーバーサイドに比較的苦手意識を持っています。
今日はそういう状態の僕が、どういうふうに開発しているかという話をします。
技術に自信がないのでペアを組んだ
給与計算freeeの開発チームでは、ひとつの機能を開発するときに エンジニアのペア制 というのをとっています。
かつて僕が給与計算freeeのチームに異動してすぐの頃、僕はサーバーサイドの技術に自信が無く、一方でほかのチームメンバーはフロントエンドの技術に自信がないという状態でした。そんな中で、わりと凝ったUIをもつ機能を作るために始めたのがペア制でした。
すなわち、フロントエンド開発中心の人とサーバーサイド開発中心の人がペアになってひとつの機能を開発することで、お互いが得意な部分を担当しつつコードレビューをし合う体制です。
やっていることはペアプログラミングとほとんど同じですが、同期的なペアプログラミングだと長時間やるのはしんどいし疲れるので、お互いが好きに作業してレビューを投げ合うというかたちでやっています。非同期的にやることで、極端な夜型と朝型の人でも、社内ノマドやリモート勤務の人でもペアを組める利点もあります。
ペア制を続けたおかげで、僕はサーバーサイドの実装がだんだんできるようになってきたし、チームのほかのエンジニアもフロントエンドの実装をだんだんと自信を持ってできるようになってきました。
Web APIの仕様はフロントエンドエンジニアが決める
僕がフロントエンド、もうひとりがサーバーサイドという分担で開発をする場合に良いなと思っているのが、Web APIの仕様をフロントエンドエンジニアが決めてしまう というやり方です。
実際、給与計算freeeは（ほぼ）シングルページなアプリケーションなのですが、そういうサービスで快適なUIを作るためには「こういう粒度でAPIが叩けると良い」というのを考えるのはフロントエンドエンジニアのほうが得意なのでは、と思っています。そうしないとRailsのModelのCRUDそのままみたいなAPIが用意されているけどリクエスト回数が多くなりすぎて不便、ということが起きがちだからです。
そこで、サーバーサイドのエンジニアがテーブル定義やモデルのロジックを考えて実装しているあいだに、フロントエンドエンジニアがAPIの仕様を考えて、せっかくなのでモックデータを返すところまで作ってしまうということをやったりします。モックとはいえ実際のAPIを叩きながら開発できるのでフロントエンドの実装が圧倒的にやりやすく、設計上の問題も早い段階で見つかりやすい（はず）です。
要件定義や設計からペアでやる
給与計算freee開発の特色として、 行政上の制度を前提に機能を作らなければいけないケースが多い というものがあります。これはすなわち、お役所やお役所っぽい組織の資料をしっかり読んで理解しつつ要件を整理して、仕様に落とし込まなければいけないということを意味します。得てしてこの手の資料は難解で、読み解くのに膨大なエネルギーを必要とします。
ペアで開発する場合、この段階からペアを組んで取り組むことでひとりひとりの負荷を減らすことができ、また資料の解釈を間違ったままプロジェクトを進めてしまうのを防ぎやすくなります。作ろうとしている機能について、それぞれが調べた情報をQiita Teamなどにまとめつつ読みあったりすることで、お互いがかなり深いところまで理解をすすめる事ができます。
ある程度理解が深まったら設計に入っていきます。最近はサーバーサイド担当の人がテーブルやモデル構成の定義をやっている間に、僕が画面遷移とワイヤーフレーム、必要なAPIの定義などを作るという進め方をすることが多いです。ここでもやはり、お互いの設計をレビューしあいながら進めていきます。
自分ひとりで調査をして要件を決めてからほかのエンジニアに入ってもらったり、あるいはある程度要件定義や設計が決まってからフロントエンド要員として加わったりしたこともあるのですが、そういうやり方をしても要件の背景への理解度に差があったり、設計にフロントエンドの観点が足りていなかったりして、大きな追加作業や手戻りが発生してしまうということがたびたび発生していました。
やはり 最初から最後まで同じメンバーの少人数でプロジェクトを進めていく のが最も効率よく、その最小構成は2人である、と強く感じています。ひとつのプロジェクトに割く人数が3人4人と増えても、結果的にサブプロジェクトを作るような形で2人組にして進めていくことが多いです。
ペア制の弱点
このように、ペアで開発するとお互いの弱点となる部分自信のない部分をカバーしあえる以上の効果が期待できるのですが、一方で弱点もあります。そもそも、ペアになってお互いのレビューをするということは、相手の担当する部分に関して基本的なスキルは持っている必要があるということでもあります。お互いに「その部分は自分でもできるが、自分がやるより相手がやったほうが早く良いものができる」という状態になっているのが効率が良いはずです。また、相手のスキルの問題で相手にだけレビューを頼むのが不安な部分が含まれる場合には、その部分だけ得意な人にレビューに入ってもらうこともあります。
また、担当した2人が深い知識を持てる反面、それ以外のメンバーは何も知らないという状態に陥りやすい問題もあります。要件や仕様や実装のあるべき姿について、常にその２人しか判断を下せないということは運用フェーズになると非常に危険です。
そこで、開発中から特にメイン以外の部分のレビューにだけ他のエンジニアに加わってもらったり、調べたことや考えたことの資料をなるべく残しておいたり、リリース前後に「こういう制度になっているのでこう実装します（しました）」というまとめ記事をQiita Teamに書いたりして、徐々に知識を共有していくことが重要だと思っています。リリース後に不具合が発生した場合には、敢えて開発ペアでなかった人に修正タスクをアサインして、理解のきっかけにしてもらうこともあります。
おわりに
今回紹介したのはfreee全体でやっていることというより、うちのチームはこれで上手くいっているという話でした。ほかのfreeeのエンジニアに聞くとぜんぜん違うやり方をしていたりもします。チームごとにタスク管理もミーティングも試行錯誤を繰り返しながら良くしようとしているので、来年の今頃にはうちのチームもペア制を続けているかどうかはわかりません。
ただ、いまのところ2年くらい続けて上手くいっているように思います。
そんなfreee株式会社では、業務をもっと楽しく効率よく進めていくための工夫が好きなエンジニアを募集しています。
明日は自称はったりエンジニアの @manabusakai が、はったり含有率0%な記事を書いてくれるはずです。お楽しみに。