VALLEYHILL 統合開発データ構造図｜株式会社きびだんご

VALLEYHILL 統合開発データ構造図

100%

図の読み方と確認事項

四角がデータのまとまり（テーブル）、線がその関係です。カードをクリックすると、つながっている相手だけが強調されます。

PK: そのデータを一意に識別する番号。車両なら車両ID。
FK: 他のまとまりを指し示す番号。ここで情報がつながります。
1: 線のこちら側は必ず1件。
0..*: 0件から何件でもぶら下がる。車両1台に写真が何枚も、など。
0..1: 0件か1件。査定依頼が成約せず在庫にならない場合など。
点線: 別の図のテーブルとのつながり。「全体」表示で意味を持ちます。

図1 車両・買取・販売

買取査定が成約すると在庫車両になり、その車両を各サイトへ公開する流れです。原価情報を車両本体と別のまとまり（採算）にしているのが要点で、提案書の「原価は一般公開しない」を構造そのもので担保します。公開してよい情報だけが公開設定を経由してサイトに出ます。

車両情報を新システム側にも持つか基幹から都度呼び出す方式にすると検索の速さが既存側に依存します。調査でAPIの有無と応答速度を確認して決めます。
公開可否を誰が切り替えるか基幹で登録するときに決めるのか、公開設定の画面で別途決めるのか。運用担当者が変わります。

図2 オークション・顧客管理

入札と落札の確定は既存システムが正本です。新システム側の出品と入札は、画面表示のために結果を受け取って持つまとまりになります。二重に計算はしません。顧客管理は法人顧客を親に、顧客保有車両と商談がぶら下がる形です。営業が訪問先のスマートフォンで入力するのは、主に保有車両と活動記録の2つです。

オークション会員と法人顧客をつなぐかつなぐと「入札はするが買取提案がまだの会社」が一覧で見えます。個人情報の扱い方針と合わせて判断します。
活動記録の入力項目をどこまで絞るか訪問先のスマートフォン入力なので、項目が多いと入力されません。次回対応日は必須にする想定です。

図3 連携基盤・配信・会計

見積の「共通連携基盤」にあたる部分です。ID対応表が、基幹・オークション・顧客管理それぞれの番号と、新システム内部の番号を突き合わせます。「すべてを一つのデータベースに移すことではない」という説明を実装に落とすと、このまとまりになります。同期の実行記録とエラー記録があることで、失敗した車両を把握して再処理できます。

同期の方式と間隔API接続か、定期的なCSV取り込みか。情報の種類ごとに更新時間と停止条件を決めます。
会計補助を実装するか弥生からエッサムへの現行運用で足りる場合、この部分は見積から40万円を減額できます。

調査で確定させる項目

この図は、いただいたご説明と既存の開発提案書をもとにした想定です。次の資料を確認した時点で、項目名も関係も変わります。

基幹システムの画面と項目の一覧車両情報のどの項目が基幹にあり、どれが新設なのかを突き合わせます。
匿名化した車両データ実データの入り方を見ないと、重複や写真の不足量が分かりません。
接続口の資料と改修権限APIがない場合は既存側の改修が必要になり、その分は別発注になります。
入札から落札、会員審査までの操作デモどの処理を既存側が確定させているかを目で確認します。
弥生とエッサムの製品名、月次CSVの見本会計補助が必要かどうかの判断材料です。

この構成で作れるかどうか、いくらかかるかは、先行調査（180万円・4〜6週間）で確定します。調査では接続試験の結果と残課題まで文書でお渡しするので、本開発に進まない判断もできます。

株式会社きびだんご
VALLEYHILL 統合開発提案補足資料｜2026年9月16日
本資料は公開情報と先方ご説明に基づく想定構成です。個別環境の接続可否は確認できていません。