業務改善をシステム化するときは、「何を作るか」より先に「今の業務がどう流れていて、どこで詰まっているか」を現場と同じ解像度で押さえることが出発点です。そのうえで小さく作り、本番業務と並行して試し、使われ続けているかを数字で確かめるところまでが一続きの仕事になります。この記事では、受入検品の改善を例に、聞き取りから定着までの7段階と、各段階で手元に残すべき成果物を説明します。
システム化した業務改善が失敗する典型
業務改善のシステム化でよく起きるのは、「システムは動いているのに、現場が元のやり方に戻っている」という状態です。原因はたいてい次のどれかです。
- 依頼者（管理職や情報システム部門）の話だけで作り、実際に作業する人の手順を見ていない
- 例外の処理（不良品、数量違い、急ぎの出荷）を考えておらず、現場が紙やExcelで裏運用を始めた
- 入力の手間が以前より増えた
- リリースして終わりにし、誰も利用状況を見ていなかった
どれも、作る技術の問題ではありません。作る前と作った後の進め方の問題です。
7段階の全体像
| 段階 | やること | 手元に残す成果物 |
|---|---|---|
| 1. 聞き取り | 大きな論点（予算・期日・決裁者・目的）から聞き、業務の担当者に会う | 聞き取りメモ、関係者一覧 |
| 2. ASIS整理 | 今の業務を誰が・何を・どの順で行うかを図にする | ASIS業務フロー、件数と所要時間 |
| 3. 課題の特定 | どこで時間・ミス・待ちが発生しているかを数字で示す | 課題一覧表 |
| 4. TOBEと代替案 | あるべき流れを描き、システム以外の手段とも比べる | TOBE業務フロー、案の比較表 |
| 5. 小さく作る | 件数の多いパターンだけで最初の版を作る | 要件のメモ、最初の版 |
| 6. 並行運用 | 本番業務の一部で旧手順と並べて試す | 試験結果、修正一覧 |
| 7. 定着確認 | 利用状況を見て、改善・継続・撤退を判断する | 利用ログ、判断の記録 |
以下、部品を仕入れて組立工場に供給する会社の「受入検品」を例に、段階ごとに見ていきます。
1. 聞き取り：上から聞き、作業者に会う
最初の打ち合わせで依頼者から出てきたのは「検品をタブレットでできるようにしたい」という要望でした。ここでいきなり画面の話を始めると、予算や期日が後からひっくり返ります。先に押さえるのは、予算の枠、いつまでに使い始めたいか、最終的に誰が決めるか、何を良くしたいのか（工数か、ミスか、在庫の正確さか）、外せない制約（既存の在庫システムを残すか）です。
そのうえで、実際に検品する倉庫の担当者に会います。聞き取りは白紙で臨まず、「入荷は1日30件くらい、1件あたり5分ほどですか」のように仮説を持って行き、違っていたら直してもらう形が早く進みます。聞き方の詳細はヒアリングの記事にまとめています。
2. ASIS整理：作業を順番どおりに書き出す
聞き取りと現場の観察から、今の流れを書き出します。
- 入荷した部品を、紙の納品書と突き合わせて数を数える
- 紙のチェックシートに数量と結果を手書きする
- 夕方に事務担当がチェックシートをExcelに転記する
- 翌朝、Excelを見ながら在庫システムに入庫を入力する
- 数量違いがあれば、購買担当が仕入先に電話する
書き出すと、同じ数字を3回書き写していること、入庫が在庫システムに反映されるまで最大で翌朝まで空くことが見えます。件数と所要時間もここで書いておきます。図にする方法はASIS業務フローの記事を参照してください。
3. 課題の特定：困りごとを数字にする
「転記が大変」という声を、「1日30件×転記2回、1件2分として1日約2時間」のように数字にします。数字にすると、どこを直すと効果が大きいかの比較ができます。この例で挙がった課題は次の3つでした。
- 転記の手間（1日約2時間）
- 転記ミスによる在庫差異（月に数件、棚卸で発覚）
- 入庫の反映が翌朝になり、当日入荷した部品を当日出荷に引き当てられない
3つ目は依頼者が最初に言っていなかった課題ですが、営業部門から見ると一番影響が大きいものでした。課題は1枚の表にまとめておくと、関係者で優先順位を議論しやすくなります。表の作り方は課題一覧表の記事で紹介しています。
4. TOBEと代替案：システム以外とも比べる
あるべき流れは「検品した時点で在庫システムに入庫が記録され、数量違いは購買担当に自動で通知される」と書けます。ここで大事なのは、新しく作る以外の案とも比べることです。
| 案 | 内容 | 費用感 | 向いている状況 |
|---|---|---|---|
| A | 在庫システムに標準で付いているハンディ端末の機能を使う | 小 | 標準機能で8割の要件が満たせる |
| B | 共有スプレッドシートに直接入力し、夕方に一括取り込み | ごく小 | 当日反映が必須でない |
| C | タブレット用の検品画面を新しく作り、在庫システムに連携 | 中〜大 | 例外処理や独自の項目が多い |
この例では、当日反映が必要だったためBは外れ、Aの標準機能では数量違いの通知ができないことから、Cを小さく始めることになりました。比べた記録を残しておくと、後から「なぜ作ったのか」と聞かれたときに答えられます。TOBEの描き方はTOBE業務フロー設計の記事で詳しく扱っています。
5. 小さく作る：多いパターンから
入荷の記録を見ると、全体の8割以上は「納品書どおりの数量で問題なし」でした。最初の版はこのパターンと「数量違い」の2つだけを扱い、返品や分納は従来どおり紙で処理すると決めました。全部の例外を最初から作ろうとすると、完成が遅れるうえ、使われない機能が増えます。
作る前に、最低限次のことは文章にしておきます。
- 誰が、どのタイミングで、何を入力するか
- 数量違いのとき、誰に何が通知されるか
- 通信が切れたとき（倉庫の奥は電波が弱い）にどう動くか
- 入力が終わったことを、担当者が画面でどう確認できるか
画面の設計では、現場の作業姿勢も確かめます。検品担当は片手に部品、片手に納品書を持っていることが多く、細かい入力欄が並ぶ画面は使いにくくなります。数量が納品書どおりなら1回のタップで確定でき、違うときだけ数量を入力する形にすると、入力の手間は紙より少なくなります。
6. 並行運用：本番の一部で旧手順と並べる
いきなり全面切り替えにせず、例えば2週間、特定の仕入先からの入荷だけを新しい画面で処理し、従来のチェックシートも並行して書いてもらいます。両方の結果を突き合わせれば、数量の取りこぼしや操作のつまずきが見つかります。
並行運用の前に、テスト期間、対象範囲、出てきた要望の扱い（軽微なものは翌週、大きなものは次の段階）を関係者と合意しておきます。現場の中で業務に詳しく、周りへの発言力もある人に早めに参加してもらうと、修正点の優先順位が現場の感覚に合いやすくなります。
7. 定着確認：使われているかを数字で見る
リリース後は、機能ごとの利用回数、エラーの発生件数、未処理のまま残っている件数を週次で見ます。例えば「数量違いの通知が2週間で1件も出ていない」なら、本当に違いがないのか、現場が紙で処理しているのかを確認しに行きます。
節目も決めておきます。3ヶ月の時点で対象業務の大半が新しい手順に移っているか、半年の時点で転記時間が想定どおり減っているか。届いていなければ、操作の問題か、周知不足か、そもそも不要だったのかを切り分けて手を打ちます。
よくある失敗
- 依頼者の要望を仕様として受け取る：「タブレットで検品したい」は手段であり、解決したい課題は別のところにあることが多い
- ASISを書かずに作り始める：同じ転記を別の形で残してしまい、手間が減らない
- 例外を全部作ろうとする：リリースが半年遅れ、その間に現場の運用が変わる
- 並行運用を省く：本番初日に取りこぼしが出て、現場の信頼を失う
- リリース後に誰も見ていない：半年後には元のExcelに戻っている
この記事のまとめ
- 業務改善のシステム化の成否は、作る前の聞き取りと作った後の定着で決まる
- 聞き取りは大きな論点から始め、必ず作業する人に会う
- ASISを順番どおりに書き出し、困りごとを件数と時間で数字にする
- TOBEを描いたら、新しく作る以外の案とも比べて記録を残す
- 件数の多いパターンだけで小さく作り、本番の一部で並行運用する
- リリース後は利用状況を数字で見て、節目ごとに改善・継続・撤退を判断する
この記事の内容は、ロードマップのStep 6「進めて作る」にあたります。前提となる聞き取りとASIS・TOBEはStep 2「聞く」とStep 4「あるべき姿を描く」で扱っています。体系立てて学ぶなら、FDEガイドのプロジェクトスタート時のヒアリングと現場導入のための要件定義を参照してください。演習とテストはlecture.iplot.jpで取り組めます。