はじめに
リファクタリングについてのテクニカルな話を書こうと思えばいくつか書ける。ただ、結局のところは有名な本（マーティン本 とか コードコンプリート とか）をいくつか読んで、現場のプログラムを何度も何度も読みこんで、少しづつ直していくほかはない。自走力（＝自習力）と問題意識（＝「めんどくせぇ～」のアンテナ）があればリファクタリングのスキルなんてものは自然についてくるもんよ。
今回はアドベントカレンダーをきっかけに、いつもの記事とは色を変えて「現場のリファクタリングに取り掛かるための戦略」について書いてみようと思う。エンジニアとして生き抜くための勘所みたいなものを書ければいいなと思う。具体的な現場名はさすがに書かないけど、繁忙期には3週間（＝21日間）ほどマジで休みなしになるあの現場にいた時期というのは、やっぱりいろんなエッセンスが混じったひとつの「戦争」だったんだろうなと思う。
―― 技術的負債は、リファクタリングの文化を作って丁寧にスプリントをこなせばきれいになる
いや、コピペが氾濫するカオスな開発現場にリファクタリング文化を産みだすのは簡単なことではないよ。カイゼンに「答え」なんてないし、今回の記事は結論にすらたどりつかないかもしれない。それでも書くのは、どこかの誰かがひとつの現場について書き殴った散文も、どこかでだれかの役に立つことがあると思っているためだ。
火災を起こしながら成長するプロダクト
開発コードが、未来のスケール規模に合うように完璧に整備されてから「階段をのぼるように」成長するプロダクトなんてのはないと思っている。最初「えいや」で作ってたまたま人気に火がつくと、いろんなITエンジニアが後追いで投下される。僕もそんな「傭兵」のひとりだ。
もともと「背中から３つめの足が生えて手になってる」ようなよくわからんコードなのに、（そんなプログラマの心配をよそに）プロダクトはなぜか急成長して毎年クライアントが2倍になったりする。感覚的にはあの混乱具合は「加速度的」と言っても過言ではなかったと思う。輪をかけてクライアントごとの個別カスタマイズがあったりするから2倍がただの2倍じゃないんだよ。保守のパーティーが始まる。
保守の難易度が極まってきて、リードタイム（＝保守チケット1つあたりの所要時間）が無視できないほどに長くなってくると、顧客の要求に耐えられないと上層部が判断し、どこかからアジャイルチームが投下される。定時で帰るJIRAおじさんも一緒にどこからか発生し、JIRAの自動化が進む（しかも間違った使い方で。。。）。よくわからないミーティングの時間が増える。ある日、予算不足を起因として大ナタが振るわれ、開発チームの半分が消えた。宴もたけなわである。いや、地獄の三丁目か。Open な Issue が 1,000 を切ったことはなかったな。。。為す術がないという意味で「森林火災」という言葉がぴったりだった。
僕は最初はSE（設計屋）として入ったんだ。気がついたら人がいなくてプログラマになっていた。気がついたら旧機能の最後のひとりの保守プログラマになっていた。しかもそれが2年足らずの時期における出来事だった。めんどうな個別カスタマイズも切り捨てるほうに舵を切り始めたようだ。なるほど、どんなにクライアントが増えたソフトウェアもこうしたことが積み重なって人がこなく（＝古く）なっていくんだろう。諸行無常である。
タバコと政治
いきなり差し込むが、これはほんとに根深いテーマ。現場の「政治」はタバコ部屋で決まる。これはいまだに感じる。釣りバカ日誌の釣り仲間みたいなもん（モノがタバコになったりゴルフになる）。僕はタバコが吸えないのでそのアプローチはできない。ただ人間観察を続けていると、チームが新たに組まれる（＝カネの流れが発生する）ときなんかは特に、タバコを吸えることが「グリップ力」に繋がってくる。技術力がなんぼあってもリファクタリングのスタート地点は、なぜか「仕事の勤勉さ」の延長線上にはない。正直悔しいが、手段はまだある。
対立は静かに起こる
ある日、開発のメインチームが、コアになる機能をDDDで作り変えた。作り変えたというよりは併設した。クライアントが増えるごとにコピペコードが量産されることに業を煮やしたのだ。現場は忙しすぎて「動けばとりあえずPM裁量でリリースできる」状態になっていたため、上層部はコア機能が2重化したことを知らなかった（※PMはドメイン別にいる）
タバコ部屋で政治を動かしている上層部からすればこれはクーデターのようなもの。あちこちに「クライアントを識別するif」があるコードの書き方とガチDDDが混在した結果、コア機能は「旧機能チーム」と「新機能チーム」にサイロ化した。dbのテーブル数は2倍以上になった。
コア機能が2重化したことを知ったカスタマーサポートは悶絶してミーティングを増やした。さて、上層部、開発者、カスタマーサポート、それぞれにはそれぞれの思惑というか、正義がある。どの思惑も正解だし、収束できるような絶対の正解はない。
「チーム」は紆余曲折ごとに「サイロ」化して「強く」なる。良くも悪くもサビが蓄積するわけだ。このフェーズにおけるチームのコミュニケーションには高揚感すらある。
いい本「サイロ・エフェクト」
リファクタリング文化は「事故」をもって「発火」させる
「改善して保守の所要時間を短縮する」ための、リファクタリングのマインドセットをどのように醸成していくか。これは時にキレイゴトでは難しい。
―― リファクタリングを癖づけしてきれいなコードを保ち、これからのスケールアップに備えよう！
この手のお題目は、「（上層部からみると特に）ヒマなときにやること」に見える。「やっても機能が同じならそんなものはあとまわし」となったケースはごまんとある。戦禍においては、ヘルメットしてバールのようなものを握って「いいものを作ろう」と部署ごとの思惑がぶつかり合う。『いいものを作ろう』には含みがあって、「業務クオリティをいいものにしたいから余計な新しいことは増やさないでくれ」というブロッカー視点の言い回しにすることもできる。
いい本「シリコンバレーの交渉術」
逃げるのも戦略
DDDでコア機能を作り変えたプロパーエンジニアは、「事故」によって急激に昇進した。新機能まわりのすべてを知っているから、上層部としてはどうしても管理側に置かざるを得なくなったのだ。「戦禍」において昇進するのは、波風を立てない勤勉な人間ではなく「やらかす」ほうの人間だ。
が、彼は結局辞めてしまった。ポストを用意しても辞める人は辞める。そう、現場のマインドは結局変わらなかったのだ。「新しいことしやがってよぉぉぉ！」の空気が勝ってしまうと現場は最高にkaosになる。このころになると、スキルミスマッチで現場が追い出す人数よりもSI（開発者差し出し側）がキレて引き上げる人数のほうが多かったような印象。
現場のマインドが変わらないのなら「会社を変える」のは、エンジニアの戦略としては正しい。僕は彼の決断を応援した。
単価を上げろ
「リファクタリングしたいなら単価を上げろ。」
これは、一見繋がらない。
ただ、すでに述べたようにリファクタリングできるかどうかは現場のマインドセットや政治も関わってくる。「いつか誰かが」と思って大人しく仕事をしているだけではなにも変わらないこともすでに述べた。上層部に「一理ある」と思わせ、風向きを変えるにはどうしたらいいだろうか。
ここまで記事を読み進めた人には言ってもいいだろう。こんなことを考える時点でわたしもあなたも、仕事に対して十分「熱意」のある人間である。リファクタリングとは「機能が変わらないのに時間を用意して整理する」ことだ。一見効果はないのに時間をかけて「生産性を上げに行く」行為だ。空気が変わらないなら変えに行くしかない。
名乗りをあげよう（＝単価を上げよう）。そう、「俺には価値があるぞ、俺の話を聞け！」と名乗るのだ。もちろん名乗りを上げるには不断の努力が必要になる。仕事でいいものを作ろうと思えば自然と「仕事の鬼」になる。終電が多すぎて現場のために徒歩圏内に引っ越したし、よくわからん腹痛で朝方救急車に乗ったこともあったな。。
現場入りして1年が経った頃、単価を10万上げろと強く交渉した（結果的に8万上げた）。会社員の頃は単価交渉できるような人間ではなかった。いい社員を演じていたとは思うけど、いま振り返るとこれは結局自信のなさから来ていたように思う。単価交渉は「覚悟」である。
いい仕事をするというのは、きれいに言えば「一生懸命」取り組むことなんだけど、生々しく言えばそれは「忍耐」というか、自分のなかの「怒り」との戦いである。こうすればいいということがチームという単位でわかっているのに世界は変わらない（＝PMより上に話が通らない）し上層部はまったくリファクタリングのための時間を用意してくれないことに憤慨するわけだ。まるで補給のこない前線である。
なにかを前に押すとなにかが戻ってくる。振り子のように。単価交渉をすれば、「こいつ単価交渉してきてるけどなんの仕事してるの？？」と目をつけられる。リファクタリングしにいくための起爆点はこういう場所にある。そんなもんなのである。上層部にとって、「え？！」というアクションがこなければ「働いてくれる人」は便利な存在なだけだ。導火線をよじって作れ。チームで同じ思いをしている人を探してPMも巻き込め。観察者であれ、というのは仕事も、そして投資でも一緒だ。
あ、僕はめったに怒らないいい人ですよ！
クルマと一緒ですよ。スムーズに人を運ぶ、とてもいいものだけどエンジンの部分は人がさわれないぐらい熱いどころか爆発してるでしょ？
いい本「失敗の本質―日本軍の組織論的研究」
息を吸うように努力をする
不断の努力が必要という話をした。
なぜエンジニアになったのか、なぜフリーランスになったのか。つねに考える。努力は難しいものじゃない。Qiitaの記事を書いてもいいしなにをしてもいい。「おまえが持ってるスキルの根拠を見せろ」みたいなことを言われたときに、くちで説明するのとQiitaなどの記事を積み上げたページを見せるのとでは説得力が違う。なにもしないことは、エンジニアとしてかなりの悪手である（フリーランスになるならばなおさら）。こんなこと言ってるけど学生時代は努力苦手でしたー
いい言葉
「The only constant is change（地球上でたった1つの真実は変わり続けるということだけ）」
さいごに
今回は、大戦略としてのリファクタリングに関する工夫の話をした。
単価を上げれば現場を追い出されるリスクも高まるし、十中八九それが原因で僕も現場をやめることになったんだけど、IT全体からすれば人材の流動化が起こって別の現場の助けになることができる（実際、上げようとした単価額を上回る単価の現場にいるのがいまだから）。単価を上げることも正解だし、単価なんて上げずに平和を重視することも正解だし、世の中に正解はいくらでもある。ただ、逃げずに本気で手を動かしたやつにしか見えない景色ってやつはあるんだよ。
なにかの流れを変えようと思えば、すべては「覚悟」に帰結する。
追い出されたっていいじゃねーか。大事なのは現場を思って本気になれたかどうかだ。頑張ってんのは必ず誰かが見てる。仕事はいろんな思惑が混ざり合って、まるでモツ煮込みみたい。俺は仕事が大好きだ。エンジニアはいろんなスキルを身に着けようね 