2. Googleスプレッドシートで業務のMVPを作る

表を動かすと、足りないルールが分かる

前の記事では、業務の目的とルールを整理しました。次に行うのは、いきなり完成版のアプリを作ることではなく、現場の担当者が実際に使って確かめられる小さな試作品を作ることです。

Googleスプレッドシートは、入力する項目と計算結果を同じ場所で見比べられます。「この注文では原価がまだ決まらない」「同じ顧客でも納品先が違う」といった問題を、画面開発に入る前に発見できます。表が完成したことより、業務のルールを確かめられたことに意味があります。

MVPで、業務が回るかを検証する

MVP（Minimum Viable Product）は、必要最小限の機能で価値を検証するためのものです。 このシリーズでは、現場の担当者が使い、受注前の採算確認に役立つかを確かめる小さな業務の試作品を指します。

最初から通知、スマートフォン対応、AIによる入力、複雑なダッシュボードまで作り込む必要はありません。まず「必要な情報を登録できる」「予定採算を計算できる」「承認が必要な案件を見つけられる」の三つに絞ります。承認は人が手作業で行って構いません。

大切なのは、表の形ができたことではなく、実際の担当者が一巡の仕事を行い、改善につながるかを確かめることです。少数の案件で試し、入力にかかった時間、確認漏れ、差し戻しの理由を記録します。

1. 四つのシートに役割を分ける

架空の青葉社では、まず一受注につき一商品、分納なしの見積確認を対象にします。複数商品や分納まで扱う場合は、受注と受注明細、出荷を別の表に分ける設計が必要です。

シート名	役割	主な内容
業務定義	情報の意味と運用を決める	列の説明、単位、必須条件、状態、承認条件、担当者
顧客マスタ	繰り返し使う情報をそろえる	顧客ID、顧客名、有効・無効
受注台帳	一件ごとの事実と予定を記録する	受注ID、日付、顧客ID、数量、金額、確認状態
集計	判断に使う形へまとめる	確認待ち一覧、月別の見積貢献額、顧客別件数

集計の見栄えを先に作るより、入力する項目の意味を先に決めます。毎月新しい台帳を複製するより、日付の列を持つ一つの台帳を絞り込む方が、期間をまたぐ比較やAIによる参照を設計しやすくなります。

2. 台帳は、一行に一件を記録する

見出しは1行目に置き、データは2行目から連続して記録します。データの途中に合計行や説明文を入れたり、セルを結合したりしません。表示用の帳票が必要なら、台帳とは別のシートに作ります。

列	項目	ルール
A	受注ID	一件に一つの固定ID。行番号をIDにしない
B	見積日	日付として入力
C	顧客ID	顧客マスタから選ぶ
D	数量	この例では正の整数
E	税抜単価	円単位の数値。0円は明示的な値として扱う
F	予定変動費合計	一件全体の金額。未確定なら空欄
G	見積売上	数量 × 税抜単価。計算列
H	見積貢献額	見積売上 − 予定変動費合計。計算列
I	状態	下書き、確認待ち、承認済み、却下、キャンセル
J	承認者	承認した人を記録
K	承認日時	承認時点の日時を固定して記録
L	備考	例外の理由。重要な項目をすべて自由記述へ押し込まない

この例の見積貢献額は、対象受注の予定変動費だけを差し引いた管理用の金額です。固定費やその他の費用をすべて引いた営業利益ではありません。費用の範囲は変動費・固定費の分類と照らして決めます。

小さな入力例

次は架空の数値です。予定変動費は一個当たりではなく、受注全体の合計です。

受注ID	数量	税抜単価	予定変動費合計	見積売上	見積貢献額
ORD-001	10	5,000	32,000	50,000	18,000
ORD-002	5	8,000	45,000	40,000	−5,000
ORD-003	3	6,000	未確定	18,000	未計算

ORD-003の費用が未確定なのに0円として計算すると、18,000円の貢献額があるように見えてしまいます。未入力と0を区別することは、管理会計の数字を守るために必要です。

3. 計算を見える形にする

受注台帳のG2に次の式を入力し、必要な行へコピーします。

=IF(OR(D2="",E2=""),"",D2*E2)

H2には次の式を入れます。

=IF(OR(G2="",F2=""),"",G2-F2)

この式は未入力なら空欄を返しますが、負の数量や文字列、ID重複などのすべてを検証するものではありません。入力規則と担当者の確認を組み合わせます。式を入れ忘れた行も確認対象です。

顧客IDと状態はプルダウンで選択し、数量や金額には数値の条件を設定します。計算列は誤って書き換えにくいよう保護します。ただし、シートや範囲の保護は、秘密情報を閲覧させないためのアクセス制御とは別です。閲覧範囲が異なる情報は、ファイルやシステム自体を分けることも検討します。

承認日時に NOW() をそのまま使うと、再計算で変わり得ます。試作では承認時の値を手入力で固定し、自動化する際に承認操作とともに記録する設計へ進めます。

4. 普段の注文と、困る注文の両方を試す

現場担当者と原価担当者が、次のケースを一緒に確認します。最初は実在の顧客情報を含まない架空データで試してください。

試すケース	期待する扱い
ORD-001の通常注文	売上50,000円、貢献額18,000円となる
ORD-002の赤字見積もり	自動で承認せず、責任者へ確認する
ORD-003の原価未確定	貢献額を表示せず、承認を保留する
同じ受注IDを追加	重複を見つけ、正しい一件を担当者が確認する
承認済みの数量を変更	変更履歴と理由を残し、再承認する
キャンセル	行を削除せず、状態を変更し、承認済み集計から除く

ここで示した承認や重複検知が、上の二つの数式だけで自動実行されるわけではありません。試作では、確認待ち一覧と手順書に沿って人が行い、必要な制御を洗い出します。

同じ人が入力してそのまま自分で承認できる運用や、承認後も自由に金額を変えられる台帳は、本番の承認システムとして十分とはいえません。正式な承認には、権限の分離と変更の追跡も必要です。

5. アプリ化へ進む条件を決める

一度動いたら完成ではありません。通常の一巡に加えて、変更・取消・未確定のケースも試し、「誰が使っても同じ結果になるか」「記録の修正を追えるか」「集計が元データと一致するか」を確かめます。

一方で、多人数が同時更新する、複雑な権限が必要、複数の表を一体として確実に更新する必要がある、といった場合は、スプレッドシートを本番の中心に据え続けることが難しくなります。既存の業務ソフトやデータベースを使う方が適切な場合もあります。

試作品で決まった列の定義、承認条件、例外、確認例は、そのままアプリ開発をAIへ依頼するための材料になります。次は、MVPを検証して、AIでアプリ化・自動化へ進むを読み、どの操作を任せるかを考えます。