今日も社内で、こんな声が聞こえてきます。
「このメソッド、結局“何”をしているコードなんだっけ？」
「処理の意図が読めなくて、レビューに時間がかかる…」
コードが動作することには問題がなくても、“読む側が迷う”場面ほど、チーム全体での時間コストが増えることがあります。
その原因のひとつが、What（何をしたいか）と How（どう実現しているか）が同じ層に混ざることです。
この「層が混ざる」という小さなほころびは、次第に大きな読みづらさを生むようになります。
今回は、この「意図と実装の混在」をどう整理し、コードをもっと読みやすくするかを解説します。
What と How が混ざるとコードはこう曖昧になる
例えばこんなコードです。
public void Process()
{
var id = input.Trim().ToUpper(); // ID整形（How）
var customer = _repo.Get(id); // 取得（How）
if (customer == null) // 判定（What）
{
_logger.Log("NOT FOUND"); // 通知（How）
return;
}
_logger.Log("OK"); // 通知（How）
}
ぱっと見で「なんとなく読める」けれど、
「結局このメソッドは何をしたいのか？」
が一瞬で判断できるかというと…微妙です。
- データの前処理
- DBアクセス
- 例外的な判定
- ログ通知
これらが一段の箱に押し込まれている状態です。
意図と実装が混ざることで、メソッドが“ただの手順”になってしまいます。
層を分けると“意図が透けて見えるコード”になる
読みやすいコードは、上の層に What（意図） があり、
下の層に How（手段） が置かれています。
例えばこうです。
public Result CheckUserStatus(string rawId)
{
var id = rawId.NormalizeCustomerId(); // How は切り出す
var customer = FetchCustomer(id); // How を抽象化
return GetStatusResult(customer); // What としての判断
}
上のメソッドは「流れの説明書」のように読めます。
- 顧客IDを整える
- 顧客データを取得する
- 結果を判定する
意図（What）が流れとして読み取れるコードになり、実装の細部は下の層へ押し出されます。
メソッドの“意味”だけが綺麗に浮かび上がります。
Why：なぜ分けるだけでこんなに読みやすくなるのか
理由はシンプルです。人は「目的」→「手段」の順で理解するからです。
- 目的（What）が最初に見える
- 必要なら How を読み解く
この構造の方が圧倒的に理解しやすく、読み手の脳が無駄なスクロールと推測をしなくて済みます。
そしてこの考え方は「関心の分離」に直結する
「What と How を切り分ける」 という考え方は、
そのまま 関心の分離（Separation of Concerns, SoC） に繋がります。
関心の分離とは
役割の異なるものを同じ場所に置かず、それぞれの関心ごとを独立させる
という設計の基本思想です。
これをメソッド単位で実践したものが、
What（意図）と How（実装）を分ける行為です。
- What：ビジネス的な意図・やりたいこと
- How：それを実現する技術的な詳細
多くのエンジニアは MVC や層アーキテクチャで SoC を学びますが、
その前段階として ひとつのメソッドの中から SoC が始まっている のです。
さらに大きな視点で見ると、恩恵は積みあがっていく
メソッド内での What/How 分離ができると…
- 似たような処理を別の層に寄せ、アーキテクチャを整理できる
- プレゼンテーション層・ドメイン層・インフラ層の構造化が自然にできる
- テスト対象を自然に小さく（単位ごと）切れる
プロジェクト全体の整理につながります。
SoC を「アーキテクチャの話」だけで終わらせず、
日々のコードの中にも SoC の入口があることを意識すると良いです。
“How を出す場所”は、拡張メソッドや小さな関数が向いている
以下のような器があると、上の層（What）がスリムになります。
- 拡張メソッド
- private メソッド
- 小さな専用クラス
var id = rawId.NormalizeCustomerId();
var customer = customerRepository.GetBy(id);
return GetStatusResult(customer);
上の3行に “意図”だけが残る状態 が理想です。
まとめ
- What と How が混ざると意図が読みにくい
- 上に What、下に How を配置するだけで透明度が上がる
- この考え方は 関心の分離（SoC） に直結する
- SoC はアーキテクチャだけの概念ではなく、メソッド単位から始められる
- How を拡張メソッドや小さな関数に寄せると、自然と層が整理される
💡 ポイント：
小さなコードの工夫が、チーム全体の理解コストを下げ、プロジェクトの品質向上につながります。