この記事は株式会社イルシルのテックブログとして、イルシルの技術的な取り組みについて紹介しています！
こんにちは、イルシルでPdM(プロダクトマネージャー)を担当しているku-sukeです。イルシルはAIをつかってスライド生成ができるサービスで、日本らしいデザインや、有料ですがPowerPointにも書き出しができる（海外製サービスなどはHTMLベースなので非対応が多い）ところが特徴のサービスです。
今回、フロントエンドを劇的に改善する必要があり、mizchiさんのFrontend改善のFull Planを申し込んで１か月（連休挟んだので実際はもう少し長く）がっつり見ていただきました。
なお、技術的な解説はmizchiさんのZennに記載されていますので、本記事では主にPdMの立場から、なぜ自分たちだけでの負債解消ではなくmizchiさんに入ってもらったのか、その結果どうだったのか、1か月の過ごし方はどうだったのかといったあたりをご紹介できればと思います。技術的なポイントはこちらの記事をご覧ください。
ブラウザ上でスライドエディタを作る大変さ
さて、イルシルについてもう少し解説すると、AIを使って主にチャット形式でスライドの構成を考えるパートと、デザインテンプレートをフル活用してスライドを編集するパートに分かれます。いずれも改善が必要だったのですが、とくにスライドエディタに関しては同時にロードするリソースも多く、気が付くとChromeタブのメモリ使用量が1GBを超える..といったことも起きていました。
左にスライドプレビュー、下部にデザイン提案、上部に図形などのツール、右側はAIエディタ、中央のスライド編集を取り囲んで盛りだくさんの画面で、同時編集にも対応するため通信も頻繁に走っています。
サービスが爆発的人気となり負債が山盛りに
このイルシルを開発した当初は、AIもなく、デザインテンプレートを使ったパワポエディタから始まりました。そのころはユーザ数も少なく今の構成でも問題なかったのですが、AIを搭載して以降ユーザー数が爆発的に伸び（特に直近の約半年で10万人増えて19万ユーザ超）機能開発や不具合修正に追われてパフォーマンスに手を入れるタイミングを見失っていました。
実際、メンバーの中でも古いMacを使っている人は、Meetを使いながらイルシルを画面共有しようとするとブラウザが固まるという状況が発生しており、このままでは品質が成長の足かせになってしまうのが明白でした。
パフォーマンス以外にも技術的負債の解消でやりたいことやたくさんあったのですが、週に数時間をひとりづつ負債解消に使うといった程度では追いつかない状態となっていました。
mizchiさんのパフォーマンス改善サービスを申し込んでみた
mizchiさんの改善サービスを知るきっかけとなったのは、LAPRASさんの公開パフォーマンスチューニングでした。
このなかで、DeveloperToolをふんだんに活用しながら、コスパのいい改善を提案されているのを見て、もしかしたらいまのイルシルにちょうどいいのでは？と考えてDMでご相談してみたのです。
お話を聞いてみたところ、
- 基本的に１か月でソースコード分析して、こう直したら早くなるというサンプルコードを書いて解説してくれる
- ドメイン知識が必要な部分には原則踏み込まない
みたいな感じで、あと余談でこういったオンライングラフィック編集ツールのご経験もあるということと、AIコーディングに相当突っ込まれていることも知っていたので、すぐに社内決済をあげて４月からお願いすることになりました。
古すぎて改善できない・・初手で大きな選択をせまられる
さて、それで早速ソースコードを見てもらって、動作確認してもらったのですが「すみません、このプロジェクト、もろもろアップデートしないと改善に取り組めません」との報告が。
内容は確かにその通りで、使っていない（可能性の高い、でも確信が持てない）ライブラリも含め依存関係が多くあり、それをアップデートせずに小手先で改善できる範囲は限られているということがわかりました。
一気にやるか vs 少しづつやるか
わかりました、が、悩みどころです。各種ライブラリやランタイムのバージョンを上げるとなると、大変です。何度か個人的に経験はあるのですが、一番しんどいのが本番デプロイがしばらくできなくなること、mainブランチにマージができなくなり、開発フローがぐだぐだになったり地獄のようなマージ作業が発生することです。
やらしい話ですが、せっかくまとまったお金払って１か月来てもらうのに、小手先をちょろっと改善して終わりというのはないだろうという気持ちが勝ってしまい、PdMの強権発動で開発ラインをほとんど止めてバージョンアップに集中することにしました。
びっくりするくらいダサいネーミング（昭和世代なので・・・）
当初「みんなでやったら3日くらいで行けるっしょ」みたいな無茶を言って顰蹙を買ったのですが、結果的には10営業日くらいで本番デプロイまで行けて、アップデート待ちの滞留を最小限に抑えることができました。
チームの皆さんすごい頑張ってくれて、本当にありがたかったです。もちろんずっとやりたかった負債解消がやっとできるということもありますし、mizchiさんが来てくれて「お祭り」みたいになったのも頑張れた要因じゃないかと思っています。
パフォーマンス改善サービスの結果
実はこれ以外にも先行して活動していた負債解消もあったのですが、それらも併せて開発ワークフローがだいぶ整ってきました。
- 開発環境、ステージングのコンテナ化
- ライブラリのアップデートや削減
- バンドルの分割
- テストツールの変更とテストコードの書き方
1か月をどう過ごしたかというと、営業日ベースで5日分析、10日改善、5日残課題のディスカッションという感じです。短期のコンサルティングなどでよくある問題ですが、契約期間が短いと「手を動かすのが先生がいなくなったあと」という問題がよく起きてしまいます。
そういう意味では、かなりの無茶ぶりでしたが、mizchiさんがいる間に一番大きな部分をやり切れたのは本当に良かったと思っています。実は僕がプロダクトチームを担当し始めたのは４月からだったこともあり、呼ぶだけ呼んでおいてCTOやEMに丸投げすることも多々あってだいぶ迷惑をかけてしまいました。成果はすべてを癒すということでキレイに収まりましたが、本当はもっと準備できたんじゃないかなという反省もあります。
負債解消やパフォーマンスにどう投資するかはPdMも悩むから
一般的に、開発チームがどの程度負債解消やパフォーマンスに取り組むかは答えがないように思います。事業は複雑なので、スライド編集画面のロードが5秒から4秒に、メモリ1GBが0.8GBに減ったところで売り上げがどれほど上がるのか完璧に説明することはできません。
また、どこまでやってどこで止めるかも難しいものです。これをやったら速くなるだろうという施策が20個くらいあって、工数を金額換算して500万円分の工数だったとして、それを全部考えもなく投資するわけにはいきません。
そういったときに、フロントのメトリクスや負債に関して「ここは赤信号、ここは黄色」「この改善は工数のわりに速度貢献が高い」のような経験からくるアドバイスをもらえたことは、PdMにとって重要な手術をする前のセカンドオピニオンとしてありがたかったです。
また、アドバイスだけでなく初めの第一歩を踏み出すためのコードも提供いただいたので「理屈は分かったが手元のコードをどこから始めればいいかわからん」という状態にならずに済んだのも非常に大きかったと思います。
まとめ
- mizchiさんの改善サービスで負債解消やパフォーマンス改善をイベントとして取り組めた
- 数字を預かるPdMとしても投資対効果がわかりやすくて満足度が高かった
- お願いするときは新規開発を止めて集中して対応したほうがよさそう
フロントエンドの世界はトレンドの移り変わりが激しかったり、その世代ごとの依存関係が複雑だったりするため、これを機に定期的に勉強会を行ってフロントの環境を見直していくという取り組みも実施することになりました。そのタイミングでDevToolsをつかった定期的なメトリクスの確認もおこなうことで、フロントエンドを健全に保つための取り組みが組織に定着できそうです。
mizchiさん、開発チームをはじめとするイルシルの皆さん、ありがとうございました！
Discussion