小さなWebアプリや業務改善の相談では、最初から仕様が固まっていないことがよくあります。むしろ、画面、機能、権限、データ項目まで整理できているなら、すでにかなり検討が進んでいます。実際には「毎回この確認が面倒」「スプレッドシートが複雑になってきた」「担当者が休むと分からない」「月末だけ妙に時間がかかる」といった違和感から始まることが多いです。
cyfr では、その段階から相談できることを大事にしています。ただし、これは「仕様がなくても開発できる」という意味ではありません。開発に入る前には、作る範囲、扱う情報、確認方法、運用の責任を整理する必要があります。相談の初期段階では、完成した仕様書よりも、いまの業務で何が重くなっているかを一緒に見ることが重要だと考えています。
仕様書より先に、業務の流れを見る
最初に確認したいのは、作りたい画面の数ではなく、業務がどう流れているかです。誰が依頼を受け、どこに入力し、誰が確認し、どの時点で判断し、最後に何を残すのか。どの作業に時間がかかり、どこでミスが起きやすく、どの部分は今のままで問題ないのか。そこを整理すると、作るべき部分と作らない部分が見えてきます。
たとえば「管理画面がほしい」という相談でも、よく聞くと本当に必要なのは、入力内容のチェック、対応状況の一覧、月次の出力だけかもしれません。逆に「ちょっとした一覧がほしい」という依頼でも、権限、履歴、外部サービス連携、個人情報の扱いを考える必要がある場合もあります。最初の言葉だけで作り始めると、軽くしたかった業務がかえって重くなることがあります。
「何を作るか」より先に、「何を軽くしたいか」を見る。これは、cyfr が小さなWebアプリ開発や業務改善相談で大事にしている判断基準です。
作るべきでないものを見極める
相談の価値は、作るものを決めることだけではありません。作らない方がよいものを見極めることも価値です。既存ツールで十分に回るなら、それを使い続けた方がよい場合があります。スプレッドシートで柔軟に直した方が早い業務もあります。手作業のまま残した方が、人の判断を入れやすい場面もあります。
Webアプリ化する価値が出やすいのは、繰り返し発生し、ルールがある程度決まっていて、抜け漏れや確認負担が大きい部分です。
- 同じ情報を複数の場所へ入力している
- 確認済みかどうかを毎回探している
- 月次報告や請求前チェックで似た作業を繰り返している
- 担当者ごとに判断基準が違い、引き継ぎづらい
- 作業履歴や対応状況をあとから確認したい
このような部分だけを小さくアプリ化できれば、既存の運用を壊さずに負担を減らせます。逆に、年に数回しか発生しない作業や、例外が多すぎて毎回人が考える必要がある作業は、無理にアプリ化しない方がよいこともあります。
小さなプロトタイプから始める
仕様が曖昧なときは、大きく作るより小さく試す方が向いています。まずは最低限の入力画面、一覧、確認ステータス、出力だけを作り、実際の業務に当てはめてみる。そこで「この項目はいらない」「ここで確認したい」「この順番だと使いにくい」といったことが分かります。
小さなプロトタイプは、完成品ではありません。業務を理解するための道具でもあります。文章だけで仕様を詰めるより、触れる形にした方が、利用者も判断しやすくなります。特に小さなチームでは、最初から大きな仕組みを作るより、使いながら必要な範囲を確かめる方が合っていることが多いです。
もちろん、プロトタイプのまま本番運用に入ってよいわけではありません。実際に使う段階では、データの保存、権限、バックアップ、誤操作、問い合わせ先なども考える必要があります。小さく始めるのは、曖昧なまま進めるためではなく、判断材料を早く得るためです。
相談の入口は、困っている作業でよい
相談するときに、画面構成や技術選定まで決めておく必要はありません。最初は、次のような情報があれば十分に話を始められます。
- 今どの作業が面倒か
- どの情報を何度も入力しているか
- どこで確認漏れや手戻りが起きるか
- 誰が使い、誰が確認するのか
- どのツールは今後も使い続けたいか
そこから、既存ツールで済むのか、運用を少し直せばよいのか、小さなWebアプリにする価値があるのかを一緒に整理します。すぐに開発へ進むより、まず作るべき範囲を絞る方が、結果として無駄な作り込みを避けやすくなります。
仕様が固まっていない段階でも、業務の流れや困っている場面が分かれば相談は始められます。小さなWebアプリ化、業務改善相談、技術顧問として整理したいことがあれば、サービスページ（/services）で支援内容を確認し、相談ページ（/contact）から連絡できます。最初は「この作業を軽くしたい」という粒度で構いません。
相談の入口
似た業務の整理や小さなWebアプリ化を相談できます。
記事に近い課題がある場合は、サービス内容を見たうえで、まだ仕様が決まっていない段階から相談できます。過度に作り込まず、まず軽くできる範囲から一緒に整理します。