Webアプリ開発を小さく始めるには？段階的に作って改善する進め方

小さく始める3つの利点

• 早く使い始められる：範囲が小さい分、開発期間が短くなり、効果を早く得られる
• 使ってみて分かることを反映できる：机上では気づかなかった使い勝手や、本当に必要な機能が見えてくる
• 無駄な開発を避けられる：「あると便利」と思っていた機能が、実は不要だったと分かることもある

業務用のWebアプリは、使い始めてから「この項目は一覧に出ていてほしい」「この作業も一緒にできると楽だ」といった要望が出てくるものです。最初から完璧を目指すより、使いながら改善するほうが、現場に合った仕組みになります。

例：社内申請の仕組みを段階的に作る

考え方をつかむための例です（特定の企業の事例ではありません）。従業員30名ほどの会社で、備品購入や経費の申請を、紙の申請書とメールで回しているとします。困っているのは「申請がどこで止まっているか分からない」「承認済みの申請を経理が探すのに時間がかかる」の2点です。

第1段階だけで、「どこで止まっているか分からない」「承認済みを探せない」という二つの課題は解決します。金額による承認ルートの分岐は、第1段階を使ってみて「上長の承認が必要な申請はどのくらいあるか」が分かってから決めても遅くありません。

最初の版の範囲の決め方

1. いちばん困っている作業を一つ選ぶ：時間がかかる、ミスが多い、属人化している作業
2. その作業を解決する最小の機能を考える：登録、一覧、詳細、ステータスなど、基本の組み合わせから
3. 例外は後に回す：頻度の低いケースは、当面は手作業や備考欄で対応する
4. 便利機能は後に回す：通知、集計、帳票の自動作成などは、運用を見てから判断する

上の例でいえば、「承認ルートの分岐」は例外、「領収書の画像管理」は便利機能にあたります。どちらも大切ですが、最初の課題を解決するのに欠かせないものではありません。

小さく始めてよいか、最初から広く作るべきか

小さく始めるか、まとめて作るかは二択ではなく、業務と状況に合わせて選ぶものです。補助金を使う場合のスケジュールの考え方は補助金でシステム開発をするときのスケジュールで解説しています。

小さく始めても、最初に考えておくべきこと

• 将来の利用者の広がり（他部署、他拠点、社外）
• 将来つなげたい業務や仕組み（会計、顧客管理、在庫など）
• 扱うデータの量の見込み
• 権限の考え方（将来、見せる範囲を分ける可能性があるか）

次の段階に進むかどうかの判断

• 使われているか：対象の担当者が日常的に使っているか、紙やメールに戻っていないか
• 課題は解決したか：最初に選んだ作業は楽になったか
• 現場の要望：使っている人から、どんな改善の要望が出ているか
• 残っている手作業：仕組みの外で、まだ手作業になっている部分はどこか

後回しにした機能や新しい要望は一つの一覧にまとめ、効果の大きさと費用の目安を書き添えておくと、次の段階の判断と社内での説明がしやすくなります。思いついた順に依頼すると、費用がかさみ、全体の使い勝手もちぐはぐになりがちです。

小さく始めることへの社内の合意

小さく始める進め方は合理的ですが、社内の理解がないと「これだけしかできないのか」と受け止められることがあります。最初の版で解決する課題と解決しない課題、後回しにした機能は「やらない」のではなく「次の段階の候補」であること、次の段階を判断する時期と担当者を、事前に関係者と共有しておきましょう。

相談の前に整理しておきたいこと

• いちばん困っている作業と、その作業に関わる人
• 今使っている道具（紙、Excel、メールなど）と、その見本
• 将来やりたいこと（最初の版に入れなくてよいもの）
• 使い始めたい時期と、その理由

費用の面から範囲を見直す方法はWebシステム開発の見積もりが高くなる理由と、費用を抑える方法、新規事業の場合はMVPとは？機能の絞り込み方、進め方でつまずきやすい点は業務アプリ開発で失敗する会社の共通点で解説しています。

最初の版と次の段階を分けて考えます

Tailboneは、目的がはっきりしたWebアプリを、必要な範囲で素早く形にすることを得意としています。上の社内申請の例のように、いちばん困っている作業を伺い、最初の版に入れる範囲と次の段階の候補を分けて整理したうえで、初回納品後は合意した範囲内で使える状態まで調整します。次の段階は、使ってみた結果を踏まえて改めてご相談いただけます。