開発について相談する
← Case Studies

CASE STUDY

業務システム（API・DB・管理画面）

不動産仕入れ判定、LINE配信基盤など、判断・処理・記録をひとつのシステムにまとめる。

PROBLEM

課題

仕入れ判断や顧客配信のような業務は、調査・計算・配信・記録がそれぞれ別のツールや個人の作業に分散しがちです。判断の根拠や配信状態が残らず、担当者が変わると再現できなくなります。

BEFORE

従来のフロー

  1. 01必要な情報を複数の窓口・ツールで別々に調べる
  2. 02表計算ソフトで独自に計算・集計する
  3. 03判断や作業内容が個人のメモやメールに残る
  4. 04実行結果（配信・処理）の状態を手動で確認する
  5. 05資料化・報告のたびに情報をかき集め直す

DESIGN PRINCIPLES

設計方針

外部データと業務ロジックを分離する

公的データ・外部APIの取得と、自社の判断ロジック（財務判定・配信ルール等）を別レイヤーとして設計し、どちらか一方の変更が他方に波及しないようにします。

処理と記録を同じ場所に残す

計算結果・配信結果を都度データベースへ記録し、後から同じ根拠を再現できるようにします。

実行主体（Worker・バッチ）を分離する

即時応答が必要な画面操作と、時間のかかる処理（配信・再計算）を分離し、失敗時の再試行や状態確認をしやすくします。

ARCHITECTURE

システム構成

  1. 01入力・検索画面（管理画面）
  2. 02外部API連携（公的データ・通知チャネル等）
  3. 03業務ロジック（判定・シナリオ計算・配信ルール）
  4. 04データベース（履歴・監査ログを含む）
  5. 05非同期処理（Worker・スケジュール実行）
  6. 06出力（帳票・ダッシュボード・配信履歴）

SCREENS

実画面

不動産仕入れ判定システムの実画面
不動産仕入れ判定システムの実画面
不動産仕入れ判定システムの実画面
LINE顧客配信プラットフォームの実画面
LINE顧客配信プラットフォームの実画面
LINE顧客配信プラットフォームの実画面

IMPLEMENTED FEATURES

実装機能

  • 案件入力フォーム
  • 外部データ調査（相場・規制・ハザード）
  • 3シナリオ収支シミュレーション
  • 財務判定ロジック
  • A4判断ブリーフ出力
  • 引受基準設定画面
  • PostgreSQL + PostGIS
  • 顧客(Contacts)管理
  • シナリオ・ステップ配信設計
  • 配信Worker（自動処理）
  • 配信履歴・イベント履歴
  • 外部イベント受信API（52ルート）
  • APIキー発行・管理
  • 管理者ログイン（開発用簡易トークン認証）

EXCEPTION HANDLING

例外・エラー対応

  • 参考データが不足する場合は無理に数値を出さず「算出不可」「データ不足」と明示する（不動産仕入れ判定システム）
  • 配信の試行回数・失敗理由をレコードとして保持し、再試行の判断材料にする（LINE顧客配信プラットフォーム）

CURRENT LIMITATIONS

現在の制限

  • 実ブラウザでの画面確認は本サイト制作時が初回（それまでは自動テストのみで検証）
  • 汎用的なCRUD管理画面ではなく、引受基準の設定画面のみ
  • 認証・マルチテナント機能は未実装
  • 市街化調整区域の判定ルールは未発火（データ未提供のため）
  • ローン費用計算は簡易化（複利・返済スケジュールなし）
  • 実LINE Messaging APIへの送信・Webhook受信は未接続（Mock Providerで検証）
  • Flex Message等の高度なメッセージ種別は未実装（テキストのみ）
  • 管理者認証は開発用の簡易トークン方式

BUILD THE NEXT ONE

この領域について、相談する。

開発について相談する