「今のExcel管理が限界かもしれない。でも、いきなり業務システムを作るほどなのか分からない。」そう感じると、開発会社に相談する前に迷いやすくなります。
Notionやスプレッドシートで十分なのか、簡単な試作を挟むべきなのか、最初から個別開発に進むべきなのか。答えはツール名だけでは決まりません。
この記事では、業務システムを作る前に、Excel・Notion・試作のどこから始めると失敗しにくいかを整理します。開発会社へ相談する前に、今の業務をどの段階で扱うべきか見分けるための実践メモです。
いきなり作るべきか迷うのは自然です
「業務を楽にしたいだけなのに、システム開発の話になると急に大きく感じる」
社内の申込管理、予約管理、問い合わせ対応、請求前の確認、イベント参加者リスト。最初はExcelやGoogle Sheetsで十分でも、人が増えたり、確認する項目が増えたり、通知や承認が必要になったりすると、だんだん運用が重くなります。
ただ、そこでいきなり本格的な業務システムを作ると、費用も期間も大きくなります。逆に、既存ツールだけで粘りすぎると、転記ミス、確認漏れ、担当者依存、二重管理が増えます。
大事なのは「Excelが悪い」「Notionなら解決」「システム化すれば安心」と決めつけないことです。まずは、今の業務がどのくらい構造化され、誰が、どの頻度で、どんな責任を持って使うのかを見ます。
先に結論
業務システムを作る前の分岐は、次の順番で考えると整理しやすくなります。
- 個人または少人数で、表の形で管理できるならExcel
- チームで状態・担当・関連メモを見たいならNotion
- 入力導線、通知、権限、外部連携を試したいなら試作
- 社外ユーザーや正式運用に出すなら本開発
ExcelやNotionは、相談前の整理にも使いやすい道具です。一方で、外部の人に入力してもらう、入力内容に応じて通知する、権限を分ける、決済やメールと連携する、履歴を残す、といった要件が出てきたら、既存ツールだけで抱え込むより試作で確認した方が安全です。
開発会社に相談するときも、「業務システムを作りたいです」より、「いまExcelでここまで回していて、ここから先を試作で確認したいです」と言える方が、提案も見積もりも具体的になります。
Excel・Notion・試作の分岐点
まずは、次の表で今の業務を見てください。これは相場や制度上のルールではなく、Ready Mockで相談前整理に使う実務上の目安です。
| 始め方 | 向いている状態 | 注意したいサイン | 次の一手 |
|---|---|---|---|
| Excel | 一覧、計算、集計が中心。担当者が少なく、手動確認でも回る。 | 列が増え続ける、最新版が分からない、転記ミスが出る。 | 列・ステータス・担当者を整理し、業務の型を作る。 |
| Notion | 案件、タスク、顧客、イベントなどをチームで見たい。 | 入力ルールが人によって違う、承認や通知が手作業になる。 | ビュー、担当、状態、関連ページを整え、運用ルールを決める。 |
| 試作 | 入力フォーム、通知、管理画面、権限、外部連携の必要性を確かめたい。 | 本開発の範囲が大きく、どこまで作るべきか判断できない。 | 1つの業務、1つの導線、1つの利用者に絞って触れる形を作る。 |
| 本開発 | 社外提供、安定運用、監査性、権限管理、保守体制が必要。 | 例外処理、問い合わせ対応、データ管理責任が曖昧。 | 要件、運用担当、リリース後の改善方針を決める。 |
この表で大切なのは、ExcelやNotionを「仮のもの」として軽く扱わないことです。うまく設計されたExcelやNotionは、後で試作や本開発に進むときの要件整理になります。逆に、整理されていない状態でシステム化すると、混乱した業務をそのままコードに移すことになります。
Excelで始めてよいケース
Excelは、一覧性、計算、集計、ちょっとした比較に強い道具です。Microsoft SupportのExcel specifications and limitsでは、ワークシートの行数・列数などの仕様上限も公開されています。つまりExcelは小さい業務だけの道具ではありません。
ただし、業務管理で見るべきなのは行数の上限ではありません。実務上は、次の条件がそろっているならExcelで始めても問題になりにくいです。
- 入力する人が少ない
- 最新版の場所が明確
- 変更履歴を厳密に追わなくてよい
- 入力ミスがあっても人が確認できる
- 社外ユーザーに直接入力させない
- 通知や承認がなくても業務が止まらない
たとえば、イベント候補者の一次整理、社内だけで見る予算メモ、月次の簡易集計ならExcelで十分なことがあります。最初からシステム化せず、列名、入力ルール、ステータス、担当者を整えるだけで改善する場合もあります。
一方で、Excelが業務そのものの入口になり、複数人が同時に判断し、外部入力や通知まで担い始めたら、別の方法を考えるサインです。
Notionで整理しやすいケース
Notionは、単なる表というより、情報をページとして持ちながら、状態や担当者で見方を変えたい業務に向いています。Notion HelpのIntro to databasesでは、Notionのデータベースをページの集合として説明し、プロパティやビューによって情報を整理できることが示されています。
次のような状態なら、いきなり個別開発に進む前にNotionで整理する価値があります。
- 案件ごとにメモや添付情報がある
- タスク、顧客、イベント、問い合わせを状態別に見たい
- チームで「誰が何を見るか」をそろえたい
- 会議メモや判断履歴も同じ場所に置きたい
- まず運用ルールを固めたい
Notionでうまくいくかを見ると、業務システムに必要な項目も見えます。たとえば「ステータスは何種類必要か」「担当者は1人か複数か」「どの情報は毎回入力されるか」「どの画面がよく使われるか」が分かります。
ただし、Notionも万能ではありません。入力内容に応じて自動で外部メールを送る、顧客ごとに細かな権限を分ける、決済や会員情報と連動する、社外ユーザー向けに専用画面を出す、といった話になると、Notion運用だけでは無理に感じる場面が出てきます。そのときはNotionで固めた業務の型をもとに、試作へ進むと無駄が少なくなります。
試作に進むべきケース
試作が向いているのは、ExcelやNotionでは「管理」はできても、「実際の入力体験」や「自動化したときの流れ」が見えないときです。
たとえば、次のようなケースです。
- 申込フォームから管理者確認まで一連の導線を試したい
- 顧客、参加者、会員など社外の人が入力する
- 入力内容によって通知先や確認フローが変わる
- 管理画面で検索、ステータス変更、CSV出力を試したい
- LINE、メール、Google Sheets、決済など外部サービスとつなぐ前提がある
- 本開発の見積もりを取る前に、必要な範囲を小さく確認したい
GOV.UK Service ManualのHow the discovery phase worksでは、サービスを作る前に、解くべき問題、利用者、制約、改善機会を理解することが説明されています。さらに、discoveryの段階ではサービスを作り始めないとも説明されています。
これは小規模な民間案件にも使える考え方です。いきなり完成版を作るのではなく、まず問題と利用者を整理し、その後に試作で「この流れなら使えるか」を確かめる。そうすると、作るべきものと作らなくてよいものを分けやすくなります。
根拠から見た考え方
ここでの分岐は、特定ツールの優劣ではなく、業務とシステムを分けて考えるためのものです。
デジタル庁のデジタル社会推進標準ガイドラインでは、サービス・業務改革と、それに伴う情報システムの整備・管理について、共通ルールや参考ドキュメントが整理されています。業務システムを考えるときも、画面や機能だけを先に決めるのではなく、業務そのものをどう変えるかを見る必要があります。
同ページのデータ連携に関するドキュメントでは、データの利活用や連携がしやすい設計の重要性も示されています。ExcelやNotionで管理している情報が、将来ほかの仕組みとつながる可能性があるなら、列名、状態、ID、入力ルールを早めに整えることが重要です。
Microsoft SupportとNotion Helpは、それぞれExcelやNotionでできることの公式情報として確認しました。Excelは大きな表や集計に使えます。Notionはページ、プロパティ、ビューでチームの情報を整理できます。ただし、どちらも「正式な業務システムとして必要な権限、外部入力、監査性、連携、保守」まで自動的に満たすものではありません。
だから、既存ツールで業務の型を整理し、試作で入力体験と運用を確かめ、本開発で安定運用へ進むという順番が実務では扱いやすくなります。
相談前の実践メモ
開発会社に相談する前に、今の業務を次の5つで書き出してください。
1. いま使っている台帳を書く
Excel、Notion、Google Sheets、紙、メール、LINEなど、実際に業務で使っている場所を書きます。きれいな資料ではなく、現物ベースで十分です。
2. 入力する人と見る人を分ける
入力する人、確認する人、承認する人、問い合わせを受ける人を分けます。ここが曖昧だと、管理画面や権限の要件が膨らみやすくなります。
3. 手動でよい部分を残す
初回から全部を自動化しようとすると、例外処理まで大きくなります。実務上の目安として、月に数回しか起きない例外や、担当者が目で見た方が安全な判断は、最初は手動でも構いません。
4. 自動化しないと価値が出ない部分を決める
一方で、申込直後の通知、担当者へのアラート、入力漏れの防止、ステータス変更の記録などは、自動化することで価値が出やすい部分です。ここを試作の中心にすると、効果を確認しやすくなります。
5. まず1つの業務だけに絞る
予約、申込、問い合わせ、請求前確認、イベント管理など、最初は1つに絞ってください。複数業務を同時にシステム化しようとすると、共通化の議論が先に膨らみ、試すべき入口が見えにくくなります。
開発前チェック
次のうち3つ以上当てはまるなら、ExcelやNotionの整理だけで止めず、試作を検討する価値があります。
- 外部の人に入力してもらう
- 入力後に自動通知したい
- 管理者がステータスを変更する
- 申込、予約、問い合わせなどの受付導線がある
- 権限ごとに見せる情報を変えたい
- CSV出力や外部サービス連携が必要
- 担当者が変わると運用が止まりそう
- 最新版の台帳が分からなくなることがある
- 手作業の転記や確認漏れが起きている
- 本開発の見積もりを取るには前提が曖昧
逆に、当てはまる項目が少ないなら、まずExcelやNotionの列、ステータス、担当者、入力ルールを整えるだけで十分かもしれません。
次にやること
まず、今の業務を「Excelで続ける」「Notionで整理する」「試作で確認する」の3列に分けてください。完全に正しく分類する必要はありません。迷う項目があること自体が、相談時の論点になります。
そのうえで、試作候補を1つだけ選びます。おすすめは、転記が多い業務、通知漏れが起きやすい業務、社外の人が入力する業務です。ここは小さく作っても効果を見やすいからです。
もし、何から整理すべきか迷う場合は、先に開発外注前チェックリストで相談前の材料をそろえてください。どこまで作るかの段階で迷う場合は、MVP・試作・本開発の違いも参考になります。
業務システムは、いきなり大きく作るものとは限りません。ExcelやNotionで業務の型を見つけ、試作で流れを確かめ、必要なところだけ本開発に進む。その順番にするだけで、相談の不安も、見積もりのぶれも小さくできます。
参考情報
この記事では、次の公的・公式情報を確認しました。参照日はすべて2026年7月7日です。
- デジタル庁「デジタル社会推進標準ガイドライン」: ページ最終更新日 2026年6月12日。DS-100、DS-110、DS-120は2025年6月19日更新、策定日または最終改定日 2025年5月27日。DS-400 政府相互運用性フレームワークは2026年3月24日更新。
- GOV.UK Service Manual「How the discovery phase works」: Published 4 August 2016, Last updated 21 June 2021.
- Microsoft Support「Excel specifications and limits」: Excel for Microsoft 365、Excel 2024、Excel 2021、Excel 2019、Excel 2016に適用される仕様ページとして確認。ページ上で公開日・更新日は確認できませんでした。
- Notion Help Center「Intro to databases」: Notionデータベースの構造、プロパティ、ビューに関する公式ヘルプとして確認。ページ上で公開日・更新日は確認できませんでした。