「上限を変える」から、変更の地図を描く
数字一つの変更が、入力・権限・実行・契約・試験へどう広がるか。振込上限、預金の価格、模型の仮定という三種類を見比べます。
本文の説明・図・掲載コードだけで読み進められます。出典リンクは、権限のある人向け（非公開GitHub）です。GitHubで閲覧権限がある方だけ開けます。
この記事でわかること
- まず対象・時点・既存依頼への扱いを日本語で固定する
- データの形を変える変更と、既存の版管理で足りる変更を分ける
- 否定例と不書込みの確認まで、影響範囲の見積りに含める
この記事の目次
最初の成果物は、変更する数字ではなく約束
架空の相談として「個人の1回の振込上限を50万円から60万円へ上げたい。1日の上限100万円は維持したい」を考えます。これは変更を実行する提案ではなく、影響を読むための例です。コードを探す前に、個人か法人か、内部振込か他行送金か、いつから有効か、受付済みの依頼へどう適用するかを言葉でそろえる必要があります。
現行の個人のSQL経路では、受付時に50万円を超える依頼を拒否し、実行時にも1回50万円・日本時間の1日100万円を確認します。限度額の読取り関数も同じ数値を返します。したがって「50万円を一か所だけ60万円にする」では、受付・確定・表示が別の約束をするおそれがあります。
逆に、画面の説明だけを変更したいなら金融の上限まで変える理由はありません。何を変え、何を保つかを最初に決めることで、変更を必要以上に広げずに済みます。見積りの単位も「ファイル何行」より「どの約束を変え、その証拠をどこで確認するか」が役立ちます。
画面からデータベースまで、条件の置き場所を分ける
入力のスキーマは、受け付ける項目とその形の約束です。現行の振込依頼は7桁の口座番号、金額、依頼人名、メモなどを受け付け、送金元の持ち主や確定状態を利用者に自由入力させません。金額は正の整数の文字列として受け取り、計算機で正確に表せる上限も確かめます。これは業務上の50万円という上限とは別の制約です。
50万円を60万円へ変えるだけなら、金額を小数や一般の数値へ変える必要はありません。文字列の意味、整数円、本人から送金元を導く境界は維持します。スキーマに新しい「上限」項目を足して利用者が指定できるようにすれば、上限を守るはずの側へ決定権を渡しかねません。
サービスには legacy と Java の処理先の分岐があります。影響調査では入口の受付と確定、限度額の読取り、その値を使う画面、各処理経路の契約を追います。今回読んだSQL経路だけを直せばすべての構成で一致するとは言えません。稼働中の処理先は未確認なので、配備構成を確かめる作業も見積りから落とせません。
列を増やす前に、誰が決める値なのかを考える
現在の個人上限を固定値のまま変える案なら、上限専用の新しい表や列が必須とは限りません。ただし受付・確定・読取りへ散らばった条件の整合が必要です。一方「顧客別の上限を管理画面で変更する」という要望なら、対象者、提案値、適用時刻、変更者、承認状態、履歴を持つ設計へ話が広がります。これは同じ数値変更に見えても、見積りの大きさが違います。
その場合に考えるべきは、表だけではありません。誰が提案し、誰が承認し、本人は何を読めるか。直接更新の権限をどう閉じ、許可した入口の内側で所有者と役割をどう確認するか。変更途中の停止や復旧で、どの版が有効なのかをどう説明するか。これらは新しい仕様の検討事項であり、現行の個人上限に既に承認画面があるという意味ではありません。
確定時の検査を画面側へ移すのは、簡単に見えて安全性を弱めます。日次上限は口座ロックを取った後に当日の成立済み金額を集計します。別件が先に成立した分も反映する必要があるからです。上限を変更するときも、この順序と、重複再送を新しい利用額へ数えない意味を保つ必要があります。
金利変更は、既存契約を書き換える話ではない
次に、架空の12か月定期の新規金利を0.80%から1.20%へ変える相談を考えます。MiniBankには pricing.product_versions という価格の版があるため、既存の型と範囲内の変更なら、計算式や表の構造を変えるより、新しい版を提案して承認する業務として扱えます。1bpは0.01パーセントポイントなので、80bpから120bpへの変更です。
提案には将来の営業上の適用日が必要で、承認するのは提案者とは別の管理責任者です。決裁済みの版は書き換えず、後から何を約束したかを残します。顧客が見積りを受け取り、そこから契約を作る際には、見積りの所有者、使用済みか、有効期限、いま有効な価格の版かを確認します。
葵さんが旧版で既に作った契約の金利は、その契約の写しとして保持されます。新金利は既存契約を遡って上書きしません。一方、旧版の見積りを受け取っただけで契約前だった蓮さんは、新版が有効になった後にその見積りを使うと拒否され、新しい見積りが必要になります。この違いを見落とすと、「新規だけ変更」のはずが過去の約束まで変わってしまいます。
根拠：価格の型、決裁後の不変性、契約の写し ↗（非公開GitHub・要権限）
模型の仮定変更は、実績へ届かせない
「金利が上がったとき、預金金利へ伝える割合を0.3から0.4へ変えてみたい」は、さらに別の変更です。v20のデジタルツインでは、これは架空の模型のパラメータの版に属します。現実の顧客金利や振込限度額を変更する指示ではありません。模型は凍結した実績、シナリオ、モデルの版、シード値から計算し、正式な元帳へは記帳しません。
既存の9項目の範囲内で仮定を変えるなら、新しいモデル版の提案・別の管理責任者による決裁という流れが用意されています。余分な項目や型違い、範囲外の値を足すことは拒否されます。もし10番目の仮定や新しい数式が欲しいなら、型検証、説明する数式、入力の収集、出力、再現用の版、独立の検算まで変更範囲が広がります。
比較条件にも注意が要ります。標準の比較は、同じ基準・モデル版・シード値の実行どうしに限定されています。モデル版を変えた二つをそのまま既存の比較機能へ渡せるとは限りません。どの要因の差を測りたいのかを明示し、模型の数値が変わることと、その仮定が現実に正しいことを混同しない読み方が必要です。
根拠：模型の入力、権限、比較と限界 ↗（非公開GitHub・要権限）
変更の見積りには、拒否すべき具体例も入れる
振込の仮の新上限60万円なら、59万9,999円、60万円、60万1円という境界を、受付と確定の両方で考えます。ただし60万円以下でも、その日の使用済み額と合わせて100万円を超えれば成立してはいけません。当日既に40万円を使っている場合の60万円と60万1円、同時に二件が上限を取り合う場合、同じ成立済み依頼を再送した場合を分けます。これらは変更後に必要となる試験の提案で、現在すでに新上限を試した結果ではありません。
価格変更なら、適用前後の新規契約、既存契約の不変、期限切れ・旧版・他人・使用済みの見積り、自己承認の拒否を確認します。模型変更なら、同じ入力の再現、計算上の恒等式、必要入力がないときの拒否、実績の表が実行前後で変わらないことを確認します。正常な結果のスクリーンショットだけでは足りません。
権限のない経路から回避できないかも、型と数値の試験とは別の仕事です。業務規則のSQL試験で認証済みfixtureを使うなら、本物の認証経路の確認を済ませた扱いにはしません。影響範囲を小さく見積もるために必要な試験を省くより、未実行の範囲を分けて提示する方が、次の判断に使える見積りになります。
実装の読み方：変更後の約束を短く書く
以下は仮の上限変更に対する受入条件の例です。現行コードの抜粋でも、実行済みの結果でもありません。
1回上限 = 600,000円（変更案）
日次上限 = 1,000,000円（維持案）
同じ依頼の再送 → 使用額を追加しない
別件の同時送信 → ロック後の合計で判断
受付と確定と上限読取り → 同じ約束
拒否された取引 → 金額の部分更新を残さない根拠：現行の上限・競合・再送を検査する試験 ↗（非公開GitHub・要権限）
変更後を判断する証拠までが、ひとまとまり
最後に、コードを編集した状態と、目的の環境で変更が有効になった状態を分けます。影響メモには、対象の約束、触る入口と保存先、権限、既存データへの扱い、実行する検査、配備後に確かめる読み取り、問題時の戻し方を並べます。この記事ではその地図を描いているだけで、銀行コード・DB・認証設定を変更していません。
戻し方も「前のファイルへ戻す」だけでは足りません。新しい価格で作った契約が既にあるなら、過去の契約を消してなかったことにはできません。新しいモデル版やシナリオは業務設定で、v20の最終的な復旧用の要約にはその行の内容が含まれます。一方、診断の記録であるベースラインと実行結果はそこに含まれません。設定と観測の保存範囲が違うため、変更の種類ごとに復旧の証拠も変わります。
短い数字変更でも、入口と実行の整合、時間、既存契約、権限、復旧という観点を通すと、必要な仕事を見落としにくくなります。工数の時間数を断定するには、実際の配備構成と変更方針、利用できる試験環境が必要です。固定ソースを読む段階では、「何を確認できたら完了と言えるか」を具体的に示すことが、最も確かな見積りの出発点です。
出典と、確認できた範囲
以下のリンクは非公開GitHubへの出典で、閲覧権限が必要です。本文はリンク先を開かなくても読める構成です。固定コード・設計資料を参照していますが、今回、この読み物のために銀行の取引やDB操作、本番試験は実行していません。実装や資料にある検査と、こちらで実施した検証を混同しないようにしています。
- 個人振込の受付上限 ↗（非公開GitHub・要権限）
依頼の受付にある上限と同一依頼の内容確認 - 個人振込の実行上限 ↗（非公開GitHub・要権限）
口座ロック後に判定する1回・日次・頻度上限 - 限度額の表示用契約 ↗（非公開GitHub・要権限）
実行だけではなく読み取りの返却値にも条件がある - 振込入力の境界 ↗（非公開GitHub・要権限）
顧客が指定できる項目を限定する - 価格の版管理 ↗（非公開GitHub・要権限）
将来適用、独立承認、見積り、契約の固定条件 - 価格変更の試験 ↗（非公開GitHub・要権限）
既存契約と新規条件を分離する検査 - 模型の契約と保存範囲 ↗（非公開GitHub・要権限）
試算を実績から分離し、版・比較・復旧対象を定義 - 最終復旧要約の設定ハッシュ ↗（非公開GitHub・要権限）
モデル・シナリオを対象にする最終コード
MiniBankは学習・検証用の銀行アプリです。架空の金額や人物は、仕組みを説明するための例です。
つながる読み物
ここまで読んだ記録を、ひとつ。
自分のペースで。あとから取り消すこともできます。