内部品質の低下を「実装前」にキャッチする「設計レビュー」のすすめ【Sansan笹川】

インボイス管理サービス「Bill One」や契約データベース「Contract One」など、近年続々と新たなDXサービスを立ち上げているSansan。それに伴ってプロダクト開発組織である技術本部も拡大し、いまや総勢500名のエンジニアと13のチームを抱える大所帯になっています。

一般的にプロダクトの数や組織の規模が急拡大すると、リソースが追いつかず設計品質に問題が生じがちです。Sansanではそのリスクを見越して、2023年7月から新たな取り組みとして全社的な「設計レビュー」を開始しました。一般的なコードレビューとは異なり、コードを書き始める前の「設計」にレビューをするのです。

設計レビューを推進するのは、リクルートやエムスリーを経て2023年に同社に参画した、Sansan Engineering Unit部長の笹川裕人さん。「始めた当初は現場の反発もあった」と話す笹川さんに、設計レビューの目的から、どうやって進めているのか、また、社内に取り組みを浸透させるための工夫と、開始から約1年経った今感じている成果や手応えを伺いました。

• keyboard_arrow_down エキスパートの2人が、全プロダクトの「設計」をレビューする
• keyboard_arrow_down 1年で約10件ほど、クリティカルな問題の発生を未然に防げた
• keyboard_arrow_down オープンな場での設計レビューで、エキスパートの知見共有が進む

――笹川さんが担当されている「設計レビュー」の概要を教えてください。

笹川：プロダクトに何らかの変更が加わる際、実装に入る前に行うレビューです。コーディングの前に、メンバーに簡易的なドキュメントを書いてもらい、私ともう1人のエンジニアがレビューします。

内部品質を上げるには、コードを書き始める前の設計段階で間違いや抜け漏れをいかに減らすかが鍵を握ります。コーディングに入ってから問題に気づいても、修正できる範囲は限定されるため、結局は設計からやり直しになってしまう。それではコスパが悪すぎるので、実装の前段階でレビューを入れることにしたんです。

またSansanの開発組織は13チームに分かれていますが、私たちが組織横断的にレビューを行うことで、高い技術力を持つエンジニアが少ないチームをカバーし、組織全体で一定の設計品質を担保できると考えました。

――具体的にはどのような手順で進めているのですか。

笹川：プロダクトに変更が発生する際、開発担当者はその背景・目的と内容をドキュメントにまとめます。

例えば、ミドルウエアを新たに導入するなら、「なぜ変更するのか」という理由の説明と導入したいと考えているミドルウエアの選択肢、アーキテクチャの概要図を記載します。データベースのテーブル変更のように設計において特に重要な案件については、カラムやレコードを含めたER図を記載するなど、ドキュメントの内容もより具体的になります。

ドキュメントができたらレビュアーに提出します。レビュアーは私と「Bill One」開発ユニットでテックリードを務める加藤（耕太さん）が担当しています。

どちらか1人ではなく、必ず両者にレビューしてもらうのがルールです。それぞれが異なる視点から評価すれば多様な気づきを得られるので、単独で行うよりレビューの質が高まると判断しました。

――レビューの依頼からフィードバックまでは、どのようなスケジュールで進行していますか。

笹川：Slackに設計レビュー用のオープンチャンネルがあり、メンバーが依頼すると、レビュアー2人に通知されます。ドキュメント提出時に、メンバーからフィードバックの期限について要望をもらいます。とはいえ、２人ともなるべく短期間で対応しているので、ほとんどのレビューは1～3営業日で終わります。

レビューの際のコミュニケーションは、基本的に非同期で行います。私たちがドキュメントにコメントを入れてメンバーに返信してもらう形がメインです。テキストだけで伝わりにくい場合はミーティングを入れることもありますが、今のところ9割以上はドキュメントのコメントのみで問題なく実施できています。レビュアーが2人ともOKを出したらレビューは完了とし、実装に移ります。

――一般的なコードレビューを含め、開発過程でレビューを入れると工数が増えて負荷が大きくなりがちです。副部長としての業務に加えて継続的に設計レビューを行うのは、大変ではありませんか？

笹川：負荷を感じるほどではないですね。設計レビューが発生するのは平均で月に10件ほどで、週に2件から4件ほど。それほど複雑な内容でなければ、レビューの作業は1時間程度で終わるので、始業前やちょっとした空き時間などをうまく使えばこなせる量です。

それに私も加藤も技術が好きなので、レビューするのが苦にならないんですよ。むしろドキュメントを見るのが楽しいくらい。だから無理なく続けられるのかもしれません。

――コードレビューとは違い、設計段階でレビューを入れるケースは珍しいので、いちから仕組みをつくる難しさもあったのではないかと思います。設計レビューのワークフローをうまく回すために工夫したことを教えてください。

笹川：まず、ハイレイヤーのアーキテクトがいるチームは設計レビュー免除としました。すでに話した通り、設計レビューの目的の1つはチーム間の人材分布の偏りをカバーすることなので、技術力の高いエンジニアが揃っているチームまで対象にする必要がないからです。

次に「レビューすべき条件」を明確に定めました。わかりやすい判断基準がないと、レビューを依頼するかどうか迷う時間が無駄だし、「これって本当にレビューを頼んでいいのかな」と考え出すと心理的なハードルも高くなってしまうからです。

そこで「新しいミドルウエアを導入するとき」「データベースを変更するとき」「検索エンジンを導入するとき」といったわかりやすい条件を設けて、それに当てはまればレビューに出す、というシンプルな仕組みにしました。

――条件はレビュアーの2人で決めたのですか？

笹川：私たち2人とマネージャー陣で意見を出し合って決めました。最初から条件を最小限に絞り込むより、まずはレビュー需要が高そうな要素を最大限に集める方向性で議論しました。実際にやってみて負荷が大きすぎるようなら、あとで調整することもできるので。

議論の中でマネージャーたちから批判が多かったのはデータベースのテーブル変更です。「そんなに細かい変更まで条件に入れるのか」と。

ただ結果的にはまったく問題ありませんでした。細かい変更だからレビューはすぐ終わるので、メンバーが作業を進める上での障壁にはならない。コードと違ってデータベースのリファクタリングは難しく、一度変更したらそのまま長期に渡って使い続けることになるので、テーブル変更も条件に入れてよかったと感じています。

――設計レビューを有効な取り組みにするには、レビュアーにも相応のスキルや知見が求められると思います。ご自身の経験を踏まえて、レビュアーの役割を果たすのに必要な要素を教えてください。

笹川：技術的な知見が求められるのは大前提として、加えて必要なのがドメインの理解です。特に他チームのレビューも担当する場合は、レビューイが手がけるサービスのコードを読んだり、そのチームの人たちから話を聞いてプロダクトへの理解を深めるなどの努力が求められます。

またロジカルに議論するスキルも重要です。何か指摘されると自分自身が否定されたかのように感じてしまう人もいるので、あくまで設計についての評価であることを論理的に伝える力が必要となります。

――確かにコミュニケーション力はレビュアーに不可欠なスキルですね。他にもレビューイとのコミュニケーションを円滑にする工夫はされていますか？

笹川：コメントする際に気をつけているのは、こちらの意図が明確に伝わる書き方をすること。コードレビューでもよくやりますが、必ずやって欲しいことは「must」、単なるコメントなら「comment」、質問なら「ask」、余談みたいなどうでもいい話には「nits」など、ひと目でわかるキーワードを入れます。

それと私たちのように組織横断的に設計レビューを行う場合、自分が所属するチーム以外のエンジニアとも対話するので、事前に相手とのつながりをつくっておくとコミュニケーションがスムーズになります。

実は当初、私はそのことに思い至らず、あるメンバーから「知らない人に指摘されるのが嫌です」と言われてハッとしたことがあります。設計レビューを始めた時はSansanに入社してから日が浅かったので、まだ私と面識がない人も多かったんですね。

だからスタート前に「こんな取り組みを始めます」と各チームへ説明に行くなど接点をつくっておけば、レビューを受ける側の心理的ハードルも下がったんじゃないかなと。これは反省点のひとつです。

――そもそもなぜ設計レビューを始めようと考えたのですか。

笹川：設計レビューを始めた2023年当時は、Sansanが新たな拡大フェーズに入ったタイミングでした。なかでもインボイス管理サービス「Bill One」の事業が大きく伸びていて、このプロダクトを担当する開発チームも、短期間でメンバーを2倍に増やすほど急拡大していました。

組織が急速に拡大すると、現場ではさまざまな混乱や綻びが生じやすくなります。特にプロダクトがアーリーフェーズにある新規事業チームでは、市場の要望に応えるために、短いサイクルで設計の変更が必要になる。しかも組織の拡大スピードが速いために、ハイレベルな人材の確保が追いつかないチームもある中で、多くの変更に対応するのは大変です。

当時、プロダクト開発に支障をきたすほどの問題が起こっていたわけではありませんが、その寸前までいったという話はいくつか耳にしていました。これは何らかの手を打たないと、設計の品質を持続的に高めるのは難しいのでは？と考え、設計レビューを始めたんです。

――設計レビューの開始から1年弱が経過しました。取り組みの成果は出ていますか。

笹川：やっておいてよかったと感じる場面は多いですね。まずは当初の狙い通り、実装に移る前の段階で問題を発見できるようになったのは大きな成果です。

設計レビューの開始以来、70件から80件ほどレビューしてきましたが、そのうち10件弱でクリティカルな指摘が入りました。そのまま進めていたら、将来的な拡張に耐えられなくなったり、継続的な改善が難しくなるなどの問題に発展していたかもしれません。これを防げたのは幸いでした。

それに、設計レビューで重大な指摘が入らなくても、レビューを受ける前提があるので、担当メンバーが常により良い手段を検討してくれるようになりました。そのおかげで、全体的な設計品質の向上にもつながっています。

また、設計の際、目的に対して最適な手段を選べるようになったことも、大きな収穫です。設計の品質を上げるために重要なのが、手段の目的化を防ぐことです。例えば「全文検索エンジンはElasticsearchを入れます」という場合、複数の選択肢を比較検討した上で出した結論ならいいのですが、最初からElasticsearchを入れることが目的であるかのような書き方をしているドキュメントも少なくありません。

この場合はドキュメントを書いた設計担当者とディスカッションして、他に選択肢がないかをもう一度考えてもらいます。どのエンジンを入れるかはあくまで手段であって、この変更の目的は「より良いプロダクトをつくること」であるはずです。「このエンジンを入れると運用負荷が上がるけど本当に大丈夫ですか？」「導入するとしても本当にこのフェーズが適切ですか？」といった質問をコメントで返すと、最終的に当初とは異なる結論になることもよくあります。日々の設計レビューによってこうしたプロセスを根気よく繰り返すことで、真っ当な検証を経て結論を出す習慣がメンバーに根付いてきています。

――設計レビューには、メンバーの思考や行動の変容を促す効果もあるのですね。

笹川：そうですね。あと、メンバーたちのドキュメンテーションに対する抵抗感がなくなったのも大きな進歩です。

エンジニアにとって「第三者に伝える能力」は重要で、非同期コミュニケーションにおいて的確に伝えるスキルがないと、開発を進める中でもチーム内に誤解や齟齬が生じ、プロダクトの品質低下につながります。裏を返すと、伝える能力が向上すれば設計の品質も上がり、チームの生産性も高まるわけです。

ドキュメントの作成は、このスキルを磨くのに最適なトレーニングになります。テンプレートが欲しいとの声もあったのですが、いちから文書を作成することがドキュメンテーションスキルの底上げになると考え、あえて体裁は自由にしました。私たちがレビューする際も、設計の内容そのものに対する指摘だけでなく、わかりにくい文章や表現があればフィードバックするようにしています。

ただ最近はドキュメントの品質について指摘する機会も少なくなり、メンバーの伝える能力が確実に向上していることを実感しています。

――レビュアー側は手応えを得ていますが、レビューイとなるエンジニアはどう感じているのでしょう？　開始当初から現場も協力的だったのですか。

笹川：設計レビューを始めることをアナウンスした時は、現場からそれなりの反発はありました。工数が増えるとか、スピード感が落ちるとか。ただそれらは当然予想できる反応だったので、私と加藤の間で、リードタイムはできるだけ短くすることを努力目標として共有しました。

「そもそも何でやるんですか？」と意義を問う声もありましたね。設計品質を高めるためと説明はしましたが、これは実際にやってみないと理解できない部分もあるので、「やりにくい点があれば改善するので、とにかく一度やってみよう」と伝えて実施に踏み切りました。

――実施後はメンバーの反応に変化はありましたか。

笹川：最初の1～2ヶ月が過ぎた頃には、もうレビューに出すのが当たり前という雰囲気になっていました。開始後もスループットの数字に増減がなかったので、メンバーも開発の工数やスピードには影響しないと納得できたのでしょう。

最近はSlack上でも「不安だったら一度レビューに出してみたら？」といったメンバー同士のやりとりを見かけるようになりました。設計者自身が「この設計で大丈夫」と安心感を得るためにレビューの場を活用してくれることも多いようです。レビュアーの私たちが頼られる存在になれているようで嬉しいですね。

――実際にやってみて効果を体感してもらうことが、当初の反発を解消する最良の方法だったわけですね。

笹川：はい。また、社内のエキスパートが持つ知見の共有にも、設計レビューが一役買っているようです。設計レビューが社内で浸透するにつれて、私と加藤以外のオプショナルな参加者がコメントするケースも増えています。Slackのオープンチャネルでやりとりするので、レビューの内容を見て「このコンポーネントには詳しいです」「その件なら前職で扱ったことがあります」といった形で、自分の得意領域について自発的に指摘やアドバイスをくれるんです。

最近では設計レビューのコメントから学ぶ勉強会が開かれるなど、当事者であるレビューイ以外のエンジニアも、積極的に知見を共有しようとする意識が広がっています。最終的に出来上がったものを見る機会はあっても、設計の過程でどのような変遷があったかを知る機会は意外と少ない。レビュアーとレビューイのやりとりを追うことで、「なぜこの結果になったのか」を理解することは、エンジニアにとって大きな学びになります。

――設計レビューの開始から1年弱でそれだけの成果が出ているんですね。

笹川：本当に、この取り組みを始めてよかったと思っています。ただ、設計レビューの開始後に新たにリリースされたプロダクトはまだ多くないので、設計のクオリティに対する直接的な効果が見えてくるのはこれからだと思います。

今後は設計レビューがプロダクトの品質にどれだけ寄与しているかを計測して数値化することも検討し、より良い運用につなげていく予定です。短期間でも効果は出ていますが、長期的に続けてこそ得られるメリットがあるはずなので、取り組みを継続してさらなる設計品質の向上を目指していきたいですね。

取材・執筆：塚田 有香
編集：光松 瞳