システム開発の全体像

最初に：システム開発は、コードを書くことだけではない

システム開発は、困りごとを見つけ、解決条件を合意し、仕組みを設計し、実装と検証を行い、本番で価値を出し続ける活動です。完成品を納めた瞬間より、その後に安全・安定して使える期間の方が長いことも珍しくありません。

各工程は一度通って終わりではありません。運用で得た利用者の声、障害、法改正、利用量の変化を次の要件へ戻す循環です。

1. 01企画・構想：なぜ必要か
2. 02要件定義：何を満たすか
3. 03設計：どう分け、どう動かすか
4. 04実装：設計を動く形にする
5. 05テスト：期待と危険を確かめる
6. 06リリース：利用可能な場所へ届ける
7. 07運用保守：見守り、直し、改善する
8. 08刷新・廃止：安全に次へ移す

全工程を、1つの表でつかむ

要件定義：希望を、判断できる条件へ変える

『便利な振込を作る』は希望であり、そのままでは完成を判定できません。誰が、何を、どの条件ででき、失敗時にどうなり、どの速さ・安全性が必要かまで具体化します。

要件には、できることを表す機能要件と、速さ・安全性・稼働率・復旧・監査・保守性を表す非機能要件があります。対象外も書くことで、無限に範囲が広がるscope creepを防ぎます。

設計：作る前に、責任と失敗の扱いを決める

設計は図を描くこと自体ではなく、選択肢から方針を決め、その理由とtrade-offを残すことです。どこで本人確認するか、正式な残高は何か、途中失敗をどう戻すか、誰が運用するかを決めます。

図面の使い分け：1枚ですべてを説明しない

シーケンス図：振込1件を時間順に読む

sequence図は、横に登場人物、縦に時間を置きます。上から下へ読み、矢印で依頼と返答を追います。正常時だけでなく、認証失敗、残高不足、DB失敗、timeout後の再送も分岐として描くと、責任の空白が見つかります。

• 矢印の出発点は責任を持ってrequestする側
• DBへ到達する前後で、入力・本人・権限を再確認する
• timeoutは失敗確定とは限らないため、再送時の冪等性を設計する
• 途中のどこで失敗しても片側だけ確定しないtransaction境界を示す

顧客 → 振込画面 : 送金先・金額を入力
振込画面 → Next.js API : token + idempotency key + 金額
Next.js API → Supabase Auth : tokenを検証
Next.js API → 選択backend → PostgreSQL RPC : request_transfer()で依頼保存、confirm_transfer_otp()でコード確認、内部execute_transfer()
PostgreSQL RPC → PostgreSQL RPC : 権限・状態・残高を確認し口座をlock
PostgreSQL RPC → Ledger : 借方と貸方を同じtransactionで記帳
Ledger → Audit : actorと結果を追記
PostgreSQL RPC → Next.js API : 成功または安全なerror
Next.js API → 振込画面 : 結果を表示

実装：コードを書いた後に、完成へ近づける

実装では、設計をcode、DB migration、設定、test codeとして具体化します。ただ動くことは出発点です。小さな変更、peer review、型検査、静的解析、自動test、設計との照合を通して、他の人が安全に変更できる状態へ近づけます。

1. 01小さな作業単位と完了条件を決める
2. 02branchでcode・test・migrationを変更
3. 03手元で型検査・lint・testを実行
4. 04Pull Requestで意図・risk・戻し方をreview
5. 05自動検査を通し、承認後にmerge
6. 06release後の指標とerrorを確認

テスト：正解だけでなく、壊れ方を確かめる

ウォーターフォール：段階と合意点を明確にする

ウォーターフォールは、要件・設計・実装・test・導入を大きな段階として計画し、成果物を確認して次へ進む方法です。変更禁止という意味ではありませんが、後工程の変更ほど影響確認と合意に費用がかかります。

規制、契約、予算、hardware、外部組織との接続など、先に確定すべき条件が多い案件で管理しやすい一方、利用者が実物を見る時期が遅いと、誤解の発見も遅れます。

アジャイル：小さく作り、早く学ぶ

アジャイルは、利用者に価値のある小さな単位を短い周期で作り、動くものへのfeedbackから優先順位や設計を更新する考え方です。ScrumやKanbanはその実践方法の例です。

計画や文書が不要という意味ではありません。重要な不変条件、architecture、security、法令、運用は先に扱い、変化する部分は小さな反復で学びます。

1. 01Product goalと優先順位を決める
2. 02Backlogから小さな価値を選ぶ
3. 03設計・実装・testを短い周期で完了
4. 04利用者と動く結果をreview
5. 05改善点とriskをbacklogへ戻す
6. 06次の周期で優先順位を更新

ウォーターフォールとアジャイルを比較する

現実の金融・enterprise開発では、全体予算、法令、data migration、release判定は段階的に管理し、各機能の画面や業務改善は反復して作るhybridも一般的です。名前より、変更をどう判断し品質をどう守るかが重要です。

RFP：同じ土俵で提案を依頼する

RFP（Request for Proposal）は、発注側が候補vendorへ提案を求める文書です。単なる見積依頼ではなく、背景・目的・範囲・条件・評価方法を共有し、各社の解決方法、体制、費用、riskを比較します。RFPだけで詳細要件がすべて完成するわけではありません。

ライブラリ、フレームワーク、runtimeを区別する

境界は製品の説明によって重なることもあります。大切なのは分類暗記ではなく、誰が実行順を決め、どのversionへ依存し、更新時に何をtestするかです。

開発環境とインフラ環境：『手元で動く』を本番へ運ぶ

開発環境は、開発者がcodeを書き、実行し、testする場所です。インフラ環境は、利用者へserviceを届けるための計算資源、network、DB、domain、証明書、権限、秘密、監視などの土台です。

• 環境ごとにDB、credential、domain、外部連携先を分離する
• 秘密情報はGitへ入れず、secret管理から実行時に渡す
• Infrastructure as Codeでnetworkやservice設定をreview可能にする
• 本番変更は人の手順だけでなく、自動化・承認・監査を組み合わせる

Dockerとcontainer：持ち運べる実行単位

Dockerはcontainerを作成・配布・実行するための代表的なplatformです。Dockerfileというrecipeからimageを作り、そのimageからcontainerという実行中のinstanceを起動します。registryはimageを保管・配布する倉庫です。

containerは一般に仮想machineより軽量ですが、完全なmachineでも、自動的なsecurity境界でもありません。containerを消すと内部の書込みも失う可能性があるため、永続dataはvolumeや外部DBへ分離します。

CI/CD：変更を、同じ検査と手順で届ける

CI（Continuous Integration）は変更を頻繁に共有し、自動build・test・解析で統合問題を早く見つける活動です。CDは検査済み成果物を安全に配布できる状態へ保つContinuous Delivery、または本番まで自動反映するContinuous Deploymentを指します。どちらかは組織ごとに明示します。

1. 01Gitへ小さな変更をpush
2. 02依存関係を固定しbuild
3. 03型・lint・unit・integration test
4. 04SAST・SCA・secret・設定scan
5. 05同一artifactをstagingへdeploy
6. 06受入・承認・migration安全性を確認
7. 07段階的にproductionへrelease
8. 08SLI・error・照合を監視し必要ならrollback

脆弱性診断：攻撃者の入口を、複数の方法で探す

脆弱性診断は、1つのtool名ではありません。設計前のthreat modeling、source codeを調べるSAST、依存packageを調べるSCA、動作中のapplicationへrequestするDAST、設定・secret・container imageのscan、専門家によるpenetration testを組み合わせます。

自動scanには誤検知と見逃しがあります。結果は業務影響、攻撃条件、権限、data、修正期限で優先順位を付け、修正後に再testします。

監視と可観測性：信用を、運用中の数字で守る

監視は、あらかじめ重要と分かっている状態を継続確認する活動です。可観測性は、未知の問題でもmetrics、logs、tracesなどから内部状態を調べられる性質です。dashboardを置くだけでは運用にならず、alertを受ける人、判断基準、runbook、連絡先、復旧権限が必要です。

バージョン管理とGit：変更の履歴を共同で扱う

version管理は、fileの変更を時間とともに記録し、過去の状態を比較・復元できるようにします。Gitではworking treeで編集し、stageで次の記録候補を選び、commitで意味のあるsnapshotとして残します。branchで作業を分け、Pull Requestでreviewし、mergeで共有します。

リリース、運用、保守：作った後が信用の本番

deployは新しいcodeを実行環境へ置く技術操作、releaseは利用者へ機能を有効化する業務判断です。段階releaseやfeature flagを使えば、配備してもまだ全員へ見せない運用ができます。

保守には不具合修正だけでなく、依存部品の更新、法改正、性能改善、権限棚卸し、backup復元訓練、文書とrunbook更新が含まれます。softwareとcloud serviceのsupport終了日も管理します。

1. 01変更内容・影響・戻し方を確認
2. 02同じartifactを環境間で昇格
3. 03DB migrationの互換性とlockを確認
4. 04限定範囲へrelease
5. 05技術指標・業務指標・照合を監視
6. 06問題なら停止・rollback・reversal等で影響を封じる
7. 07postmortemから要件とbacklogを更新

Minibankへ当てはめる：あるものと、これから学ぶもの

非エンジニア向け：会議で確認する10の質問

• 誰のどの問題を解決し、成功を何で測りますか？
• 対象範囲と、今回作らないものは何ですか？
• 正常時だけでなく、失敗・再送・同時実行時はどうなりますか？
• 正式なdataはどこにあり、誰が変更できますか？
• この図はどの範囲を示し、何を省略していますか？
• 完成条件にはsecurity、性能、復旧、運用が含まれていますか？
• 開発・test・staging・本番のdataと秘密は分離されていますか？
• 変更は誰がreviewし、どの自動testを通り、どう戻せますか？
• 異常を誰が何分で知り、どの手順と権限で対応しますか？
• vendorや技術を終了・移行するとき、dataと業務を取り出せますか？