「システムを作ってほしい」と言われても、最初に作らない理由

最近、業務改善について企業や専門家の方とお話しする機会が少しずつ増えてきました。

相談の入口では、

「この仕事を自動化したい」

「管理システムを作れないか」

「AIを使えば楽にならないか」

という話になることがあります。

作る側としては、

「ではシステムを作りましょう」

と言った方が話は早いかもしれません。

でも最近、私はむしろ、

最初に「本当に作る必要がありますか？」と考えるようになりました。

今回は、その理由について書いてみます。

「困っている仕事」と「作ってほしいもの」は同じとは限らない

先日、ある専門家の方と業務効率化についてお話しする機会がありました。

最初は、

「助成金業務を効率化したい」

というところから始まりました。

助成金の申請には、

企業情報。

従業員情報。

必要書類。

期限。

申請書類。

さまざまな情報が関係します。

ここだけ見ると、

助成金申請を管理する専用システムを作ればよさそうに見えます。

でも実際に話を聞いていくと、

一番困っていたところは少し違いました。

書類そのものを作ることより、

必要な書類を集めること。

不足しているものを確認すること。

期限を管理すること。

ここにかなり時間が使われていました。

つまり、

「助成金システムが欲しい」

という話をそのまま受け取っていたら、

本当の問題とは少し違うものを作っていた可能性があります。

だから最初の1ヶ月は「作らない」

今回考えた進め方では、

いきなり開発には入りません。

まず、

調べる。

次に、

選ぶ。

そのあと、

入れる。

実際に運用して、

回す。

それでも市販の仕組みでは埋まらない部分が残ったときだけ、

最後に、

作る。

という5段階に分けました。

最初にやるのは、

現在の仕事の流れを整理すること。

どこで止まっているのか。

誰が何を確認しているのか。

必要な書類は何なのか。

どの作業に時間がかかっているのか。

そして、

すでに世の中にあるサービスで解決できないかを調べます。

「買えば済む」なら、その方がいい

私は自分でも業務ツールを作っています。

だからこそ、

ここは意識して線を引く必要があると思っています。

自分で作れる人間が調査すると、

何でも、

「作った方がいい」

という結論へ寄ってしまう可能性があります。

でも企業側から見れば、

月数千円の既存サービスで解決できるなら、

その方が早い。

保守も任せられる。

制度変更にも追従してくれる。

自社専用システムを持たなくて済む。

というメリットがあります。

だから今回の提案では、

最初の調査段階では、自分で作っているツールを候補に入れないことにしました。

市販ツールと、

「そもそも作らない」

という選択肢だけを比較します。

調べた結果、

「このサービスを買った方が早いです」

となれば、

そうお伝えする。

それでいいと思っています。

システムを作ると、仕事も増える

新しいシステムを作ると、便利になることばかりが注目されます。

でも実際には、

管理する仕事も増えます。

アカウントを管理する。

権限を管理する。

データを保存する。

バックアップを考える。

制度が変われば直す。

担当者が変われば教える。

不具合が出れば対応する。

つまり、

システムそのものが、新しい業務になる。

ことがあります。

毎月30分の作業をなくすために、

巨大な専用システムを作る。

これでは、かえって仕事が増えることもあります。

だから、

Excelを少し直せば済むならExcel。

フォーム一つで済むならフォーム。

既存サービスで済むなら既存サービス。

それでも足りなければ、初めて作る。

この順番の方が、私は現場には合っていると思っています。

実際、これまでの改善も「全部作り直す」ではありませんでした

AkariLabのポートフォリオに載せている事例でも、考え方は同じです。

全国80〜100店舗規模の飲食チェーンで使うExcel業務では、

既存の仕事そのものを全部捨てて、新しいシステムへ置き換えたわけではありません。

もともと現場で使われていたExcelを起点に、

店舗ごとに必要なファイルを自動生成する。

月160本以上を配布する。

店舗から戻った情報をまとめる。

本部の結果を再び店舗へ返す。

という、

人が何度も繰り返していた部分だけを仕組みにしました。

さらに、

再計算に失敗した場合には古い数字をそのまま配布しないよう、処理を止める仕組みも入れました。

新しいものを作ることより、

今ある仕事のどこを残し、どこだけ変えるか。

こちらの方が重要だった事例です。

勤怠OCRも、同じ考え方です

現在提供している紙のタイムカード・勤怠表のCSV化も、

給与計算システムを作りたいわけではありません。

紙を見ながら、

出勤時間を入力する。

退勤時間を入力する。

それを人数分繰り返す。

この部分だけを小さく減らしています。

しかも、

AIの読み取り結果をそのまま正解にはしません。

怪しい行。

人数が合わない場合。

日付の並びがおかしい場合。

こうしたところは人に戻します。

全部を機械へ渡すより、

機械に渡していい部分だけ渡す。

ここでも考え方は同じです。

この話は、前回の記事で詳しく書きました。

▼実際に使ってもらったら、想定していなかった穴が見つかった。勤怠OCRを作り直した話

実際に使ってもらったら、想定していなかった穴が見つかった。勤怠OCRを作り直した話

作る前に「どこまでなら作らなくていいか」を考える

業務改善の相談を受けるとき、

最近は、

「何を作りましょうか」

より、

「どこまでなら作らなくて済むでしょうか」

を先に考えるようになりました。

少し変な話ですが、

作らない方がいいと判断することも、業務改善の仕事だと思っています。

必要以上に大きな仕組みを持たない。

必要以上に個人情報を集めない。

必要以上に業務を変えない。

必要以上に費用をかけない。

そして、

本当に残った問題だけを作る。

AkariLabでは、相談だけでも受けています

「自動化したい気はするけれど、何を変えればいいのか分からない」

という段階なら、

最初から開発を依頼する必要はありません。

現在ココナラでは、

業務の自動化を現場目線で整理する相談サービス

を用意しています。

▼業務の自動化、現場目線でご相談乗ります

ここでは、

自動化した方がいいところ。

人が残った方がいいところ。

Excelで済むところ。

既存サービスを探した方がいいところ。

個別に作る価値があるところ。

を一緒に整理します。

「作るもの」が見えている場合は、小さく実装する

一方で、

「この作業をこうしたい」

というところまで見えている場合には、

小さな業務ツールとして実装することもできます。

勤怠表のCSV化。

Excel・VBAによる業務自動化。

LINE Bot。

AIを使った小さな業務ツール。

必要な範囲だけ作ります。

▼AkariLabのサービス・実績一覧

https://coconala.com/users/102148/portfolios

ポートフォリオには、

月160本以上のExcel自動生成、

87店舗で使うLINE Bot、

給与計算Excelを別のプログラムで検算した事例なども掲載しています。

「何が作れるか」だけではなく、

なぜその形にしたのか

というところも見ていただければと思います。

最近、面談を重ねながら感じていること

業務改善の話を聞いていると、

会社が違っても、

似たところで仕事が止まっていることがあります。

情報が集まらない。

同じ内容を何度も入力している。

確認したかどうか分からない。

担当者しか分からない。

Excelが増え続けている。

こうした問題です。

そして、

そのすべてに新しいシステムが必要なわけではありません。

むしろ、

仕事の流れを一度整理するだけで、

「ここだけ直せばいい」

と見えてくることがあります。

だから、

システムを作る前に、

まず仕事を見る。

既存の道具を探す。

小さく試す。

それでも足りないところだけ作る。

AkariLabでは、

そんな順番で業務改善を考えていきたいと思っています。

作ることを目的にせず、仕事が少し楽になることを目的にする。

その方が、長く使える仕組みになる気がしています。