電話で受けた注文を紙に書き、棚の在庫を確認してからLINEで返事をする。メールで届いた追加希望を管理表へ転記し、夕方になってから「誰が対応したか」をもう一度確かめる。そんな作業を業務アプリにしたいと思うと、必要そうな機能が一気に増えていきます。

入力フォーム、一覧、通知、検索、月ごとの集計、管理画面、担当者メモ、権限設定。どれも業務に関係しているので、「初回から全部ほしい」と感じるのは自然です。ただ、全部を同じ重さで見積もると、相談内容が大きくなりすぎます。

この記事では、「その機能、本当に初回から必要？」を責める言葉ではなく、相談しやすくするための分け方として整理します。

全部ほしくなるのは自然です

「これも必要そう。外したら現場が困りそう。でも、全部入れたら見積もりが大きくなりそう」

たとえば、次のような場面です。

  • 電話、LINE、メールで受けた内容を一つの一覧へまとめたいが、検索や月ごとの集計も最初から必要に見える
  • 紙の申込書をフォームにしたいが、確認メール、前日通知、管理画面、集計画面も一緒に欲しくなる
  • 担当者へ知らせる仕組みを考えると、メール通知、チャット通知、未対応アラートの全部が必要に見える
  • 管理者だけが見る画面も、あとで困りそうなので初回から入れたくなる
  • 現場の人へ聞くと、それぞれ「これがないと困る」と言い、何を先に相談すればよいか分からない

業務アプリは、見た目の画面だけでは終わりません。

通知、一覧、確認メール、集計、管理画面のように、裏側の作業までつながっています。だから、最初から全部ほしいと思うのはおかしくありません。

ただし、開発会社へ相談するときは、全部を一つのかたまりにしない方が話しやすくなります。必要か不要かではなく、初回から必要か、設計だけ先に見るか、後で足せるかに分けます。

先に結論

業務アプリの機能は、次の4つに分けて相談します。

  1. 初回から必要：これがないと、現場の作業が最後まで進まない
  2. 初回で小さく試す：便利そうだが、使われ方を見てから広げたい
  3. 設計だけ先に見る：初回には作らないが、後で足せるようにしておきたい
  4. 今は作らない：今の手作業や既存サービスで続けても大きく困らない

この分け方にすると、「全部必要です」と伝えるより、開発会社が見積もりや進め方を考えやすくなります。

大切なのは、機能名だけで判断しないことです。

たとえば「通知」は、返信漏れが起きている現場では初回から必要かもしれません。一方で、担当者が一人だけなら、最初は一覧を見る運用でも回るかもしれません。

同じ機能でも、業務の流れによって扱いは変わります。

まず「最初に通したい流れ」を決める

機能を分ける前に、最初に通したい業務の流れを一つ選びます。

機能一覧から始めると、ほとんどが必要に見えます。通知も検索も集計も、あれば便利だからです。

先に決めるのは、「どの作業が最後まで通れば、現場が助かるか」です。

たとえば、注文対応なら次のように書けます。

  • お客様から電話、LINE、メールで注文が入る
  • 受付担当が注文内容を一覧へ入れる
  • 在庫担当が内容を確認する
  • 受付担当がお客様へ返事をする
  • 店長が未対応の注文だけを見る

この流れが見えると、初回から必要な機能も見えます。

注文内容の入力、対応状況の一覧、担当者への通知は必要かもしれません。月次集計、売上分析、細かい権限設定、見た目の作り込みは、後で足せるかもしれません。

GOV.UKのサービスマニュアルでは、作り始める前に問題、利用者、制約を理解することが大切だと説明されています（参考）。小さな業務アプリでも同じです。機能名より先に、誰がどの流れで困っているかを見ます。

デジタル庁の標準ガイドライン群も、サービス・業務改革と情報システム整備を共通ルールとして扱い、要件定義書や調達仕様書のテンプレートを示しています（参考）。これは政府向けの本格的な資料ですが、「業務とシステムを分けずに考える」という点は、開発相談前の整理にも使えます。

迷った機能は4つに分ける

ここから、思いついた機能を4つに分けます。

「初回から必要」は、これがないと最初に選んだ流れが止まるものです。

「初回で小さく試す」は、使われそうだが、実際の使い方を見てから広げたいものです。たとえば、担当者ごとのメモ欄、在庫の簡易表示、スマートフォンでの確認画面などです。

「設計だけ先に見る」は、初回には作らないものの、後で足す前提を開発会社へ伝えておくものです。月次集計を後で作りたいなら、日付や担当者は最初から保存しておく必要があります。

「今は作らない」は、今の道具で続ける方がよいものです。請求書作成は今使っている会計ソフトで続ける、予約は既存サービスで受ける、といった判断です。

分け方向いている機能主なメリットデメリット・確認点相談時の言い方
初回から必要

入力、一覧、通知、確認画面など、これがないと注文受付や申込対応が最後まで進まない

現場が実際に使える形になり、公開後の確認もしやすい

初回から必要に入れすぎると、見積もりと確認作業が大きくなりやすい

この流れが止まらないために、初回から必要な範囲を一緒に見たい

初回で小さく試す

担当者メモ、簡易集計、スマートフォン確認など、便利そうだが使われ方がまだ読めない

小さく入れて、使われるかを見てから本格的に広げられる

試す目的が曖昧だと、ただの追加機能になり、初回の範囲が広がる

この機能は小さく試し、現場が使うかを見てから広げたい

設計だけ先に見る

月次集計、詳細検索、外部連携、権限設定など、後で足したい可能性が高い

初回では作り込まず、後で困らない保存項目や画面の余地を確認できる

先に何を残すべきかを相談しないと、後で作り直しが増えることがある

初回には入れないが、後で足せるように必要な前提だけ確認したい

今は作らない

会計ソフト、予約サービス、スプレッドシートなど、今の道具で大きく困っていない作業

作る範囲を増やさず、慣れている道具を活かせる

手で移す作業は残る。どこまで手作業で許容できるかを決める

この部分は今の道具で続け、必要になったら改めて考えたい

これは、機能を削るための表ではありません。

全部必要に見える機能を、相談しやすい順番へ並べ直すための表です。

根拠から見た考え方

業務アプリの開発では、「全部をそろえてから公開する」より、「現場で使う流れを早めに出し、学んで直す」方が合う場面があります。

GOV.UKのアルファ段階の説明では、全体を試作する必要はなく、難しそうな部分に絞って確かめる考え方が示されています（参考）。ここでいうアルファは、一般公開する完成版ではなく、試すための段階です。

Scrum Guideでは、作るものの一覧を「Product Backlog」と呼び、順番のある一覧として扱います。また、短い期間で使える形のものを作り、確認しながら次を調整する考え方が説明されています（参考）。この記事では専門用語を使いすぎないため、「作るものの一覧」と言い換えます。

GOV.UKのユーザーストーリーの資料では、完了条件をチェックリストとして持つ考え方も紹介されています（参考）。完了条件とは、「何ができたら、その機能は使えると言えるか」を短く書いたものです。

たとえば、注文受付なら次のように書けます。

  • お客様の名前、連絡先、注文内容が一覧に残る
  • 未対応、確認中、返信済みの状態が分かる
  • 担当者へ確認依頼が届く
  • 返信済みの注文を後から探せる

この条件があると、「画面はできたが、現場では使えない」というズレを減らせます。

相談前にできる5つの整理

開発会社へ相談する前に、完璧な資料は不要です。

ただし、次の5つをメモしておくと、業務アプリの範囲を相談しやすくなります。

1. 今の作業を機能名に置き換えずに書く

最初は、日常の言葉で書きます。

  • 電話で注文を受け、紙に書く
  • 在庫棚を見に行き、担当者へ確認する
  • LINEでお客様へ返事をする
  • 夕方にスプレッドシートへ転記する

この粒度で十分です。

「注文管理」「在庫管理」「顧客管理」とまとめると、最初に何を楽にしたいのかが見えにくくなります。

2. 最初に通したい業務を一つ選ぶ

初回の相談では、複数の流れを同時に変えようとしない方が進めやすいです。

注文受付、予約変更、問い合わせ対応、申込管理などから、一つ選びます。

選ぶ基準は、次のどれかです。

  • 確認漏れが起きると、お客様へ迷惑がかかる
  • 毎日発生していて、担当者の負担が大きい
  • 紙や転記が多く、状況が見えにくい
  • 小さく試しても、現場が変化を感じやすい

全部を同時に選ばなくて大丈夫です。

3. 初回から必要かどうかは「流れが止まるか」で見る

初回から必要かどうかは、好みではなく、最初の流れが止まるかで見ます。

たとえば、注文受付なら、入力画面と対応状況の一覧は初回から必要になりやすいです。入力した内容を誰も見られなければ、業務が進まないからです。

一方で、月別グラフは便利でも、注文受付の流れが止まる原因にはなりません。この場合は、設計だけ先に見ておく形でもよいかもしれません。

4. 小さく試す機能には「何を確かめるか」を添える

小さく試す機能は、ただ入れるだけでは広がりすぎます。

次のように、確かめたいことを一つ添えます。

  • スマートフォン画面は、現場担当が実際に休憩時間でも確認できるかを確かめる
  • 在庫の簡易表示は、担当者が棚を見に行く回数を減らせるかを確かめる
  • メモ欄は、電話で聞いた補足を次の担当者が読めるかを確かめる

「便利そう」ではなく、「何が分かれば次に進むか」で考えます。

5. 後で足したい機能は、保存する情報を先に聞く

後で足したい機能は、放置する機能ではありません。

初回に作り込まない代わりに、あとで足せるかを確認します。

  • 月次集計を後で作るなら、日付や担当者が保存されている必要がある
  • 検索を後で強化するなら、検索したい項目が入力欄として残っている必要がある
  • 外部サービスとつなぐなら、相手のサービスが取り出せる情報を確認する必要がある

ここを相談しておくと、「初回には入れないが、後で困らない」形にしやすくなります。

初回から入れたくなりやすい機能

初回から入れたくなりやすい機能には、共通点があります。

それは、「あると便利」だが「最初の流れを終えるためには必須ではない」ものです。

  • 細かい検索条件は、最初はキーワード検索や一覧確認で代わりにできる場合がある
  • 詳細な権限設定は、最初に使う担当者が少ないなら簡単な分け方で始められる場合がある
  • 月別グラフや集計画面は、最初は一覧画面や手元の表で確認できる場合がある
  • デザインの細かい演出は、業務で使えるかを確認した後に整えても間に合う場合がある
  • 複数サービスとの自動連携は、最初は手で取り出す運用で試せる場合がある

もちろん、業務によっては初回から必要になるものもあります。

個人情報を扱う場合のアクセス管理や、誤送信を防ぐ確認画面は、最初から必要になることがあります。ここは「削る」のではなく、開発会社へ相談して安全な範囲を決めます。

業務アプリの機能整理チェック

全部にチェックが入らなくても大丈夫です。

未チェックの項目は、初回相談で一緒に決める項目です。

そのまま使える相談メモ

業務アプリの機能整理メモをコピーできます

全部必要に見える状態でも大丈夫です。今の流れ、初回から必要な機能、後で足したい機能を書いて相談できます。

業務アプリ開発で相談したい内容：

【今の業務の流れ】
例：電話で注文を受ける → 紙に書く → 在庫を確認する → LINEで返信する → 夕方に表へ転記する

【最初に楽にしたい一連の作業】
例：注文内容を一覧に集め、在庫確認の担当者へ知らせ、返信漏れを減らしたい

【初回から必要だと思うこと】
例：注文内容の入力、担当者への通知、対応状況の一覧、確認メール

【小さく試したいこと】
例：在庫数の簡易表示、担当者ごとの対応メモ、スマートフォンでの確認

【設計だけ先に見たいこと】
例：月次集計、細かい権限設定、外部サービスとの自動連携

【今は作らなくてもよいこと】
例：請求書作成は今使っている会計ソフトで続ける

【不安なこと】
例：外しすぎて現場が使えないものにならないか、逆に全部入れて費用が膨らまないか

【共有できる資料】
例：紙の注文票、今の管理表、LINEの定型文、確認メールの文面

次にやること

まず、今の業務から「最初に通したい流れ」を一つ選びます。

次に、思いついた機能を、初回から必要、小さく試す、設計だけ先に見る、今は作らない、の4つに分けます。迷った機能は、無理に初回へ入れず、「相談で確認したい」と書いておきます。

開発会社へ相談するときは、次の3つを聞いてください。

  1. この機能は、初回からないと現場の作業が止まるか
  2. 後で足す場合、最初から保存しておくべき情報はあるか
  3. 小さく試すなら、どのくらいの形から始められるか

Ready Mockの業務改善チェックでは、紙、電話、LINE、メール、転記、確認漏れのうち、どこから業務アプリ化するとよいか確認できます。機能一覧を作る前の入口整理に使えます。

参考情報

  • デジタル庁「デジタル社会推進標準ガイドライン」 - ページ最終更新日 2026年6月12日。DS-100/110/120は2025年6月19日更新、策定日または最終改定日 2025年5月27日。DS-121は策定日または最終改定日 2021年3月30日。業務改革と情報システム整備を一体で扱う考え方、要件定義書・調達仕様書テンプレートの位置づけを参照。2026年7月14日参照。
  • GOV.UK Service Manual「How the discovery phase works」 - Published 4 August 2016、Last updated 21 June 2021。作る前に問題、利用者、制約を理解する考え方を参照。2026年7月14日参照。
  • GOV.UK Service Manual「How the alpha phase works」 - Published 4 August 2016、Last updated 8 May 2019。全体を試作せず、難しい部分に絞って試す考え方を参照。2026年7月14日参照。
  • GOV.UK Service Manual「Writing user stories」 - Published 16 February 2016、Last updated 23 May 2016。利用者の行動と完了条件を短く整理する考え方を参照。2026年7月14日参照。
  • ScrumGuides.org「The 2020 Scrum Guide」 - HTML版は2020年11月版の直接移植。ページ上にHTML版の個別更新日は未確認。作るものの一覧、短い期間で使えるものを確認して次を調整する考え方を参照。2026年7月14日参照。