Railsだからできる 例外業務に禍根を残さない 設定設計パターン

2025/09/27のKaigi on Rails 2025（Day2）にて発表しました。

Transcript

1. Railsだからできる 例外業務に禍根を残さない 設定設計パターン Kaigi on Rails 2025 day2
2. HN ei.ei.eiichi えいえい 所属 株式会社 坂ノ途中 ITチーム・経営企画 自己紹介
3. Railsだからできる 例外業務に禍根を残さない 設定設計パターン 事業紹介
4. 100年先もつづく、農業を。 全国の生産者さんのお野菜をあつめて、ご家庭や飲食店、小売店さんに配送しています。 約400軒
5. 海ノ向こうコーヒー 33か国/100種類を超える生豆ラインナップ 約3,000軒のカフェや焙煎所へ 韓国やインドネシアでの販売も開始 現地パートナーを介して 生豆を輸入している国/地域 スタッフが産地に通い、 直接生豆を輸入している国/地域 全10か国 焙煎豆を小売店さんでも販売中 カスカラシロップは 海ノ向こうコーヒー発の製品です。
7. Railsだからできる 例外業務に禍根を残さない 設定設計パターン これから話すこと
8. • 例外業務とはどんなものか？ • 例外業務を取り扱う設定化には、どのようなパターンがあり、どう選ぶのか？ • 選んだ仕組みを理解してもらい、権限委譲するための工夫 複雑なドメインを乗り越えるための術を話します。 これから話すこと
9. Railsだからできる 例外業務に禍根を残さない 設定設計パターン 例外業務とは？ パレートの法則の20％側
10. そもそも例外業務isなに？ 生産者さん お客さま お届け 生産者さんから、お野菜を集めて、お客様にお届けする、シンプルなお仕事です。 集めて
11. そもそも例外業務isなに？ お客さま たくさんの 生産者さん 店舗で購入 飲食店でお食事 直接お届け 地域ごとに 集荷・発送 セットにしてお届け
12. そもそも例外業務isなに？ お客さま たくさんの 生産者さん 店舗で購入 飲食店でお食事 直接お届け 地域ごとに 集荷・発送 セットにしてお届け 出荷漏れ 配送遅延 都会から遠い産地 台風・大雪 品質不具合 消化仕入れ FAX注文 出荷数調整 チェーン別 商品コード
13. そもそも例外業務isなに？ お客さま たくさんの 生産者さん 店舗で購 直接お届け 生産者組合が まとめて集荷 セットにしてお届け 生産者までわかる「お野菜の説明書」をお届けしています。
14. これまでの流れを乗り切るための数々の「工夫」があります。 ex) 曜日によって配送ルートが違うので、配送料を正しく計算してほしい。休市日も便が違う。 ex) キク科アレルギーのお客様には、野菜セットのレタスをジャガイモに入れ替える。 ex) そのお客様の前回お届け時に、ジャガイモが入っていたなら、さらに入れ替える。 ex) そもそも、前回の野菜がジャガイモ（デストロイヤー）だったら、同じ野菜とみなすのか？ ex) 収穫不良で欠品があったら、飲食店にはメールを送ってほしい。特定のお客様はFAXで。 ex) 1kgのじゃがいもを10袋分の袋詰をすると、在庫が10.5kg減る。 ex) 届いた万願寺とうがらしに日焼けがあったので、お客さまへのメッセージを変更したい。 → 坂ノ途中では上記の例外はすべて全て設定化されており、業務担当者が調整しています。 そもそも例外業務isなに？
15. こうした例外に対して機能を一つずつ作っていくことは そこまで難しくありません。 その代わり、運用していく上での困難がいくつもあります。 業務担当者が変わり、引き継ぎが上手くいかない。 システム開発を進めていくことで、変更の影響範囲が読めなくなる。 業務担当者がシステム外に仕組みを作り、理解が難しくなる。 例外業務の扱いが難しい理由
16. こうした例外業務をすべて把握して、システム担当者が開発にあたることはできるで しょうか？ →すぐに限界が来てしまいます。 そのために 各業務の担当者が掌握できるような、「設定」として切り出しましょう。 例外業務を取扱うための設定化
17. 「設定登録業務を業務担当者に委譲しやすいこと」 具体的には ・機能自体のわかりやすさ。 ・変更作業がどのくらい簡単にできるのか。 ・影響範囲がどのくらい及ぶのかがわかること。 「説明なしに、すぐに慣れることができるか？」が一つの指標になります。 設定化していく上で、重要なポイントはたった１つ
18. Railsだからできる 例外業務に禍根を残さない 設定設計パターン 実装例を紹介します 納品書出力を事例に、いろんな設定方法で実装します
19. スーパーチェーンの店舗AとBには、全店舗合計を表示した納品書を別途出力する。 この機能を６つの方法を用いて、実装していきます。 1. コードに直接書く 2. 共通設定テーブル 3. 備考欄を利用する 4. 設定カラムの追加 5. 構造体定義を作成 6. テーブル設定化 作るのはこんな機能
20. 実装イメージはこんな感じです。 Customer（顧客）が複数のOrder（受注）を持つ関係
21. まずは例外ケース扱いをとして YAGNIの原則に従って コードに埋め込みます。 １,コードに直接書く
22. こまめな設定変更があるため、 Configテーブルを作成し、 管理画面上から編集できるようにする。 設定画面の増えすぎ防ぐことも意図 ２,共通設定テーブル
23. 「1️⃣コードに直接書く」や「2️⃣共通設定テーブル」を利用した設定が増えていく。 → 変更の多い項目に適用されると 調査依頼や設定依頼が増えすぎて、開発担当が開発できない。 変更頻度が非常に低いケース（年１以下）に向いています。 この仕組みで、設定項目が増えるとどうなるか？
24. ユーザーから変更したい要望があり、 カラム追加するほどでもない。 と考えて備考欄を採用します。 特定顧客対応で カラムは増やしたくないため、 やむなくです。 ユーザーにとっては分かりやすい。 ３,備考欄を利用する
25. 取り扱い先のグループが増えたため、 納品書のフォーマットが さらに増えました。 カラムを独立させて、 enum定義に移行しましょう。 ４,設定カラムの追加
26. 「3️⃣備考欄を利用する」や「4️⃣設定カラムの追加」が増え続ける → １顧客を登録するためには、数十箇所の設定が登録必須になる。 → 画面上の設定項目が増えすぎて、ベテラン業務担当者しか登録できない。 また項目が増えることで、組み合わせパターンも爆発していきます。 設定の選択肢が少ない場合に、向いています。 必須項目にしたい場合は、カラムを分けましょう。 これら２つの仕組みで、項目が増えるとどうなるか？
27. ５,構造体定義を作成する 納品書種類ごとに金額計算方法を 変えたい要望がきました。 設定値に連動する項目が複数ある場合は Structを利用して 固定値であることを明記しましょう。 設定項目ごとの組み合わせ爆発を 防ぎたいケース利用します。
28. 管理画面上で編集できる要望があれば テーブル設定化までしましょう。 設定値に連動する項目ごとの 組み合わせを考慮する 必要はありますが、 ユーザーニーズにしっかり答えれます。 ６,テーブル設定化
29. 実装パターン６つ、すべて検索スコープと判定メソッドが変化していません。 Viewの実装を変えずに、貫けたのは、View直書きしなかったから。 開発初期のちょっとしたひと手間の投資が、ちゃんと回収できました。 Ruby on Railsのここが素晴らしい
30. Railsだからできる 例外業務に禍根を残さない 設定設計パターン どの実装をえらぶのか？
31. 変更頻度と、設定の複雑さで分析する 設定パターンの複雑さ 高い 変更の多さ 低い 少ない 多い 共通設定 テーブル 2 コードに 直接書く 1 備考欄を 利用する 3 設定カラムの 追加 4 テーブル 設定化 6 構造体定義を 作成 5
32. 変更頻度と、設定の複雑さで分析する 実装例のケース 設定パターンの複雑さ 高い 変更の多さ 共通設定 テーブル 低い 少ない 多い 備考欄を 利用する テーブル 設定化 コードに 直接書く 設定カラムの 追加 構造体定義を 作成 2 1 3 4 6 5
33. 実装方法を判断する経験則 共通設定 テーブル コードに 直接書く 備考欄を 利用する 設定カラム の追加 テーブル 設定化 構造体定義を 作成 ユーザー 変更あり 2 1 3 4 6 5 設定の 変更頻度 が多い 連動する 項目が 複数 必須項目 にしたい いいえ はい はい いいえ はい いいえ はい いいえ いいえ はい 連動する 設定は 組み合わせ自由
34. Railsだからできる 例外業務に禍根を残さない 設定設計パターン 設定の委譲しやすさを上げる
35. 内部変数として持っているケース（特にマジックナンバー）は コードを書いている人にしかわからないことも多い。 すべて、わかりやすく表示する。 条件判定に使われる設定は、すべて一覧に表示するぐらいの気持ちでOK まずは誰もが見れるように。
36. 変更の影響がわからないものは、誰も変更できない。 １，ユーザーが分かりやすい名前と一貫性。 ２，画面上に影響の説明を書く。 ３，設定コピー機能は常に欲しい。 「変更は怖いけど、新しいものは作れる。」 のが、ユーザーの心理。 実装コストも低いのでおすすめ。 設定の影響先がわかる。
37. 「もとに戻せる」は、ユーザーの安心感です。 Auditsを利用して履歴を残し、 ユーザーも見えるようにしましょう。 履歴さえ残っていれば、 何が起こっているかもしらべてくれるし、 元に戻す対応もしてくれます。 履歴が残って、もとに戻せる。
38. だれかが言わないと、例外業務をやめよう。とはならない。 最初の一声になってみる。 シンプルさを考えられるのは、エンジニアだからこそ。 そもそも例外業務をやめる。
39. Railsだからできる 例外業務に禍根を残さない 設定設計パターン まとめ
40. 設定づくりは奥が深い。 ・どの設定が正しいかは、常に選択の余地があります。 ・設定テーブルをどう切り出すか？の切り口こそ設計の妙味。 ・切り出すためには、既知のドメイン知識はとても参考にできる。先人の知恵。 ・分かりづらい設定になっても、変更に強い実装があれば、立て直せる。 ・ユーザーの失敗や問い合わせは、すべて改善の余地 まとめ
41. 設定は全部jsonやKVSでいいんじゃない？ 適用開始日を含む設定の取り扱い 設定だけでは防げない条件文だらけのView SoRとSoAの特性の違うデータモデルの取り扱い。 組織内での設定の共有と分割。逆コンウェイの法則はつかえる。 ドメイン駆動設計をはじめよう(2024) データモデリングでドメインを駆動する(2024) 話せなかったこと 参考文献
42. 内製システム開発の楽しさ。 ・ユーザーがとても近い。 ・フルサイクルの開発ができる。 ・企画・開発・インフラ・保守サポートまで。 ・自由度が高い動的な開発。 さいごに
43. Railsだからできる 例外業務に禍根を残さない 設定設計パターン ご清聴ありがとうございました。