何を作ればいいか、まだ分からないときは？

小さなWebアプリや業務改善の相談では、最初から仕様が固まっていないことがよくあります。むしろ、画面、機能、権限、データ項目まで整理できているなら、すでにかなり検討が進んでいます。実際には「毎回この確認が面倒」「スプレッドシートが複雑になってきた」「担当者が休むと分からない」「月末だけ妙に時間がかかる」といった違和感から始まることが多いです。

この段階で、画面や機能を急いで決める必要はありません。ただし、「仕様がなくても開発できる」という意味ではありません。開発に入る前には、作る範囲、扱う情報、確認方法、運用の責任を整理する必要があります。まずは完成した仕様書よりも、いまの業務で何が重くなっているかを見ることが重要だと考えています。

仕様書より先に、業務の流れを見る

最初に確認したいのは、作りたい画面の数ではなく、業務がどう流れているかです。誰が依頼を受け、どこに入力し、誰が確認し、どの時点で判断し、最後に何を残すのか。どの作業に時間がかかり、どこでミスが起きやすく、どの部分は今のままで問題ないのか。そこを整理すると、作るべき部分と作らない部分が見えてきます。

たとえば「管理画面がほしい」という相談でも、よく聞くと本当に必要なのは、入力内容のチェック、対応状況の一覧、月次の出力だけかもしれません。逆に「ちょっとした一覧がほしい」という依頼でも、権限、履歴、外部サービス連携、個人情報の扱いを考える必要がある場合もあります。最初の言葉だけで作り始めると、軽くしたかった業務がかえって重くなることがあります。

「何を作るか」より先に、「何を軽くしたいか」を見る。作り始める範囲を決めるときは、ここを判断の基準にしています。

作るべきでないものを見極める

作るものを決めるときには、作らずに残す方がよい部分も探します。既存ツールで十分に回るなら、それを使い続けた方がよい場合があります。スプレッドシートで柔軟に直した方が早い業務もあります。手作業のまま残した方が、人の判断を入れやすい場面もあります。

Webアプリ化する価値が出やすいのは、繰り返し発生し、ルールがある程度決まっていて、抜け漏れや確認負担が大きい部分です。

• 同じ情報を複数の場所へ入力している
• 確認済みかどうかを毎回探している
• 月次報告や請求前チェックで似た作業を繰り返している
• 担当者ごとに判断基準が違い、引き継ぎづらい
• 作業履歴や対応状況をあとから確認したい

このような部分だけを小さくアプリ化できれば、既存の運用を壊さずに負担を減らせます。逆に、年に数回しか発生しない作業や、例外が多すぎて毎回人が考える必要がある作業は、無理にアプリ化しない方がよいこともあります。

小さなプロトタイプから始める

仕様が曖昧なときは、大きく作るより小さく試す方が向いています。まずは最低限の入力画面、一覧、確認ステータス、出力だけを作り、実際の業務に当てはめてみる。そこで「この項目はいらない」「ここで確認したい」「この順番だと使いにくい」といったことが分かります。

小さなプロトタイプは、完成品ではありません。業務への理解を深めるためにも役立ちます。文章だけで仕様を詰めるより、触れる形にした方が、利用者も判断しやすくなります。特に小さなチームでは、最初から大きな仕組みを作るより、使いながら必要な範囲を確かめる方が合っていることが多いです。

もちろん、プロトタイプのまま本番運用に入ってよいわけではありません。実際に使う段階では、データの保存、権限、バックアップ、誤操作、問い合わせ先なども考える必要があります。小さく始めるのは、曖昧なまま進めるためではなく、判断材料を早く得るためです。

困っている作業を書き出す

画面構成や技術選定より先に、次のことを書き出してみます。

• 今どの作業が面倒か
• どの情報を何度も入力しているか
• どこで確認漏れや手戻りが起きるか
• 誰が使い、誰が確認するのか
• どのツールは今後も使い続けたいか

そこから、既存ツールで済むのか、運用を少し直せばよいのか、小さなWebアプリにする価値があるのかを整理できます。すぐに開発へ進むより、まず作るべき範囲を絞る方が、結果として無駄な作り込みを避けやすくなります。

仕様が固まっていなくても、業務の流れや実現したいことが分かれば、検討は始められます。完成した仕様書を最初から揃えるよりも、何を確かめ、どこから取り組むかを順に整理することが大切です。