情報を届けることが中心なら、Webサイト
事業を紹介する、サービスの特徴を伝える、記事を読んでもらう。こうした目的では、情報の並び方や文章、読む人が次に進みやすい導線が中心になります。
たとえば修理サービスのサイトなら、対応できる内容、依頼方法、料金の考え方、問い合わせ先が必要です。会員登録がなくても、読んだ人が依頼を検討できれば、目的を果たせる場合があります。
フォームやブログのような機能があるからといって、サイト全体を大きなシステムとしてつくる必要があるとは限りません。
情報を入力し、作業を進めることが中心なら、Webアプリ
依頼の状態を更新する、担当者ごとの仕事を確認する、入力内容を集計する。こうした用途では、利用者の操作とデータの扱いが重要になります。
たとえば社内の修理受付管理なら、受付内容の登録、担当者の割り当て、進捗の変更、履歴の確認といった操作が必要です。見た目だけでなく、誰がどの情報を見たり変更したりできるかまで考えます。
ログインや権限、データの保管、バックアップなども、扱う情報や運用に応じて検討が必要になります。画面が一つでも、裏側の条件によって作業範囲は変わります。
同じ事業でも、役割を分けて考えられる
| やりたいこと | 中心となるもの |
|---|---|
| 対応メニューをお客さまに紹介する | サービス紹介サイト |
| 相談内容を受け取り、メールで確認する | サイトと問い合わせフォーム |
| 社内で担当・進捗・履歴を共有する | 業務用のWebアプリ |
| お客さま自身が依頼状況を確認する | 認証や権限を含むWebアプリ |
この区分は、見積もりを一律に決めるためのものではありません。目的を伝えるための整理です。サイトの問い合わせを、社内のアプリにつなげるような組み合わせも考えられます。
最初の一歩は「一つの作業」に絞る
最初からすべての業務を置き換えようとすると、確認すべき条件が増えます。まず、どの作業の手間を減らしたいかを一つ選び、その開始から完了までを書き出してみてください。
- 誰が、どんな情報を入力するか
- 入力後、誰が確認するか
- 何ができれば、その作業は完了するか
- 入力ミスや変更が起きたとき、どう戻すか
たとえば「問い合わせ内容を一か所にまとめ、対応済みかどうかがわかるようにする」。この程度の具体性があれば、必要な画面や操作を相談する出発点になります。
つくる前に、今ある道具で足りない理由も確かめる
新しく開発することが、いつも最初の答えとは限りません。既存の表計算や業務ツールで目的を満たせるかを確認し、それでも残る困りごとを整理すると、開発する範囲を絞りやすくなります。
逆に、独自の手順や画面が必要で、既存の方法では何度も同じ手作業が発生するなら、小さなアプリをつくることを検討できます。初期制作だけでなく、誰が使い方を管理し、変更時にどう対応するかもあわせて考えましょう。
KSCへのご相談では、最初から「サイト」「アプリ」を決めていただく必要はありません。今の作業と、できるようにしたいことを文章で共有いただければ、必要な範囲を一緒に整理します。