同じ結果を出す手順が、人によって3通りのやり方になっている職場があります。整理したい気持ちはあっても、下手に触ると誰かの仕事が止まりそうで怖い、というためらいもあります。その恐れを乗り越えるための考え方が、今日扱う「リファクタリング」です。結論を先に言えば、鍵は「何を変えないか」を先に決めておくことにあります。この考え方を知っているかどうかで、同じ「業務を整理したい」という気持ちが、無謀な賭けになるか、安全に進められる作業になるかが分かれます。
リファクタリングとは何か
ソフトウェア開発におけるリファクタリングとは、外から見た振る舞いを変えずに、内部の構造だけを整理し直す作業のことです。ここでいう「外から見た振る舞い」とは、入力に対してどんな出力が返ってくるか、という結果のことです。機能を追加する作業でもなければ、バグを直す作業でもありません。「同じことをする、もっと分かりやすい形」に書き直す、それだけの作業です。
重要なのは、「振る舞いを変えない」という約束を、誰かが保証してくれる仕組みがあって初めて、この作業は安全にできるという点です。ソフトウェア開発では、その保証をテストが担います。整理する前にテストを実行し、整理した後にもう一度同じテストを実行して、結果が変わっていないことを確認する。この一手間があるからこそ、開発者は安心してコードの中身に手を入れられます。逆に、確認する手段が何もないまま構造をいじると、それはリファクタリングではなく、ただの賭けになってしまいます。
もう1つ大事な特徴は、リファクタリングを一度に大きくやらないという原則です。開発者は、構造を整理する作業を、できるだけ小さな単位に分けて進めます。1つ整理しては確認し、また1つ整理しては確認する、という細かい往復を繰り返します。一度に広い範囲を書き換えてしまうと、もし結果がずれたときに、原因がどこにあるのか分からなくなるからです。小さく直して、都度確かめる。この往復こそが、リファクタリングを安全な作業にしている最大の理由です。一度に大きく変えたい衝動を抑えることが、結局は一番の近道になります。
仕事の言葉に翻訳すると
業務におけるリファクタリングとは、最終的なアウトプット、たとえば承認される稟議や、提出される報告書の中身を変えずに、そこに至るまでの手順・様式・分担だけを整理し直すことです。目指す状態は明快です。「今までと同じものが、今までより少ない手間で、今までより早く出てくる」。これが実現できていれば、リファクタリングは成功しています。
リファクタリングとよく混同されるのが、業務そのものを見直して結果まで変えてしまう「業務改革」です。両者は似ているようで、前提がまったく違います。業務改革は、最終的な成果物や判断基準そのものを変える取り組みで、関係者の合意形成に時間がかかります。リファクタリングは、成果物は変えないという前提のもとで進めるため、合意形成の負担がずっと軽く済みます。「何を変えないか」を先に決めておくことが、この作業を軽くする鍵になります。
業務改革が「何を変えるか」を議論する作業だとすれば、リファクタリングは「何を変えないでおくか」を先に固定してから動く作業だと言えます。この違いを職場で共有しておくことには、実務上の利点もあります。「結果は変えません、手順だけ整理します」と最初に宣言できれば、関係者の警戒は大きく下がります。逆に、この宣言なしに手順を触り始めると、周囲は「何か変えられるのではないか」と身構えてしまい、協力を得にくくなります。リファクタリングは技術であると同時に、周囲の理解を得るための伝え方でもあるのです。
具体的な場面
転記作業の一本化。稟議申請の際、担当者は複数のExcelファイルに同じ数字をそれぞれ手で転記していました。金額を1つ直すたびに、3つのシートを開き直して同じ数字を打ち込み直す必要があり、転記ミスも度々発生していました。1つの入力フォームに数字を入れれば、関係する各シートに自動で反映されるよう整理したところ、最終的にできあがる稟議書の内容は、以前とまったく同じままでした。変わったのは、そこに至るまでの手間と、転記ミスの起こりやすさだけです。承認者から見ても、稟議書の見た目や承認すべき内容は一切変わっていません。
議事録の様式統一。あるチームでは、3人のメンバーがそれぞれ違う粒度で議事録を作成していました。決定事項の書き方も、担当者の書き方も、人によってばらばらで、後から読み返す人はどこに何が書いてあるかを毎回探す必要がありました。共通のテンプレートに統一したことで、会議で決まった内容という「結果」はまったく変わらないまま、後から読み返す人の負担が大きく減りました。誰が書いても同じ場所に同じ種類の情報がある、という状態になったことが、整理の実質的な成果です。
承認順序の入れ替え。ある承認フローには、実質的にはほとんど確認をしていない中間承認者が含まれていました。形式上の押印だけが目的化していて、その承認者の確認を待つあいだ、申請は何日も止まっていました。承認そのものを省略するのではなく、承認の順番を組み替えて、実質的な確認をする人を先に回すようにしたところ、最終的な承認結果は変わらないまま、承認が完了するまでの時間が短縮されました。誰の権限も奪っていないのに、待ち時間だけが減った、という点が重要です。
なぜ怖くなくなるのか — 確認の仕組みを先に作る
3つの場面に共通しているのは、手を入れる前に「結果が変わっていないか、どう確認するか」を決めていたことです。転記の一本化では、新旧のやり方で同じ案件を1件処理し、金額が一致するかを確認しました。議事録の統一では、過去の決定事項を新テンプレートに書き写してみて、抜け落ちる情報がないかを確認しました。承認順序の入れ替えでは、承認する人の顔ぶれが変わらないことを、関係者全員に事前に確認しました。どの場合も、確認の方法は特別なものではなく、数分でできる簡単な照合です。それでも、この一手間があるかどうかが、「安心して整理できるか」と「触るのが怖いままか」を分けています。確認の方法を先に決めておけば、途中で不安になったときにも、その基準に立ち返って進めるかどうかを判断できます。逆に確認の方法を決めずに進めると、うまくいっているかどうかの手応えがないまま、なんとなく不安なだけの状態が続いてしまいます。
落とし穴 — 「整理」のつもりが「変更」になる
「振る舞いを変えない」ことを確認する手段がないまま手を付けると、リファクタリングのつもりが、いつの間にか仕様変更になってしまいます。これは、テストのないコードをリファクタリングするときに開発現場で起こる典型的な失敗と、まったく同じ構造です。業務であれば、変更の前後で「同じ入力に対して同じ結果になるか」を、少なくとも一度は照合する機会を作る必要があります。たとえば、新旧両方のやり方で1件だけ実際に処理してみて、出てくる結果を突き合わせる、という程度の確認でも効果があります。この確認を省略した状態で「たぶん大丈夫」のまま進めてしまうと、後になって承認基準が微妙に変わっていたことに誰も気づかない、という事態になりかねません。
もう1つの落とし穴は、整理すること自体が目的化してしまうことです。誰の得にもならない体裁の美化に時間を使い、肝心の手間や時間は変わらないまま終わる、という失敗です。たとえば、フォーマットの見た目を何度も微調整することに時間を費やしても、実際に作業する人の手間が減っていなければ、それはリファクタリングとは呼べません。リファクタリングの目的は「見た目を整えること」ではなく「同じ結果を、より少ない手間で得られるようにすること」だと、常に立ち返る必要があります。迷ったときは、「この変更で、誰かの作業時間が実際に減るか」を自分に問い直すとよいでしょう。その答えが曖昧なままなら、まだ手を動かす段階ではない、というサインです。
最後に、一度に手を広げすぎないことも重要です。関係する手順すべてを一気に組み替えようとすると、途中で収拾がつかなくなり、結果が本当に変わっていないかの確認も難しくなります。小さな範囲で1つずつ手を入れ、その都度結果を確認しながら進めるほうが、最後までやり切れます。
さらに、誰の手順を整理するのかという点にも注意が必要です。自分1人の作業手順を整理するのと、他部署が関わる手順を整理するのとでは、必要な確認の重さがまったく違います。他部署が関わる手順であれば、変更を伝えるだけでなく、実際に困る人がいないかを、着手前に必ず確かめておく必要があります。「良かれと思って整理したら、実は誰かがその手間そのものを別の目的に使っていた」という失敗は、珍しくありません。たとえば、転記作業をしていた時間を、内容を見直す時間として実質的に使っていた、というようなケースです。表面上の手間だけを見て整理すると、見えていなかった価値まで一緒に削ってしまうことがあります。だからこそ、他部署が関わる整理では、変更内容を伝える前に「今のやり方の中で、意外と役に立っている部分はないか」を、相手に率直に尋ねる一手間が欠かせません。
リファクタリングは一度で終わらない
ここまで見てきた3つの場面は、いずれも一度きりの整理として紹介しましたが、実際にはリファクタリングは一度やって終わりという性質のものではありません。業務の内容や関係者は、時間が経てば少しずつ変わっていきます。今日整えた手順も、半年後には別の部分が使いにくくなっているかもしれません。ソフトウェア開発の現場でも、コードは一度整理して終わりではなく、機能追加のたびに少しずつ整え直され続けます。完璧に整った状態を一度作ることを目指すのではなく、触るたびに少しだけ整える、という向き合い方のほうが現実的です。この「触るたびに少しだけ」という発想は、この章の後半で扱うボーイスカウトルールにそのままつながっていきます。一度に完璧を目指すのではなく、小さな改善を積み重ねる姿勢のほうが、結果的に長く続きます。
持ち帰り
- リファクタリングとは、結果を変えずに、そこに至る手順や様式だけを整理し直す作業のこと
- 「結果が変わっていないか」を確認する手段を用意して初めて、安心して手を入れられる
- 一度に広げすぎず、小さな範囲で確認しながら進めるほうが最後までやり切れる
やってみる
自分が繰り返している作業の中で、同じ数字や同じ文言を複数の場所に手で転記している箇所を1つ見つけ、1箇所にまとめられないか考えてみましょう。