はじめに

関数レビューにおいて、最も頻出かつ初見では気づかれにくいのが「引数の責務の曖昧さ」である。
この問題は、単にコードの見た目や処理結果では表れず、関数の「設計意図」「再利用性」「構造的整合性」に直結する。

本マニュアルでは、引数の数・型・意味に対するレビュー視点の具体化を行うとともに、よくある責務の混在ケースに対して、どうレビューすべきかを事例と図で解説する。

引数のレビューが必要になる理由

• 関数の責務を見極める最大のヒントは引数設計にある
• 将来的な関数再利用性に大きく影響する
• 引数と本体の責務が一致していないケースが多い

ケーススタディ：役割の異なる値を1関数に押し込めた例

def generate_report(data, user, export_path, notify_admin):
    # 処理...
    if notify_admin:
        send_email(user)
    save_to_file(data, export_path)

@Reviewer: `user`は通知処理のためだけに存在しており、レポート生成の本来の責務とは無関係です。`notify_admin`とのセットは関数外に切り出す方が望ましく、構造的責務が分離されます。

この例では、generate_reportという関数が「レポートを作る」のか「通知も送る」のか、意図が分散してしまっている。
レビューでは引数の“用途”の一貫性に注目し、責務分離の必要性を議論すべきである。

責務分離前後の構造図

↓ 責務を関数単位で分離した構造

構造の違いからも明らかなように、「データの扱い」と「通知」という性質の異なる目的は分離すべきである。

よくあるレビュー対象の引数パターン

対話レビュー例：引数設計の相談対応

def upload(file, validate=True, notify=None):
    ...
@Reviewer
`validate`と`notify`は用途が全く異なり、責務の混在が懸念されます。
`validate_file`と`notify_user`を関数外で呼び出し、明示的な処理構成にできませんか？
@Developer
バリデーションと通知はオプションで切替え可能にしたいのですが、冗長になりますか？
@Reviewer
責務の混在を避ける構成で、オプション制御も呼び出し側で担保するのが明確です。

レビュー観点整理：引数に潜む設計上の問題

• 引数が多すぎる（4つ以上） → 責務が多重化している兆候
• ブール値が複数存在する → 条件分岐ロジックが内部に潜む
• データと制御が混在する → 呼び出し側の責務が奪われている
• 型が不明（dict, Any） → 使用目的が明示されていない可能性
• 関数内で一切使われていない引数がある → 将来用・使い回し臭がある

まとめ：レビューアーとしての構造的判断

引数のレビューは、関数の「中」だけを見るのではなく、「関数外との関係性」を構造的に捉えることが重要である。

関数の引数を見れば、

• 責務の分離が適切か
• 制御が混入していないか
• 呼び出し元との依存が過剰でないか

を定量的に見抜くことができる。

レビューアーは常に、関数がどこから呼ばれ、どう使われる想定なのかまでを読み解き、
引数という設計の窓口から構造的な問題提起を行うスキルを磨くべきである。