Service Dev所属、サーバサイドエンジニアの宮村です。 現在私は、Service Devのチームに所属し、ネットショップ作成サービス「BASE」及びショッピングアプリ「BASE」の機能開発を担当しています。
BASEでは最近、機能開発の際に設計レビューを行うようにしています。その取り組みについて紹介したいと思います。
開発チームについて
BASEの開発チームは、メンバーが増えるに従って専門化する形でチームを分割してきました。
現在、サービスの機能開発を主に担当しているService Dev Sectionは、バックエンドが担当領域を分担して2Group、フロントエンド、ネイティブアプリを担当するそれぞれ1Groupの計4つのGroupから成り、Service Devのエンジニアはいずれかのチームに所属する形となっています。
（組織図について興味を持たれた方は、こちらの会社説明資料をご確認いただければと思います。）
機能開発の際はそれらの職能別のGroupを横断する形でプロジェクトチームを編成し、プロジェクトチームが主体となって機能開発を行っていきます。チームのメンバー構成はプロジェクトの特性や規模により様々ですが、多くの場合、同じグループから1〜2名がプロジェクトにアサインされることとなります。
設計レビューを始めたわけ
機能の増加、開発メンバーの増加、並行するプロジェクトの増加により、新しく課題が見えてきました。エンジニアに対して多くのプロジェクトが立ち上がったことで顕著に現れたものもありました。
- サーバサイドの領域を専門にするエンジニアが自分以外にプロジェクト内にはいない・少ない状態になるため、機能の品質が個人に依存しがちな状況になってしまっていた。早い段階で多くの目で見ることで、機能の品質を担保したい。
- チームのコードレビューのプロセスは取り入れていたが、コードレビューの段階で指摘を受けると手戻りが大きいので、早い段階で既存のシステムに詳しいチームメンバーによるレビューを取り入れ、手戻りを少なくしたい。
- コードレビュー時に初めてコードを渡されても仕様把握が難しいので、チームメンバー側が事前に新機能を把握しておきたい。
以前からコードレビューは必須としており、チームで品質を担保することを重視してきていましたが、設計段階でレビューを行うことで改善できることもあるのではないかと思い、設計レビューを始めてみることにしました。
設計レビューの実践
いつやるのか
設計レビューのタイミングは、プロジェクトにエンジニアが参加し、テーブル設計、画面設計がある程度できた頃、実装に入る前を目安としました。これまでの実績では、開発チームのキックオフから数日〜数週間の間に行われています。
どうやるのか
プロジェクトの担当エンジニアが、レビュー用のドキュメントを作成します。それをもとに、チームメンバーに説明しフィードバックを受ける形でレビュー会を開催します。対面もしくはオンラインミーティングで、同期的に行うこととしており、所要時間は機能によりますが、30分から2時間程度としています。長くなる場合は、複数回に分けて実施することもあります。
ドキュメントとして必ず用意するようにしているのは、以下の内容です。
- データベース設計
- 一度動き出すと変更のコストが大きいので、ER図を必ず用意して確認するようにしています。
- アプリケーションのスケーラビリティ
- クリティカルな処理への影響
- 決済などお金に関わる箇所を中心に、不具合が発生すると影響が大きい部分は特に注視します。
その他、画面設計やシーケンス図など、機能を理解するための資料を必要に応じて用意します。
設計レビューを運用してみて
最初にやってみてうまくいかなかったこと
仕様理解のために画面イメージから説明を進めていたところ、機能の仕様やUIへのフィードバックが盛り上がってしまい、時間がかかりすぎてしまいました。サービスに対する思いが各々にあることはとても良いと思いますが、効率の面からはバランスを取る必要があります。
それらの部分は、プロジェクトチームでディレクターやデザイナーも含めて検討されたものであり、一番その機能を考えているのはプロジェクトチームのメンバーということは間違いないでしょう。これらの点についてはプロジェクトチームでの決定を尊重し、設計レビューでは実現方法にフォーカスしてレビューするようにしました。
機能の仕様やUIについては明らかに問題があると考えられる場合のみフィードバックすることにして、再度仕切り直すことにしました。
良い点
進め方は未だ改善を繰り返していますが、総合するとポジティブな面が多いと感じています。いくつかを箇条書きで挙げてみます。
- ドキュメントを起こして他の人のレビューを受けるというプロセス自体で、設計が整理される効果がある
- 担当エンジニアが責任を持って設計するので大筋では問題ないことが多いが、やはりいくつかの有効な指摘がある
- レビュアが現在担当しているリリース前の機能との整合などを検討できるといったメリットもある
- レビューを受ける側のメリットとして、まだ実装を始める前なので指摘を受け入れて修正しやすい
- コードレビューの時点では、当然ですがコードはある程度書き終わっているので、その時点でこの変更は…という躊躇も生まれますが、それがないのは個人的にとても大きいと感じています。
もちろん、このレビューは開発を始める前のプロジェクトチームを含めて新機能に対する理解が深くはないタイミングで行われるので、すべてがここでレビューを受けたとおりには進みませんし、すべての問題を軌道修正できるわけでもありません。ただ、レビューを行ったほうが、開発起因での手戻りや課題が早い時点で発生するようになったというような気はします。
課題や注意点
準備段階に関しては、レビューのフォーマットが各人に任せるのではなく統一したほうがレビューする側がやりやすいのではないかということで検討しています。ただ、プロジェクトの特性などもあるので型を決めて守るというのが最善ではない気がしており、試行錯誤しているところです。
また、レビューまでにどのくらい詰めるか、という点も個人の感覚に頼るところが多いかもしれません。レビューを受けても大きな変更は必要ないだろうという程度には詰める必要がありますが、詰め切るのに時間をかけすぎても機能の提供に時間がかかってしまいます。 やりたいことは Move Fast にプロダクトを改善することなので、それを念頭に置いてよりプロセスの方も良い形に改善していきたいと思います。
設計レビュー後のプロセス
設計が承認されると、それをもとに見積もりを行い、各チームの開発に進んでいきます。この時点でプロジェクトのスケジュール、人員計画の見直しを行うようにしています。とりあえず始めてみて、遅れそうになったところ調整を行うのではなく、この段階で相談できるようになったことも、プロジェクト管理の観点からはポジティブな面と言えるかもしれません。（もちろん、開発開始後でも、必要があれば柔軟に対応していきます。）
まとめ
- メンバーの増加、プロジェクトの増加という状況の中、サービス品質と開発スピードを維持するために、設計レビューを取り入れました。
- 最初は所属Group内で試験的に行っていましたが、最近では別チームも含め、ほぼすべてのPJを対象にレビューを行っています。また、チーム内でのレビュー後にマネージャやCTOといった意思決定者も交えたレビューを実施するようにもなり、少しずつ役割を広げて運用されています。
- より良い開発が行えるよう、私たちも日々試行錯誤しながらやっているのですが、同じような課題を抱える方の取り組みの第一歩として、少しでも参考になれば幸いです。
