「欲しい機能があるツールが見つからない」なら作れます|既製品に仕事を合わせる前に考えたい“専用ツール”という選択肢
「探せば何かあると思ったんですけど、ちょうどいいツールがないんですよね」
業務改善の話をしていると、珍しくない悩みです。
勤怠、顧客管理、在庫管理、日報、予約、見積、進捗管理。
世の中には便利なサービスがたくさんあります。
それでも実際に使おうとすると、
「この項目だけ足りない」
「この画面はいらない」
「ここだけExcelに戻る」
「結局、最後は手入力」
「会社のやり方をツール側に合わせないといけない」
となることがあります。
既製品が悪いわけではありません。
むしろ、条件が合うなら既製品を使ったほうが早いです。
ただ、仕事のほうを無理に変えてまでツールへ合わせ始めたら、一度だけ別の選択肢も考えていいと思っています。
自分たちの業務に合わせて、必要な機能だけを持った専用ツールを作る。
今回は、既製品を使い続けるケースと、専用ツールを考えたほうがいいケースを分けてみます。
「あと1個だけ足りない」が意外と重い
既製品を探していると、最初はかなり良さそうに見えます。
一覧がある。
検索できる。
CSVも出せる。
スマホにも対応している。
ここまで見ると「これでいけそう」です。
でも運用を始めると、
「登録した後にこの帳票も出したい」
「この条件のときだけ担当者へメールしたい」
「A部署にはここまで見せたい」
「入力した内容を別の一覧にも反映したい」
みたいな、自社固有の部分が出てきます。
その1個を補うためにExcelを横へ置く。
ツールからCSVを出す。
Excelへ貼る。
関数で加工する。
メールへ添付する。
はい。
気づくと、新しいツールを入れたのに手作業が増えています。
「システム化したはずなのに、人が間をつないでいる」
これは結構あります。
僕が気になるのは、この“人がつなぐ作業”です。
そこが毎回同じなら、本当はツール側へ寄せられる可能性があります。
専用ツールは大げさなものじゃなくていい
「オリジナルツールを作る」と聞くと、
何百万円。
半年開発。
サーバー構築。
専任担当者。
みたいなイメージを持つ人もいると思います。
もちろん大規模なシステムならそうなります。
でも、業務改善で使う専用ツールはもっと小さく始められます。
例えば、
・入力フォーム
・一覧表示
・検索
・絞り込み
・CSV出力
・PDF作成
・メール通知
・簡単な権限分け
・履歴保存
この中から、本当に必要なものだけ。
最初は「登録して一覧を見る」だけでもいいです。
使ってみて、
「やっぱりPDFも欲しい」
「スマホでも確認したい」
「担当者別に表示を変えたい」
となったら追加する。
この進め方のほうが、最初から全部を作り込むより失敗しにくいです。
開発側としても、実際に使われた後の要望のほうが精度が高いんですよね。
打ち合わせ中に想像した要望より、
1週間使って出てきた「ここ面倒」のほうが強い。
机上の完璧な仕様書より、現場の「これ毎回押すの嫌なんですよ」が勝つことがあります。
Excelのままが正解なことも普通にある
ここは外したくないところです。
専用ツールの記事を書いているからといって、何でもWebアプリ化したほうがいいとは思っていません。
例えば、
利用者が1人。
月に数回しか使わない。
データ量も少ない。
複雑な権限もいらない。
最終成果物がExcel。
この条件なら、ExcelやVBAのまま直したほうがいいことがあります。
GoogleスプレッドシートとGASで十分なケースもあります。
逆に、
複数人で同時に使う。
スマホからも入力したい。
誰が変更したか残したい。
データを一元管理したい。
検索や絞り込みを頻繁に使う。
外部サービスと連携したい。
こうなると、専用のWebツールを考えやすくなります。
大事なのは「Webアプリを作ること」ではありません。
今の仕事に一番合う形を選ぶことです。
僕はここを先に決めたいです。
新しい技術を使ったほうが格好いい。
それは開発者側の都合です。
利用者からしたら、毎朝ちゃんと動くほうが大事です。
「専用」の良さは機能を増やせることではない
専用ツールのメリットとして、
「好きな機能を追加できます」
と言われることがあります。
もちろんそれもあります。
でも僕は、むしろ逆だと思っています。
いらない機能を入れなくていい。
これが大きいです。
市販サービスは、多くの会社に使ってもらう必要があります。
だから機能が増えます。
設定画面。
権限。
通知。
ダッシュボード。
分析。
連携。
全部必要な会社もあります。
一方で、自社では3画面しか使わないかもしれません。
それなら、
登録。
一覧。
出力。
この3つだけで迷わない画面を作る。
そのほうが現場では使いやすいことがあります。
「高機能」と「使いやすい」は同じではありません。
ここ、システムを作る側にいると忘れそうになります。
僕も機能を追加したくなります。
作れると入れたくなるんですよね。
でも、それをやるとボタンだらけになります。
なので最近は「この機能、本当に使います?」を先に聞くほうが大事だと思っています。
ChatGPTやClaude Codeで作れる時代だからこそ
ChatGPT、Claude Code、Cursorが出てきて、ツールを作るハードルはかなり下がりました。
簡単な画面なら、以前より速く形にできます。
これは間違いなく良い変化です。
ただし、
画面ができた。
ボタンが動いた。
ここで業務ツールが完成するわけではありません。
誰が使うのか。
同時に操作したらどうするのか。
間違って削除したら戻せるのか。
データはどこへ保存するのか。
ログインは必要か。
バックアップはどうするのか。
将来項目が増えたらどうするのか。
実際に仕事へ入れるなら、このあたりも考えます。
コードを書くスピードが上がった分、
「何を作るか」を決めるほうが重要になった感じがあります。
だから、
「ChatGPTで作ったけど途中で分からなくなった」
でも全然おかしくありません。
コードの問題ではなく、設計を決める段階に来ただけのこともあります。
既製品と専用ツールの簡単な分け方
僕なら最初に3つ見ます。
1つ目。
既製品で業務の8割くらい満たせるか。
満たせるなら、まず既製品を候補にします。
2つ目。
足りない2割を人が毎日補っていないか。
毎回CSVを出して加工。
別システムへ転記。
メールへ貼り付け。
ここが重いなら専用化を検討します。
3つ目。
その業務が今後も続くか。
年に1回、10分の作業を自動化しても費用対効果は出にくいです。
毎日30分。
毎週2時間。
複数人が同じことをしている。
こういう仕事ほど仕組みにする意味が出ます。
## 「こんなのあれば」で相談して大丈夫です
専用ツールを作りたいと思っても、
「仕様書が書けない」
「何の言語がいいか分からない」
「WebアプリなのかGASなのかも分からない」
ここで止まる人がいます。
そこは最初に決まっていなくて大丈夫です。
むしろ、
今は何を使っているか。
どこが面倒か。
理想として何ができればうれしいか。
この3つのほうが重要です。
例えば、
「毎日このExcelを更新しています」
「このあと3か所へ転記しています」
「本当は1画面で終わらせたいです」
これで十分スタートできます。
そこから、
Excelを直すのか。
GASを使うのか。
Pythonで裏側を処理するのか。
Webアプリにするのか。
順番に決めればいいです。
既製品を何個探しても微妙に合わない。
そんなときは、仕事のほうを無理やりツールへ合わせる前に、
「自分たちの仕事に合わせた道具を作る」
という選択肢もあります。
大げさなシステムでなくても構いません。
毎日触る人が、
「これなら楽になった」
と思えるもの。
専用ツールは、そこからでいいと思っています。