最初から完成品を作らない。小さく作って、現場で育てる

ここまでの記事では、

「人がやらなくていい仕事を減らす」

「作業そのものではなく、仕事の受け渡しを整える」

「自動化する前に、例外を見つける」

という話を書いてきました。

ここまで来ると、

「では、実際に仕組みを作るときはどう進めるのか」

という話になります。

私が大切だと思っているのは、

最初から完成品を作ろうとしないこと

です。

少し意外に感じるかもしれません。

せっかくシステムを作るなら、

最初からきれいに、

全部入りで、

便利なものを作った方が良さそうに見えます。

でも実際の現場では、

最初から正解が全部分かっていることの方が少ないです。

ヒアリングだけでは分からないことがある

業務改善を始めるとき、

まず今の仕事について聞きます。

何を使っているか。

誰が担当しているか。

どこで時間がかかっているか。

どんなミスが起きるか。

もちろん、これは必要です。

ただ、ヒアリングだけでは見えないものがあります。

それは、

実際に使ってみたときの違和感

です。

たとえば、

「このボタンは押しにくい」

「この項目はここにあると思わなかった」

「毎回ここを確認するなら、最初から表示してほしい」

「この画面より、Excelで見た方が早い」

こうした意見です。

設計段階では問題なさそうでも、

現場に入れた瞬間に分かることがあります。

作る側の「便利」と、使う側の「便利」は違う

これはかなり重要だと思っています。

開発する側から見ると、

機能が多い。

自動化率が高い。

画面がきれい。

処理が速い。

こういうものを「便利」と考えがちです。

でも使う側からすると、

入力する場所が分かる。

迷わない。

確認したい情報がすぐ見える。

いつもの仕事を大きく変えなくていい。

こちらの方が大切なことがあります。

つまり、

高機能であることと、現場で使いやすいことは同じではありません。

まず、一番困っているところだけ作る

たとえば毎月の勤怠処理で、

紙のタイムカードを見ながら

Excelへ入力する作業に時間がかかっている。

それなら最初は、

画像を読み取ってCSVへ変換する。

まず、それだけでもいいと思います。

給与計算まで全部つなぐ。

勤怠管理システムと連携する。

従業員情報を管理する。

管理画面を作る。

通知機能を付ける。

もちろん、将来的にはできるかもしれません。

でも最初から全部作ると、

本当に必要な機能が分からなくなります。

まず、

今、一番面倒なところを一つだけ減らす。

それで現場が楽になるかを見る。

実際に使ってもらうと、次に必要なものが見えてくる

現在、勤怠表のOCRデータ化についても、

実際の業務で使える形を確認しながら進めています。

紙のタイムカードを読み取り、

出退勤時刻を整理する。

そこまでは技術的にできます。

でも実際の運用では、

どの形式で納品するのが使いやすいのか。

どこを確認対象にするのか。

どんな場合に止めるのか。

誰が最終確認するのか。

こうした部分が重要になります。

そしてこれは、

実際に使う人によって違います。

だからこそ、

作って終わりではなく、

使う → 気付く → 直す

という流れが必要になります。

助成金業務支援も、まずは一部から

現在試作している助成金業務支援の仕組みでも、

考え方は同じです。

助成金業務には、

制度の確認。

企業情報の確認。

対象者情報の確認。

必要書類の収集。

進捗管理。

申請書類の作成。

さまざまな工程があります。

これを最初から全部システム化しようとすると、

かなり大きなものになります。

だから、

まず一つの制度。

まず一つの流れ。

まず一つの入力画面。

という形で小さく作る。

そして、

本当に楽になるのか。

現場で困るところはないか。

確認していく。

その方が、

結果として使えるものになりやすいと思っています。

「完成してから使う」では遅いこともある

システム開発では、

完成してから現場へ渡す。

という考え方もあります。

もちろん、

業務内容によってはそれが必要です。

でも小規模な業務改善では、

完成を待たずに、

小さく試した方がいい場合があります。

なぜなら、

間違ったものを完成させることが一番もったいないからです。

時間をかけて作った。

機能もたくさん付けた。

でも、

現場では使いにくかった。

こうなると、

作った側も使う側も困ります。

だから早い段階で、

「これで使えそうですか？」

と確認する。

そして違えば直す。

 変更できる余白を残す

最初から仕様を固めすぎると、

変更するのが大変になります。

一方で、

最初から何も決めないのもよくありません。

必要なのは、

最低限のルールだけ決めて、

変更できる余白を残すこと。

たとえば、

出力する項目。

確認する人。

エラー時の扱い。

最低限ここだけ決める。

それ以外は、

実際の運用を見ながら調整する。

このくらいがちょうどいい場合があります。

業務改善は「システム導入イベント」ではない

業務改善というと、

新しいシステムを導入する。

という一度きりのイベントのように考えられがちです。

でも実際には、

少し変える。

使ってみる。

また少し変える。

この繰り返しの方が自然です。

仕事そのものも変わります。

担当者も変わります。

会社の規模も変わります。

制度も変わります。

だから、

一度作って永久に完成。

ということは、

ほとんどありません。

小さい仕組みなら、失敗も小さくできる

小さく始めるメリットは、

成功しやすいことだけではありません。

失敗したときの影響も小さい

ということです。

一つの作業だけ試して、

合わなければ戻す。

別の方法を試す。

修正する。

これができます。

大きなシステムを一気に入れると、

戻すこと自体が大変になります。

だから私は、

小さな会社や、

少人数の現場ほど、

小さく試すやり方が合っていると思っています。

作らないという判断もある

ここも大事なところです。

業務を見た結果、

新しいシステムを作らなくてもいい。

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

Excelの使い方を少し変える。

フォルダ構成を整理する。

入力フォームを一つ作る。

既にあるサービスを使う。

これで解決するなら、

それでいい。

「業務改善＝システム開発」

ではありません。

むしろ、

作らずに済むなら、その方がいいこともあります。

AkariLabでやりたいのは「一緒に育てる」こと

AkariLabでは、

最初から大きなシステムを提案するより、

今の仕事を見て、

一番困っているところを見つけて、

小さく仕組みにする。

そして、

実際に使いながら整える。

そんな進め方を大切にしています。

必要なら機能を増やす。

必要なければ増やさない。

別の方法が良ければ変える。

大切なのは、

作ったものを守ることではなく、

仕事が楽になる状態を作ること。

だからです。

紙のタイムカードや勤怠表については、

現在ココナラでデータ化サービスを提供しています。

▼タイムカード・勤怠表のデータ化サービス

まずはサンプルの帳票を確認し、

どこまで読み取れそうか。

どんな形で納品するのが使いやすいか。

そこから考える形でも構いません。

最初から大きく変えなくてもいい。

一つ楽になったら、

次を考える。

業務改善は、

完成品を買うことではなく、今の仕事に合う形を少しずつ作っていくこと。

私は、そんな進め方が現場には合っていると思っています。