システム導入の効果測定は何を見る？導入前後の比べ方と振り返りの記録

システム導入の効果を確かめるには、導入前に困っていた仕事を一つ選び、何を、どんな条件で比べるかを先に決めます。作業時間の合計だけでなく、処理した件数、やり直し、待ち時間、現場の負担もあわせて見ると、次に直すところが見つけやすくなります。

導入の目的に近づいたかを判断するために、発注者や業務責任者が振り返りで使う記録の作り方を整理します。

「何が困っていたか」から、測る項目を選ぶ

「業務を効率化したい」だけでは、どの数字を見ればよいかが決まりません。注文を別の台帳に書き写す手間を減らしたいのか、注文内容の確認待ちを短くしたいのかで、見る項目が変わります。

書き写しを減らしたいなら、対象の注文で何回入力し直しているかを見ます。確認待ちを減らしたいなら、受け付けてから担当者が確認するまでの時間を見ます。入力画面が速くなっても、後の工程で確認が増えれば、仕事全体の負担は変わらないことがあります。

まずは「困っていたこと」「導入で変えたこと」「確かめたい変化」を一文ずつ書き出します。導入前にまとめた要件や打ち合わせのメモがあれば、最初の目的を思い出す手掛かりになります。目的の整理の仕方は「要件定義で目的と業務を整理する方法」でも紹介しています。

英国政府のサービスの指標の決め方（英国政府、英語）も、目的に沿う指標、現状の基準、数字と利用者の声を合わせる考え方を示しています。行政サービス向けの資料を参考に、本文の項目は中小企業の業務に合わせて独自に整理しました。

導入前の基準を残し、比べる仕事をそろえる

導入後の数字だけでは、変化を判断しにくいです。導入前に準備できるなら、同じ仕事の件数とかかった時間を記録します。期間は月末の締めなど、仕事が一巡する区切りを踏まえて決めます。

受注入力を比べるなら、どの種類の注文を対象にするかをそろえます。決まった形の注文と、個別の確認が必要な注文を混ぜると、仕事の中身が変わっただけで平均の時間が動きます。繁忙期かどうか、担当の人数、取引先の入れ替わりも、比べる条件に関わります。

作業時間を測る場合は、どこからどこまでを測るかも合わせます。画面に入力している時間と、承認を待っている時間は別のものです。待ち時間を含めた全体の時間を見るのか、実際に手を動かした時間を見るのかを、記録する人どうしで確かめておきましょう。

導入前の記録がないときは、分かる範囲と不明を分ける

導入前に測っていなければ、必ず後から推定できるとは限りません。分からない数字を感覚で埋めず、まず残っている台帳、伝票、メールの日時など、記録で確かめられる範囲を調べます。そのうえで、次の三つを分けて書きます。

• 記録で確かめられたこと
• 記録をもとに推定したこと（推定の方法も書く）
• 分からないこと

例えば「導入前の注文件数は台帳で確かめられたが、一件にかかった時間は記録がなく不明」と書きます。

確かめられる範囲が足りないときは、無理に導入前と比べません。導入後の今の状態を新しい基準として記録し、次の改善の前後を比べる形に切り替えます。

作業時間・品質・使われ方を、目的に合わせて見る

最初から多くの項目を集めると、記録そのものが負担になります。導入の目的に直接つながる項目を中心にし、その数字だけでは見落とす点を補う項目を少し加えます。

この表は記録項目の例です。目標値や、一律に成否を判定する基準ではありません。

使われた回数が増えても、それだけで効果が出たとは言えません。画面が分かれているために、同じ仕事で開く回数が増えているだけのこともあります。反対に、社内からの質問が増えても、うまくいっていないとは限りません。不具合への質問か、新しい使い方への質問かで意味が変わります。

業務の改善に必要な範囲で記録し、集計担当と置き場所を決めます。個人や顧客の情報を不用意に共有しないようにしましょう。

数値の変化と、その理由の仮説を分ける

「導入後に作業時間が減った」という事実があっても、原因がすべてシステムとは限りません。注文が少ない時期だった、担当者が慣れた、社内のルールを同時に変えた、といった事情も考えられます。

振り返りでは、確かめられた事実と、理由の仮説を分けて書きます。例えば「対象期間の合計時間は短くなった。ただし処理件数も少ないため、一件あたりの時間はまだ比べられていない」と残します。これは書き方の例で、Ouverの導入実績ではありません。

記録が抜けた日を、ゼロとして集計しないことも大切です。「記録していない」と「作業がなかった」を分け、比較に含めた範囲をそろえます。集め方を途中で変えた場合は、その時点をメモしておきます。

導入直後は、操作に慣れるまで時間がかかることがあります。その期間だけで成否を決めず、ふだんの使い方に落ち着いた後の変化も見ます。ただし「慣れれば解決する」と決めつけず、仕事が止まる問題や大きな誤りは早めに開発会社と共有します。

現場の声は、困った場面と一緒に残す

感想に加え、どの仕事で何をしようとして手が止まったかを聞くと、数字の背景が見えてきます。

例えば「検索しにくい」という声なら、探していた情報、入れた条件、見つけた後の仕事まで確かめます。検索の条件を増やす前に、情報の持ち方や仕事の手順に原因がないかを考えられます。

確認する人や後の工程の担当者にも聞き、別の部署へ負担が移っていないかを確かめます。すべての要望を機能追加にする必要はありません。

振り返りメモは、例えば次の形でまとめます（架空の例）。

対象の仕事

受注入力（決まった形の注文のみ）

期間と件数

導入前と導入後で、締めを1回ずつ含む期間と、それぞれの処理件数

測り方

入力を始めてから確認依頼を出すまで

確かめた変化

同じ種類の注文で、一件あたりの時間が短くなった

理由の仮説

台帳への書き写しが要らなくなったため。担当者の慣れの影響はまだ分けられていない

現場の声

確認担当から「差し戻しの理由が分かりにくい」

まだ分からないこと

差し戻しの件数が変わったか。確認担当が次の締めまでに記録する