【やさしく解説 設計編・中級 #1】一つの車に、運転手は一人 ～ある倉庫システムの事例から～

【やさしく解説 設計編・中級 #1】一つの車に、運転手は一人

長年動いてきた倉庫システムに、「箱サイズ」という言葉がありました。
現場はその数字で段ボールを組み、営業はその数字で運賃を決める。

ある日、営業の依頼でプログラムを書き換えました。
翌日、梱包作業場から電話が鳴ります。
「60の箱を組んだら、商品が入らないんですが」

障害対応の会議室で、誰かが言いました。
「営業からの変更で、なぜ梱包作業が止まるのか」

その『なぜ』につく名前が、単一責任の原則（SRP）です。
SOLID五原則の筆頭。けれど「一つのクラスは一つのことだけ」という覚え方は、この現場では通用しませんでした。

持ち帰りは一問だけ。
「その車の運転席に、何人座っていますか？」

コードは出てきません。
クリーンアーキテクチャ本を読んでいなくても大丈夫です。既読の方には、おさらいとして。

SOLIDを原則からではなく、事例から読み直す中級シリーズ（全6回）の第1回です。

---紹介したブログ記事

渡辺幸三「業務システムとマイクロサービス（１）」設計者の発言、2020年
`https://dbconcept.hatenablog.com/entry/2020/11/05/074400`

---
※本編にて、「ドメイン」とは、「駆動」とは、を解説しています。中級編の前にどうぞ

【やさしく解説 設計編 #0】DDDのコード、読めるのに分からない人へ
https://speakerdeck.com/panda728/yasasikujie-shuo-she-ji-bian-number-0

ｰｰｰ
【やさしく解説 設計編・中級 】目次
#1 一つの車に、運転手は一人 ～ ある倉庫システムの事例から ～
　キーワード：`SOLID` `単一責任の原則（SRP）` `アクター`
https://speakerdeck.com/panda728/yasasiku-sekkei-2-number-1

#2 使わないボタンだらけのリモコン ～ となりの変更で、うちのビルドが赤くなる話 ～
　キーワード：`SOLID` `インターフェース分離の原則（ISP）`
https://speakerdeck.com/panda728/yasasiku-sekkei-2-number-2

#3 【やさしく解説 設計編・中級 #3】形はあっていたのに ～ 形に書けない約束の話 ～
　キーワード：`SOLID` `リスコフの置換原則（LSP）` `事前条件、事後条件、不変条件`
https://speakerdeck.com/panda728/yasasiku-sekkei-2-number-3

#4 ルールの寿命と、システムの年輪 ～ 月曜の朝の、一通の通知から ～
　キーワード：`SOLID` `依存性逆転の原則（DIP）` `安定依存`
https://speakerdeck.com/panda728/yasasiku-sekkei-2-number-4

#5 なぜ「足すだけ」が、「足すだけ」で済まないのか～ ボタンひとつの依頼から ～
　キーワード：`SOLID` `開放閉鎖の原則（OCP）`
https://speakerdeck.com/panda728/yasasiku-sekkei-2-number-5

#6 良いアーキテクチャとは ～ 一本の登り道の、行き先 ～
　キーワード：`SOLID` `クリーンアーキテクチャ`
https://speakerdeck.com/panda728/yasasiku-sekkei-2-number-6

※ 7/17 目次およびスライド間のリンクを調整

Transcript

1. 一つの車に、 運転手は一人 【やさしく解説 設計編・中級 #1】ある倉庫システムの事例から 2026.07 北尾　英之 (@kitaohx) 1
2. こちらは、中級編です 本編（#0〜#4）では「ドメイン」や「駆動」についてお話ししました。 　その本編で使ったたとえは、使うたびに短くおさらいします。 ※ #0 も合わせてご覧ください。 https://speakerdeck.com/panda728/yasasikujie-shuo-she-ji-bian-number-0 ま え お き 2
3. 今日は、ひとつの事例から始めます。 長年運用してきた倉庫システムで起きた 　ある 障害 の話です。 ま え お き 3
4. 「箱サイズ」という言葉がありました ・倉庫現場は、この数字を見て段ボールを組み立てます。 ・営業は、この数字で荷主に請求する運賃を決めます。 システムは、順調に稼働してきました。 症 状 4
5. ある日 営業から、依頼が来ました。 「大口のお客様との契約で、キャンペーンのセット商品は 　運賃をワンサイズ下におまけすることになりました。 　対象商品は、箱サイズを『80』ではなく『60』にしてください」 エンジニアは取り込み処理を修正しました。 　テストも通り、請求はワンサイズ下の金額になりました。 症 状 5
6. 翌日 梱包作業場から、連絡がありました。 「指示どおり60の箱を組んだら、商品が入らないんですが。 　マスタの寸法設定、おかしくなっていませんか」 結局その日は、80の箱を組み直して梱包し、 　リストの「60」を赤ペンで「80」に直すことにしました。 症 状 6
7. 後日 障害対応の会議室で、誰かが言いました。 「営業からの変更で、なぜ梱包作業が止まるのか」 症 状 7
8. なぜ、トラブルがおきたのでしょう？ 少しの間、想像してみてください。 8
9. 変更を求めてくる人が、二人いた 誰が 「箱サイズ」の意味 使い道 現場 段ボールの大きさ 箱を組み立てる 営業 運賃の区分 請求を計算する 依頼の「60にして」と、電話の「寸法がおかしい」 。 　これは、同じ言葉を、別々の意味で話しています。 二つの意味が 同じ数字でなくなったとき、 障害になります。 解 剖 9
10. でも、言葉が一つだった当時、 　その設計はまっとうな判断でした 作った当時、箱の大きさと運賃の区分は、いつも同じ数字でした。 　区別のいらない二つを、商売は一つの言葉で呼んでいました。 設計は、その言葉を忠実に写したのです。 解 剖 10
11. 前提を崩したのは、商売の成長でした 前提が崩れたのは、 「運賃だけおまけする」という新しい契約です。 　商売の成長が、二つの意味を、別々の数字へ引き離したのです。 いわば、一台の車に、二人が相乗りしていた 設計でした。 行き先が同じあいだ、相乗りは、事故になりません。 解 剖 11
12. 処置：車を分ける 営業のために、新しい言葉を作りました。請求サイズ です。 ・運賃の請求は、請求サイズ（営業の判断）から作られます。 ・現場のリストは、これまでどおり箱サイズ（現場の事実）を見ます。 実装も、運転手にあわせて二つに分かれました。 　もう、営業の変更で、梱包作業が止まることはありません。 処 置 12
13. 起きていたこと 変更を求めてくる声が二系統あるのに、 　ハンドルは一つしかありませんでした。 そのため、ハンドルの取り合いが起こります。 コードが100行でも、声が二系統ならぶつかる。 1000行でも、一系統なら 平和。 つまり、問題は大きさではなく、運転手の人数 です。 解 剖 13
14. この症状には、名前がついています 単一責任の原則（SRP） 。 設計の五原則SOLID、その筆頭です。 　ロバート・C・マーティンの定義は、こうです。 モジュールは、たった一人の アクター に対して 責務を負うべきである。 命 名 14
15. アクターは運転手、モジュールは車 アクターとは、変更を求めてくる声のまとまり。 　本編#4にも出てきた 運転手 です。 モジュールとは、関数やデータのひとかたまり。 　この話の 車 は、 「箱サイズ」の言葉でした。 一つの車に、運転手は一人。 これが、 単一責任の原則（SRP） です。 命 名 15
16. 以前の私は、単一責任の原則（SRP） をこう覚えていました 「一つのクラスは、一つのことだけ」 。 この覚え方だと、先ほどの障害を前にしても、 　SRP違反には見えませんでした。 なにを数えれば「一つ」なのか、見えなかったのです。 命 名 16
17. 「一つ」だったものとは ですが、いまなら見えます。 数えるのは、運転手 「箱サイズ」には 運転手 が二人いる！ 命 名 17
18. アクターの数え方 組織図の部署ではない。 経理部の中に、税務の声と 管理会計の声があるなら、アクターは二人 画面のユーザーとも限らない。 税制改正は国の声。 締切も、上司も、AIも、運転席に座れる アクターは「この変更は、誰から来るか」で決まります。 命 名 18
19. その車の運転席に、 　何人座っていますか？ 今日の持ち帰りは、この一問だけです。 19
20. 今週、どこかで試してみて よく変更しているファイルをGitの履歴画面で開き、 　各変更の横に依頼主の名前を挙げてください。 「営業の契約」 「現場の運用変更」 「税制改正」 「フレームワーク更新」 依頼主の名前が二種類以上並んだら、 　そのファイルの運転席には、二人以上が座っています。 や っ て み よ う 20
21. 寄り道：業務システム開発手法の分野でも 業務システム開発の分野には、三要素分析法で有名な、渡辺幸三さんがいます。 渡辺さんが提唱する「CRUD基準によるサブシステム分割」 。その基準は、 「ブロック間をまたぐ更新系操作が存在しない」こと。 Create・Update・Delete（作成・更新・削除）はブロックの内部に隠れ、 　ブロックの間に残るのは、Read（参照）だけ。 これは、先ほどの、アクターの数え方と似ています。 　つまり、一人の運転手のハンドル操作が、車内で完結することです。 よ り み ち 21
22. SOLIDは五原則。 今日は、その一つ目でした 残りの4つも、原則からではなく、事例から始めます。 　最後に、まとめの回を足して、全6回。 次回（中級 #2）：使わないボタンだらけのリモコン https://speakerdeck.com/panda728/yasasiku-sekkei-2-number-2 22
23. この回が借りたもの 単一責任の原則（SRP）、アクター ロバート・C・マーティン著、角征典・高木正弘訳 『Clean Architecture 達人に学ぶソフトウェアの構造と設計』KADOKAWA、2018年 https://www.kadokawa.co.jp/product/301806000678/ （本文の「運転手」は、アクターの本連載訳であり、"変更要求の発生源"であるという捉え方を採用します。 ） CRUD基準によるサブシステム分割 渡辺幸三「業務システムとマイクロサービス（１） 」設計者の発言、2020年 https://dbconcept.hatenablog.com/entry/2020/11/05/074400 車と運転席のたとえ、症状の物語 本連載のたとえです。事例はフィクションです。 引 用 元 23