v1からv20へ：小さな銀行を通じて身につく見方
機能の数より、正しさ・運用・説明責任のつながりが大切。別のシステムにも持ち帰れる設計の考え方を整理する。
本文の説明・図・掲載コードだけで読み進められます。出典リンクは、権限のある人向け（非公開GitHub）です。GitHubで閲覧権限がある方だけ開けます。
この記事でわかること
- 正しい数字、異常から戻れる運用、後から説明できる記録を一緒に考える
- 状態・権限・時間・版を分けると、複雑な業務を読める
- 模型の限界と確認した証拠を、成果と同じくらい明確にする
この記事の目次
1. 機能が増えた歴史を、三つの問いに読み替える
v1の小さな銀行からv20のDigital Twinまでを読むと、関心は画面の操作から、業務全体のつながりへ広がります。残高が見えること、振込ができることだけでなく、二重にならないか、途中で止まったらどうするか、誰の判断だったか、どの前提で未来を計算したかが問われるようになります。
この変化を三つの視点にまとめられます。一つ目は正しさ。金額と状態が守るべき規則に従うか。二つ目は運用。失敗を見つけ、担当者が安全に次の行動を選べるか。三つ目は説明責任。どの事実と権限と判断から結果が生じたかを、後からたどれるかです。
たとえば融資の返済で、借貸が一致しても二重引落しなら正しくありません。画面が失敗と表示されても、実際には確定済みかもしれません。返金できても、理由と元の返済との関係がなければ説明に困ります。三つは別々の追加機能ではなく、一件の業務に同時に必要な見方です。
2. 「借方と貸方が合う」は、正しさの一部分
複式簿記の借貸一致は強力ですが、それだけで業務の正しさは決まりません。架空の花さんが1万円を一度だけ送るつもりだったのに、同じ内容を二度記帳すれば、二つの仕訳はそれぞれ借貸が一致し得ます。会計の形は正しくても、利用者の意図には反しています。
そこで、同じ操作を識別するキー、同じキーの内容照合、状態の前提条件、現在の権限の確認が必要になります。商品には契約時の金利、営業日、計算の丸めも加わります。正しさとは一つの数式ではなく、いくつかの守るべき規則が同時に成立することです。
さらに、正式な元帳と、素早い表示に使う残高、融資や定期預金の明細、総勘定元帳の集計が一致するかを別に確かめます。合計だけ一致していても、契約ごとの内訳が違うことはあります。v19では、基準銀行をグループへ読み出す接続口の一致も独立した検査になりました。数字を別の形へ変換する場所には、変換を確かめる責任が生まれます。
この見方は請求や在庫にも使えます。金額の合計や個数が合うだけでなく、「誰の、どの注文の、どの状態のものか」を保つ必要があります。
3. 結果不明を、失敗へ押し込めない
操作を「成功か失敗」の二つだけで表すと、通信が途中で切れた瞬間に困ります。依頼が届く前に切れたのか、確定した後に応答だけ消えたのか、画面側には区別できないからです。結果不明を一つの状態として認めることは、システムが弱いという告白ではなく、分かっている事実を正直に示す設計です。
v9の他行送金シミュレーターは、結果不明を自動再送せず、同じ支払IDで相手側の記録を照会します。v14の融資は操作キーで確定結果を探します。どちらも、反応がないから新しい操作を作るという近道を避けています。運用に必要なのは、赤いエラー表示だけでなく「次に何を確かめるか」です。
グループ内移動で片側だけ確定したときも、照合待ちという状態を残し、理由付きの再試行か逆仕訳で解消します。失敗を無理に隠すと、後から担当者が見ても何を戻せばよいか分かりません。停止できること、照会できること、安全に再開できることが、日常の業務を続けられる条件になります。
ただし、安全側に止まる設計には代償があります。必要な権限の人がいない、照合の差が消えないときには、業務を再開できません。その待ち時間を誰が引き受けるかも、システムの仕様の一部です。
4. 後から分かるようにするなら、上書きより追加する
価格改定のたびに金利設定を上書きすると、昔の契約が何を約束していたか分からなくなります。誤った仕訳を削除すると、なぜ残高が変わったかの経緯が消えます。MiniBankでは商品条件の版、契約時の写し、元の記録に結びつく訂正という形で、過去を説明できる材料を残します。
承認も「承認済み」という一語では足りません。誰が提案し、誰が決裁したか、実行時にもその権限が有効かを分けます。v14の融資実行は、過去の承認に頼り切らず現在の権限を再確認します。v18やv20のモデルも、別の管理責任者が仮定の版を承認します。計算結果を管理する前に、計算の前提を誰が引き受けたかを残すのです。
一方、記録を増やせばすべて解決するわけではありません。読む順序や元の業務との結び付きがなければ、ログはただの大量の文字になります。金融の履歴と、見積り、試算、通知、担当者の判断は性質が違います。何の根拠になる記録かを分けて残すことで、必要なときに説明へ組み立てられます。
5. 「いつの正しさか」を忘れない
今日の残高が正しくても、古いバックアップから復元した今日の残高は、失われた取引を含まないかもしれません。説明用に、午前の預金10万円が午後に11万円へ増えた後、午前の状態へ戻したとします。復元後の元帳も借貸は合い、内部の残高計算も10万円で一致し得ます。しかし午後の1万円が消えたことは、復元先の中だけを見ても分かりません。
v17が外に控えた比較基準を要求するのはこのためです。復元先で新しく作った確認値を復元先自身と比べても、古い状態の自己一致にしかなりません。復旧とは、データを読み込めたことに加えて、どの時点までの事実を戻せたか、どの権限や状態が巻き戻ったかを確かめる業務です。
時間は利息にも影響します。融資の約定日は論理上の営業日で扱い、別の処理には実時刻の日本時間の暦日が使われます。v18・v20は入力を凍結して再現性を高めますが、材料がもともと異なる時計に従っているという限界は消しません。時点、期間、日付の意味をラベルに残すことは、表示の飾りではなく計算条件の説明です。
復旧の技術的な所要時間も、将来の復旧保証ではありません。測った機械、データ量、手順、人の待ち時間を含むかどうかが変われば値は変わります。
6. 模型は、事実を増やすのでなく問いを増やす
v13の資金繰り、v18のリスク、v20のDigital Twinへ進むと、実績から計算した値が増えていきます。ここで大事なのは、計算結果の精密さを、現実の確かさと取り違えないことです。円単位まで表示できても、預金がどのくらい動くかという仮定が架空なら、将来の利益をその精度で知っているわけではありません。
v20は同じ事実、同じモデル、同じシードで再現できるようにし、別条件を比較します。得られるのは「この仮定ならこの経路で変わる」という説明です。預金金利を抑えれば費用は減るが、預金流出で借入が増え、その利息が次の月へ響く。このような複数の力を考えるために役立ちます。
限界を列挙することも模型の説明です。定期預金の元本を固定する、借入を返済しない、延滞の遷移を動かさない、といった簡略が結論にどう影響するかを読む必要があります。実績と予測のラベルを分け、予測を正式な元帳へ書かないのは、現実の事実と説明の道具を混ぜないためです。
7. 次のシステムでも使える、四つの読み方
この学習を別の業務へ持ち帰るなら、最初に「何が正本か」を探します。画面に表示する値、業務の明細、正式な履歴のどれを基準にするかが曖昧だと、不一致が起きても直す向きが決まりません。次に「どこまでを一度に確定するか」を探します。同じ処理内でそろえる範囲と、相手を待つ範囲を分けます。
三つ目に「誰が、いつ、何を許されるか」を読みます。ログインだけでなく所有者、役割、同意、承認、有効期限まで確認します。四つ目に「失敗のあと何が残るか」を見ます。結果不明の照会先、訂正元との関係、復旧の基準、欠測の説明があれば、正常時の画面だけでは分からない設計の強さが見えてきます。
確認した証拠の範囲も分けます。仕様を読んだこと、ソースを読んだこと、隔離環境で動かした記録、現在の公開環境で確かめたことは、それぞれ別です。過去の開発資料の「未公開」を現在へ持ち越すのも、過去の試験合格を現在の運用保証へ広げるのも適切ではありません。本教材は固定コミットを根拠とする読み物で、実銀行・実決済ネットワーク・市場予測の能力を主張しません。
v1からv20を学ぶ到達点は、すべての関数名を覚えることではありません。一つの数字を見たときに、その事実、条件、時点、権限、失敗時の扱いまで問い直せるようになることです。
出典と、確認できた範囲
以下のリンクは非公開GitHubへの出典で、閲覧権限が必要です。本文はリンク先を開かなくても読める構成です。固定コード・設計資料を参照していますが、今回、この読み物のために銀行の取引やDB操作、本番試験は実行していません。実装や資料にある検査と、こちらで実施した検証を混同しないようにしています。
- 融資の確定規則 ↗（非公開GitHub・要権限）
正しさ、冪等性、現在権限、訂正、契約単位の照合 - 預金価格の版管理 ↗（非公開GitHub・要権限）
過去の約束を固定する設計 - 他行送金の結果不明 ↗（非公開GitHub・要権限）
応答なしと失敗を分ける運用 - 復旧の契約 ↗（非公開GitHub・要権限）
外部の証拠、再開、測定と保証の違い - リスク測定の契約 ↗（非公開GitHub・要権限）
凍結した入力と時計の限界 - グループの契約 ↗（非公開GitHub・要権限）
接続口の照合と片側確定の扱い - Digital Twinの契約 ↗（非公開GitHub・要権限）
再現性、仮定、権限、実績との分離
MiniBankは学習・検証用の銀行アプリです。架空の金額や人物は、仕組みを説明するための例です。
つながる読み物
ここまで読んだ記録を、ひとつ。
自分のペースで。あとから取り消すこともできます。