エンタープライズアプリケーション
組織全体を支えるシステム
実際に何が違うのか
システムとウェブサイトを分ける6つのこと
役割は多く、事実は一つ
支店長、経理担当、地域責任者、監査人は、同じ記録をそれぞれ違う見え方で必要とします。そして誰も、見るべきでないものを黙って見られてはいけません。役割ごとのアクセス権は画面の中に隠すのではなく、データの層で設計します。ボタンを表示しないだけの画面は、アクセス制御とは言えないからです。
意味のある承認
代理承認やエスカレーションを含む多段階の承認フローと、誰がどの版の何を承認したかを時刻つきで残す記録。争いになったときに効いてくるのは、この「版」の部分です。承認後に書き換えられた文書についた承認は、承認とは言えません。
説明責任を果たせる監査ログ
すべての変更を上書きではなく、出来事として記録します。変更前の値、変更後の値、誰が、いつ、なぜ。何か月もあとでも経緯を再現できること。それが唯一意味のある基準であり、金融や規制対象の業務がそもそもこのシステムで回せる理由です。
帳尻の合うお金
集金、精算、返金、送金、そして月末に銀行明細と一致しなければならない元帳。連携そのものは簡単な半分です。こうしたプロジェクトが実際につまずくのは、照合と失敗時の処理です。
相手側の不調にも耐える連携
決済ゲートウェイ、会計ソフト、行政ポータル、物流、メッセージング。相手のシステムは遅く、タイムアウトし、ときには二重に応答するという前提で作ります。再試行で顧客に二重請求が起きることはありません。
業務を止めない移行
スプレッドシートや手に余るようになったソフトウェアからの移行は、新しいシステムが確かだとわかるまで両方を並行して動かします。後戻りできない週末の一斉切り替えは、日曜の夜に誰かに迫ってよい決断ではありません。
進め方
6つのフェーズ。最初はコードではありません
実際に起きていることを調べる
文書に書かれた業務ではなく、抜け道も含めて実際に行われている業務を見ます。その抜け道こそが要件です。それを無視したシステムの横で、社員はこっそりスプレッドシートを使い続けることになります。
アーキテクチャと、書面で残す意思決定の記録
構成、データモデル、外部連携、トレードオフを、その理由とともに書き残します。2年後に誰かが、推測で判断を覆すのではなく、なぜその選択をしたのかを確かめられるようにするためです。
使える単位で作る
18か月かけて作り最後にお披露目するのではなく、一つの部署、一つの拠点ずつ、実際に使える状態で稼働させます。2つ目を書いているあいだに、1つ目はもう本番で動いています。
移行し、並行稼働させる
過去のデータを移し、目視ではなく照合で正しさを確かめます。数字が1サイクル分すべて一致するまで、両方のシステムを動かします。
使う人たちをトレーニングする
自分たちのデータで、自分たちの拠点で。こうしたプロジェクトの多くは定着の段階で失敗し、しかも静かに失敗します。ソフトウェアは動いているのに、誰も使っていないのです。
運用する
監視、実際に復元して確かめたバックアップ、障害時の連絡体制、四半期ごとに見直すロードマップ。ローンチ後に誰も責任を持たないシステムは、誰が手を加えなくても劣化していきます。
技術スタック
確かめられるよう、名前を挙げます
プロダクト
- Next.js
- React
- TypeScript
- Tailwind CSS
- React Native
- Expo
バックエンド
- NestJS
- Node.js
- PostgreSQL
- Prisma
- Redis
- WebSockets
クラウド
- Vercel
- Render
- Cloudflare
- Docker
- オブジェクトストレージ
- CDN
決済
- Razorpay
- Stripe
- Cashfree
- UPI
- 送金
- サブスクリプション
AI
- Google Gemini
- Claude
- 画像認識
- 音声
- 埋め込み
- エージェント
グロース
- テクニカルSEO
- Meta Ads
- Google Ads
- WhatsApp Business
- メール
- アナリティクス
お持ちいただきたいのは仕様書ではなく、業務そのものです。
最初の打ち合わせでいちばん役に立つのは、ふだんの火曜日にチームが何をしているかを一緒にたどることです。仕様書はそこから生まれます。書くのは私たちで、お客様ではありません。