この記事はドワンゴ Advent Calendar 2024 9日目の記事です。

はじめに

株式会社ドワンゴのニコニコ生放送でフロントエンドを担当している misuken です。

ニコニコ生放送のフロントエンドチームでは、1年半前くらいからリファクタ会というものを実施しています。

このリファクタ会を実施するまでにどのような経緯があったのか、実施してからどのような変化があったのかを共有しようと思います。

※ この記事で言うリファクタには、もう少し範囲の広いリアーキテクチャも含まれます

結論

時間の無い方のために結論から先に書くと次のようになります。

リファクタ代行ではメンバーの成長に繋がらず、生産性が上がらなかった
メンバーに目の前で実際に成功体験を共有することが大切だった
ヒアリングしながらリファクタするとコスパが良かった
リファクタ会の効果で、そもそも負債を生みにくい流れが機能し始めた
主観的なわかりやすさではなく、論理的に改善されていることが重要

チーム構成

前提として、ニコニコ生放送のフロントエンドでは、開発チームが分かれており、自身はVCチームに所属しています。

チーム名	管轄	責務
VCチーム	プレゼンテーションコンポーネント周辺デザインシステムの整備	Viewの見た目全般 Storybookの保守デザイナーとの連携
RIAチーム	PCとスマホ用の全ページ View以外の領域全般	API通信周りドメインロジック状態管理 Props生成映像&コメント周り全般

リファクタ会を始める前

ニコニコ生放送では2016年にHTML5化に向けたフロントエンドの大改革が始まって以来、システムはどんどん巨大化し、複雑な機能の追加も続いてきました。

自身は過去からの経験や、BCD Designをはじめとした設計や保守性、スケールを重視した開発を追求してきたため、VCチームの領域に関してはある程度安定化させることができていたのですが、若手が中心のRIAチームでは、チームのメンバーでも手に負えない複雑さを持つ領域が増えつつありました。

常に新規機能のリリースが続く状況であるため、どうしても付け足しの連続で拡張を続ける流れが生じやすく、負債を解消するためにまとまった時間を取ることが難しいといったよくある問題に加え、メンバーがリファクタで成功した経験が十分でなく、次のような問題も生じていました。

リファクタを行ってもあまり負債の解消に繋がらない
リファクタした結果、負債の形が変わったり、新たな負債が生じる
リファクタ内容を理解するためにレビューにものすごい時間がかかる

このような状況では、費用対効果が合わないだけでなく、リファクタをしても楽にならないという失敗経験が重なり、リファクタは消耗する答えの出ないものというイメージになっていきます。

担当範囲の拡大

以前は自身もVCチームの責務で手一杯だったのですが、チームのメンバーが成長したこともあり、以前よりは余力が出てくるタイミングになりました。

そこで、VCチームだけでなく、RIA1やRIA2のPullRequestにも目を通すようにしました。

すると、PullRequestのタイミングで芽を摘まないと後からの回収コストが高くなってしまう負債や、すでに複雑になっていてレビューしてもよくわからないコードなど、悩ましい問題が見えてきました。

ここで問題になったのが、機能を実装する担当者としては、リリースを意識して実装しているため、そのPullRequest上で指摘があっても、なかなか対応する時間が取れないということでした。ましてやリファクタの成功体験を積み上げていない場合、リスクの判断といった部分でも守りに入りたい心理が働きます。

また、PullRequest上での指摘は、断片的になりやすかったり、小さな範囲での改善しかできなかったりするため、その場限りの改善となってメンバーの成長に繋がりにくいという問題もありました。

そうなると当然、いくつかのファイルを横断するような改善を提案しにくかったり、既存実装まで渡る改善が行いにくかったり、それらを実行に移そうとすると説明する側もかなりのパワーを要してしまいます。

リファクタ代行

機能追加のためのPullRequestにリファクタの指摘を入れていくというのは、元々うまくいかないスキームであるとは思っていたので、方針を変えることにしました。

とりあえず機能追加のPullRequestはマージしてもらって、そのあと自身でリファクタしたPullRequestを作成し、レビューしてもらうというものです。

しかし、せっかくマージされたコードをあとから改変するというのは、実装担当者からはネガティブな印象を持たれる可能性があるので、リファクタする側も気になる点です。それでも負債が厳しい背景があったので、受け入れてはもらえていた感じはあります。

ところがこの方法には他の点に問題があると感じました。それは、改善されたコードの差分をレビューしてもらったとしても、なぜ元のコードからこのように改善されたのか、リファクタの過程が伝わらない点です。

たしかに責務が整理されたり、把握できなくなっていた依存関係が明確になったり、わかりにくいと感じていた部分がわかりやすくなることで、前より改善された結果を受け入れてもらうことはできるのですが、結果だけを見てもらってもメンバーの成長には寄与しません。

PullRequestのコミットごとに懇切丁寧にコメントを書いたとしても、今度は書く方も読む方も大変ハードな作業になるだけで、レビューのチェックもなかなか付かなくなるうえ、そのPullRequestがマージされたらそれらの説明は忘れられてしまいます。

すると構図としては、みんなが実装したものを後からずっと追いかけるようにリファクタし続けなければならず、これはまたハードな仕事で生産的ではありません。

成功体験を共有

このままでは双方に負担が大きくなってしまうので、さらにアプローチを変更することにしました。

"釣った魚をあげるのではなく、釣り方を教える" ということを意識して、リファクタの過程を効率よく共有するというものです。

自身がリファクタやリアーキテクチャを行うときを思い浮かべると、常にいくつかのポイントを意識して行っています。それらが無ければスピードも精度も出ず、主観的なリファクタになってしまう分かれ目であるとわかっていたので、メンバーにもそのポイントを共有することが重要と考えました。

小さいコードレベルでのパターン、横断的な構成におけるパターン、クリーンアーキテクチャやBCD Design、既存の技術で裏付けされている概念やその応用など、「こういう違和感があるところはこうこうこうなってるから、こういうプロセスでアプローチすると、このように改善されます」と実際に目の前で改善されていく様子を体験してもらう形です。

メンバーは常日頃の設計や実装の最中に、違和感や困った感情を抱いているものの、目の前にある風景(問題)をどう解決していいのかわからないわけです。そこで、同じ風景(問題)を目の前にして実際に解決されていく光景を一度見れば、再び同じ風景(問題)を見たときにどうすればいいのかがわかるようになったり、不安を感じにくくなったりします。

リファクタ会の開催

このような流れを経て、毎週木曜日に30分〜1時間程度のリファクタ会というものを始めました。
現在は毎回だいたい7人くらいのメンバーが参加しています。

会の方針としては以下。

PullRequestのレビュー時に気になる部分があればissue化
issue化されている中から旬なものや費用対効果の高いものをピックアップ
そのissueをネタとしてリファクタ会の時間で改善を行う
リファクタを行うのは自身が担当
リファクタの成功を体感してもらう
内容は録画してあとから誰でも見られるようにする
他作業で忙しかったり、準備が整っていない週はスキップする(だいたい開催できている)

実際、30分〜1時間の時間でリファクタしきることは難しいので、着眼点やアプローチなど、どのように捉えてどのように対処していくのかの部分を重視し、以下の流れで進めています。

着眼点を説明しながら手を動かす
積極的にヒアリングしながら進める
方向性や着地点が共有できた段階で質疑応答タイム
リファクタ会終了後に残りの部分を調整してPullRequestとして仕上げる
その回だけで終わらなければ翌週再び続きを再開

この中のヒアリングというのは例えば以下のように、限られた時間内でサクサク進めるために、調べるのに少しちょっと時間がかかりそうな部分を聞いてみたり、感覚的にしっくり来るかを確認するものです。

「ここってコードを見る感じ、こういうことをしようとしているように思うのですがあってますかね？」
「このパターンだと、だいたいこういう方向に改善していくと良いはずなんですけど、違和感あったりしますかね？」
「似たような流れが何箇所にあるようですが、意図としては同じものですかね？何か差はありますか？」

そして、このヒアリングには二つの効果があります。

一つ目は自身が担当している範囲のコードではないので、相対的にリファクタできる部分はあっても、ドメイン知識やロジック、何をしているかを知る必要があるという点です。担当外の部分のコードであっても、責務境界、依存関係、説明的なコードといった、望ましい状態の本質は変わらないので、ドメインや背景を確認しながら進めていきます。

二つ目はヒアリングをすることで、本当はどういうものなのか、どういった意図が隠れているのか、といった潜在的な情報をメンバーから聞き取ることです。だいたい問題のある部分は、暗黙知か意味が適切に実装に反映されていないことが多いので、それをコードや設計上に説明しながら投影していくと、メンバーの記憶にも定着しやすいように感じます。

だいたい手を動かしている時間帯は、ヒアリング以外でメンバーからはあまり声は上がらないのですが、質疑応答タイムでは疑問点だったり、繋がりのわからなかった部分や、他の方法とどう違うのか、といった深堀りの議論が行われるので、理解度を深める効果に繋がっています。

リファクタ会のあとに出すPullRequestでは、大事なプロセスはすべて会で説明できているので、PullRequest上でコメントを書く数も少なくて済み、大量のやり取りが発生するようなこともありません。

リファクタ会による様々な効果

リファクタ会を続けてみると、リファクタ会を通して実際に改善されていく効果はもちろんなのですが、それ以外にも効果が生まれています。

例えば、メンバーが新機能を作り始める段階や、作っている途中で事前に設計やアプローチに関する相談をしてくれる機会が増えたり、各個人で行うリファクタが的確にポイントを抑えた価値のある改善に繋がっているなど、以前とは違う流れの変化を感じています。

また、普段のPullRequest上でも、リファクタ会で共通認識が形成できているので、コードの改善ポイントを以前より指摘しやすくなったり、以前説明したことのあるパターンやその応用であることを伝えると伝わりやすくなるなど、コミュニケーションコストの削減にも繋がっています。

特にリファクタ会へリーダー陣に参加してもらえると、リーダーがチーム内で改善方針を浸透させてくれたりするので、改善が円滑に進めやすくなる印象があります。

日頃からリファクタ会でコミュニケーションを取ったり、実際にリファクタの成功体験を積み重ねることで、事前に費用対効果のある設計を意識したり、依存関係を妥協しなくなるなど、よくある理想と現実的な話に収束せず、明確なメリットを得る改善を行える体制が整ってきました。

大変なところ

この形式のリファクタ会ですが、大変なところもあります。

一番は30分〜1時間の中で失敗できないという点です。そのため、難度の高そうなお題の場合はリファクタ会の前日に手を動かして予め会の中でどのように進めるかの予習を行うこともあります。

リファクタしている最中に思ったようにいかず「よくわからなくなってしまいましたね」というのはまさに失敗体験ですから、そのようなことがあってはいけません。論理的に改善されていなければ、メンバーにも納得してもらえないので、あらゆる変更に対してなぜそうするのかを説明できるよう進めていくことに気を付けています。

このあたりは、BCD Designでの経験、及びそのアプローチが非常に役立っているように感じていて、要件を適切にコードに写像し続けていくとわかりやすいものになるということをリファクタ会の中でも活かせていることを実感します。

試してみたけど難しかったこと

リファクタ会では、自身が手を動かしながら説明するスタンスを取っていますが、最初の頃はメンバーに手を動かしてもらって成功体験を積んでもらったほうが良いかなと思い、やってみたことがあります。

しかし、時間的な制約がある中でメンバーに手を動かしてもらうのが難しいことや、コードを移動しながら様々な関係性などを説明するときはどうしても自身の画面で説明しないと難しいなどがあり、現在のスタイルに落ち着いています。

今後変化させていくことはあるかもしれませんが、現状のスタイルで十分効果があると感じているので、当面はこのスタイルを続けていく予定です。

まとめ

今回はニコニコ生放送のフロントエンドチームで取り組んでいるリファクタ会について取り上げました。

チームやメンバーのスキルセットによってリファクタとどう向き合うか、どのような方法が合うかは千差万別なので、この方法が合う合わないはあると思いますが、リファクタが得意なメンバーがいる場合は、このような方法も一つの手段になるのではないでしょうか。

リファクタは身近なものでありながら、教えるのも学ぶのも難しい技術であると思います。しかし、成功体験を目の当たりにすることで突破口につなげられることがわかってきたことは大きな前進です。

今後も保守しやすい領域を増やし、開発効率の向上や、メンバーが気持ちよく開発できる環境を拡大していきたいと思います。

株式会社ドワンゴでは、様々なサービス、コンテンツを一緒につくるメンバーを募集しています。ドワンゴに興味がある。または応募しようか迷っている方がいれば、気軽に応募してみてください。

新卒採用はこちら
キャリア採用はこちら

Discussion