営業・案件・稼働の記録が部署ごとのスプレッドシートに散らばり、社長から「まとめてシステムにして、AI でも使えるようにしたい」と言われていませんか。結論から言うと、画面や機能を考える前に、データの入口と過去分の扱いを決めておくことが一番の近道です。この記事では、Gonmura が開発した社内データ基盤の案件で実際に決めたことをもとに、開発前にやる5つの整備と、明日から始められる準備を紹介します。
手元のシートの一覧があれば、移すデータの範囲と進め方を無料で整理します（相談する）。
結論: 機能より先に「入力の書式・過去データ・つなぐ鍵」を決める
システム化がつまずく原因は、画面の出来よりもデータにあることが多くあります。入力の書式が人によって違う、同じ案件が別の名前で記録されている、過去のシートを全部移そうとして止まる、の3つが典型です。
開発会社に見積もりを頼む前に、次の5つを決めておくと、要件の打ち合わせが具体的になり、作り直しも減らせます。
- 使う機能から逆算して、入力の書式を作り直す
- アンケートや評価も、使い道から逆算して質問を決める
- 過去データを「移す・保管だけ・捨てる」に分ける
- シート同士をつなぐ鍵（案件名など）を決める
- 本番のデータは自社の環境に置く
事例: 法人向けサービス会社の社内データ基盤
ここからは、Gonmura が開発を担当した案件をもとに説明します。顧客は、法人向けの支援サービスを展開する会社です（社名は伏せます）。営業、案件の進み具合、担当者の稼働報告、顧客アンケートが、顧客管理の SaaS と多数のスプレッドシートに分かれていました。
| 項目 | 内容 |
|---|---|
| 困っていたこと | 案件・稼働報告・売上・アンケートが分散し、横断して見られない |
| 作ったもの | 社内データ基盤（部署別のダッシュボード、担当者の候補探し、案件の見守りなど） |
| この記事で扱う段階 | 4か月。最初の1か月は体制とデータの整備、優先順位の確認、仕様の詰めに充てた |
| Gonmura の役割 | 要件の整理、データ基盤と管理画面の開発、AI 機能の実装 |
開発を加速したのは2か月目からです。実際の業務で試しながら、機能を少しずつ引き上げる進め方を取りました。
整備1: 使う機能から逆算して、入力の書式を作り直す
最初に手を付けたのは、担当者が毎月書く稼働報告のスプレッドシートです。それまでの書式では「何をしたか」は分かっても、「なぜそうしたか」「結果どうなったか」が残っていませんでした。
新しい書式では、行動の背景と結果まで書く欄を設け、月1回の入力を必須にしました。あわせて、どのデータがどの機能に使われるのか、必須かどうかを一覧で確かめられるようにしています。
一覧があると、現場は「この欄は何のために書くのか」が分かります。プロジェクトごとのシートはフォルダを分けて置き、あとから AI が読み込みやすい形にしました。
見たい数字から逆算して入力欄を先に決めると、開発の後半で「欲しい数字が取れない」と気付く手戻りを防げます。
整備2: アンケートや評価も、使い道から逆算する
顧客アンケートも見直しました。満足度の点数だけでは、良かった理由も悪かった理由も拾えず、システムの判断材料になりません。
さらに、継続の意向・紹介の意向・課題を毎月聞いていたため、回答する顧客の負担が大きくなっていました。そこで、質問を次のように組み直しています。
- 担当者の評価は、点数とは別に「良かった点」「悪かった点」を聞く
- 毎月のアンケートは「今月の担当者の動き」など直近のことに絞る
- 継続や紹介の意向は、年1回程度のアンケートにまとめる
回答はシートに貯めず、データ基盤に直接入れる方針にしました。顧客管理の SaaS に入れる案もありましたが、開発費が高くなるため見送っています。
整備3: 過去データは「移す・保管だけ・捨てる」に分ける
議論になったのが過去データの扱いです。過去の売上・案件・稼働報告は新しい書式と形が違い、そのままでは新しい機能に使えません。
一方で現場には、苦情の対応などで半年から1年前の稼働報告を見返す場面があります。一気に消すのは危ない、という判断でした。
そこで過去データは新しい機能では使わず、更新しない「過去の履歴」としてデータ基盤に保管するだけにしました。必要なときに見られれば足り、日常的には使わないからです。
売上の推移も、過去分をすべて移すのではなく、契約を始めた月から表示する形に決めました。入力の仕方がばらばらだった古い報告シートは、「そもそも反映させるのか」から話し合っています。
既存データの移行は、システム開発とは別のプロジェクトとして、役割と日程を分けて調整しました。
整備4: シート同士をつなぐ「鍵」を決める
データを横断して見るには、どのシートの行とどの案件が同じものかを結び付ける必要があります。この案件では、チャットのやり取りと案件・担当者を結び付けるのに、約800件の紐付けが必要でした。
そこで、チャットルームの名前と案件名から AI が自動で結び付ける機能を作りました。判定の確からしさは95%程度で、残りは手作業で直せるようにしています。
アンケートなどの入力では、プロジェクト名さえ入っていれば多くの情報を自動で結び付けられます。入力の最初にプロジェクト名を選んでもらう形にするのが要点です。
なお、メールや個別のメッセージでやり取りされると、システムでは追えません。この案件では、連絡の場所を契約で決めておく対策も検討しました。
整備5: 本番のデータは自社の環境に置く
開発の初めは、Gonmura 側のクラウド環境で仮に組み立てて動かしました。本番の運用が見えてきた段階で、顧客自身の Google Cloud のプロジェクトを作ってもらい、そこへ環境とデータを移しています。
顧客が環境の持ち主になっていれば、将来開発会社を替えるときも、データを引き取る交渉は要りません。発注する側から「本番はどこに置くのか」を最初に確かめておくと安心です。
よくある失敗と、システム化しなくていい場面
- 過去のシートを全部移そうとして、移行の作業だけで予定が尽きる
- 入力の書式を変えずに画面だけを作り、欲しい数字が取れない
- 案件名の書き方が人によって違い、データがつながらない
反対に、シートが数枚で入力する人も数人なら、システムを作るより、書式をそろえて入力のルールを決めるだけで足りる場合があります。開発費をかける前に、まず書式の統一で困りごとが消えるかを試してください。
費用の考え方は「システム開発の費用相場」、外部に頼む形の違いは「受託開発とSESの違い」で解説しています。
次にやること: 開発会社に相談する前の3ステップ
- 管理部門の担当者が、今使っているシートを一覧にし、「誰が・いつ・何のために入力しているか」を書き出す
- 経営者と現場の責任者で、システムで見たい数字を3つまで決め、それに要るシートと列に印を付ける
- 過去データを「新しいシステムに移す」「履歴として保管だけする」「捨てる」の3つに分ける
この3つがそろうと、開発会社との最初の打ち合わせで、移すデータの量と作る機能の範囲を具体的に話せます。