というわけで今回の改善案は、ネット注文システムから配送業者のシステムに合致する注文データを出力する機能を追加するために、「自分でツールを作る」を行うこととなりました(図3)。
図3が改善後のイメージです。ネット注文システムに入った注文データを、注文データとして外部ファイルに出力します。その後、配送業者のシステムに入力します。これで出力したデータをそのまま取り込めます。
また、ソフトの改修作業も、注文情報をファイルに出力するだけなので、大きな工数がかからないことから、この方向性で進めました。その結果、配送業者のシステムでの入力作業の大部分を自動化できています(多少のGUI操作は必要ですが)。
改善案を考えた後は、店側に了解を取らねばなりません。筆者は、下記のように説明を行いました。
上記を説明し、改善案を店側から了承を得られました。
配送業者のシステムの入力作業が簡単になったため、発送処理の作業時間の短縮とミスの低減ができました。特に、繁忙期(例えばクリスマスやお歳暮)には、非常に件数が多いため非常に効果があったそうです。また、この改善案により浮いた時間を「接客の時間の増加」「品出し」などの作業に割り当てられました。
改善案の全てが順調に進んだわけではありません。運用時には、少なからず問題点がありました。
改善案の導入初期は、注文データの出力機能にバグがあり、配送業者のシステムにデータが正しく読み込めない事象が発生しました。従業員さんは、バグが発生するたびに、業務が中断されてしまい、従来の作業を行っていたそうです。
従業員さんは、「何のための改善なのだろう」と思ったことでしょう。
一部の従業員さんは、今回の改善プロセスではなく、従来の業務フローで作業をしてしまい、改善案の浸透に時間がかかりました。その従業員さんからすると、改善活動は慣れ親しんだ作業を変えることになるため、負担となっていたかもしれません。もう少し、丁寧に説明し、歩み寄ることが必要だったと思います。
今回は、「自分でツールを作る」に着目して、小規模な業務効率化のケーススタディーを紹介しました。改善策としてはもっと良い方法があったかと思いますが、今回最もお伝えしたかったことは「業務改善の進め方」です。
10人規模の非常に小さな組織であっても、慣れ親しんだ従来の業務を変更することは簡単ではありません。必ず、効率化に対する「抵抗勢力」が起こります。特に、現場で行われる複雑な業務を改善しようとすると、「効率化に時間がかかる」「メンバーから反発がある」と、必ず反対派から文句が出ます。この問題は、「ソフトウェアの改善」や「プロセスの効率改良」ではなく、社会学や心理学の範囲の課題かもしれません。
前回記事の冒頭で挙げた「コロナ禍における問答無用のシステム化」の事例は、誰も効率化に対して文句が言えず、システム化が一気に進んだ例外的な事例でしょう。今では、コロナ禍の最中のような「劇的なシステム化」は期待できません。業務の中で効率化しやすいところに着目し、なるべく小さい範囲で改善のループを回していくとよいと思います。
前々シリーズ「ソフトウェア技術者のためのバグ百科事典」を大幅に加筆、修正した山浦恒央先生の書籍「ソフトウェア技術者のためのバグ検出テキスト」が日科技連出版から好評発売中です。連載でも取り上げた、「要求仕様書のバグ」「実装抜けのバグ」「テスト業務のバグ」など、バグを36種類に分類して解説しています。囲碁や将棋であれば、「相掛かり」「矢倉」「四間飛車」「藤井システム」のような戦法を網羅した内容になっています。
前著「ソフトウェア技術者のためのバグ検出ドリル」(2019年11月刊行)も好評発売中です。実際にバグを含む要求仕様書、設計書、コーディング、デバッグ、保守を具体的に取り上げ、練習問題として31問を出題しました。同書は、囲碁や将棋における「次の一手」的な問題であり、ピンポイントの場面を取り上げ、実践力を鍛えることを目的としています。
両書とも興味のある方は、Amazon.comや書店でチェックしてください!
東海大学 大学院 組込み技術研究科 非常勤講師(工学博士)
Copyright © ITmedia, Inc. All Rights Reserved.