1. AIでアプリを作る前に、業務を整理整頓する

「AIで受注管理アプリを作ってほしい」。そう依頼する前に、受注管理のどこで困っているかを整理します。転記が多いのか、納期が分からないのか、赤字の見積もりを受けてしまうのか。同じ受注管理でも、解決する問題によって必要な仕組みが変わります。

最初に決めるのは画面の形ではなく、業務の目的とルールです。 AIは文章やコードの作成を助けてくれますが、自社で何を承認済みと呼ぶか、誰が原価を確認するかまでは、説明なしに決められません。

このシリーズでは、架空の小規模事業者「青葉社」の受注業務を例に、業務を整理し、Googleスプレッドシートで試し、その後にアプリ化やAI連携を検討します。小さく検証できる業務で使う進め方であり、すべての業務を表計算に置き換えるという意味ではありません。

現在の作業をそのまま自動化すると、不要な転記や二重承認も残ります。まず、普段の一件の仕事を追い、「誰から何を受け取り、何を判断し、誰へ渡すか」を書き出します。

現在の作業	困っていること	整理した後の方針
メールの受注内容を各担当者の表へ転記	同じ注文なのに数量が違う	受注IDを付け、原本となる台帳を一つ決める
顧客名を自由入力	略称と正式名称が混在する	顧客IDを選び、表示名と分ける
利益を月末に確認	採算の悪い注文への対応が遅い	見積時点の予定原価と見積貢献額を確認する
全件を管理者へ相談	小さな案件も待ちが生じる	承認が必要な条件と例外を決める

「以前からやっているから」で残っている作業は、利用者と目的を確かめます。誰も使っていない帳票は、作成を速くする前に、廃止できるかを考えます。

必要な仕事が分かったら、情報の置き場所と取り扱いをそろえます。例えば「売上」という列でも、税込・税抜、見積・確定、出荷・請求のどれを表すかで数字は変わります。

青葉社では、まず次の内容を一枚の「業務定義」シートにまとめます。

項目	記入例
目的	受注前に予定採算を確認し、承認漏れを防ぐ
対象範囲	一つの部門の通常受注。返品・分納・複数商品は別途ルールを検討する
開始と終了	営業が見積を登録してから、責任者が受注可否を決めるまで
入力	顧客ID、数量、税抜単価、予定変動費、納期
判断	見積貢献額がマイナス、原価未確定などは承認を保留する
出力	確認待ちの一覧と、承認済みの受注一覧
責任	営業が登録、原価担当が費用を確認、責任者が承認する
完了の条件	必須項目がそろい、判断の根拠と承認者・承認日時が残っている

予定の金額と実績の金額を同じセルで上書きすると、見積もりが妥当だったかを後から比較できません。予定と実績、入力値と計算値、申請と承認は分けて記録することが基本です。

画面が完成してから「返品がある」「数量が変わる」と分かると、設計の変更が必要になります。最初に、少なくとも次の例外を挙げてください。

• 必須情報が未入力：0として計算せず、確認待ちにする。
• 同じ受注を二重登録：受注IDの重複を検出し、担当者が確認する。
• 承認後に数量や価格が変更：変更内容を記録し、再承認する。
• キャンセル：行を消さず、状態と理由を残す。
• 対象外の注文：通常の処理に混ぜず、個別確認へ回す。

すべてを自動処理する必要はありません。例外を見つけて人に戻す仕組みも、自動化の大切な仕事です。

「便利になった」だけでなく、改善前後で何を比べるかを決めます。入力時間、転記回数、承認待ち時間、修正件数など、対象業務に近い指標から始めます。

例えば月100件の入力が、一件6分から3分になった場合、削減できる作業時間は月300分、つまり5時間です。時間当たり2,000円で評価すると、月1万円相当の余力が生まれる計算です。これは架空の試算であり、給与支出がそのまま1万円減るという意味ではありません。保守、利用料、確認作業、教育の時間も差し引いて評価します。

管理会計の視点では、空いた時間を営業や改善に振り向けられるか、納期や誤りも改善するかまで確認します。

担当者が同じ一件について、同じ入力、同じ状態、同じ承認条件を説明できれば、試作に進みやすくなります。説明が食い違う部分は、AIへの依頼を詳しくする前に、社内のルールを決める必要があります。

次は、Googleスプレッドシートで業務のMVPを作るへ進みます。