保守しにくい既存コード群を90日で改善するロードマップ｜現状評価から運用標準化まで

保守しにくい既存コード群は、開発チームの速度を下げるだけでなく、事業判断そのものを遅らせます。機能を追加するたびに別の画面が壊れる、障害調査に数日かかる、特定の担当者しか修正できない、影響範囲が読めないため小さな変更でもリリースが怖い、という状態が続く場合、コードは事業を支える資産ではなく、成長を妨げる制約になります。

ただし、保守しにくいコードを前にして、最初から全面的に書き直す判断は危険です。現行システムには、仕様書に残っていない業務ルール、過去の例外対応、外部連携の細かな条件、担当者だけが知っている運用手順が含まれている場合があります。これらを理解しないまま作り直すと、必要な処理を失い、移行期間が長期化し、現場業務に混乱が発生します。

本記事では、保守しにくい既存コード群を90日間で改善するための現実的なロードマップを解説します。現状評価、業務フロー整理、依存関係分析、ログと監視の整備、テスト追加、段階的な再構成、継続的統合、技術文書化、継続改善までを順番に進めることで、いきなり壊すのではなく、安全に変えられる状態を作ります。

1. 90日改善ロードマップの前提

90日間の改善では、短期間で全体を完璧に作り替えることを目標にしません。目的は、現行システムを理解し、危険な領域を見える化し、変更時の安全網を作り、保守しやすい状態へ少しずつ近づけることです。

1.1 いきなり書き直さない理由

保守しにくいコードを見ると、開発者は全面的に書き直したくなります。命名が乱れている、処理が長い、責任範囲が曖昧、同じ処理が複数箇所にある、テストがない、ログが足りないという状態では、既存コードを直すより新しく作った方が速く見えるためです。しかし、業務システムの価値はコードのきれいさだけで決まりません。長年の運用で蓄積した業務ルール、取引先ごとの例外処理、締め処理、権限判断、外部連携条件が、読みにくいコードの中に埋まっている場合があります。

いきなり書き直すと、これらの業務知識を失う危険があります。画面上は同じように見えても、請求金額の端数処理、在庫引当の優先順位、顧客区分ごとの割引条件、月末処理の例外が再現されていなければ、現場業務は止まります。最初に必要なのは、古いコードを否定することではなく、現在の挙動と業務上の意味を把握することです。

1.2 改善対象を絞る理由

90日間で既存コード群全体を完全に整理することは現実的ではありません。対象範囲を広げすぎると、調査、テスト、修正、確認、文書化のすべてが中途半端になります。結果として、見た目だけ整ったが保守性は改善されていない、重要領域にテストがない、障害対応手順が残っていないという状態になりやすくなります。

改善対象は、業務影響、障害頻度、改修頻度、担当者依存、調査時間を基準に絞ります。請求、在庫、顧客情報、権限、外部連携、定期処理のように障害時の影響が大きい領域を優先します。小さく対象を絞ることで、調査から安定化、再構成、文書化までを一通り完了でき、次の改善領域へ展開しやすくなります。

1.3 業務影響を先に確認する理由

コードの複雑さだけを見て改善優先度を決めると、事業上の重要度を見落とします。技術的には読みにくい処理でも、利用頻度が低く、障害時の影響が小さい場合は、すぐに直す必要がない場合があります。一方で、短い処理でも請求金額、在庫数、権限判定、外部連携に関わる場合は、優先して確認するべきです。

業務影響を先に確認することで、改善の目的が明確になります。開発者の負担を下げるための改善なのか、障害リスクを下げるための改善なのか、リリース速度を上げるための改善なのかを分けて判断できます。90日間の改善では、技術的な美しさよりも、業務を止めずに変更しやすくすることを重視します。

2. 第1段階：現状評価

1日目から15日目までは、現行システムの全体像を把握する段階です。この期間では、大きなコード変更を行いません。システムと機能単位の棚卸し、技術的負債の特定、建築構造の分析、高リスク領域の整理を行い、以降の改善に必要な判断材料を作ります。

2.1 システムと機能単位を棚卸しする

最初に行うべき作業は、システム全体の棚卸しです。画面、管理機能、定期処理、外部連携、認証、権限管理、帳票出力、通知処理、データ更新処理を一覧化します。保守しにくい既存コード群では、現在も使われている機能、過去に使われていたが残っている機能、利用状況が不明な機能が混在しています。これらを区別しないまま改善を始めると、不要な機能に時間を使い、重要機能の改善が遅れます。

棚卸しでは、コードの行数ではなく、業務上の役割を記録します。各機能について、利用部署、利用頻度、関連データ、外部連携、障害発生時の影響、担当者を整理します。たとえば、行数が少ない処理でも、請求確定や在庫更新に関わる場合は高い優先度で扱う必要があります。棚卸しの成果物は、後の依存関係分析、テスト追加、再構成計画の基礎になります。

2.2 技術的負債を特定する

技術的負債とは、短期的な修正や場当たり的な設計を積み重ねた結果、後から変更や保守が難しくなった状態です。重複した処理、長すぎる関数、複雑な条件分岐、命名規則の不統一、責任範囲が曖昧なクラス、不要な設定、古いライブラリへの依存は、技術的負債の代表例です。90日間の改善では、すべての負債を一度に解消するのではなく、業務影響と改修頻度が高い負債から優先します。

技術的負債を特定する際には、開発者の感覚だけに頼りません。変更履歴、障害履歴、修正にかかった時間、担当者の偏りを確認します。頻繁に修正されているのに毎回調査時間が長い領域、障害が繰り返し発生する領域、特定担当者しか触れない領域は、優先度が高い負債です。技術的負債を記録するときは、場所、症状、業務影響、解消方針、後回しにする理由を明確にします。

この表を使うと、技術的負債を感覚ではなく管理対象として扱えます。

2.3 現在の建築構造を分析する

現行システムの建築構造を把握することも重要です。画面、業務処理、データ操作、外部連携、認証、定期処理がどのように分かれているかを確認します。保守しにくい既存コード群では、画面側に業務ロジックが混在していたり、データ操作が複数箇所に散らばっていたり、外部連携の失敗処理が統一されていなかったりする場合があります。

建築構造の分析では、理想的な設計図をいきなり作る必要はありません。まずは現状の依存関係を図にし、どの機能がどの機能に影響しているかを可視化します。変更頻度が高いのに依存先が多い領域、障害時に影響範囲が広がりやすい領域、テストしにくい領域を見つけることが目的です。この分析結果は、後半の段階的な再構成で重要な判断材料になります。

2.4 高リスク領域を特定する

第1段階の最後に、高リスク領域を特定します。高リスク領域とは、障害が起きると売上、請求、在庫、顧客対応、法令対応、社内運用に大きな影響を与える部分です。たとえば、決済処理、請求金額計算、在庫引当、権限管理、顧客情報更新、外部サービス連携は、優先的に確認するべき領域です。

高リスク領域を特定するときは、技術的な複雑さだけで判断しません。業務部門への影響、利用頻度、過去の障害件数、修正時の影響範囲、担当者依存の強さを合わせて評価します。この段階で高リスク領域を明確にしておけば、テスト追加、ログ追加、監視設計、再構成の優先順位を一貫して決められます。

3. 第2段階：システムの挙動を理解する

16日目から30日目までは、コードの静的な構造だけでなく、実際の業務でシステムがどのように動いているかを理解します。業務フロー、機能間の依存関係、データベース、外部連携、性能上の詰まりを整理します。

3.1 業務フローを対応付ける

保守しにくい既存コード群を改善するには、コードの構造だけでなく、業務フローとの対応を理解する必要があります。受注登録、承認、在庫確認、出荷指示、請求、入金確認、顧客通知といった業務の流れを整理し、それぞれの処理がどの画面、どの関数、どのデータベース更新に対応しているかを確認します。

この対応付けができると、修正時の影響範囲を判断しやすくなります。たとえば、一つの入力項目を変更する場合でも、帳票、外部連携、集計処理、権限チェックに影響する可能性があります。業務フローとコードを対応付けることで、開発者だけでなく、業務部門も変更内容を理解しやすくなります。

3.2 機能単位の依存関係を特定する

次に、機能単位の依存関係を整理します。利用者管理、商品管理、受注管理、請求管理、通知処理、帳票出力、外部連携が互いにどのように依存しているかを把握します。依存関係が明確でない状態では、一つの機能を修正しただけで別の機能に障害が出る危険があります。

依存関係の整理では、呼び出し関係、共有データ、設定ファイル、共通関数、外部サービス、定期処理を確認します。特に、共通関数に多くの業務ルールが集まっている場合、影響範囲が広くなりやすいため注意が必要です。依存関係を図で表すと、再構成する順番とテストで重点確認する領域が見えてきます。

3.3 データベースと外部連携を分析する

保守しにくいシステムでは、データベース構造が複雑化していることがあります。使われていない列、意味が分かりにくいコード値、重複したマスターデータ、履歴データの肥大化、更新元が複数あるテーブルは、障害や集計不一致の原因になります。データベース分析では、主要テーブル、参照関係、更新頻度、データ量、業務上の重要度を整理します。

外部連携の分析も同時に進めます。連携先、送受信データ、認証方式、失敗時の再送処理、連携頻度、障害時の通知方法を確認します。外部連携は、現行システムの外側に影響が広がる領域です。ここを理解しないまま再構成すると、社内外の業務が止まる可能性があります。

3.4 現在の詰まりを記録する

第2段階の最後では、現在発生している詰まりを記録します。詰まりには、画面表示が遅い、検索に時間がかかる、集計処理が長い、定期処理が業務時間に食い込む、外部連携で失敗が多い、障害調査にログが足りない、といった問題があります。これらは感覚ではなく、発生条件と影響範囲を記録する必要があります。

詰まりを記録する際には、利用者の不満だけでなく、処理時間、発生時刻、対象機能、関連データ量、再現条件を確認します。後の段階で監視や技術ダッシュボードを導入するためには、現在の状態を測定できる形にしておく必要があります。詰まりを数値で記録できれば、改善後の効果も説明しやすくなります。

4. 第3段階：観測できる状態にする

31日目から45日目までは、システムを観測できる状態にします。保守しにくい既存コード群では、障害が起きても原因を追えない、処理時間を測れない、利用状況を確認できない状態がよくあります。大きな変更を入れる前に、ログ、監視、技術ダッシュボード、基準値を整えます。

4.1 必要なログを追加する

最初に追加すべきものは、原因調査に必要なログです。重要な業務処理の開始と終了、処理時間、入力値の識別情報、外部連携の結果、エラー内容、利用者操作、権限判定の結果を記録します。ただし、個人情報や機密情報をそのままログに出してはいけません。ログは、障害調査に必要な情報と情報保護の両方を考えて設計します。

ログ追加では、量を増やせば良いわけではありません。読めないログ、検索できないログ、形式が統一されていないログは、障害対応の役に立ちません。ログの形式、重要度、保存期間、検索方法、通知条件を決めます。高リスク領域から優先的にログを追加することで、短期間でも障害調査力を高められます。

4.2 監視項目を決める

監視では、システムが正常に動いているかを継続的に確認します。サーバー負荷、メモリ使用量、データベース接続数、処理時間、エラー件数、外部連携失敗数、定期処理の完了状況、バックアップ結果を監視対象にします。監視がなければ、障害が現場からの連絡で初めて分かり、対応が遅れます。

監視設計では、通知先と対応手順も決める必要があります。エラーが発生したときに、誰が通知を受け、どの手順で影響範囲を確認し、どの条件で緊急対応に切り替えるかを明確にします。監視は技術者向けの仕組みではなく、業務停止を防ぐための運用基盤です。

4.3 技術ダッシュボードを作る

技術ダッシュボードは、システムの状態を継続的に把握するための画面です。処理時間、エラー数、障害件数、外部連携の成功率、リリース回数、テスト結果、復旧時間、未解決バグ数を一目で確認できるようにします。チーム全体が同じ数字を見られる状態にすると、感覚ではなく事実に基づいて優先順位を決められます。

技術ダッシュボードは、経営層や業務部門への説明にも役立ちます。たとえば、障害対応時間が短くなった、未解決バグが減った、処理時間が改善した、外部連携失敗率が下がった、といった成果を数値で共有できます。保守改善は目に見えにくい取り組みですが、ダッシュボードがあれば改善効果を説明しやすくなります。

4.4 基準となる品質指標を定義する

改善の効果を判断するためには、基準となる品質指標が必要です。現在のバグ発生率、平均復旧時間、リリース頻度、テスト網羅率、処理時間、外部連携失敗率を記録します。基準値がないまま再構成を進めると、改善したのか、悪化したのかを判断できません。

品質指標は、プロジェクトの目的とつながっている必要があります。事業上の問題が障害復旧の遅さであれば、平均復旧時間を重視します。新機能開発の遅さが問題であれば、リリース頻度と変更リードタイムを重視します。品質指標は多く設定しすぎず、90日間で改善効果を確認できる項目に絞ることが重要です。

5. 第4段階：変更前に安定化する

46日目から60日目までは、大きな再構成に入る前にシステムを安定化します。高リスク領域にテストを追加し、未解決バグを減らし、深刻な建築上の問題を修正し、機能間の結合を弱めます。この段階を飛ばすと、再構成中に既存障害と新規障害が混ざり、原因調査が難しくなります。

5.1 高リスク領域にテストを追加する

最初にテストを追加するべき領域は、高リスク領域です。請求金額計算、在庫更新、権限判定、外部連携、顧客情報更新、定期処理は、障害時の影響が大きいため優先します。既存コードにテストが少ない場合、全体のテスト網羅率を急に上げるより、障害影響が大きい処理に絞ってテストを追加する方が現実的です。

テスト追加では、正常系だけでなく、異常系、境界値、権限違反、外部連携失敗、データ欠損も確認します。既存コードがテストしにくい場合は、テストしやすい小さな単位へ処理を切り出す準備を行います。テストは再構成の安全網です。安全網がないまま大きな変更を進めると、品質低下を防げません。

5.2 未解決バグを減らす

再構成に入る前に、未解決バグを整理します。すべてを修正する必要はありませんが、業務影響が大きいバグ、再発しているバグ、原因が分かっているのに放置されているバグは優先的に処理します。未解決バグが多い状態で再構成を始めると、新しい変更が原因なのか、以前から存在していた問題なのか判断しにくくなります。

未解決バグを減らす際には、修正、保留、仕様確認、再現不可、重複の分類を明確にします。分類されていないバグ一覧は、チームの判断を遅らせます。優先度を決める基準は、発生頻度、業務影響、復旧難易度、顧客影響です。バグ管理を整理するだけでも、保守チームの負担は大きく下がります。

5.3 深刻な建築上の問題を修正する

既存コード群には、後の再構成を妨げる深刻な建築上の問題が含まれている場合があります。たとえば、画面処理に大量の業務ロジックが含まれている、共通処理が肥大化している、外部連携の失敗処理が統一されていない、データ更新処理が複数箇所に散らばっている、といった状態です。これらは後半の再構成前に最低限整理する必要があります。

ただし、この段階で完璧な設計へ作り替える必要はありません。目的は、大きな変更に耐えられる状態を作ることです。高リスク領域に影響する最小限の構造改善を行い、変更後は必ずテストとログで確認します。深刻な建築上の問題を放置したまま再構成を始めると、改善作業そのものが障害原因になります。

5.4 機能間の結合を弱める

保守しにくいコードでは、機能間の結合が強くなりがちです。一つの機能を変更すると、関係ない画面、定期処理、外部連携に影響する状態では、開発速度が上がりません。第4段階では、結合が強い箇所を特定し、共通処理の分離、入出力の明確化、設定値の整理を行います。

結合を弱める際には、いきなり大きく分割するのではなく、影響範囲が分かる小さな変更から始めます。たとえば、業務ルールを画面から分離する、外部連携処理を専用の処理へ集約する、共通関数の責任範囲を分ける、といった改善が有効です。結合を弱めることで、後半の段階的な再構成を安全に進められます。

6. 第5段階：制御された再構成を行う

61日目から75日目までは、実際にコードの再構成を進めます。重要なのは、全体を一気に変えないことです。小さな機能単位で変更し、テストと監視で安全を確認しながら進めます。再構成の目的は、見た目を整えることではなく、変更しやすく、理解しやすく、障害を追いやすい構造へ近づけることです。

6.1 小さな機能単位で再構成する

再構成は、小さな機能単位で進めます。受注検索、請求計算、顧客情報更新、通知処理、外部連携の再送処理のように、影響範囲を限定できる単位を選びます。全体を一気に再構成すると、障害発生時に原因を特定できず、テスト範囲も広がりすぎます。

小さな単位で再構成する際には、変更前の挙動を記録し、変更後に同じ結果が出ることを確認します。業務仕様を変える再構成と、内部構造だけを変える再構成を分けて管理します。内部構造だけを変える場合は、利用者の操作、出力結果、外部連携結果を変えないことが原則です。

6.2 業務ロジックを画面から分離する

保守しにくいシステムでは、画面処理の中に業務ロジックが混在していることがあります。画面表示、入力検証、金額計算、在庫更新、権限判定、外部連携が一つの処理に集まっていると、修正時の影響範囲が広がります。業務ロジックを画面から分離することで、テストしやすく、再利用しやすく、変更しやすい構造になります。

分離する際には、画面側は入力と表示に集中させ、業務ルールは専用の処理へ移します。たとえば、請求金額計算、割引判定、承認条件、在庫引当ルールは、画面から独立した形にします。これにより、別の画面や定期処理から同じ業務ルールを使えるようになり、重複処理と修正漏れを減らせます。

6.3 命名と構成を標準化する

命名とフォルダ構成が統一されていないコードは、新任者にとって理解しにくくなります。変数名、関数名、ファイル名、フォルダ名、設定名がばらばらだと、同じ意味の処理を探すだけで時間がかかります。第5段階では、命名規則と構成ルールを定義し、変更対象の機能から順に標準化します。

標準化では、既存コード全体を一度に変更しない方が安全です。現在再構成している機能、修正頻度が高い機能、新規追加する機能から適用します。命名と構成を整えることで、コード確認の基準が明確になり、技術文書も書きやすくなります。小さな標準化の積み重ねが、長期的な保守性を支えます。

6.4 不要なコードを削除する

不要なコードは、保守性を下げます。使われていない関数、過去の仕様のために残った条件分岐、呼び出されていない画面、古い定期処理、未使用の設定が残っていると、調査時に判断を迷わせます。不要なコードを削除することで、理解するべき範囲が狭くなり、障害調査も速くなります。

削除する前には、利用状況、呼び出し関係、運用担当者の確認、ログによる実績確認を行います。特に古いシステムでは、年次処理や特定の締め処理だけで使われるコードが残っている場合があります。削除判断を急ぐと、後から必要な処理を失う危険があります。削除対象、確認結果、削除日、戻し方を記録し、安全に整理します。

7. 第6段階：運用標準化へ移す

76日目から90日目までは、改善した状態を継続できる仕組みを整えます。継続的統合、継続的デリバリー、コード確認チェックリスト、技術文書、継続改善計画を整備し、90日後に元の状態へ戻らないようにします。

7.1 継続的統合を整える

継続的統合は、コード変更を安全に取り込み、テストと確認を自動化するための仕組みです。保守しにくい既存コード群では、手作業の反映、環境差分、手順漏れが障害原因になることがあります。自動テスト、静的解析、構文確認、依存関係確認を整えることで、変更時の基本的な事故を減らせます。

最初から高度な仕組みを目指す必要はありません。最低限、コード変更時にテストが実行されること、構文エラーや依存関係の問題を検知できること、確認結果が記録されることを整えます。継続的統合を導入すると、再構成後の品質を維持しやすくなります。

7.2 継続的デリバリーを段階導入する

継続的デリバリーは、確認済みの変更を安全に利用環境へ反映するための考え方です。保守しにくいコードでは、反映作業が担当者依存になりやすく、手順漏れ、設定漏れ、反映漏れが発生します。反映手順を標準化し、自動化できる部分から整えることで、リリース時の事故を減らせます。

ただし、基幹業務システムでは、すべてを自動で即時反映する必要はありません。承認、業務部門への通知、停止時間の確認、切り戻し手順を含めて、安全な反映プロセスを作ることが重要です。自動化の目的は速さだけではなく、手順の再現性と安全性を高めることです。

7.3 コード確認チェックリストを作る

コード確認チェックリストは、品質をチームで揃えるための仕組みです。処理の責任範囲、命名規則、テスト有無、ログ出力、権限確認、例外処理、性能影響、外部連携への影響、データベース変更の有無を確認項目に含めます。人によって確認観点が変わる状態では、品質が安定しません。

チェックリストは、細かすぎると運用されなくなります。高リスク領域、データ更新、外部連携、権限管理、定期処理に関わる変更では重点確認し、軽微な表示修正では簡略化する、といった運用が現実的です。コード確認は指摘の場ではなく、障害を事前に防ぐための共同作業として位置づけます。

7.4 技術文書を更新し続ける

技術文書は、90日間の改善を長期運用へつなげるために必要です。システム構成、主要機能、データベース構造、外部連携、監視項目、ログ仕様、反映手順、障害対応手順、再構成済み領域、今後の課題を整理します。文書がなければ、改善した内容が担当者の頭の中に残り、再び属人化します。

技術文書は、完璧な分量よりも更新され続けることが重要です。古くなった文書は、存在しない文書より危険な場合があります。責任者、更新タイミング、変更時の確認方法を決めます。新任者が最初に読む文書、障害時に見る文書、設計判断を確認する文書を分けると、運用しやすくなります。

8. 90日ロードマップの全体表

90日間の改善は、調査、理解、観測、安定化、再構成、標準化の順番で進めると管理しやすくなります。各段階の目的、主な作業、成果物を明確にすると、チーム内で進捗を共有しやすく、経営層や業務部門にも説明しやすくなります。

この一覧表を使うと、90日間の取り組みを単なる修正作業ではなく、保守性を継続的に高める改善プロジェクトとして管理できます。

9. 90日間で見るべき品質指標

90日間の改善では、感覚ではなく数値で状態を確認する必要があります。バグ発生率、リリース頻度、平均復旧時間、テスト網羅率を追うことで、改善が開発速度、品質、運用安定性にどう影響しているかを判断できます。

9.1 バグ発生率

バグ発生率は、一定期間内に発生した不具合の数を示します。新しい変更によってバグが増えているのか、既存障害が減っているのかを確認するために使います。ただし、バグ数だけを見ると判断を誤る場合があります。重要なのは、件数だけでなく、重大度、発生領域、再発率、修正にかかった時間を合わせて見ることです。

90日間の前半では、ログや監視を整えたことで隠れていたバグが見えるようになり、一時的に件数が増える場合があります。これは必ずしも悪化ではありません。中盤以降は、高リスク領域のテスト追加と安定化によって、重大バグと再発バグが減っているかを確認します。

9.2 リリース頻度

リリース頻度は、変更を本番または利用環境へ反映する頻度です。保守しにくいコードでは、リリース準備に時間がかかり、変更をまとめて大きく出す運用になりやすくなります。この状態では、障害発生時に原因を特定しにくく、利用者への影響も大きくなります。

90日間の改善では、リリース頻度を高めることそのものが目的ではありません。目的は、小さく安全に変更できる状態を作ることです。テスト、コード確認、反映手順、監視が整うと、小さな変更を短い間隔で出しやすくなります。リリース頻度は、チームの変更能力を示す重要な指標です。

9.3 平均復旧時間

平均復旧時間は、障害発生から復旧までにかかった平均時間です。保守しにくい既存コード群では、障害そのものよりも原因調査に時間がかかることが多くあります。ログが足りない、依存関係が不明、担当者が限られている状態では、復旧までの時間が長くなります。

平均復旧時間を短くするには、ログ、監視、手順書、責任分担が必要です。90日間の改善では、重大障害の復旧時間が短くなっているか、原因調査の時間が減っているかを確認します。平均復旧時間は、運用品質を判断するうえで非常に重要です。

9.4 テスト網羅率

テスト網羅率は、コードや機能のうち、テストで確認されている範囲を示します。ただし、数値だけを追うと、重要度の低い部分のテストを増やして見かけの数値を上げるだけになる危険があります。保守改善で重視すべきなのは、高リスク領域がテストされているかです。

90日間では、全体のテスト網羅率を急に高めるより、請求、在庫、権限、外部連携、定期処理のような障害影響が大きい領域にテストを追加します。テスト網羅率は、数値と対象領域をセットで見る必要があります。重要機能にテストがある状態を作ることで、再構成の安全性が高まります。

10. チーム体制と責任範囲

保守しにくい既存コード群を改善するには、技術作業だけでなく、責任範囲の整理が必要です。誰が判断し、誰が確認し、誰が業務部門と調整し、誰が文書を更新するのかが曖昧なままでは、改善活動が一時的な作業で終わります。

10.1 改善責任者を決める

90日間の改善には、全体を見て優先順位を決める改善責任者が必要です。改善責任者は、すべてのコードを直接修正する人ではありません。技術的負債の優先順位、業務影響の確認、リスク領域の選定、進捗管理、関係者への説明を担う役割です。

改善責任者がいない場合、各開発者が自分の見える範囲だけを改善し、全体としての成果が見えにくくなります。責任者を決めることで、90日間の目的、対象範囲、成果物、次の改善計画が明確になります。改善活動を継続するためには、個人の善意ではなく、役割として管理する必要があります。

10.2 機能ごとの担当者を明確にする

保守しにくいコードでは、機能ごとの担当者が曖昧になっていることがあります。障害が発生しても誰に確認すればよいか分からない、変更時に誰の承認が必要か分からない、過去の仕様を誰も説明できない状態では、改善が進みません。機能ごとの担当者を明確にすることで、調査と判断の速度が上がります。

担当者を決める際には、主担当と確認者を分けると効果的です。主担当は日常的な理解と修正を担い、確認者は設計判断やリスク判断を補います。一人に知識を集中させるのではなく、最低二人が重要領域を理解できる状態を目指すことで、属人化リスクを減らせます。

10.3 業務部門との確認ルートを作る

既存コード群の改善では、技術者だけでは判断できない場面が多くあります。処理が複雑に見えても、業務上必要な例外処理である場合があります。逆に、長年残っている処理でも、現在は使われていない場合があります。これを判断するには、業務部門との確認ルートが必要です。

確認ルートでは、誰に、どの内容を、どの形式で確認するかを決めます。たとえば、請求処理は経理担当、在庫処理は物流担当、権限管理は管理部門、顧客情報は営業責任者に確認する形です。業務部門を巻き込むことで、コード改善が現場業務とずれる危険を減らせます。

11. 小規模チームで進める場合の考え方

小規模チームでも、90日間の改善ロードマップは適用できます。ただし、大規模チームと同じ範囲を扱うと負荷が高くなります。対象領域を絞り、通常開発と改善を分けすぎず、毎週の改善単位を小さくすることが重要です。

11.1 対象領域を絞る

小規模チームでは、最初からシステム全体を改善対象にしない方が現実的です。高リスク領域を一つ選び、棚卸し、業務フロー確認、ログ追加、テスト追加、小さな再構成、文書化までを一通り行います。小さな成功を作ることで、次の領域へ展開しやすくなります。

対象領域を絞ると、改善効果も測定しやすくなります。たとえば、請求処理だけを対象にすれば、障害件数、調査時間、テスト網羅、処理時間の変化を追いやすくなります。小規模チームでは、広く浅く改善するより、狭く深く改善して型を作る方が効果的です。

11.2 通常開発と改善を分けすぎない

小規模チームでは、通常開発と改善活動を完全に分けると時間が足りません。新機能開発、バグ修正、問い合わせ対応の中に、小さな改善を組み込む方が継続しやすくなります。たとえば、修正する機能にログを追加する、関連するテストを一つ増やす、命名をそろえる、短い説明文を文書に残す、といった改善です。

この方法では、改善活動が特別なプロジェクトではなく、日常開発の一部になります。大きな再構成を一度に行うのではなく、触った領域を少しずつ改善することで、長期的に保守性を高められます。小規模チームほど、無理のない改善習慣が重要です。

11.3 毎週の改善単位を小さくする

小規模チームでは、毎週の改善単位を小さく設定します。一週間で完了できる単位にしないと、改善タスクが積み残され、通常業務に押し流されます。たとえば、重要処理にログを追加する、外部連携失敗時の通知を整える、請求計算のテストを追加する、未使用設定を確認して削除する、といった単位です。

小さな改善でも、記録を残せば成果になります。改善前の問題、変更内容、確認結果、残った課題を短く記録します。これを毎週続けることで、90日後には改善履歴が蓄積され、次の計画を立てやすくなります。小規模チームでは、継続できる粒度で進めることが成功の条件です。

12. よくある失敗

保守しにくい既存コード群の改善では、急ぎすぎること、測定しないこと、早すぎる全面書き直し、文書と責任者の不足が失敗につながります。90日間の改善では、現行システムを理解しながら安全に進める姿勢が重要です。

12.1 全体を一気に再構成する

最も危険な失敗は、既存コード群を一気に再構成することです。全体をまとめて変更すると、障害が発生したときに原因を特定できません。利用者から見ると、どの変更がどの不具合につながったのか分からず、現場の信頼も失われます。

再構成は、小さな機能単位で進めるべきです。変更前の挙動を記録し、変更後に同じ結果が出ることを確認し、監視とログで影響を追います。大きな改善を小さな変更に分解できるかどうかが、保守改善の成功率を左右します。

12.2 変更前に測定しない

変更前の状態を測定しないまま改善を進めると、効果を判断できません。処理速度が改善したのか、障害対応時間が短くなったのか、バグが減ったのかを説明できなければ、改善活動の価値が社内に伝わりません。感覚だけで「良くなった」と説明しても、次の投資判断につながりにくくなります。

改善前には、処理時間、バグ件数、復旧時間、リリース頻度、テスト網羅率、外部連携失敗率を記録します。すべてを完璧に測る必要はありませんが、プロジェクト目的に関係する指標は必ず残します。測定は、改善の正しさを確認するための土台です。

12.3 早すぎる全面書き直し

保守しにくい既存コードを見ると、全面的に書き直したくなる場合があります。しかし、業務ルール、例外処理、外部連携、過去データの意味を理解しないまま書き直すと、現行システムで支えていた重要な処理を失う危険があります。全面書き直しは、技術的には魅力的に見えても、業務リスクが高い判断です。

全面書き直しを検討する前に、現行システムの棚卸し、業務フロー対応付け、データ構造分析、高リスク領域の特定を行うべきです。再構成、部分移行、機能単位の置き換えで対応できる領域が多い場合、全面書き直しは後回しにできます。判断基準は、開発者の疲労感ではなく、事業影響と移行リスクです。

12.4 文書と責任者が不足している

文書と責任者が不足している状態では、改善後も保守性は安定しません。設計判断の理由、変更した領域、残した技術的負債、監視項目、障害対応手順が記録されていなければ、数か月後に同じ調査を繰り返すことになります。また、責任者が明確でない機能は、障害時の対応が遅れます。

90日間の改善では、技術文書と機能責任者をセットで整理します。機能ごとに、主担当、確認者、関連文書、重要な業務ルールを記録します。文書と責任者を整えることで、改善活動が一時的な取り組みではなく、長期運用の仕組みになります。

13. 90日後に続けるべき改善

90日後には、改善活動を終えるのではなく、次の改善サイクルへ移します。残った技術的負債を分類し、次の四半期計画へつなげ、改善を開発文化に組み込むことが重要です。

13.1 残った技術的負債を分類する

90日間ですべての技術的負債を解消することは現実的ではありません。最後に、残った負債を分類します。業務影響が大きい負債、開発速度を下げている負債、担当者依存が強い負債、将来の拡張を妨げる負債、当面は許容できる負債に分けます。

分類することで、次に何を優先するべきかが明確になります。すべての負債を同じ重さで扱うと、重要な改善に集中できません。負債の内容、影響、解消工数、対応期限を記録し、次の改善計画へ引き継ぎます。

13.2 次の四半期計画へつなげる

90日後の改善結果は、次の四半期計画へつなげます。改善できた領域、未対応の領域、数値が改善した指標、悪化した指標、追加で必要なテスト、分離したい機能を整理します。この振り返りを行わないと、改善活動が単発で終わります。

次の四半期では、対象領域を広げるか、改善済み領域をさらに安定化するかを判断します。たとえば、請求処理を改善した後に在庫処理へ進む、外部連携の監視を強化する、権限管理のテストを増やす、といった計画です。90日間の成果を使って、次の改善を現実的に設計します。

13.3 改善を開発文化に組み込む

保守性の改善は、一度実施して終わる作業ではありません。新機能を追加し続ければ、新しい技術的負債も発生します。重要なのは、改善を特別な活動ではなく、日常の開発文化に組み込むことです。コード確認、テスト追加、ログ設計、文書更新、依存関係の確認を、通常開発の一部として扱います。

改善を文化にするには、成果を見える化することも重要です。平均復旧時間が短くなった、障害件数が減った、リリース頻度が安定した、新任者の引き継ぎ時間が短くなった、といった成果を共有します。成果が見えると、保守改善は後回しの作業ではなく、事業を支える投資として認識されやすくなります。

14. よくある質問

14.1 既存コード群を全面的に書き直すべきか

全面的な書き直しは、最後の選択肢として考えるべきです。現行システムの業務ルール、データ構造、外部連携、例外処理を理解しないまま書き直すと、現場業務に必要な処理を失う危険があります。特に、請求、在庫、顧客管理、権限管理、会計連携に関わるシステムでは、書き直しによる移行リスクが高くなります。

まずは、現行調査、業務フロー整理、技術的負債の分類、高リスク領域のテスト追加を行います。そのうえで、部分再構成で対応できるのか、機能単位で置き換えるべきか、全面書き直しが必要かを判断します。全面書き直しは、十分な調査と移行計画が整ってから検討するべきです。

14.2 いつ再構成を優先するべきか

既存機能が事業上まだ有効で、処理内容を理解でき、テスト追加によって安全に変更できる場合は、再構成を優先します。再構成は、利用者に見える動作を変えずに内部構造を改善できるため、業務影響を抑えやすい方法です。

一方で、現行技術が保守不能に近い、処理が業務要件と大きくずれている、外部連携やセキュリティ要件を満たせない、部分改善では費用対効果が低い場合は、機能単位の置き換えや書き直しを検討します。判断は、技術者の感覚ではなく、保守費、障害リスク、移行リスク、事業影響で行います。

14.3 テスト網羅率はどの程度あれば十分か

一律の数値だけで十分かどうかは判断できません。重要なのは、障害影響が大きい領域がテストされているかです。請求金額計算、在庫更新、権限判定、外部連携、顧客情報更新、定期処理は、優先的にテストを追加するべき領域です。

90日間の改善では、全体のテスト網羅率を急に高めるより、高リスク領域のテストを厚くする方が効果的です。最初の目標としては、重要機能の正常系、異常系、境界値、権限違反、外部連携失敗を確認できる状態を目指します。数値は結果として追い、対象領域の妥当性を重視します。

14.4 技術的負債は新機能より先に処理するべきか

技術的負債と新機能は、対立するものとして扱わない方が現実的です。すべての技術的負債を先に処理すると、新機能開発が止まります。一方で、技術的負債を放置したまま新機能を追加し続けると、開発速度と品質がさらに下がります。

優先すべき技術的負債は、新機能開発の障害になっている負債、障害を繰り返している負債、担当者依存が強い負債、セキュリティやデータ整合性に関わる負債です。新機能開発の中に小さな再構成を組み込み、変更する領域の保守性を少しずつ改善する運用が有効です。

14.5 最も重要な品質指標はどれか

最も重要な品質指標は、チームの課題によって変わります。障害対応が遅い場合は平均復旧時間、品質低下が問題ならバグ発生率と再発率、リリースが遅い場合はリリース頻度、変更が怖い場合は高リスク領域のテスト網羅率を重視します。

90日間の改善では、すべての指標を同じ重みで追う必要はありません。事業上の問題に直結する指標を三つ程度に絞り、毎週確認します。数値が改善しているかだけでなく、改善の理由と悪化の原因を記録することが重要です。

14.6 継続的統合は最初から必要か

最初から高度な仕組みを作る必要はありません。ただし、早い段階で最低限の自動確認は整えるべきです。コード変更時にテストを実行する、構文エラーを検知する、依存関係の問題を確認する、反映手順を標準化するだけでも、障害リスクを下げられます。

90日間の前半では、現行分析と観測を優先します。中盤以降、高リスク領域のテストが増えた段階で、自動実行の仕組みを整えると効果が出やすくなります。目的は仕組みを導入することではなく、変更を安全に確認できる状態を作ることです。

14.7 小規模チームでも適用できるか

小規模チームでも適用できます。ただし、大規模な改善計画をそのまま実行するのではなく、対象範囲を絞る必要があります。最初は高リスク領域を一つ選び、棚卸し、ログ追加、テスト追加、小さな再構成、文書化までを一通り行う方法が現実的です。

小規模チームでは、改善作業と通常開発を分けすぎると時間が足りなくなります。新機能開発やバグ修正のタイミングで、関連する技術的負債を小さく改善する運用が有効です。重要なのは、90日間で全体を変えることではなく、継続的に改善できる型を作ることです。

14.8 90日後に何をするべきか

90日後には、改善結果を振り返り、次の改善計画を作ります。バグ発生率、平均復旧時間、リリース頻度、テスト網羅率、未解決の技術的負債、残った高リスク領域を確認します。改善できた領域と、まだ手を付けられていない領域を分けて整理します。

次の90日では、対象領域を広げるか、既に改善した領域をさらに安定化するかを判断します。継続改善計画には、事業優先度、障害リスク、保守工数、担当者依存を反映します。90日間の取り組みを一度きりで終わらせず、開発運用の標準プロセスへ組み込むことが重要です。

おわりに

保守しにくい既存コード群を改善するには、いきなり全体を書き直すのではなく、現状評価、挙動理解、観測と測定、安定化、制御された再構成、運用標準化の順番で進めることが重要です。最初の15日間で全体像と高リスク領域を把握し、次の15日間で業務フローと依存関係を理解し、31日目以降にログ、監視、品質指標を整えることで、改善の土台ができます。

90日間の目的は、すべての技術的負債を消すことではありません。目的は、変更しても壊れにくく、障害が起きても原因を追いやすく、新任者が参加しても理解しやすい状態へ近づけることです。小さく測定し、小さく安定化し、小さく再構成し、改善結果を文書と運用手順に残すことで、保守困難な既存コード群は長期的に改善できる資産へ変わります。