システム開発の相談では、最初から完璧な仕様書が必要なわけではありません。一方で、何も整理しないまま「とりあえずシステムを作りたい」と進めると、作る範囲が広がりすぎたり、現場で使われない機能が増えたりします。開発前に重要なのは、作りたい機能を並べることではなく、今の業務で何が起きていて、何を変えたいのかを明確にすることです。
まず「何を作るか」ではなく「何を変えるか」を決める
システム開発の出発点は、画面や機能ではなく、業務上の変化です。たとえば「管理画面がほしい」という要望でも、背景には、確認作業を減らしたい、入力ミスを防ぎたい、担当者しか分からない状態をなくしたい、複数拠点の情報を一元化したい、といった目的があります。この目的が曖昧なままだと、機能は増えても課題が残る可能性があります。最初に、現状の困りごと、理想の状態、利用者、判断に必要な情報を整理することで、開発すべき範囲が見えやすくなります。
- 現在どの業務に時間がかかっているか
- どの作業でミスや確認漏れが起きているか
- 誰が、どのタイミングで、何を判断しているか
- システム化後に減らしたい作業・増やしたい価値は何か
利用者と運用者を分けて考える
システムを使う人と、システムを管理する人は同じとは限りません。現場担当者、管理者、経営側、外部パートナーなど、関係者によって見たい情報や操作したい内容は異なります。利用者の整理が不十分だと、権限設計や画面構成が曖昧になり、リリース後に運用しづらくなります。誰が毎日使うのか、誰が承認するのか、誰がデータを修正するのか、誰が問い合わせを受けるのかを事前に分けて考えることが重要です。
- 日常的に入力・確認する人
- 承認・判断する人
- マスターデータを管理する人
- トラブル時に対応する人
作る・つなぐ・既存サービスを使うを比較する
すべてを独自開発する必要はありません。既存SaaSで足りる部分、API連携で解決できる部分、独自開発すべき部分を分けることで、過剰な開発を避けられます。特に、会計、決済、メール配信、認証、ファイル管理などは、既存サービスを活用した方が合理的な場合があります。一方で、自社固有の業務ルールや複雑なワークフロー、既存データとの関係が重要な部分は、独自開発やカスタム連携が必要になることがあります。
- 既存SaaSで十分な業務
- APIや自動化でつなげばよい業務
- 自社固有ルールが強く独自開発が必要な業務
- まず小さく検証すべき不確実な業務
既存データと既存システムを確認する
新しいシステムを作る場合でも、既存のExcel、スプレッドシート、業務SaaS、古い社内システム、顧客データなどとの関係を無視できません。どのデータを移行するのか、どのデータを正とするのか、更新タイミングをどう扱うのかを決めないまま開発すると、二重入力やデータ不整合が残ります。開発前には、現在どこにどの情報があり、誰が更新し、どの業務で使われているかを整理しておく必要があります。
- 現在使っているExcel・SaaS・社内システム
- 移行すべきデータと残すデータ
- 正しい情報の管理場所
- 外部サービスとの連携要否
最初から全部作らず、段階を分ける
業務システムは、一度にすべての機能を作るより、重要な業務から段階的に作った方がうまく進むことがあります。最初の範囲を小さくすれば、現場で実際に使いながら改善点を見つけられます。反対に、最初から全機能を作ろうとすると、仕様調整に時間がかかり、完成時には業務が変わっていることもあります。最初のリリースで何を実現し、次の段階で何を追加するかを分けることが重要です。
- 最初に解決する業務を絞る
- 後から追加できる機能を分ける
- 検証が必要な機能はPoCにする
- リリース後の改善サイクルを決める
運用後に誰が使い、誰が改善するかを考える
システムはリリースして終わりではありません。運用後には、利用者からの問い合わせ、データ修正、権限変更、業務ルールの変更、機能改善の要望が出てきます。これらを誰が受け、どの優先順位で改善するのかを決めておかないと、せっかく作ったシステムが使いづらいまま放置されます。開発前から運用体制を考えることで、使われ続けるシステムに近づきます。
- 管理者と利用者の役割
- データ登録・更新の責任
- 権限・承認フロー
- 改善要望の扱い方