はじめに

共通関数を修正したとき、他の機能が壊れてしまった経験はありませんか？

わたしは現場で活かすため、個人開発で実務頻出の機能実装やデグレ解消をしています。以前、ログイン判定の共通関数を微修正したところ、管理画面のアクセス制御まで影響して本番障害を起こしました。修正自体は5行程度でしたが、影響範囲の調査を怠ったことが原因でした。実務でこんなことを繰り返すと、開発スピードも信頼も一気に失われます。

この経験から、修正時には必ず「影響調査」と「テストケースの洗い出し」を行うようになりました。

とくにWeb系スタートアップのような少人数開発の現場では、一人ひとりの修正が全体に与える影響が大きいため、『デグレを起こさない開発』は、スピードと同じくらい重要だと考えています。この記事では、『共通関数』を例に、不安なく開発を進めるために、実践すべき具体的な手順を整理します。

なぜ共通関数の修正は危険なのか

共通関数は複数の機能から呼び出されているため、1箇所の修正が予想外の場所に影響します。

例えば、こんな関数があったとします。

// 日付フォーマット用の共通関数
function formatDate(date) {
  return date.toLocaleDateString('ja-JP');
}

この関数を「時刻も表示したい」という要望で修正すると：

function formatDate(date) {
  return date.toLocaleString('ja-JP'); // 時刻も含むように変更
}

一見問題なさそうですが、この関数を使っている「請求書の発行日表示」や「ログの日付フィルター」など、すべての箇所で時刻が表示されるようになってしまいます。請求書に「2025/10/02 14:30:15」と時刻まで表示されたら、デザインが崩れるかもしれません。

そこでデグレ防止のため、以下２つの対策「影響調査」「テスト」を実施します。

1. 影響調査：使用箇所を漏れなく洗い出す

修正前に必ずやるのが、「この関数はどこで使われているか？」の全件調査です。

具体的な調査手順

ステップ1：使用箇所を検索

grepやIDEの全文検索で関数名を検索します。

検索キーワード: formatDate(

括弧まで含めることで、変数名やコメントを除外できます。

ステップ2：リストアップ

検索結果をNotionやスプレッドシートで整理します。

ファイル名	行数	使用箇所の機能	影響の有無
InvoiceDetail.jsx	45	請求書の発行日表示	○ 時刻が表示されると崩れる
UserActivityLog.jsx	102	ログの日付表示	△ 時刻があっても問題なし
ReportExport.js	78	CSVエクスポートの日付列	○ フォーマットが変わると困る

このリストを作ると、「修正の影響が出る箇所」と「問題ない箇所」が可視化されます。

ステップ3：間接的な影響も確認

さらに注意が必要なのは、その関数を呼び出している別の共通関数がないかです。

例えば、formatDate()を使っているgenerateReportTitle()があれば、そこ経由で影響が広がります。

function generateReportTitle(date) {
  return `売上レポート_${formatDate(date)}`; // formatDateを使用
}

この場合、generateReportTitle()の使用箇所も調査対象になります。

この調査で分かること

修正の影響範囲
どの機能をテストすべきか
そもそも共通関数として修正すべきか、別関数を作るべきか

今回の例なら「時刻付きは別関数にする」という判断もできます。

2. テストケース：2種類のテストで確実に検証

影響調査が終わったら、次はテストケースの作成です。
今回は「修正箇所のテスト」と「既存機能のテスト」の2種類を用意します。

テストケース1：修正箇所が仕様通りか

まず、今回の修正自体が正しく動くかを確認します。

修正内容： formatDate()に時刻も含める

テストケース例：

テスト項目	入力値	期待結果
通常の日時	new Date('2025-10-02 14:30:00')	"2025/10/2 14:30:00"
午前0時	new Date('2025-10-02 00:00:00')	"2025/10/2 0:00:00"
年またぎ	new Date('2024-12-31 23:59:59')	"2024/12/31 23:59:59"

このテストで「修正が要件を満たしているか」を確認します。

テストケース2：既存機能が壊れていないか

次に、影響調査でリストアップした機能が、修正前と同じように動くかを確認します。

テスト対象： 請求書の発行日表示（InvoiceDetail.jsx）

テストケース例：

テスト項目	操作手順	期待結果
請求書表示	請求書ID=123を表示	発行日が「2025/10/02 14:30:00」で表示される（デザイン崩れなし）
印刷プレビュー	請求書の印刷プレビューを開く	発行日のフォーマットが正しく、用紙内に収まっている

実際には、このケースでは時刻表示でデザインが崩れる可能性があります。
だからこそ、このテストで事前に気づけるわけです。

手動テストだけでなく自動テストも

理想は自動テストを書くことです。

describe('formatDate', () => {
  test('時刻を含む形式で返す', () => {
    const date = new Date('2025-10-02 14:30:00');
    expect(formatDate(date)).toBe('2025/10/2 14:30:00');
  });
});

共通関数なら自動テストの恩恵が大きく、次回以降の修正でもデグレを防げます。

実際の修正フロー

現場を想定した手順をまとめます。

修正依頼を受ける
- 「formatDateに時刻も表示したい」
影響調査
- grepやIDE検索で使用箇所を洗い出し
- スプレッドシートに整理
- 間接的な影響も調査
方針決定
- 既存関数を修正するか、新しい関数を作るか判断
- 今回は影響範囲が大きいためformatDateTime()という別関数を作る方針に
テストケース作成
- 作成した関数のテスト
- 既存関数が影響を受けないことの確認テスト
実装＆テスト実施
レビュー依頼
- 影響調査の結果とテストケースも添えて

このフローで、デグレのリスクを大幅に減らせます。

まとめ

共通関数の修正では、以下の2つを必ずやっています。

影響調査：使用箇所を全件洗い出し、影響範囲を可視化
テストケース：修正箇所と既存機能の両方をテスト

デグレを100％防ぐのは難しいですが、この2つを実践するだけでリスクは大きく減らせます。

特に小規模チームでは、一人ひとりの行動がサービス全体に影響するので、今後もこうした基本を大切にしていきます。