はじめに
共通関数を修正したとき、他の機能が壊れてしまった経験はありませんか？
わたしは現場で活かすため、個人開発で実務頻出の機能実装やデグレ解消をしています。以前、ログイン判定の共通関数を微修正したところ、管理画面のアクセス制御まで影響して本番障害を起こしました。修正自体は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つを実践するだけでリスクは大きく減らせます。
特に小規模チームでは、一人ひとりの行動がサービス全体に影響するので、今後もこうした基本を大切にしていきます。