利用者の目的と利用結果から考える

実装の都合と利用者が得る結果がぶつかったら、利用者の結果を選ぶ。粗いものを多く出すより、磨いたものを少なく出す。

なぜ: 利用者が受け取るのは実装でなく結果。作る側に都合のよい形は作る費用を下げるが、その差は使うたびに利用者が払う。

適用する場面:

• 機能・選択肢・設定を足すか決めるとき。
• 解析の出力・レポート・CLI の表示・文書の構成を決めるとき。
• 作りやすさを理由に、利用者に手作業（変換・読み替え・再実行）を残そうとしたとき。

やること:

• 利用者を特定する。画面なら使う人、ライブラリや内部の API なら import する同僚、文書なら読む人。次にコードを保守する人も利用者。影響は、その人の立場で説明する。
• 機能・選択肢の 1 つ 1 つに理由を求める。中心の流れに役立たないものは入れない。
• 本番のコードの前に、使い捨ての形（ノートブック・小さなスクリプト・下書き）で試す。細部（表示の揃え、エラーのときの表示と次の手、出力の単位）まで詰める。

使わないとき: 何から作るかという作業の順番の判断。それは principle-foundational-thinking が決め、この原則は目標を決める。

確かめる例: 成果物に、理由の無い選択肢や設定が無い。報告が「利用者は何ができるようになったか」から書かれている。