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

by えいえい

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

HN ei.ei.eiichi えいえい所属株式会社坂ノ途中 ITチーム・経営企画自己紹介

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

100年先もつづく、農業を。全国の生産者さんのお野菜をあつめて、ご家庭や飲食店、小売店さんに配送しています。約400軒

Slide 5

Slide 5 text

海ノ向こうコーヒー 33か国/100種類を超える生豆ラインナップ約3,000軒のカフェや焙煎所へ韓国やインドネシアでの販売も開始現地パートナーを介して生豆を輸入している国/地域スタッフが産地に通い、直接生豆を輸入している国/地域全10か国焙煎豆を小売店さんでも販売中カスカラシロップは海ノ向こうコーヒー発の製品です。

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

● 例外業務とはどんなものか？ ● 例外業務を取り扱う設定化には、どのようなパターンがあり、どう選ぶのか？ ● 選んだ仕組みを理解してもらい、権限委譲するための工夫複雑なドメインを乗り越えるための術を話します。これから話すこと

Slide 9

Slide 9 text

Railsだからできる例外業務に禍根を残さない設定設計パターン例外業務とは？パレートの法則の20％側

Slide 10

Slide 10 text

そもそも例外業務isなに？生産者さんお客さまお届け生産者さんから、お野菜を集めて、お客様にお届けする、シンプルなお仕事です。集めて

Slide 11

Slide 11 text

そもそも例外業務isなに？お客さまたくさんの生産者さん店舗で購入飲食店でお食事直接お届け地域ごとに集荷・発送セットにしてお届け

Slide 12

Slide 12 text

そもそも例外業務isなに？お客さまたくさんの生産者さん店舗で購入飲食店でお食事直接お届け地域ごとに集荷・発送セットにしてお届け出荷漏れ配送遅延都会から遠い産地台風・大雪品質不具合消化仕入れ FAX注文出荷数調整チェーン別商品コード

Slide 13

Slide 13 text

そもそも例外業務isなに？お客さまたくさんの生産者さん店舗で購直接お届け生産者組合がまとめて集荷セットにしてお届け生産者までわかる「お野菜の説明書」をお届けしています。

Slide 14

Slide 14 text

これまでの流れを乗り切るための数々の「工夫」があります。 ex) 曜日によって配送ルートが違うので、配送料を正しく計算してほしい。休市日も便が違う。 ex) キク科アレルギーのお客様には、野菜セットのレタスをジャガイモに入れ替える。 ex) そのお客様の前回お届け時に、ジャガイモが入っていたなら、さらに入れ替える。 ex) そもそも、前回の野菜がジャガイモ（デストロイヤー）だったら、同じ野菜とみなすのか？ ex) 収穫不良で欠品があったら、飲食店にはメールを送ってほしい。特定のお客様はFAXで。 ex) 1kgのじゃがいもを10袋分の袋詰をすると、在庫が10.5kg減る。 ex) 届いた万願寺とうがらしに日焼けがあったので、お客さまへのメッセージを変更したい。 → 坂ノ途中では上記の例外はすべて全て設定化されており、業務担当者が調整しています。そもそも例外業務isなに？

Slide 15

Slide 15 text

こうした例外に対して機能を一つずつ作っていくことはそこまで難しくありません。その代わり、運用していく上での困難がいくつもあります。業務担当者が変わり、引き継ぎが上手くいかない。システム開発を進めていくことで、変更の影響範囲が読めなくなる。業務担当者がシステム外に仕組みを作り、理解が難しくなる。例外業務の扱いが難しい理由

Slide 16

Slide 16 text

こうした例外業務をすべて把握して、システム担当者が開発にあたることはできるでしょうか？ →すぐに限界が来てしまいます。そのために各業務の担当者が掌握できるような、「設定」として切り出しましょう。例外業務を取扱うための設定化

Slide 17

Slide 17 text

「設定登録業務を業務担当者に委譲しやすいこと」具体的には・機能自体のわかりやすさ。・変更作業がどのくらい簡単にできるのか。・影響範囲がどのくらい及ぶのかがわかること。「説明なしに、すぐに慣れることができるか？」が一つの指標になります。設定化していく上で、重要なポイントはたった１つ

Slide 18

Slide 18 text

Railsだからできる例外業務に禍根を残さない設定設計パターン実装例を紹介します納品書出力を事例に、いろんな設定方法で実装します

Slide 19

Slide 19 text

スーパーチェーンの店舗AとBには、全店舗合計を表示した納品書を別途出力する。この機能を６つの方法を用いて、実装していきます。 1. コードに直接書く 2. 共通設定テーブル 3. 備考欄を利用する 4. 設定カラムの追加 5. 構造体定義を作成 6. テーブル設定化作るのはこんな機能

Slide 20

Slide 20 text

実装イメージはこんな感じです。 Customer（顧客）が複数のOrder（受注）を持つ関係

Slide 21

Slide 21 text

まずは例外ケース扱いをとして YAGNIの原則に従ってコードに埋め込みます。１,コードに直接書く

Slide 22

Slide 22 text

こまめな設定変更があるため、 Configテーブルを作成し、管理画面上から編集できるようにする。設定画面の増えすぎ防ぐことも意図２,共通設定テーブル

Slide 23

Slide 23 text

「1️⃣コードに直接書く」や「2️⃣共通設定テーブル」を利用した設定が増えていく。 → 変更の多い項目に適用されると調査依頼や設定依頼が増えすぎて、開発担当が開発できない。変更頻度が非常に低いケース（年１以下）に向いています。この仕組みで、設定項目が増えるとどうなるか？

Slide 24

Slide 24 text

ユーザーから変更したい要望があり、カラム追加するほどでもない。と考えて備考欄を採用します。特定顧客対応でカラムは増やしたくないため、やむなくです。ユーザーにとっては分かりやすい。３,備考欄を利用する

Slide 25

Slide 25 text

取り扱い先のグループが増えたため、納品書のフォーマットがさらに増えました。カラムを独立させて、 enum定義に移行しましょう。４,設定カラムの追加

Slide 26

Slide 26 text

「3️⃣備考欄を利用する」や「4️⃣設定カラムの追加」が増え続ける → １顧客を登録するためには、数十箇所の設定が登録必須になる。 → 画面上の設定項目が増えすぎて、ベテラン業務担当者しか登録できない。また項目が増えることで、組み合わせパターンも爆発していきます。設定の選択肢が少ない場合に、向いています。必須項目にしたい場合は、カラムを分けましょう。これら２つの仕組みで、項目が増えるとどうなるか？

Slide 27

Slide 27 text

５,構造体定義を作成する納品書種類ごとに金額計算方法を変えたい要望がきました。設定値に連動する項目が複数ある場合は Structを利用して固定値であることを明記しましょう。設定項目ごとの組み合わせ爆発を防ぎたいケース利用します。

Slide 28

Slide 28 text

管理画面上で編集できる要望があればテーブル設定化までしましょう。設定値に連動する項目ごとの組み合わせを考慮する必要はありますが、ユーザーニーズにしっかり答えれます。６,テーブル設定化

Slide 29

Slide 29 text

実装パターン６つ、すべて検索スコープと判定メソッドが変化していません。 Viewの実装を変えずに、貫けたのは、View直書きしなかったから。開発初期のちょっとしたひと手間の投資が、ちゃんと回収できました。 Ruby on Railsのここが素晴らしい

Slide 30

Slide 30 text

Railsだからできる例外業務に禍根を残さない設定設計パターンどの実装をえらぶのか？

Slide 31

Slide 31 text

変更頻度と、設定の複雑さで分析する設定パターンの複雑さ高い変更の多さ低い少ない多い共通設定テーブル 2 コードに直接書く 1 備考欄を利用する 3 設定カラムの追加 4 テーブル設定化 6 構造体定義を作成 5

Slide 32

Slide 32 text

変更頻度と、設定の複雑さで分析する実装例のケース設定パターンの複雑さ高い変更の多さ共通設定テーブル低い少ない多い備考欄を利用するテーブル設定化コードに直接書く設定カラムの追加構造体定義を作成 2 1 3 4 6 5

Slide 33

Slide 33 text

実装方法を判断する経験則共通設定テーブルコードに直接書く備考欄を利用する設定カラムの追加テーブル設定化構造体定義を作成ユーザー変更あり 2 1 3 4 6 5 設定の変更頻度が多い連動する項目が複数必須項目にしたいいいえはいはいいいえはいいいえはいいいえいいえはい連動する設定は組み合わせ自由

Slide 34

Slide 34 text

Railsだからできる例外業務に禍根を残さない設定設計パターン設定の委譲しやすさを上げる

Slide 35

Slide 35 text

内部変数として持っているケース（特にマジックナンバー）はコードを書いている人にしかわからないことも多い。すべて、わかりやすく表示する。条件判定に使われる設定は、すべて一覧に表示するぐらいの気持ちでOK まずは誰もが見れるように。

Slide 36

Slide 36 text

変更の影響がわからないものは、誰も変更できない。１，ユーザーが分かりやすい名前と一貫性。２，画面上に影響の説明を書く。３，設定コピー機能は常に欲しい。「変更は怖いけど、新しいものは作れる。」のが、ユーザーの心理。実装コストも低いのでおすすめ。設定の影響先がわかる。

Slide 37

Slide 37 text

「もとに戻せる」は、ユーザーの安心感です。 Auditsを利用して履歴を残し、ユーザーも見えるようにしましょう。履歴さえ残っていれば、何が起こっているかもしらべてくれるし、元に戻す対応もしてくれます。履歴が残って、もとに戻せる。

Slide 38

Slide 38 text

だれかが言わないと、例外業務をやめよう。とはならない。最初の一声になってみる。シンプルさを考えられるのは、エンジニアだからこそ。そもそも例外業務をやめる。

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

設定づくりは奥が深い。・どの設定が正しいかは、常に選択の余地があります。・設定テーブルをどう切り出すか？の切り口こそ設計の妙味。・切り出すためには、既知のドメイン知識はとても参考にできる。先人の知恵。・分かりづらい設定になっても、変更に強い実装があれば、立て直せる。・ユーザーの失敗や問い合わせは、すべて改善の余地まとめ

Slide 41

Slide 41 text

設定は全部jsonやKVSでいいんじゃない？適用開始日を含む設定の取り扱い設定だけでは防げない条件文だらけのView SoRとSoAの特性の違うデータモデルの取り扱い。組織内での設定の共有と分割。逆コンウェイの法則はつかえる。ドメイン駆動設計をはじめよう(2024) データモデリングでドメインを駆動する(2024) 話せなかったこと参考文献

Slide 42

Slide 42 text

内製システム開発の楽しさ。・ユーザーがとても近い。・フルサイクルの開発ができる。・企画・開発・インフラ・保守サポートまで。・自由度が高い動的な開発。さいごに

Slide 43

Slide 43 text

Railsだからできる例外業務に禍根を残さない設定設計パターンご清聴ありがとうございました。