プロダクトオーナーにリファクタリングを承諾してもらう方法

リファクタリングの難しさ

• 直接は顧客に価値を届けない
• 何を持って完了とするのか曖昧

できること

普段からの共有

• 難しいと思っていること、躓いたポイント、解決したポイントは普段からPOに共有する
  • これが多いほど、シンパシーが生まれる
• 「いろいろ大変なんだね」と思わせる
• 後から違う話をしている最中に、「そういえばこんなこともあった」というような伝え方は心証がよくない

違う物事に例える

• 例えば、机の上の整理整頓ができていないと、仕事の効率が悪い
  • 同様にファイルの行数が多いだけで、効率は落ちる
  • あるべきものがあるべきところにないだけで、効率は落ちる
  • 色んな機能が一つのクラスにあると、効率は落ちる
  • 関数の行数が多いと、読みにくく、新しく入った人の理解が遅れる
  • コードを見れば、拡張する際にどこに何を置けばいいかわかるようなコードが理想
• ChatworkからSlackに移ったのは、ぶっちゃけオシャレだからでしょう？
  • コードも見た目が良くないと開発する気が失せる
• 単に、今後、こういうことをする際に毎回やらなくて済む、と具体的に伝えることも必要。その上で上記のような説得をすると効果が大きいかも

他の権威を利用する

• 例えば、フレームワーク導入など、自分で調べて説得することももちろん重要だが、ネットの記事などを見せると納得してくれる場合もある
• こういうやり方があるから、私達も導入してみましょう、のような紹介の仕方
  • もちろん記事を理解した上でやる
  • 記事を理解した上で、さらに私達の場合は〜なので、少し修正して〜のようにやればいいかもしれない、など、理解したアピールも重要

根回し

• 少なくとも開発者同士は結託しておきましょう

完了条件を明確にする

• 難しいときもある
• 小分けにできることはあるので、一度に一箇所だけやるようにする
• やってるうちにスコープを広げたくなるけど我慢

やってみせる

• 実際にやってみせる
• POが開発に詳しくて、簡単に例示できる場合に使える
• きれいなコードに共感してもらえるかもしれない

本当に必要なのか

• 本当に意味のあるリファクタリングなのか、考える
  • もしかしたら本当に無意味かも