設計から入り、開発を始めて早くも1か月

設計から入り、古物商向けのアプリ「古物台帳」の開発を始めて、早くも1か月が経ちました。

このAIの時代に、v1の開発に1か月もかかるとは、正直なところ始める前には思っていませんでした。AIに相談すれば設計書を書けますし、コードのたたき台も作れます。昔より開発が速くなっている実感もあります。

それでも、アプリはなかなか完成しません。今回は機能一覧や使い方を詳しく説明する記事ではなく、開発を続ける途中で感じたことを、雑記として残しておこうと思います。

このアプリを作ろうと思った理由

古物商向けの業務アプリを作ろうと考えた理由は、私自身がプロの古物商として買取を行っていたからです。以前は一般的なリサイクルショップを経営し、出張買取を中心に仕事をしていました。

「古物商」と聞くと、質屋やリサイクルショップを思い浮かべる人が多いかもしれません。ただ、古物商と一言でいっても、扱う商品や営業形態はさまざまです。中古車を扱う事業者、宝石や貴金属を扱う事業者、レンタル品を扱う事業者、中古品を仕入れて販売する事業者など、いろいろな形があります。

ここでいう古物商は、単に中古品を持っている人という意味ではありません。自分で使うために買った物が不要になり、それを売るだけなら、通常は古物商の営業には当たりません。一方で、販売して利益を得る目的で中古品を仕入れて営業する場合は、古物営業法上の許可や記録義務が関係します。実際の許可の要否は、商品の種類や取引形態、営業の実態によって判断が変わるため、ここでは一般的な整理として書いています。

古物商は、取引内容を記録して保存する必要があります。紙の台帳を使う方法もありますが、出張買取のようにその場で査定や情報入力を行う仕事では、後から帳簿へ転記する作業が負担になります。自分自身がその仕事をしていたからこそ、「この部分を最初から業務の流れに組み込めないか」と考えるようになりました。

対象は広く、最初に想定しているのは出張買取

開発しているアプリの対象は、特定の商品ジャンルだけではありません。さまざまな古物商が使える業務アプリを目指しています。

ただし、最初から大規模なチェーン店向けに考えているわけではありません。個人から中規模程度の事業者、特に出張買取を行うリサイクルショップで使いやすい形を強く意識しています。

出張買取では、店舗のカウンターのように入力環境が整っているとは限りません。現場で査定し、見積もりを提示し、買取の承諾を完了させ、その後に必要な帳票や会計データへつなげる必要があります。自分の経験を振り返ると、単に台帳を電子化するだけでは足りず、買取業務の最初から最後までを見渡す必要があると感じます。

画面を作るだけでも、考えることが多い

最初は、査定画面に商品を入力して、合計金額を表示できれば一歩前進だと思っていました。

しかし実際に画面を作って触ってみると、取引日、担当者、営業所、支払方法、依頼者情報、本人確認、承諾、完了後の履歴など、入力画面の周りに決めることが次々に出てきます。

入力欄を増やせば業務に対応できるように見えますが、増やしすぎると今度は入力する人が疲れます。どの情報を最初に入力し、どの情報を後で補足できるようにするか。このあたりは、実際の画面を触りながら少しずつ整理しています。

古物台帳の管理と会計データの作成を中心にする

このアプリで目指しているのは、査定や見積もりを行い、買取承諾を完了させるところから、その後の帳票作成や会計データの出力までをつなげることです。

主役になるのは、古物台帳の管理と会計データの作成です。ただ、それだけで完結するわけではありません。取引を検索したり、期間や条件で集計したり、商品マスタを管理したり、顧客情報を確認したりする機能も必要になります。

入力したデータを台帳に記録するだけでなく、その後の出品作業や会計処理でも使えるようにする。最初からすべてを完成させるのは難しいですが、最終的には一度の入力を何度も使い回せるアプリにしたいと考えています。

なお、ここで挙げた機能がすべて現在利用できるという意味ではありません。実装済みの部分、検証中の部分、これから仕様を詰める部分が混在しています。完成機能の紹介というより、目指している全体像として受け取ってもらえればと思います。

1か月以上かかっている一番の理由は、親機と子機の設計

このアプリの最大の売りと言ってもいい機能が、1か月以上もの開発期間がかかっている大きな理由でもあります。

このアプリには、親機と子機という考え方があります。1台の親機に対して、複数の子機を登録できる構成です。

親機は査定を行う端末であると同時に、事業の管理者が使う端末でもあります。集計、データ出力、マスタ保守、子機の権限設定、セキュリティ設定など、管理に関わる機能は親機側に集約します。

そして、親機は単なる管理画面ではありません。子機から受け取ったデータを集約し、業務上の正本として保持する役割を担います。最終的にどのデータを正式なものとして扱うのかを親機側で管理する設計です。

一方の子機は、親機のデータと同期しながら査定を行う端末です。出張買取などでスタッフが持ち出し、現場で査定や入力を行うことを想定しています。子機だけで事業全体を管理するのではなく、必要な業務を現場で進め、後から親機へ戻す立ち位置です。

外部ネットワークに依存しない同期を考える

個人情報を扱うため、このアプリは外部ネットワークやクラウドへの常時接続を前提にしていません。親機と子機の同期はローカルネットワーク内で行い、基本的には同じWi-Fiに接続している端末同士でデータを共有します。

出張買取では、端末を店舗の外へ持ち出すことがあります。その間、親機と子機が常にリアルタイムでつながっているとは限りません。そこで、現場では子機側で査定を進め、帰社してから同期しても問題が起きないように、データの持ち方や履歴の残し方を考えています。

「通信できない時間があること」を例外扱いするのではなく、最初から通常の利用場面として設計する。これが、一般的なクラウド型の業務アプリとは少し違うところです。

親機に戻って同期したときには、子機で入力したデータをどう受け入れるか、親機側にすでに別の変更があった場合はどうするか、同じ商品や顧客情報が重なった場合にどう確認するか、といった問題が出てきます。画面を作るだけなら早くても、この部分を後から追加するのは難しいため、最初から設計に含めています。

Macを親機にする使い方も考えている

親機はiPadでなければならない、というわけではありません。MacにiPad版アプリをダウンロードして、親機として使う方法もあります。

事業全体の管理を行うなら、画面の広いデスクトップ環境の方が操作しやすい場面も多いはずです。集計やデータ出力、マスタ保守、子機の管理などを行う親機は、Macで使う方が便利なケースもあると思います。

さらに、VPNを利用すれば、離れた場所にある親機と子機を常時同期に近い形で運用することも可能です。たとえばTailscaleのようなVPNサービスを利用する方法が考えられます。

ただし、これは正式サポートする標準機能ではありません。VPNの設定、端末の権限、ネットワーク構成、接続できない場合の切り分けなどは利用者側の環境に依存します。基本は同じローカルネットワーク内での同期とし、VPNによる常時同期は、必要な人が自己責任で試せる拡張的な使い方という位置づけです。

最近の進捗は、見た目よりも裏側が多い

最近の作業では、派手な新画面を追加するより、既存の流れが途中で壊れないようにする作業が増えています。

査定を始めて、商品を追加し、見積りを確認し、依頼者情報や本人確認を入力して、取引完了まで進む。この一連の流れを実機で確認しながら、途中で再開した場合や、別の端末から情報を扱った場合に履歴が崩れないかを見ています。

親機と子機の同期も同じです。データを送れれば終わりではなく、どの端末の情報が正しいのか、同期後に削除した商品が残らないか、競合が起きたときにどう見せるかまで考える必要があります。

2026年7月14日時点では、商品マスタの物理削除、CSV、親機を正本とした子機への全件置換同期について、ビルド・テスト・実機確認まで行った記録が残っています。こうした作業は画面のスクリーンショットだけでは伝わりにくいのですが、アプリを業務で使えるものに近づけるためには重要な部分です。

セキュリティのことを考える時間も増えた

古物台帳アプリでは、依頼者の住所や生年月日、本人確認に関する情報を扱う可能性があります。そのため、便利な入力機能だけを先に考えるわけにはいきません。

最近は、親機側で子機の解除方法を設定したり、子機のロック状態を管理したり、個人情報をホーム画面上で隠したりする仕組みを追加しています。子機を一時的に解除する場合も、単に画面を開けるだけではなく、親機との関係や同期状態を壊さないようにする必要があります。

このあたりは、最初から完璧なセキュリティを作れているという話ではありません。どの情報をどの端末に置くのか、誰が設定を変更できるのか、ロック解除後に何を許可するのかを、開発しながら細かく決めている段階です。

MacでiPad版を動かしてみる

少し面白かったのは、Apple silicon Mac上でiPad版を動かし、親機・子機の登録や同期を試したことです。

専用のMacアプリを作ったわけではありません。iPad版をMac上で動かし、QR画像から子機登録を行い、査定開始から取引完了までの基本動作を確認しました。親機と子機を同じネットワーク内で動かす場合の接続確認にもなりました。

ただ、動いたからすぐに正式対応できるという意味ではありません。Mac上でのUI最適化や、QR画像の読み取り方法、VPNを使う場合の注意点など、まだ整理することは残っています。こういう「思ったより動く」と「製品として対応する」の間にある距離を確認できたのは、開発上の収穫でした。

仕様を決めるより、保留することも大事

開発を進めていると、機能を追加することに目が向きます。バーコード読み取り、PDF出力、会計用CSV、出品用データ、顧客検索、複数端末同期。どれもあると便利そうです。

一方で、ドキュメントにはまだ未確定の項目も多く残っています。たとえば、顧客情報の重複判定、帳票の最終形式、会計CSVの具体的な扱い、本人確認画像の保存方法などです。

ここを曖昧なまま実装すると、後から大きく作り直すことになります。今は「できることを増やす」だけでなく、「まだ決めないことを明確にする」ことも開発の一部だと感じています。

まだ完成報告ではありません

現在の古物台帳は、完成したアプリを紹介できる状態というより、実際に触れる部分を増やしながら、業務で必要なルールを整理している途中です。

査定から取引完了までの流れ、端末間同期、商品マスタ、セキュリティ設定など、少しずつ形になってきた部分はあります。ただし、帳票出力や会計連携、正式なリリース準備など、今後詰める項目も残っています。

機能だけを見ると長い道のりに感じますが、開発中に「この入力は本当に必要か」「このデータを消してよいのか」「別端末ではどう見えるのか」と考える時間そのものが、アプリの形を作っているように思います。

しばらくは、このアプリについても、完成した機能の紹介というより、作りながら考えたことを雑記として書いていくことになりそうです。