現行踏襲とは？IT現場の「前と同じで」が招く問題と対処法3選｜SE歴30年

IT業界30余年、フリーランスのシルバーエンジニア。おにぎりです。

「現行踏襲」とは、前のシステムや旧仕様をそのまま引き継ぐことを指す言葉だ。システム開発や改修の現場で「前と同じにしてください」という指示として使われる。一見合理的に見えるが、問題は「なぜそうなっているか」の根拠が誰にも分からないケースが圧倒的に多いことにある。

システム開発の現場で何度も耳にしてきた言葉だ。「現行踏襲でお願いします」——仕様書にも載っていない。誰も理由を説明できない。でも「変えてはいけない」という空気だけが漂う。30年以上この業界にいて、この言葉で何度プロジェクトが余計な工数を食ったか分からない。

結論：「現行踏襲」は根拠なき思考停止。問い直しで退治できる

感情的に「変えるな」と言われても、根拠のない仕様を抱えたまま開発を進めるとツケは必ず後で回ってくる。問い直す勇気が、現場リーダーには求められている。

IT現場で現行踏襲が起きる3つの原因

原因1：仕様を知っている人がもういない

システムの歴史が長くなるほど、当初の設計判断を覚えている人がいなくなる。ベテランが退職し、ドキュメントも整備されていないため、「なぜそうなっているかわからないまま引き継がれる」仕様が積み重なる。

以前担当した某金融系システムのリプレース案件では、「この処理は現行踏襲で」と言われた帳票が12種類あった。担当者に聞いても「ずっとそうだったので」としか言わない。全部調べたら、そのうち4種類はすでに業務で使われていなかった。

原因2：過去の判断を疑う空気がない

「昔からそうだから」「前もそうだったから」という言葉が、思考を止める。特に長年同じシステムを使ってきた組織ほど、現状を疑うことへの心理的ハードルが高くなる傾向がある。

「なぜ？」と聞くだけで「なんでそんなことも知らないんだ」という空気になる現場がある。それが続くと、若手が黙ったまま「前と同じ」で作り続ける。問わない文化が、現行踏襲を育てる。

原因3：変えることへの恐怖・責任回避

「変えて何か問題が起きたらどうする」という恐怖から、誰も変えようとしない。あるいは「誰かが決めたことを変えた責任を取りたくない」という心理も働く。現行踏襲は、人間の防衛本能の産物でもある。

これは上流の人間ほど強い。下流のSEが「変えた方がいい」と思っても、上から「リスクが怖い」で潰されることが多い。責任の所在が曖昧な組織ほど、変えることへの拒絶が強くなる。

現行踏襲が現場に与える3つのダメージ

• 工数・コストの肥大化：不要な機能や処理を維持するための開発・テスト工数が膨らむ
• 品質リスクの増大：誰も理由を知らない仕様をそのまま実装するため、バグの温床になりやすい
• 改善機会の喪失：「前と同じ」に縛られることで、本来できた業務改善・効率化のチャンスを逃す

放置すると工数が膨らみ、品質が落ち、改善機会まで逃す。三重のダメージだ。現行踏襲は「安全な選択」ではなく「先送りのリスク」だと理解しておく必要がある。

現行踏襲の退治法（3ステップ）

ステップ1：「なぜ必要か？」を問い直す

まず関係者全員に「この仕様がなぜ存在するのか」を確認して回る。誰も答えられない仕様は、不要な遺物である可能性が高い。「前がそうだったから」は理由にならないことを、チームで共通認識として持つところから始める。

• 「この処理がなくなったらどうなりますか？」と具体的に聞く
• 業務担当者や発注者、旧システム関係者など複数の視点から確認する
• 「わからない」という回答が続いた場合は、廃止候補としてリストアップ

ステップ2：背景を記録・見える化する

残す理由がある場合は、「なぜ残すのか」をドキュメントに残すことが重要だ。次の開発者が同じ問いを繰り返さないよう、判断の根拠を引き継げる状態にする。

• 「この仕様は○○という理由で残存。変更時は□□に影響あり」と明記する
• 設計書やWikiなどに集約し、次世代への知識継承を図る
• 「謎仕様リスト」として管理し、プロジェクト期間中に順次解消していく

ステップ3：選択肢を提示して決断させる

問い直した結果は、意思決定者が判断できる形で提示する。「このまま踏襲するとどうなるか」「変えるとどうなるか」を比較材料として出すことで、感情論でなく論理的な判断を促せる。

• 「踏襲する場合のコスト・リスク」と「変更する場合のコスト・メリット」を数字で示す
• 最終判断は発注者や上位管理者に委ね、記録として残す
• 決定後は全員が合意した内容として仕様書に明記する

おにぎりの実体験

あるレガシーシステムのリプレース案件で、帳票の出力フォーマットについて「現行踏襲で」という指示が出た。しかし実際に確認すると、その帳票はすでに5年以上印刷されておらず、誰も使っていなかったのだ。

「前と同じに作ってください」を鵜呑みにしていたら、誰も見ない帳票のために数週間の工数をかけていたことになる。「なぜ必要か？」のひと言で、その工数をゼロにできた。

現行踏襲に限らず、IT現場には「誰かが決めたから」「昔からそうだから」という根拠で生き残っている仕様が数多くある。それを問い直す勇気こそ、リーダーに求められるスキルだと私は今も思っている。

よくある質問

現行踏襲はなぜIT現場でなくならないのですか？

大きく3つの原因があります。①仕様を知っていた人がすでに離れている、②過去の判断を疑う空気がない、③変えることへの責任回避です。特に長く続くシステムほど「前と同じ」が安全策として機能してしまいます。

根拠のない現行踏襲に対して、リーダーはどう向き合えばいいですか？

「なぜこの仕様が必要なのか？」を問い直すことが最初の一歩です。答えられる人がいない場合、その仕様は廃止候補として記録し、選択肢を整理して意思決定者に判断させる流れを作ることが現実的な解決策です。

現行踏襲を廃止・変更する際、反発を最小限にするには？

「変えましょう」ではなく「選択肢を提示する」アプローチが効果的です。「現行維持のコスト」と「変更した場合のリスクと利点」を並べて提示することで、感情的な反発を減らしながら合理的な判断を促せます。

まとめ：「前と同じ」に疑問を持つことがプロの仕事

「現行踏襲」は根拠のない思考停止だ。仕様でも要件でもない。原因は「知識の断絶」「疑わない空気」「責任回避」の3つが重なって起きる。放置するほどプロジェクトへのダメージは深くなる。

退治法は「問い直す→記録する→選択肢を出す」の3ステップ。「前がそうだったから」ではなく「今どうあるべきか」を考え続けることが、IT現場のプロとしての仕事だ。

• 「現行踏襲」という言葉が出たら、まず「なぜ必要か？」を1回聞いてみる
• 誰も答えられない仕様は、廃止候補リストに追加する
• 残す仕様は「残す理由」をドキュメントに書き残す

この投稿が悩んでいる人へのヒントになればうれしい。感想やご意見があれば、気軽にコメントをもらえると嬉しいです。