「こんなの作れる？」からで大丈夫です｜オリジナル業務ツールが完成するまでの相談・設計・開発の流れ

「こんなの作れる？」からで大丈夫です｜オリジナル業務ツールが完成するまでの相談・設計・開発の流れ

「こういうツールが欲しいんですけど、説明の仕方が分かりません」

オリジナルツールの相談で、最初にここを心配する必要はありません。

仕様書。

画面設計書。

データベース設計。

API仕様。

最初からそんなものを用意できる人のほうが少ないです。

むしろ、

「今これが面倒」

「こんな画面があれば楽そう」

「Excelでは限界を感じている」

ここから始まるほうが自然です。

僕が新しいツールを考えるときも、いきなりコードは書きません。

まず見るのは、

誰が使うのか。

今はどうしているのか。

どこが面倒なのか。

何ができたら成功なのか。

ここです。

この記事では「こんなの作れる？」という状態から、オリジナル業務ツールが形になるまでを、できるだけ専門用語なしで整理します。

最初に必要なのは仕様書ではなく「今のやり方」

相談するときに一番助かるのは、完成された仕様書ではありません。

今の業務が分かるものです。

例えば、

・今使っているExcel

・Googleスプレッドシート

・手書きのメモ

・画面のスクリーンショット

・入力している項目

・完成後に出したい帳票

・作業の順番を書いた箇条書き

このくらい。

「毎朝このファイルを開く」

「ここをコピーする」

「この条件だけ残す」

「最後にメールする」

これだけでも、かなり情報があります。

むしろ開発側からすると、

今どう動いているかが見えれば、

「ここは自動化できそう」

「ここは人の確認を残したほうがいい」

「ここは既存ツールを使えばいい」

と整理できます。

きれいな資料より、普段の作業そのもののほうが役に立つことがあります。

1段階目は「何を作るか」ではなく「何をなくすか」

最初に、

「在庫管理システムを作りたい」

「顧客管理ツールを作りたい」

と名前から入ることがあります。

でも僕は、その前に一度止めます。

何をなくしたいですか？

手入力。

二重入力。

探す時間。

集計。

確認漏れ。

メール作成。

ファイル整理。

ここが分かると、必要な機能が見えます。

例えば「顧客管理」と言っても、

会社名を一覧で見たいだけなのか。

履歴を残したいのか。

担当者へ通知したいのか。

見積書まで作りたいのか。

全部違います。

名前だけでシステムを決めると、余計な機能を作りやすいです。

なので最初は、

今の作業。

困っている場所。

理想の状態。

この3つを並べます。

2段階目は「最初に作る範囲」を決める

オリジナルツールで失敗しやすいのが、

最初から全部入れることです。

登録。

編集。

削除。

検索。

CSV。

PDF。

メール。

権限。

履歴。

スマホ。

ダッシュボード。

思いつくものを全部入れる。

気持ちは分かります。

せっかく作るなら全部欲しいです。

でも、機能が増えるほど、

開発時間。

テスト。

操作説明。

保守。

も増えます。

そして一番怖いのは、作った後に、

「この機能ほとんど使わないですね」

となることです。

はい。

作った側も少し遠い目になります。

だから僕は、

「これがないと業務が変わらない」

という部分から作るのがいいと思っています。

例えば、

入力と一覧だけ。

検索とPDFだけ。

CSV取込と集計だけ。

最初はそれでいい。

使われることを確認してから広げます。

3段階目は画面を見ながら詰める

文章だけで仕様を決めるのは難しいです。

「一覧画面が欲しい」

と言っても、人によって想像しているものが違います。

10項目並ぶ表。

カード形式。

スマホ中心。

PC中心。

全然違います。

そこで、早めに画面イメージを作ります。

最近はChatGPT、Claude Code、Cursorなどを使うことで、たたき台を作るスピードも上がりました。

最初の画面を見てもらうと、

「ここはいらない」

「この順番がいい」

「このボタンは上に欲しい」

「スマホだとこの入力が大変そう」

と、急に具体的になります。

これが大事です。

仕様書を見て「分かりました」と言っても、

完成画面を見た瞬間に「思ってたのと違う」は普通に起きます。

だから早めに見えるものを出す。

完璧なデザインではなくていいです。

操作の流れが合っているかを先に見ます。

4段階目は「普通に動く」より例外を決める

登録ボタンを押した。

保存できた。

ここまでは作りやすいです。

実務ツールで時間がかかるのは、その周りです。

空欄だったら？

同じデータを2回登録したら？

通信途中で止まったら？

削除したデータを戻したくなったら？

2人が同時に編集したら？

権限のない人が開いたら？

こういうケース。

利用者はわざと壊そうとしているわけではありません。

普通に仕事をしているだけで起きます。

なので、

正常に動くこと。

だけではなく、

失敗したときにどうするか。

を決めます。

例えば、

入力ミスなら画面で知らせる。

重複なら登録しない。

エラーならログを残す。

削除は完全削除せず戻せるようにする。

このあたりはツールによって変わります。

業務用は、この地味な部分がかなり大事です。

5段階目は「誰が使うか」をもう一度見る

開発中は機能に目が行きます。

でも完成前に、もう一度利用者を見ます。

PCが得意な人だけが使うのか。

普段スマホ中心なのか。

毎日使うのか。

月1回なのか。

新人も触るのか。

ここで操作方法が変わります。

開発者しか分からない画面はダメです。

ボタン名を見て何をするか分からない。

入力順が分からない。

保存されたのか分からない。

こういう小さなストレスが積み上がると、

便利なはずのツールが使われなくなります。

そして最後にExcelへ戻る。

これは避けたいです。

僕は「高機能」より、

次に押す場所が分かる。

を大事にしたいです。

6段階目は実際のデータで試す

テスト用データでは動く。

これはスタートです。

本番に近いデータを入れると、

名前が長い。

空欄がある。

古い形式が混ざる。

想定外の文字が入る。

件数が多い。

いろいろ出ます。

そのため、納品前には実際の運用に近い条件で確認します。

可能なら利用者自身にも触ってもらいます。

開発者が何度操作しても、

現場の人が一度触ったほうが見つかる問題があります。

「そこ押すんだ」

みたいなやつです。

はい。

作った側には見えないんですよね。

完成後も「変えられる」前提で考える

業務は変わります。

担当者が増える。

項目が増える。

帳票が変わる。

別サービスを使い始める。

なので、オリジナルツールは最初の納品で永遠に完成ではありません。

だからこそ、

データと画面を分ける。

設定値をコードへ埋め込みすぎない。

変更しそうな項目を整理する。

など、後から直しやすい形を考えます。

もちろん、最初から未来を全部予測することはできません。

僕にも無理です。

なので、

「変わりそうなところだけ、変えやすくしておく」

くらいが現実的です。

相談前に準備するなら、この5つだけ

もし今、

「オリジナルツールを相談してみたい」

と思っているなら、次の5つがあると話が早いです。

1. 今使っているもの

Excel、紙、既存システムなど。

2. 今の作業手順

ざっくり箇条書きで十分です。

3. 一番面倒な場所

全部ではなく、一番困っているところ。

4. 利用する人数

1人か10人かで構成が変わります。

5. 最終的にどうなればうれしいか

「毎朝の30分をなくしたい」

「外出先から確認したい」

「二重入力をなくしたい」

このくらいで大丈夫です。

プログラミング言語は決めなくていいです。

データベースも決めなくていいです。

そこは要件を見て決めます。

「こんなの作れる？」が一番最初でいい

システム開発というと、

要件を全部固めてから依頼する。

というイメージがあります。

でも、小さな業務ツールなら、

「こんなの作れますか？」

から始めて問題ありません。

話してみて、

実はExcelだけで直せる。

GASで十分。

Pythonを使う。

Webアプリにする。

既存SaaSを使ったほうがいい。

という結論になることもあります。

それでいいです。

最初から作ることをゴールにしない。

今の作業を楽にする方法を探す。

その結果としてオリジナルツールが合うなら作る。

僕はその順番のほうが、長く使えるものになりやすいと思っています。

「頭の中にはあるけど、うまく説明できない」

その状態でも大丈夫です。

今の作業を見ながら、一緒に言葉にしていけば形になります。