3. MVPを検証して、AIでアプリ化・自動化へ進む

前の記事では、Googleスプレッドシートで受注管理のMVPを作りました。次に確かめるのは、「アプリにできるか」よりも、この仕組みで現場の困りごとが解決するかです。

青葉社の目的は、受注前に予定採算を確認し、承認漏れを防ぐことでした。表に入力できても、原価が分からないまま承認されるなら目的を達成していません。現場で使い、どこで止まるか、何の情報が足りないかを確認します。

まず一部門の少数の案件で試します。通常の受注だけでなく、原価未確定、赤字見積もり、数量変更、キャンセルも確認します。各案件の結果を次のように残します。

「アプリにすれば解決する」と考える前に、担当者やルールを変えることで解決する問題も分けます。原価の確認担当が決まっていないなら、通知機能を増やしても仕事は止まります。

MVPで効果を確かめた後も、一度に全部を開発する必要はありません。利用頻度、作業量、誤りの影響を見て優先順位を決めます。

スプレッドシートで十分に業務が回るなら、運用を続ける選択もあります。多人数の同時更新、細かな閲覧権限、変更履歴の厳密な管理が必要になったら、既存の業務ソフトやデータベースを使うアプリへの移行を検討します。

「この表をアプリにして」だけでは、見た目は再現できても、判断や例外の扱いが抜けることがあります。列の定義、利用者、承認条件、期待する結果を合わせて説明します。

目的：受注前に予定採算と入力不足を確認する。
対象：一受注一商品、分納なしの見積業務。
利用者：営業が登録し、原価担当が確認し、責任者が承認する。
台帳：固定の受注ID、顧客ID、数量、税抜単価、予定変動費合計、状態を持つ。
計算：見積売上＝数量×税抜単価。
      見積貢献額＝見積売上−予定変動費合計。
      原価未確定は0円扱いせず、未計算とする。
最初の機能：登録、計算、確認待ち一覧、承認記録。
承認：人が行う。承認後の変更は履歴を残して再承認する。
対象外：複数商品、分納、全件の自動承認。
確認例：通常注文、赤字見積もり、未入力、重複、変更、キャンセル。

試作で使った例も、入力と期待結果の組で渡します。数量10、税抜単価5,000円、予定変動費合計32,000円なら、見積売上50,000円、見積貢献額18,000円です。費用が未入力なら貢献額は表示せず、承認を保留することまで指定します。

決まった計算や必須項目の確認は、数式やプログラムで実行できます。文章から情報を拾う、問い合わせを分類する、確認事項の説明案を作るといった場面では、AIの活用を検討できます。

AIの出力は、まず下書きとして扱います。自動で送信・確定する範囲を広げる前に、誤りを見つけられるか、修正や取消ができるかを確認します。

画面ができたら、試作と同じ案件を入力し、同じ計算結果と状態になるかを照合します。並べ替えても受注IDで正しい一件を特定できるか、同じ登録操作を繰り返しても二重登録にならないか、承認済みの金額を変更した際に再承認へ戻るかも確認します。

最初は担当者と対象を限定して運用し、問題があれば元の手順へ戻せるようにします。旧台帳と新アプリを並行して照合する場合も、正式な原本をどちらに置くかを決め、二重入力が続かないように移行の期限を設けます。

管理会計の視点では、利用料だけでなく、保守、修正、教育、確認作業も含めて効果を評価します。削減できた時間は、それだけで支出の減少を意味しません。空いた時間を何に使い、利益や納期、品質の改善につなげるかまで考えます。

業務を整理し、スプレッドシートでMVPを作り、実務で検証してからアプリ化する。この順序を踏むことで、開発する機能だけでなく、その機能が必要な理由も説明できるようになります。

作った後に新しい例外が見つかったら、業務定義、台帳、アプリの処理を一緒に更新します。管理会計で使う数字を継続して集め、判断につなげるための仕組みとして育てていきます。

シリーズの入口：DX・IT・AIの実践ガイド