リファクタリングプロジェクトを終えて

はじめに

Merry Christmas

カオナビ様のAdvent Calendarに参加させていただきます！！
リファクタリングということで、半年間通して実施した所属部署のリファクタリングプロジェクトについて書きたいと思います！
僕が所属している部署は、いわゆる情報システム部門で、全社に展開しているインフラや、基幹システムの導入・構築・保守を行なっています。
プロジェクトをやり遂げた結果、業務の保守工数割合が33.8%だったところから10%を切るところまで削減することができました。
リファクタリングプロジェクトを通して、見えてきたものとは！？

リファクタリングプロジェクトとは

勤務している会社の自部署内で、半年間通して実施したリファクタリングプロジェクトについて説明します。

背景

日常業務が、アラート対応や、システム保守ばかりに工数を取られており、本来やるべき数年後を考えたシステム提案・構築や改善にほとんど手をつけることができていませんでした。
そこで、周辺組織へもご理解いただき、半年間リファクタリングと改善に集中させていただくことになります。
急ぎ案件だったり、致命的な不具合については随時相談を受け付けていましたが、基本的に新規の相談を受ける際は慎重に行いました。リファクタリングに集中する必要があったからです。

目的

保守工数を1/3以下に圧縮し、来年からは、未来に向けた施策に工数を使うことができるようになっていること。

方針

• 対応する優先度
  • 保守対応にかかっている工数を集計し、一番保守に時間のかかっている仕組みをリファクタリング・改修する
• 新規案件やアラートへの対応
  • リファクタリング中に発生したアラートに対しては、これまでと変わらず対応する
  • リファクタリング中は、急ぎ案件を除いて、新規案件の受付を停止する
• 不要なツール、データの整理整頓
  • 開発ツール、開発言語、開発ルールを定める
• 成果物の品質向上
  • 設計レビュー、実装後レビューの厳格にする

プロジェクト結果

冒頭でも述べましたが、プロジェクト自体は成功でした。見事に保守工数を1/3に圧縮し、保守工数の割合を全体の10%にまで削減することができたのです。定性的な評価としては次のようなことがあります。

リファクタリング前の状態

• 不要なデータファイルや、リソースが至る所に転がっており、使われているのか使われていないのかさえ管理できていない
• 例えばアラート通知するような仕組みが共有化できておらず、処理ごとで通知処理を記述している状況で非効率だった
• 前任者の遺したコードがカオス状態で、ナレッジもなく、障害が発生するたびに膨大な保守工数が発生していた。

リファクタリング後の状態

• 必要なデータが整理されている状態になった。今残っているデータファイルはすべて必要なもので、本番環境として稼働しているのか、テスト環境として稼働しているのか明確に整理された状態になった
• 前任者からの引き継ぎが無くブラックボックス化していたコードは、リファクタリングによりモダンなコーディングで、保守しやすい状態になりました
• 組織から1名育休を取得しているにもかかわらず、問い合わせの新規案件を受け取る余裕が保てています。

振り返り

続いて、リファクタリングに参加していたメンバーから出たメンタル面の振り返りについて、触れていきたいと思います。

リファクタリングを通してストレスだったこと

• 半年間という納期があったため、理想的な改修やリファクタリングではなく、目の前に見えている課題を解消するような修正にせざるを得ない状況が発生してモヤモヤ
• 設計レビュー、実装後レビューを厳格化したことにより品質は向上したが、資料作成やコミュニケーション工数が多く発生してモヤモヤ
• レビュイーは、レビュアーから指摘的な意見が多く出ているように感じて、ストレスがMAXでモヤモヤ
• 設計や実装に関して、設計やコーディングの宗教的な議論が何度かあり、前に進むのに時間がかかってモヤモヤ
• リファクタリングに集中させてほしい旨を展開していたが、幾度となく急ぎではない問い合わせが発生してモヤモヤ

リファクタリングして良かったな感じたこと

• 目標を達成し、とても大きな成功体験を得ることができた！
• 実際に保守工数が圧縮し、未来を見据える動きに時間を当てることができてきた！
• 周辺チームの問合せにしっかり耳を傾けることができ、メンバー間の関係性が向上した！
• 共通処理を整えたことで、新規開発時にも流用できることができ、構築工数の削減ができている！

おわりに

いかがでしたでしょうか。つくづく思いますが、仕事のための仕事ほど、無駄な仕事はありません！
リファクタリング自体は決して悪ではないのですが、それをどのような方針で行うかによって、メンバーのストレスは増減します。
特に、設計レビューや進捗管理のために膨大な工数がかかっているという非効率な状況は、よりメンバーの不満を膨らませてしまいます。プロジェクトとしてしっかりと管理したい、進捗させたいという気持ちも一定わかるのですが、時間が限られている状況では、過剰な品質管理は避けるべきでしょう。
結局は、納期、人的資源、品質の総合的なバランスが良いポイントを探すことに尽きるのです。そしてそれを定期的に測りましょう。（測るための工数はかけないように注意してください。）

最後まで読んでいただきありがとうございました！