01買取
買取受付・査定アプリ
出張買取の予約と訪問管理、店頭査定の記録、買取価格の根拠の共有。LINEとWebで受け付け、成約後の出品準備まで一つの流れにします。
リユース事業者の業務システムを要件定義から。
買取、ささげ、在庫、販売、本部の数字まで。リユースの業務を前提知識として持つチームが、既製のシステムとつなぎながら、足りないところを作ります。
業務を知っているから、要件定義から一緒に作れる。
リユースの業務は、一点ものの在庫、買取と販売をまたぐ原価、販路ごとの出品仕様のように、汎用のサービスが数量を前提に作られている部分で必ず隙間が出ます。その隙間を、電話とスプレッドシートと紙が埋めています。
私たちは、既製のもので足りる部分と作る部分を切り分けるところから入り、足りない部分だけを業務に合わせて作ります。AIは開発の方法として使い、書く作業のような業務の中にも組み込みます。
Systems
作るもの、ひとつずつ
リユースの業務の流れに沿って並べています。既製のサービスで足りる部分はそのまま使い、足りない部分だけを作ります。
02ささげ
書く作業のAI化
商品説明、状態記載、査定コメント、問い合わせ返信の下書きをAIが作り、担当者が確認して確定します。お客様側にAIの知識は要りません。
03ささげ
出品・販路連携システム
撮影・採寸・原稿の後の、販路ごとの出品データの作成と送信を自動化します。複数の販路へ同じ在庫から出し、売れたら他の販路から下げます。
04在庫
店舗POS・在庫管理
一点ものの在庫を数量ではなく所在で管理し、店頭の販売と在庫を同じ数字にします。既存POSの範囲外を補う開発から、POSと在庫管理（OMS）の個別構築まで。
05販売
Shopify構築・EC移行
自社ECの構築と、既存のカートからの移行。在庫と受注を基幹とつなぎ、店舗とECで同じ在庫を売ります。
06販売
eBay連携（越境）
国内の在庫をeBayに出品し、受注と在庫を国内の基幹と同期します。出品の原稿は書く作業のAI化と合わせて英文で作ります。
07販売
受注・出荷・入金照合
複数の販路の受注を一か所に集め、発送通知の送信と、販路別の入金照合までを人の手を挟まずにつなぎます。
08本部
本部の集計と可視化
店舗と販路の実績を自動で集め、数字の定義を統一します。物流費のような費用の集計も、Excelの運用から置き換えます。
09顧客
LINEの一次応答と会員証
買取や在庫の問い合わせにAIが一次応答し、担当者が確認して返します。会員証、ポイント、買取の受付、通知を同じLINEに集めます。
10顧客
顧客管理（CRM）
買取のお客様と購入のお客様の履歴を一つにし、再来店と再買取の働きかけに使います。
Map業務の流れと、
業務の流れと、
システムの置き場所
買取から本部の数字までのレールに、作るものを下げた図です。顧客との接点は、買取と販売の両側にあります。
- 買取Purchase買取受付・査定アプリ
- ささげListing prep書く作業のAI化出品・販路連携システム
- 在庫Inventory店舗POS・在庫管理
- 販売SalesShopify構築・EC移行eBay連携（越境）受注・出荷・入金照合
- 本部Head office本部の集計と可視化
- 顧客との接点CustomerLINEの一次応答と会員証顧客管理（CRM）
Works
取り組み
社名は公開していません。業種と規模、内容、段階までを記載しています。
要件定義
複数の店舗とネット販売を持つリユースチェーン店舗POSと在庫管理（OMS）の要件定義と基本設計。在庫の正本をOMSに置き、店舗・EC・本部が同じ数字を参照する構成にする。
完了
全国に店舗を持つ大手リユースチェーン物流費の集計業務の現状調査。Excelでの運用を棚卸しし、集計の定義と手順を文書にした。
提案
全国に拠点を持つ事業者多拠点の物品在庫システムの要件整理と、システム定義書の作成。拠点ごとに見える範囲が違う在庫を一つのシステムで扱う。
開発中
自社事業出張買取の受付・予約アプリ。LINEとWebで受け付け、訪問と査定の記録までを一つの流れにする。
稼働
自社プロダクトEC向けのメール配信の予測と運用（ECops）。配信の結果を予測して打ち手を決める。
開発の進め方
開発を「決める」「作る」「確かめる」に分けると、AIを使うのは「作る」の中だけです。決めるのはお客様と技術者、確かめるのは技術者とお客様で、成果物の責任は当社が負います。
- 01Decide
決める
業務の流れ、画面、帳票をお客様と協議して確定し、技術者が設計書（仕様の正本）を作ります。
- お客様
- 技術者
- 02Build
作る
技術者が仕様を指定し、AIを使ってプログラム・テスト・文書の案を作ります。案は技術者が読み、設計と合わない部分は仕様を定め直して作り直します。
- 技術者
- AI
- 03Verify
確かめる
技術者の精査、自動テストを含むテスト、リリース判定の順で確認します。受入テストと検収はお客様が行います。
- 技術者
- お客様
作る時間が短くなる分は、そのまま費用と納期に反映します。要件定義、設計、作成物の精査、受入テスト、検収、定着支援は、従来の開発と同じ内容で行います。
契約の形
進め方は2つあります。作るものが決まっているときは、成果物と金額を先に決めてから始めます。決めながら進めたいときは、月の金額と時間の枠を決め、その中で一緒に作っていきます。どちらにするかは、お話を伺ってから一緒に決めます。
Project
成果物と金額を先に決める
要件定義から開発・導入まで、何を作るかと金額を先に固めて進めます。金額が途中で動かないので、予算の確保と社内の説明がしやすい形です。規模の大きな開発に向いています。
Monthly
月の枠の中で、一緒に進める
毎月の金額と時間の枠を決め、その中で優先度の高いものから順に作ります。要件が固まりきる前から始められ、状況に合わせて中身を変えられます。社内に開発の担当を置かずに、必要な期間だけ続けられます。
Contactまずは、
まずは、
業務の話から。
要件が固まっていなくて構いません。今の業務と困りごとを伺い、既製のもので足りる部分と、作る部分の切り分けからご一緒します。