はじめに
この間、Studioでエディタの大幅な高速化をリリースしました。
これは開発初期からの設計を見直して実現したものです。確実に改善につながると確信できるものでしたが、コア機能に大きく手を入れる必要がありました。
リファクタリングは、多くの技術記事でも意見が分かれるテーマです。原則論では肯定的に語られる一方、実践論では「そのリファクタ、今やるか？見送るか？」という判断基準の重要性が強調されています。
この記事では、どうやってリファクタを見極め、どうやって組織を動かし、どうやってやりきれたのか、振り返ります。
基盤チームという取り組み
今年初めから、私はStudioの基盤チームでフロントエンドの改善全般に取り組んでいます。
現在のStudioの開発体制はいくつかのチームがあり、その一つにサービス全体を支える基盤チームがあります。基盤チームのメンバー10人ほどは個々に開発に取り組んでおり、私はその中でフロントエンド全般の改善を担当しています。
これは通常の機能開発チームとは異なり、8年ほど運用してきたプロダクト全体を把握してテコ入れするという立場です。私のポジションは遊撃的で、自分が直すべきと思ったところを自己判断でどんどん直しています。それが単独でできるようになったのは、AIと壁打ちして素早く検証できることと、自分が初期からの開発メンバーでプロダクト全体を把握していることが大きいです。
そうした取り組みの中で、初期設計を見直すべき箇所に気づくことができました。
1日かけて検証を行い、根本原因を明確にする
エディタのパフォーマンスをもっと改善したいとの声が上がり、ある日検証を始めました。
最初に疑ったのは、エディタレンダリング用の仕組みでした。いかにも不要そうな処理が多く、それらを排除すれば改善されるはずだと以前から考えていました。しかし、いくつかの観察から別の仮説が浮かびました。
- 新規プロジェクトでは重くない
- 現在ページのデータだけを軽くしても操作が重い
この2点から、「現在のページレンダリング処理」ではなく「プロジェクト全体のデータ」に問題があるのではないかと考えました。
現在編集しているページデータが少なくても、プロジェクト内の他のページのデータが多いとエディタ操作が遅くなります。この挙動から「全ページのデータがstate化されてしまっているのがパフォーマンス悪化の原因では？」と仮説を立てました。
仮説を確かめるため、無理やり現在ページ以外をstateから除外する仮の実装を作りました。コア機能に手を入れるため、従来であれば難しく時間がかかる作業です。しかしAIと壁打ちしながら検証用の実装を作ることで、素早く確認できました。
すると、エディタ操作のパフォーマンスが劇的に改善されました。Vueアプリで全ページのデータをstateで管理していたため、stateの一部を変更するだけでVueのリアクティブシステムが全体を再計算してしまっていました。ページ数が多くなるほど、この負荷が問題になります。
余計なstateを除外すればいい。解決の方向性が見えました。
単純に「パフォーマンスが悪い」という問題の要因は複雑なため、これまでなかなか特定ができていませんでした。しかし人間が仮説を立て、AIで検証用のコードを素早く作り、ひとつひとつ確認していくことで原因が確実に絞り込みやすくなります。1日かけて向き合うことで、AIだけでは特定できない根本原因を明確にできました。
検証によって価値提供を明確にする
原因と解決策が明確になりました。ここからが重要です。
検証自体は合意なしで速く進められますが、実装フェーズに進むには組織として実施を決定する必要があります。
問題を明確化し、検証環境を作ることで、何が改善できるかを他のメンバーにも具体的に示しました。
- 根本原因が特定されている
- 解決策が明確である
- 検証環境で改善効果を確認できる
- 実装の方向性が定まっている
これにより、「エディタのパフォーマンスが劇的に改善される」という価値提供が明確になりました。懸念やリスクではなく、顧客に届く価値が先に見えている状態です。ネガティブに評価されがちなリファクタですが、組織として「いいね、是非やろう」とポジティブにGoを出せる状態を作ることができました。
検証によって課題を言語化し、価値を可視化できて初めて、それが「やるべきこと」として明確になります。言語化された課題であれば、AI実装とその検証はしやすくなります。
実装よりもまず検証。これが今の自分の開発スタイルです。
短期間でのリリース
10月に取り掛かり、11月にリリースしました。1ヶ月足らずでした。
この期間には、ミニマム実装での検証、検証結果に合わせた設計見直しと本実装、自動テスト以外にもさまざまな人による実動作によるフィードバックと修正、そしてリリースまでが含まれています。
従来であれば、こうした根幹設計の見直しは数ヶ月、場合によっては1年以上かかる規模の変更だったかもしれません。それが短期間で実現できたのは、検証による課題の明確化と、AI活用による実装の高速化があったからです。
そして何より、基盤チームという立場でプロダクト全体を俯瞰し、課題に向き合える環境があったからです。
なぜ誰も向き合えていなかったのか
エディタのパフォーマンスが良くなかったことはなんとなく認識はしていました。
しかし、誰もその根本原因を明確にできていませんでした。開発者である私たちも「長年運用してきたプロダクトだから、さまざまな機能が増えたことでパフォーマンスは落ちるだろう」と捉えて、そういうものだと受け入れてしまっていました。
Dan Abramov氏の記事「How to fix any bug」では、AIにバグ修正を任せる際の教訓が語られています。
この記事では、AIが最初に失敗したのは「再現方法を検証できなかった」からだと述べています。曖昧な症状のままでは、AIは推測で修正を試みて的外れな変更を繰り返してしまう。問題を測定可能な形に変換し、検証可能なテストを用意して初めて、AIは力を発揮できるようになったと。
これは私たち人間も同じでした。「パフォーマンスが悪い」という漠然とした認識のままでは、何を直せばいいのか分からない。AIに限らず、問題が明確化されていなければ誰も向き合えません。
設計はどうしても最初から完璧にはできません。後になって見直す必要もあります。しかし、まず設計の課題を明確にする検証に誰も向き合えていませんでした。そして仮に課題が明確になったとしても、長年運用している根幹の設計に改修を入れることへのリスク、それを計画して実施するための人員や期間が大きなハードルになります。
まとめ
エディタ高速化のリリース後、顧客から大きく改善されたという声をいただきました。
これは新機能実装のように分かりやすい価値提供ではありません。しかし、確実にユーザー体験を向上させるものです。
「なんとなく認識はしているが、確実なものとして実装しづらい。あるいは現在動作しているのだからヘタに手を入れたくない」
こうした問題は多くのプロダクトが抱えています。『パフォーマンスが落ちている。リファクタすればよくなりそう』という漠然とした起点で始めると、成果が出づらく、エンジニアの自己満足と評されるかもしれません。
今回は検証によって根本原因を特定し、改善効果を先にしっかりと可視化した上で実装に進むことができました。漠然とした課題が「やるべきこと」に変わり、短期間で実現できました。
基盤チームという取り組みと検証の高速化によって、設計の見直しが組織として合意が取れてユーザー体験の向上につながる。これがプロセスとしてうまくいった、というのが今までで一番の成果です。
…つまりどういうこと？（by Claude）
この記事を読んだAIによる要約です
「大きなリファクタリングをやる前に、まず1日で検証して効果を証明する」 ということ。
- 「たぶんこれが原因だろう」と仮説を立てる
- 本格実装せず、検証用のコードをAIと一緒にサッと作る
- 実際に速くなることを目に見える形で示す
- チームに「これだけ効果あるならやろう」と納得してもらう
- そこから本格的に実装する
効果が不明なまま数ヶ月かけてリファクタリングするリスクを回避できる。「やるべきかどうか」の議論が、数字や動くデモで決着する。検証に1日使うことで、無駄な数ヶ月を防げる。
なぜ1ヶ月でやりきれたのか？
- 検証で「これをやれば速くなる」と証明済みだったので、迷いなく実装に集中できた
- AIとの協働で実装を高速化できた
- 基盤チームという立場で、自己判断で進められる裁量があった
「何をやるべきか」が明確なら、あとは手を動かすだけ。
Web制作を、ノーコードで。 ノーコードWeb制作プラットフォーム「Studio」開発で培った技術的な知見を投稿します。 Unleash Creativity.
Discussion