01. MiniBank v1では何を作ったのか | ミニバンクの作り方

まずは「銀行らしく見える画面」の裏に、どんな仕組みが必要だったのかを見渡します。

このページでわかること

MiniBank v1は、口座を作り、円の残高を見て、別の口座へ送金できる学習用システムです。画面だけでなく、本人確認、権限、取引履歴、帳簿、監査まで含めて作られています。

実際のお金や銀行ネットワークには接続しません。だからこそ、システム開発の要点を一つの題材で追えます。

利用者はログインし、本人確認を申請し、口座を開設します。残高と履歴を見たり、送金したりできます。管理者は本人確認の承認、口座の凍結、監査ログや帳簿の確認を担当します。

同じデータを扱っていても、操作できる範囲を分けることが大切です。利用者が自分で本人確認を承認できてしまっては、仕組みの意味がありません。

「画面に見えること」「裏側の処理」「残る記録」の三つを毎回確認します。たとえば送金では、ボタンを押す画面、送金を確定する処理、取引と帳簿の記録が対応します。

以後の記事は、この三つのつながりを少しずつ拡大して読みます。

v1は学習用です。実際の銀行接続、全銀・SWIFT、カード決済、融資、為替、本番の規制対応は対象外です。画面に一部の将来機能が見えても、稼働する機能とは区別して読みます。

「口座を作れる」という一行だけでは、本人確認の前後で何ができるか決まりません。v1では顧客が本人確認を申請し、管理者が審査し、確認済みになってから口座開設や送金へ進む流れを持ちます。画面、API、データベースの状態が同じ順番を守る必要があります。

要件を読むときは「誰が、どの状態で、何を実行し、その結果どの記録が残るか」まで書き下してみます。これが後のテスト項目にもなります。

たとえば口座を開く前には、ログインした顧客が誰か、本人確認が承認済みかを確かめます。実行中には同じ顧客の口座を重複して作らないようにし、実行後には口座番号と状態を保存します。「作成ボタンが押せた」だけを完成条件にすると、こうした約束が抜けます。

送金も同様です。前には権限・口座状態・残高、途中には同時実行と一括更新、後には履歴・帳簿・監査が必要です。画面の数ではなく、一件の操作を最後まで説明できるかで機能の完成度を見ます。

顧客Aが送金したとき、顧客Aには支払った金額と送金先が見えます。顧客Bには受け取った履歴が見えます。管理者には操作を調査するための記録が見えます。三者が同じ取引を見ても、公開してよい情報は同じではありません。

したがって画面を作る順番だけでなく、データを誰に見せるか、誰が状態を変えられるかを要件として決めます。これは後からセキュリティ設定だけで補うより、最初に設計した方が分かりやすくなります。

v1の本人確認は外部の本人確認サービスへ接続しません。管理者の審査という流れを学べますが、本人の実在確認や証憑の管理を実現したことにはなりません。内部送金は学べますが、他行への送金には相手システムから遅れて届く結果や失敗を扱う必要があります。

この違いを把握すると、v1を過小評価せず、同時に実際の銀行システムと混同せずに学べます。

各章では「入力は何か」「判断する場所はどこか」「失敗したら何が残るか」「成功を何で確認するか」を問いにします。答えを本文でつかんだら、末尾のファイルで対応する名前を探してください。

全部のコードを一度に読む必要はありません。ひとつの操作について、画面の言葉とデータベースの記録が結びつけば、次の機能にも同じ読み方を使えます。

v1には多くの画面がありますが、基礎となる約束は少数です。顧客は他人の口座を操作できない。金額は円整数で扱う。お金が動けば帳簿に残る。送金は一回の依頼で一回だけ成立する。この約束を先に書くと、機能の優先順位を決めやすくなります。

たとえば通知は便利ですが、通知が先に完成しても帳簿が不正確なら銀行システムとしての核は未完成です。機能数より、主要な約束が一件の操作を通して守られるかを優先します。

顧客と口座の表がなければ送金元を特定できません。帳簿の構造がなければ安全な送金を記録できません。送金ができてから、その失敗条件、監査、管理画面、照合を重ねます。依存関係を無視して画面だけ先に増やすと、後からデータの意味を変える修正が広がります。

この順番を意識してv1のマイグレーションと画面を見比べると、「なぜこの機能が先だったか」が読み取れます。