品質改善の仕事が評価されないエンジニアへ｜リファクタリングを例に
手を入れるたびに壊れる箇所を整理した。テストを追加して、変更が怖くない状態にした。開発速度は明らかに上がっている。それでも評価面談では「今期はリリースした機能が少なかったね」と言われる。
リファクタリングは、機能が増えないのに時間を使う仕事です。評価制度が増加分を見る作りになっている以上、正面からぶつかります。ただし、語り方を変えると通ることがあります。私が評価する側で、通った提案と通らなかった提案の差を整理します。
- 改善が評価制度に乗らない理由
- 技術的負債を事業の言葉に翻訳する方法
- 改善の効果を示す数字
- 承認を得やすい提案の出し方
なぜ改善は評価されないのか
1. 機能が増えないから
評価シートの主要項目は、リリースした機能、達成した売上、完了した案件です。リファクタリングはどれにも当てはまりません。作業としては大きくても、記録に残る成果物がありません。
2. 効果が将来にしか出ないから
改善の効果は、次に手を入れるときに現れます。評価期間が半期なら、効果が出る前に期が終わります。改善した本人ではなく、次に触った人が「やりやすい」と感じます。
3. 悪化を防いだことが測られないから
「このまま放置していたら、半年後には改修に倍の時間がかかっていた」は、起きなかった未来なので証明できません。
この構造は、地味な貢献全般に共通します。詳しくは地味な貢献が評価されないエンジニアへ｜ドキュメント整備を例にに書きました。
技術的負債を事業の言葉に翻訳する
承認が通らない提案の多くは、技術の言葉で書かれています。決裁する人は技術が分からないので、判断できません。
翻訳の例を挙げます。
| 技術の言葉 | 事業の言葉 |
|---|---|
| クラスが密結合で変更しづらい | 1つの改修に毎回3日かかっている。分離すれば1日で済む |
| テストがなく修正が怖い | リリース後の不具合が月4件発生し、その対応に月20時間使っている |
| 古いライブラリを使っている | サポート切れが来年で、脆弱性が出ても修正できない |
| コードが重複している | 同じ修正を5か所に入れる必要があり、漏れが起きている |
「きれいにしたい」ではなく「今これだけ損をしている」と示すのが基本です。前者は好みの話に見えますが、後者はコストの話になります。
改善の効果を示す数字
改善前に測っておくと、後から説明できます。取りやすいものを挙げます。
- 該当箇所の改修にかかる平均時間（チケットの着手から完了まで）
- その箇所に起因する不具合の件数
- ビルド・テストの実行時間
- 同じ修正を入れる必要がある箇所の数
- 新メンバーがその箇所を理解するのにかかる時間
たとえば、「この機能の改修依頼は四半期で8件あり、1件あたり平均2.5日かかっていました。共通化とテスト追加の後は1件あたり0.8日になり、四半期で約13人日の削減です」と言えると、評価者はそのまま上位者に説明できます。
数字が取れない場合は、改修チケットの実績時間だけでも見てください。多くの会社で、すでにチケット管理ツールに記録があります。
承認を得やすい提案の出し方
1. 大きくやらない
「全面的にリファクタリングしたい」は、ほぼ通りません。リスクが読めないからです。「この1機能の改修と同時に、周辺を整理する」なら通ります。
2. 機能開発に混ぜる
改善を単独の案件にせず、関連する機能開発のスコープに含めます。見積もりに「周辺整理を含む」と入れておけば、別途承認を取る必要がありません。
3. 損失額を先に出す
提案の冒頭に「現状で四半期に13人日を失っています」と書きます。技術的な説明はその後です。順番を逆にすると読まれません。
4. 終わったら結果を報告する
改善後の数字を短く共有します。1回でも実績が出ると、次の提案が通りやすくなります。この積み重ねが、改善を評価対象にする最短ルートです。
それでも改善が一切認められない組織はあります。その場合、負債は増え続け、開発速度は落ち続けます。技術的負債への向き合い方は、その会社の開発組織としての成熟度を示す指標でもあります。 外の会社がどう扱っているかを知ると、比較材料になります。
IT転職エージェント＠PRO人
ITエンジニアの転職に特化したエージェント「PRO人」。専任のキャリアアドバイザーが、経歴やスキルを踏まえた具体的な求人・条件面を提示してくれます。
- IT・Web業界の転職支援に特化
- 経歴・スキルに合わせた求人を紹介
- 年収交渉や条件面のすり合わせも相談できる
- TechGoとは別の視点で市場価値を確認できる
よくある質問
Q. 勝手にリファクタリングするのは問題ですか A. 範囲によります。担当している機能の改修に伴う整理は、通常の開発判断の範囲です。他人の担当箇所や広範囲に及ぶ変更は、事前に合意を取ったほうが安全です。
Q. 効果の数字が取れない環境です A. チケットの実績時間と、不具合の件数から始めてください。どちらも既存のツールに記録があることが多いです。それも無い場合は、自分の作業時間を1か月記録するだけでも材料になります。
Q. 改善の経験は転職で評価されますか A. されます。特に「負債を事業の言葉で説明し、承認を得て、効果を数字で示した」という一連の経験は、シニア以上の要件と重なります。技術力だけでなく、組織を動かした経験として語れます。
まとめ
リファクタリングが評価されないのは、機能が増えず、効果が将来に出て、防いだ悪化が測れないためです。
- 評価シートは増加分を見る作りなので、改善は正面からぶつかる
- 「きれいにしたい」ではなく「今これだけ損をしている」と示す
- 改修にかかる時間と不具合件数は、既存のツールから取れる
- 単独の案件にせず、機能開発のスコープに混ぜると通りやすい
まずは、最近よく触る箇所の改修チケットを3件開いて、実績時間を合計してみてください。それが提案の最初の一行になります。