見出し画像

リファクタリングをロードマップに組み込んで開発と並行しながら対処した話

Kotaro Nakamoto

こんにちは。
営業組織を改革するSaaS「GRAPH」を開発している CTO の中本です。

2022 年 7 月 12 日、GRAPHのメイン画面の一つである、「案件管理画面」の大規模改修リリースを完了しました。

見た目自体はリリース前後で変わりませんが、システムを動かしているコードはおよそ 9割以上 が変更されています。

もちろん、これだけ大量なコードを改修（リファクタリング）するには、およそ 2ヶ月半 ほどの期間を要しました。

どうして、スタートアップ時期には貴重である時間とリソースをかけてまで大規模なリファクタリングを行ったのか？

今日はそんなお話をしたいと思います。

「こんなんじゃ、ぜんぜん使い物にならない」

今年の4月、ビジネスチームからこんな連絡が入りました。

日々のクライアント業務に加え、自社の営業管理で自ら GRAPH のサービスを使っているビジネスチームだからこそ、入力ソースである案件管理のUXが良くないということを敏感に、そして身に沁みるほど感じていたのだと思います。

要するに、「こんなんじゃ、ぜんぜん使い物にならないよ」ということを暗に意味していました。

この時、私は「このままでは本当にまずいことになる」とはじめて痛感しました。

そこで、案件管理に関する不具合や改善要望に対して真摯に対応するため、開発ロードマップに2~3ヶ月に及ぶ長期改修（リファクタリング）期間を組み込みました。

機能開発を優先し、リファクタリングをおろそかにしていた

そもそも案件管理画面は、当時どのような状況になっていたのでしょうか。

案件管理画面は、去年11月にリリース（当時はヨミ表と呼称）した、営業活動における商談データを入力・蓄積するための GRAPH の主要機能です。

報告があった当時、初期リリースからちょうど半年ほど経った時期で、それまで案件管理画面に対してどんどん機能追加を行なっている最中でした。

しかし、機能追加の要望を優先しすぎた結果、コードのリファクタリングや不具合改修が追いつかず、新機能がリリースされる度、ますますバグが増えるばかりでした。

つまり、手に負えないほどの技術負債を溜め込んでしまっていたのです。さらに、自社のエンジニアチームにはフロントエンドに採用している技術の React に詳しいメンバーが不足していたため、この問題の対処も難航している状況でした。

中長期プロジェクトとして、ロードマップに設定

では、どのように対処していったかというと、

⚪︎ 現状報告の挙がっている不具合・改善要望を洗いざらい整理
⚪︎ これらを一つにまとめ、開発ロードマップに「案件管理のリファクタリング」プロジェクトを作成
⚪︎ 他画面の新機能開発と並行しつつ、案件管理のリファクタリングを実行
⚪︎ GRAPH の社員全員で QA テスト を実施
⚪︎ QA 〜 不具合改修 を繰り返して、最終チェック
⚪︎ 細かい機能改修を除いて、問題ないことを確認し、リリース

のように、上記の流れで進めていきました。

初めに個別の不具合を整理・タスク化することから始めましたが、なんとこの時点で 約50件 ほどの不具合、改善要望が発生していました。

「こんなにも不具合を出してしまっていたのか」と驚き（と絶望）を抱えながら冷静に工数を見積もると、2ヶ月半ほどかかりそうだということが分かりました。

そこで、PdMを兼任しているCOOの飯塚さんと相談し、ロードマップ上に中長期プロジェクトとして案件管理画面の機能改修期間を設けました。

あとはやるだけ、しかし問題発生

しかし、問題はここからでした。
実際にこんなにも膨れ上がった不具合をどう解消すれば良いのか。

私自身も、もちろんコードはゴリゴリ書けるつもりですが、 フロントエンドを得意としている訳ではないため、どこから対処していけば良いのかわかりませんでした。

そんな時、救世主かのごとく、フロントを極めて 早２０年の凄腕ベテランエンジニア が現れました。

彼と相談したところ、「案件管理の改修には、今のコードをほぼ全て変える必要がある」ということが分かりました。

内心ハラハラしながらも、「もうやるしかない！」と腹をくくり、彼にこの大規模改修を一任してもらうことにしました。

機能開発は止めます！なんて言えない

工数を見積もった結果、約2ヶ月半の改修が必要と判明していました。

しかし、「その期間中、一切機能開発をしません」なんて悠長なことは言ってられません。

まだまだ 戦略的に開発していかないといけないものが山ほどあるため、改修作業と同時並行で機能開発を進めることはマストでした。

ロードマップ上にすでに存在するプロジェクトを、パズルを埋めていくようにうまく組み合わせながら、リファクタリングを並行して進められるように計画していきました。

なんとかリリースした結果、大量のバグ解消だけでなく他にも良いことが

ベテランエンジニアと奮闘することおよそ2ヶ月半、、、、
ついに案件管理画面に関するあらゆるコードのリファクタリングと不具合改修が完了しました！
（体感だともっと長く感じました…）

結果、大量の不具合修正ができただけでなく、処理スピードの改善や UX の改善項目として挙がっていた一部の要望にも対応することができました。

また、大量の不具合を治すためにはまずコードのリファクタリングが必要だったため、ほぼすべてのコードを見直し・再整理したので、プログラムの見通しが以前と見違えるほど良くなり、追加の機能開発やバグ修正が非常にやりやすくなりました。

さらに、個人的に良かったなと思ったことは、
「社内でリファクタリングの重要さを共有できた」ことでした。

ロードマップに大きく「案件管理のリファクタリング期間」を設けたり、社員全員で QA テストを実施したりしたことで、エンジニアだけでなくビジネスメンバーを含め全員が「リファクタリングって大事なんだ！？」となんとなくでも意識するきっかけを作れたのではないかと感じています。

結論：リファクタリングをロードマップに入れて良かった

今回の一件を通して、エンジニアからしたら本当に当たり前な話ですが、「リファクタリングは超大事」だということを学びました。

リファクタリングをすることで、不具合を出しにくくするだけでなく、処理スピードが改善されることで UX が改善されたり、検証作業も切り分けが非常にラクになったり、はたまたエンジニア自身の DX（開発体験：Developer eXperience）向上だったり、想像していた以上に良いことばかりでした。

機能開発をつい優先してしまうのは、どの会社もあるあるだと思いますが、今回の件で、私はその代償を骨に染みるほど実感しました。また、開発方針の一つに「コアなロジックを磨き込む」ことを掲げているものの、自分自身が徹底できていなかったことを深く反省しました。

今後は、同じ轍を踏むことがないように、「普段から小さくリファクタリングしていく」&「不具合は溜めない」ことを意識して、開発体制・仕組みをより一層強化していきたいと思います。



さて、まだまだ振り返って学んだことはたくさんありますが、一旦ここらで筆を置きたいと思います。

今回振り返りも兼ねて、弊社がリファクタリングに取り組んだ話を書きましたが、他の企業でも同様な問題を抱えて困っている方がこれを読んで少しでも参考になれば幸いです。

また、弊社は今後もプロダクトの成長はもちろんのこと、私自身、そしてチーム、会社自身もものすごい勢いでアップデートしながら進んで参りますので、どうぞ引き続き応援のほどよろしくお願いいたします！

それでは！👋


いいなと思ったら応援しよう！