小さく始めることと、場当たり的に作ることは違います。画面や機能は変えられても、認証、データの責任範囲、外部連携の境界は、利用が始まってから変えるほど影響が大きくなります。
社内、顧客、取引先で、
入口を分けて考える。
社内だけが使う管理画面なのか、入居者や家主が使うマイページなのか、取引業者が使うアップローダーなのか。利用者によって認証方法、見せてよい情報、操作できる範囲が変わります。
SQairが開発した外部システムでは、Salesforceの顧客情報から起動し、ログイン中のユーザーや対象顧客を引き継ぐ設計もあります。別システムを追加しても、誰の操作か、どの顧客に対する処理かを失わないようにします。
同じ情報を二つの場所で、
正しくしようとしない。
Salesforce、会計、物件管理、外部サービスをつなぐときは、項目ごとにどのシステムを正とするかを決めます。顧客名はSalesforce、原本ファイルはS3、処理状態は外部システムというように、更新責任を明確にします。
例えば業者向けアップローダーはSalesforceの顧客情報から起動しますが、ファイル処理は別システムとして動きます。連携先へ全データを複製するのではなく、必要な識別情報だけを渡し、結果を元の顧客情報へ戻せるようにします。
「どこから取得するか」だけでなく、「どこだけが更新してよいか」を決める。
大きな原本と、
日常的に見る情報を分ける。
会議や商談の音声・全文データはS3へ保存し、Salesforceには議事録とサマリー、原本への参照先を持たせる構成を採用しています。担当者は普段の画面で要点を確認でき、必要なときだけ原本へ戻れます。
容量の大きなデータを業務システムへ詰め込まないことで、保存コストや画面の使い勝手を守れます。一方で、削除ルール、アクセス権、保存期間を別途決め、リンクだけ残って原本が見られない状態を防ぎます。
APIが止まっても、
全体を止めない。
外部連携では、通信失敗、項目不足、同じ処理の再送、相手側の仕様変更が起こります。成功時の流れだけでなく、エラーの記録、担当者への通知、再実行の方法、重複登録を防ぐキーを設計します。
画面上では「完了」と見えても外部サービス側で失敗している状態を避けるため、受付と処理完了を分けて管理します。人が調査するときに、対象データ、実行時刻、結果、エラー理由を追えるログも必要です。
最初から最大構成にせず、
変えにくい境界だけ守る。
利用者が少ない検証段階では、管理機能や自動処理を必要最小限にします。利用が増えてから、キュー処理、監視、バックアップ、権限の細分化を追加します。ただし、認証の考え方とデータの正、外部連携の責任範囲は初期から曖昧にしません。
100万円未満の小規模開発は早ければ約1か月、他案件との調整を含め2〜3か月かかる場合があります。500万円規模では半年程度が一つの目安です。規模より先に、何を最初のリリースへ含めるかを一緒に決めます。