「引数5個」の壁を越えるな！コードが「崩壊」する真の理由と健全な関数設計

皆さん、プログラミング学習を進める中で、「1つの関数に引数を5個以上渡すべきではない」という「暗黙のルール」を耳にしたことはありませんか？「なぜ5個なの？」「本当に崩壊するの？」と疑問に感じた方もいるかもしれません。このルールは、単なる数字の遊びではありません。むしろ、コードの「健全性」を保つための大切なヒントなのです。

この記事では、なぜ引数の多さがコードの「崩壊」（ここでは、保守性、可読性、テスト容易性の低下を指します）に繋がるのかを解き明かし、2026年を生きる私たちが実践すべき、より良い関数設計の道筋を皆さんと一緒に探っていきましょう。

なぜ「引数5個」が「崩壊」のサインなのか？

「引数5個」という数字は、あくまで目安です。しかし、この目安を超える関数は、往々にして以下の問題点を抱えがちです。これらが積み重なることで、やがてコード全体の「崩壊」を招いてしまうのです。

1. 可読性の著しい低下

引数が多すぎると、その関数が「一体何をするものなのか」を一目で理解するのが非常に難しくなります。関数を呼び出す際、どの引数に何が渡されるべきか、その順番はどうなっているのかを毎回確認する必要が出てきます。これは、まるで暗号を解読するようなもので、コードを読むたびに思考の負荷が増大します。結果として、新しいメンバーがコードを理解するのに時間がかかったり、既存のメンバーでさえもミスを犯しやすくなったりします。

2. テストの困難さと複雑化

関数に渡す引数が多ければ多いほど、考えられる引数の組み合わせは爆発的に増えていきます。例えば、ブール値の引数が2つあれば4通りのテストが必要ですが、5つあれば32通り、10個では1024通りものテストケースを考慮しなくてはなりません。これでは、すべてのパターンを網羅するテストを書くことは非現実的であり、テストの漏れが生じやすくなります。結果として、思わぬバグが潜みやすくなり、品質の低下を招きます。

3. 変更への弱さ（低凝集度・高結合度）

引数が多い関数は、しばしば「複数の異なる責任」を負っていることが多いです。これは、オブジェクト指向設計の原則の一つである「単一責任の原則 (Single Responsibility Principle)」に反しています。複数の責任を持つ関数は「凝集度が低い」状態と言えます。

また、引数が多いということは、その関数が多くの外部データに依存していることを意味します。これは、関数とその呼び出し元との間に「結合度が高い」状態を生み出します。もし、引数の一つが変更された場合、その変更は関数だけでなく、その関数を呼び出しているあらゆる場所にも影響を及ぼす可能性が高まります。結果として、ちょっとした変更が思わぬ場所でバグを引き起こす「リスキーなコード」となり、保守コストを押し上げてしまうのです。

健全な関数設計への3つのステップ

では、引数の多さに起因する問題を回避し、未来にわたって「健全な」コードを育むためにはどうすれば良いのでしょうか？ここでは、今日から実践できる3つのステップをご紹介します。

1. 引数を「オブジェクト」にまとめる

関連性の高い複数の引数がある場合、それらを一つの「オブジェクト」としてまとめることを検討しましょう。これは、クラス、構造体、あるいはPythonの辞書のようなデータ構造を用いることで実現できます。

悪い例:

エンジニアのスキルシェアプラットフォーム「DokuPro」

教えたい人と学びたい人を繋ぐDokuProでは、新規登録（先生・生徒）を募集中です。
詳細はこちら: https://dokupro.dev/