業務システムの改善では、利用者から聞いた要望を、そのまま形にすればよいとは限りません。私も40代の頃、担当部署から「処理を速くしてほしい」と相談され、最初はシステムの速度を上げる話だと考えました。
ところが、実際の作業について話を聞くと、本当に負担になっていたのは処理待ちではなく、担当者が毎日、同じような内容を30分以上かけて繰り返し入力していたこと。
この記事では、最初の要望と本当の課題がなぜずれていたのか、何を確認して解決策を変えたのかを振り返ります。
「処理を速くして」をそのまま受け取らなかった理由
まず担当部署の方から最初に言われたのは、「処理を速くしてほしい」という一言でした。
この言葉だけを聞けば、データベースやプログラムの処理速度を調べ、遅い部分を改善するのが自然です。私も最初は、どこに時間がかかっているのか、技術的な原因を探そうとしました。
ただ、話を聞いているうちに、少し違和感がありました。
担当者が困っている様子は伝わるのですが、「何秒遅いのか」「どの画面で待たされるのか」と聞いても、問題の形がはっきりしません。処理が遅いというより、仕事全体に手間がかかっている。そんな話し方に聞こえたのです。
要望する本人も、自分の負担を正確な言葉にできているとは限りません。毎日同じ仕事をしていると、その手順が当たり前になり、どこが本当に大変なのか分からなくなることもありますね。
そこで私は、処理速度の話だけで結論を出さず、実際にどのような流れで作業しているのかを確認することにしました。
現場で見つけた30分の繰り返し作業
作業の内容を詳しく聞くと、担当者は毎日、同じような情報を繰り返し入力していました。
一つひとつは難しい操作ではありませんが、必要なデータを確認し、決められた欄へ入力する。それを何度も繰り返す作業。それが積み重なると、なんと30分以上もかかります。
同じ内容を扱う単調な作業ほど、入力漏れや確認ミスが起きやすくなりますが、処理の待ち時間が数秒短くなったとしても、この繰り返しが残る限り、担当者の負担はほとんど変わりません。
ここでようやく、「処理を速くしてほしい」という言葉の意味が見えてきました。
担当者が求めていたのは、システム内部の処理性能を上げることというより、毎日時間を取られている作業を、少しでも早く終わらせることでした。
言葉として出てきた要望と、実際に解決すべき問題は同じとは限りません。
もし最初の言葉だけを受け取り、画面表示やデータ処理を少し高速化していたら、技術的には要望へ応えたことになります。でも、担当者が感じていた負担は残ったでしょう。
処理高速化ではなく入力自動化を選んだ
そこで私は、処理速度を上げるのではなく、繰り返していた入力作業を自動化する方法を提案しました。人が毎回入力していた内容を、すでにあるデータから取り込み、必要な形へ反映させる仕組みです。
担当者が行うのは、入力された内容を確認し、必要な箇所だけを修正する作業に変わりました。結果として、毎日30分以上かかっていた入力作業は、ほとんど手間がかからない状態になり、担当者から、
「こんなに楽になるとは思わなかった」
という言葉も聞かれ、、
処理速度ではなく作業そのものに目を向けてよかった、と思いました。
もちろん、自動化すれば何でもよいわけではありません。
自動で入力した内容が正しいか、例外的なデータに対応できるか、問題が起きたときに手作業へ戻せるか。そうした点は確認する必要があります。
それでも今回の場合は、処理を数秒縮めるより、30分の繰り返し作業をなくすほうが、はるかに大きな効果がありました。
改善の効果は、システムがどれだけ速くなったかではなく、利用者の仕事がどれだけ減ったかで考える必要があります。
エンジニアは、つい技術的な問題へと目が向かいがちだと思います。私自身も、速度の相談を受ければ、最初にプログラムの処理を疑います。でも利用者が困っているのは、コードではなく日々の仕事です。
そこを忘れると、技術的には正しくても、あまり役に立たない改善になることがあります。
要望の裏にある課題を見つける確認方法
この経験以降、利用者から改善の相談を受けたときは、要望だけでなく、実際の作業を確認するようになりました。
特に見るのは、次のような点です。
- その作業はいつ、どのくらいの頻度で行うのか
- どこに最も時間がかかっているのか
- 同じ入力や確認を繰り返していないか
- ミスが起きやすい場所はどこか
- その作業がなくなったら、何が一番楽になるのか
「何を作ってほしいですか」と聞くだけでは、利用者が思いついた解決方法しか出てきません。今回なら、「処理を速くしてほしい」がそれにあたります。
一方で、
「普段はどの順番で作業していますか」
「一番面倒なのはどこですか」
「同じ内容を何回入力していますか」
と聞くと、仕事の実態が見えやすくなります。
利用者の要望を否定する必要はありません。「処理を速くしてほしい」という言葉も、困りごとから出てきた大切な手がかりです。ただ、その言葉だけで作るものを決めず、なぜそう思ったのかをもう一段掘り下げます。
また、現場で使う人と、改善を依頼する人が別の場合もあります。
管理する立場の人には見えていない細かな手間を、実際の担当者が抱えていることも珍しくありません。そのため、できるだけ作業する本人の話を聞くことも大切です。
今回の経験から「現場を見れば必ず正解が分かる」とまでは思っていません。使う側の負担、開発に必要な時間、保守のしやすさなどを比べ、現実的な方法を選ぶ必要があります。
それでも、最初の要望だけで作り始めるより、判断を誤る可能性は減らせます。
まとめ
利用者の要望は、解決策ではなく、困っていることの手がかりとして受け取る必要があります。
「処理を速くしてほしい」と言われても、本当に減らしたいのは待ち時間ではなく、繰り返し作業かもしれません。私も実際の仕事の流れを確認したことで、処理速度ではなく入力の自動化を選べました。
何を作るか決める前に、なぜそれを求めているのかを確かめる。
この一手間が、利用者にとって本当に役立つ改善につながると思います。
コメント