memo/20251219

created 2025-12-19 modified 2025-12-19 

• ある会社が、ある会社との折衝を一元化するために、ただ一人の専任「営業担当者」を設ける、
• ように、ある組込みソフトの中で、ある制御チップ（例：温度センサー、モーター制御IC、…）と、送受信をするただ一つの専任「担当クラス」を設ける。
• 悪い例「温度センサーで何度以上を検出したら、モーター制御ICに停止を送信する」という操作を、ひと続きの処理で、書く、のは悪い例。
• 良い例「温度センサーからの入力はそこで一人。何が起きたら何をするか決める人で一人。モーター制御ICに何かを送信する人で一人」、は良い例。
• そうすると、新製品では温度センサーを別のチップに変える、としたいときに、その温度センサーのクラスを替えれば良い。

• ある工場が、ある職人に役割を与える。と、その人が自分はなになにの責任を担うんだと意識することで、日常生活でもそのことを深く考え続け、特定作業の職人に育つ。

• 良い例：夏のオフィスのエアコン温度は、ひとにより希望温度が全然違う。その場合、エアコン温度スイッチを操作する専任者を立てると、あらゆる人がこの専任者に依頼をするので、ここに狭い範囲(ドメイン)のプロ知識が集約する。ソフトウェアでも、こういうのを機能のまとまりとする。
• 例えばの話... あるオフィスでは、12時から13時は昼休みなので、節電しろー、と経営者が言う。電灯も消す。でも、13時過ぎに、外回りをしていた営業担当者が、暑い暑いと言いながら帰ってくる。ここで温度を2度、3度、5度下げても、涼しくならず、15時くらいに寒くなってみんなひざ掛け必須。自律神経失調。偏頭痛。こういうの良くない。
• なので、エアコン大臣になった山田さんは、「11:30になったら温度設定を2度下げ、12時になったら戻す」というハック(巧妙な手順)を、思いつく。すると、経営者も、営業担当者も、なんとなく幸せに、…なるかもしれない。11:30ではうまくいかないようなら、その時刻を11:20、11:10、としてみる。試行と結果観察を繰り返して、手順を最適化する。昨今のAIみたいだ(笑

• 悪い例：オフィスの壁掛け時計は、全員が正しい時刻に設定したい。なので、この時計を合わせるための、セッターやゲッターを設ける意味が薄い。必要のないオーバー抽象化は悪。