💡
副作用とは何か？開発における「避けるべきもの」と「避けられないもの」
はじめに
「副作用（side effect）」という言葉は、プログラミングの世界でよく出てきますが、初心者だけでなく中級者でも「なんとなく分かっているようで曖昧」な概念です。
この記事では、UIを伴うアプリケーション開発を前提に、「副作用とは何か」「なぜ避けた方が良いのか」「どこまでを許容すべきか」を整理します。
副作用とは？
プログラムにおける「副作用」とは、本来の目的以外の影響を与えることを指します。
例えば、次のようなケースです：
- 値を返すだけの関数が、グローバル変数を変更してしまう
- 計算結果を返すだけの処理が、ファイルを書き換える
- データ取得関数が、呼び出しのたびにログを出力して外部に依存する
こうした「副次的な影響」は、コードの挙動を予測しづらくし、バグの温床になります。
副作用を避けるべき理由
副作用が多いと、次のような問題が起こりやすくなります。
- 予測困難になる：ある処理が何を引き起こすかが読めなくなる
- テストしづらくなる：状態が外部と結びつくと、単体テストが難しくなる
- バグの原因が追いづらい：本来関係のない箇所で不具合が発生する
特にビジネスロジック層やドメインロジック層では、副作用を極力排除することが重要です。
「入力に対して出力が常に同じである」関数（＝純粋関数）はテストも容易で、保守性も高まります。
UI開発では「副作用」は避けられない
一方で、UIを持つアプリケーションでは、副作用を完全に排除することは不可能です。
たとえば、ViewModelの状態が更新されれば、Viewがそれをもとに画面を再描画します。
この「画面が変わる」というのは、まさに副作用の一種です。
しかしこれは「避けるべき副作用」ではなく、「必要な副作用」です。
重要なのは、副作用を必要最低限の場所に閉じ込める設計を意識することです。
層ごとの考え方
レイヤードアーキテクチャ（例：MVVM）を前提にすると、次のような考え方ができます：
| 層 | 副作用の扱い方 | 例 |
|---|---|---|
| UseCase / Domain | ✅ 極力避ける | 入力 → 出力が一定になる純粋関数が望ましい |
| ViewModel | ⚠️ 状態更新のみ最小限に許容 | 状態の変更や通知など |
| View (UI) | ✅ 必要な副作用を受け入れる | 画面描画、ユーザー操作、API呼び出しなど |
つまり、「上位レイヤーほど副作用を避ける」「下位レイヤー（UI層）では副作用を受け入れる」という方針が基本です。
まとめ
- 副作用とは「本来の目的以外の影響」のこと
- 副作用が多いと、コードの予測・テスト・保守が難しくなる
- UI開発では副作用を完全に避けられないため、「どこに閉じ込めるか」が設計のポイント
- ビジネスロジック層では純粋関数を意識し、副作用をUI層に集約するのが理想
💡 ポイント：「副作用はゼロにする」のではなく、「どこで起こすかをコントロールする」ことが大切です。
Discussion