この記事はCrowdWorks Advent Calendar 2018 の2日目の記事です。
はじめに
こんにちは。
クラウドワークスでプロダクトオーナーをしている 柴田 @shiba_319 です。
私の担当するWEB開発チームでは、今年6月から10月の約5ヶ月間、クラウドワークスのコア機能の一つである「仕事依頼画面」の大規模なリファクタリングプロジェクトを行なっていました。
私は、普段コードを触るのはちょっとしたスタイル修正や簡単なコード修正程度の非エンジニアPOなのですが、
今日はそんな自分が **「約6万行の大規模リファクタリングを完遂するうえでPOとしてやってよかったこと」**を書きたいと思います。
4名の開発チームで大規模リファクタリングをすることになった経緯
私たちの開発チームは、当時4名チームで、クラウドワークス発注者向けのUI/UX改善を担当していました。
（構成はエンジニア2名（！）、デザイナー1名、PO1名。中盤からエンジニア1名増え、計5名に)
リファクタリング対象になった**「仕事依頼画面」**は、クラウドワークスの発注者が仕事を発注する際に、仕事内容や予算・納期などの仕事情報を入力する画面です。
< クラウドワークスの仕事依頼画面 >
この画面はクラウドワークスの仕事が生まれる源泉であり、重要なコア機能なのですが、一方で社内のエンジニアから長年「闇」と呼ばれており
- クラウドワークス内で最も複雑なスパゲティーコード
- JavaScriptによって200以上ある仕事カテゴリ数ぶんのUI描画パターンがある
等々の問題を抱えたまま約2年間ほぼ手をつけることができていませんでした。
結果、私たちのチームがUI/UX改善を行おうとした際に
- 通常の数倍の開発工数に膨れることによるROI悪化
- 何か機能実装しようとすると闇の中にさらに闇を作ってしまうのでエンジニアが頭を抱える
といった状況となり、
**「ビジネス的にやりたいことがあっても技術的負債に行く手を阻まれる」**という大きな問題を抱えていました。
そのような状況下で、開発チームのエンジニアからPOへアラートが上がり、チームとしてリファクタリングに腰を据えて取り組むことにしました。
--
※エンジニア目線で何がどうヤバかったのか、興味のある方は、我が開発チームのエンジニアの記事をご覧ください。
混沌を極める jQuery のコードをいかにして Vue.js に頼らずに整理したか - Qiita
--
POとしてやってよかった5つのこと
まず結論としては、このリファクタリングは完遂することができ、
・6万行のコード変更
・200通り以上のUIパターン→6通りに凝縮
・疎結合でシンプルな内部構造
・コード簡素化による結果的なパフォーマンス改善
という結果をおさめることができました。
リファクタするぞ！とチームの意思が固まってからこれをやり切るまでに、
POとしてやってよかったことを記述していきたいと思います。
1.ステークホルダーにリファクタリングの価値を伝え、理解を得ること
これがリファクタリングプロジェクトのPOとして一番最初にやったことで、一番重要だと思っています。
6万行のリファクタリングともなると大変な規模で（特に当初はチームのエンジニアは、シニアエンジニア1名とジュニアエンジニア1名のたった2名）、ざっと半年間の開発工数を確保する必要がありました。
ステークホルダーには、
「現在どういう状況で、何がまずいのか」
「ビジネス的にどういう価値があるのか」
という点について説明し、具体的には
- 仕事依頼画面はプロダクトのコア機能の一つであり、今後ビジネス的に必ず改修したくなる時がくること
- いざビジネス的に改修する時がきた際、今の内部構造ではやりたいことができないこと
- 短期的に見ればユーザーに価値を与える仕事には見えないが、長期的な視点で見ると、ビジネス価値はとても大きなものになること
ここではざっくりですが、上記のようなことを伝えました。
リファクタリングのような内向きの仕事が生み出す利得は暗黙知的です。
マネージャーや周りのプロダクトオーナーにそれをやる意義を伝えることで、リファクタリングの仕事にしっかりと価値を持たせるのがPOの仕事といえるでしょう。
2. 短期的なチーム施策を全部止め、全リソースをリファクタに投入したこと
当時チームとしてあるKPIを持っていたので、すでに2〜3ヶ月分の施策プロダクトバックログを用意してありました。
が、リファクタリングに全てを注ぎ込むために、KPIはもう追わないと決め、短期施策は全て中止する判断をしました。
そして「リファクタをやりきることだけ」をチームの共通目標にすることにしました。
結果的に、開発メンバーのスイッチングコストを減り、一つのことに集中できる環境を作ることができたので、この意思決定は正解だったなと思っています。
3.リファクタリング範囲内にある、価値の低い機能を消す意思決定をすること
リファクタリングの実装フェーズに入ると、基本的にはエンジニアメインの作業のため非エンジニアPOとしては直接貢献できないのですが、
- ユーザーに使われていない機能
- メンテし続ける価値がないと判断した機能
を見つけ、「思い切って消す判断をする」ということを行いました。
全体作業量を減らすという意味で、POとしてもリファクタリング作業に貢献できたのではないかと思っています。
4. 短いスパンで途中で何度も立ち止まり、軌道修正すること
スパゲッティコードなので、とにかく内部にどんな強敵が潜んでいるかわかりません。
こういった不確実性が高い状況においては、最初のプランニングで全てを正確に見積もるのは不可能です。
ですので、計画は変わるものと捉え、1週間ごとのスプリントプランニングやリファクタの区切りのタイミング（約2〜3週間ごと）で何度も再計画していました。
（プロジェクト当初はこのことをPOとして理解しておらず、計画に固執してしまっていましたが、徐々に意味がないと気づきました）
5.リファクタリングの成果を、部署ないし全社に発信すること
最後に、無事リファクタリングをやり遂げたら、周囲に発信することです。
リファクタリングは内向きな仕事ですし、画面の見た目に変化があまりないので、何をやったのか伝わりづらいんですよね。
私たちの場合は、ちょうどタイミング良く全社キックオフのアワードがあったので、そこに自薦し、全社の前でプレゼンテーションをしました。
（ちなみに、全社MVPをいただきましたw）
以上が、POとしてやってよかったこと5つになります。
(オマケ) POとしてやるべきではなかったこと
最後に、リファクタリングプロジェクトにおいて、逆に**「これはやっちゃいけなかったなー」**という懺悔を連ねておきます。
POが実装計画の指揮をとること
自分は非エンジニアPOですし、リファクタリングはエンジニアが主体なので、はじめから実装計画はエンジニアに指揮をとってもらうべきでした。
開発チームがつくった実装計画に干渉すること
プロジェクト初期では、どうしても気になって口を出してしまっていましたが、エンジニア自身が最も状況を理解しているので、よくわかっていないPOが「ここもっと早くできないんですか？」などと干渉するのはやめましょう。
計画に固執すること
「最初の計画では〜」という会話を何度かしてしまいましたが、不確実性の高いプロジェクトにおいて、最初に立てた計画は途中でほぼ役に立たなくなることを学びました。
計画は細かいスパンで見直し、変更を歓迎しましょう。
どれも、スクラムのアンチパターンそのものですねw
おわりに
以上、「大規模リファクタリングを完遂するうえでPOとしてやってよかった5つのこと（と、やるべきではなかったこと）」でした。
プロジェクト中にいろいろな失敗を経験しながら、自分たちなりの良いやり方を模索できたのは良かったのかなと思っています。
少しでもプロジェクトを推進する方の参考になれば幸いです。