【言語化アップデートシリーズ Vol.3】
言語化を“変数と定数”で整理するという技術
Vol.2 では「具体と抽象の往復」が弱いと認識ズレが起きる、という話をしました。
今回はそこから一歩進んで、日常の言語化だけでなく、実装・レビュー・プロダクト設計にも直結する“変数と定数”の切り分けを紹介します。
エンジニアリングの世界では、
「何が変更可能で、何が固定なのか」が曖昧だと、設計も開発も破綻します。
実は 言語化もまったく同じ構造 で成り立っています。
そしてもう一つ大事なのは、この切り分けは
頭の中のカオスをほどき、論点を一瞬でクリアにするための技術
でもあるという点です。
言語化は、一種の思考の整理術となって効率的なツールとなります。
■ なぜ説明が迷子になるのか？
情報量が多いからではなく、「役割が曖昧」だから
説明が長くなる、論点が散らかる、相手にうまく伝わらない...
これらの原因はたいてい、
伝えたい情報の中で、“変わる部分（変数）”と“変わらない部分（定数）”が区別されていない
からです。
コードで例えるなら、
- 設定ファイルに書くべき “固定値” と
- 実装内で調整する “可変値”
が同じ場所に混ざっているような状態です。
すると、頭の中では “全部を同時に満たそうとする” 状態になり、
問題が解けない “カオス状態” を生みます。
そこで使えるのが今回の視点：
情報を「変数（変えられる）」と「定数（変えられない）」に分ける
この操作をするだけで、
何を議論すればいいのか／しなくていいのかが切り分かれ、
混乱が一気にほどける ようになります。
■ Step1：まず「定数」を切り出す（動かない前提）
実装でいうと“不変条件”や“仕様の制約”に当たる要素です。
例：
- もう起きてしまった事実
- ユーザーの制約
- 納期・リソース
- チームの方針
- 非機能要件
- 相手の感情（事実として既に起きているもの）
これらは議論しても動かないので、まず「背景」として固定します。
問いはこれだけ。
これはそもそも変えられるのか？
変えられないものは全部「定数」へ。
これだけで混乱のかなりの部分が消えます。
（＝扱うべき“問題の量や範囲”が一気に減るため）
■ Step2：次に「変数」を抽出する（動かせる部分）
設計でいう“調整可能なパラメータ”のような部分です。
例：
- どんな順番で進めるか
- どこを最適化するか
- UI の構成
- 伝え方
- 相談する相手
- ロジックの構造
- タスクの優先順位
定数を切り出すと、変数が自然と浮かび上がります。
ここから初めて、意思決定や設計が可能な状態 になります。
■ 数学の発想は、設計にも言語化にも効く
数学では複雑な式を扱うとき、
- 定数項をまとめる
- 変数の形（構造）だけを見る
という操作をします。
例：
A+300+200 → A+500- y = x² + 3 のカーブだけを知りたいときは「x²」にまず着目する
開発もこれと同じく、
- 設定値（定数）を切り離す
- ロジック（変数）にフォーカスする
を行います。
言語化も同じ構造で成り立っています。
動かないもの（定数）をどけると、動かせるもの（変数）が明確になり、
カオスが“構造”に変わる。
■ 言語化の型：「定数 → 変数 → 結論」
読みやすい仕様書、レビューコメント、議論の整理はほぼこの形です。
① 定数（変わらない前提を宣言）
例：「この API はレスポンス形式を変えられない」
② 変数（調整可能な部分を並べる）
例：「キャッシュ戦略」「UI 表示順」「バリデーション位置」
③ 結論（意思決定をひとことで）
例：「なので今回はキャッシュ戦略を最適化する方向で進めたい」
この流れにすると、
“何について話しているか”が一度で伝わる ようになります。
■ 落とし穴：“定数と変数の取り違え”
技術的負債や認識ズレの温床です。
● 本当は変数なのに定数扱いする例
- 「締め切りは絶対動かない」→ 調整すれば動く可能性がある
- 「仕様は変えられない」→ 実はビジネス側が柔軟だった
- 「自分のキャパは固定」→ タスク配分を変えるだけで改善する
● 本当は定数なのに変数扱いする例
- ユーザーの行動原理を“変えよう”とする
- 非機能要件を後から無理やり動かそうとする
- すでに起きた事実（障害・トラブル）を無かったことにしようとする
判断の基準はただ一つ：
これは変わる？変わらない？
ここを誤ると、一気にまたカオスが戻ってきます。
📌 誤分類を防ぐ 3ステップ
-
思い込み定数を炙り出す
（固定だと思っていたものを書き出す） -
定数にするなら理由を書く
（理由がなければ変数扱いへ戻す） -
最後に「今いじれるパラメータは？」を問う
（自動的に変数が整理される）
■ まとめ：言語化は才能ではなく、構造の扱い方
- 言語化が難しいのは“情報の優先度”が決まってないから
- 変数と定数を分けるだけで論点が一瞬で整理される
- 実装・設計・レビュー・コミュニケーションすべてで有効
- 言語化とは、「情報を構造化する技術」
- カオスは「変わる／変わらない」で分解すると消えていく
まずはこの仕分けから始める。
もしこの記事が役に立ったら、
いいね・フォロー をいただけると励みになります！
次回は、未定です！
（包含関係とか場合分けの記事でも書こうかなと思ってはいます。）
ps.
徐々にエンジニア向けの記事なのかという感じになってしまっているので、どういうスタイルなら良いのか模索中...