ビジネススクロール
仕事のヒントを、ひもとく。

前の改革が失敗したから新しい案も難しい？当時との違いを検証する

企画・意思決定
ビジネススクロール編集

以前の業務改革が失敗した職場では、新しい改善案が出ても「前も同じようなことをして失敗した」と慎重になることがあります。過去の失敗を無視するべきではありませんが、前の改革がうまくいかなかったことだけで、今回も失敗すると決めることはできません。

まず、前回は何が起き、何が原因の候補になったのかを記録から確かめます。そのうえで、今回も残っている条件、変わった条件、まだ分からない条件を分けます。以前の障害がそのまま残るなら計画の変更や見送りを考え、条件が改善されているなら、残るリスクを踏まえて改めて判断します。

「前も失敗した」が、新しい改革案の判断にどう影響するのか

以下は説明用の仮の場面です。ある会社では、数年前に経費精算の仕組みを全社で一斉に切り替えました。しかし切り替え直後に申請処理が滞り、一部の業務を元の手順に戻しました。当時の記録には、旧データの移行が遅れたことや、担当者が操作を十分に練習できなかったことが残っています。

今度は購買申請の承認手順を見直す案が出ました。会議では「前のシステム改革もうまくいかなかった。今回も現場が混乱するのでは」と懸念が出ます。これは無視できない心配です。ただし、経費精算と購買申請では業務の流れも、切り替える人数も、事前準備の仕方も違うかもしれません。

必要なのは「改革という名前が似ているか」ではなく、前回の混乱につながった条件が、今回も同じように存在するかを調べることです。原因だと思われていたことも、当時の記録と照合しないと確かなことは言えません。

失敗という結果が、当時の判断の評価に入り込む

BaronとHershey（1988）は、大学生を対象とした五つの研究で、医療上の判断や金銭的な選択について、他人がどのように決めたか、その後どんな結果になったかを読んでもらいました。判断した人が持っていた関連情報を参加者にも示した条件でも、良い結果になった判断の方が、悪い結果になった判断より適切だったと評価されやすい傾向が見られました。

このように結果を知ったことで判断自体の評価が変わる傾向を「結果バイアス」と呼びます。詳しい説明は結果バイアスの解説で確認できます。前回の改革が失敗したからといって、当時の決定に必ず問題があったとは限りません。一方で、失敗を偶然と片づけてよいとも限りません。当時の情報や準備と、結果が悪くなった経緯は別々に確かめる必要があります。

Aiyerら（2023）は、オンライン参加者692人を対象に、医療場面の判断を評価する実験を事前登録した方法で再検証しました。判断内容が同じでも、成功した結果を示された人の方が、失敗した結果を示された人より判断の質を高く評価する傾向が確認されました。ただし、この再検証は医療場面の一つのシナリオを使ったもので、職場の改革案を否決する行動を直接測ったものではありません。

似た出来事を思い出しても、重要な条件まで同じとは限らない

HolyoakとKoh（1987）は、過去に学んだ問題を別の問題の解決に使う研究を行いました。二つ目の実験では、問題どうしの目立つ外見上の共通点と、解決方法に関係する構造的な共通点を区別して調べています。どちらも過去の問題を思い出すことに影響しましたが、類似性を示された後に、その問題を解決に利用するうえでは構造的な共通点の影響がより大きく見られました。

この研究は、改革の失敗を予測する研究ではありません。ただ、過去の事例を参考にするとき、「どちらも全社改革だった」という表面的な共通点だけでなく、同じ障害が生じる仕組みがあるかを確認する考え方につながります。

前回の失敗を、新しい企画と比べる前に何を確かめるか

  • 前回は何を「失敗」としたのか：期限に間に合わなかったのか、予算を超えたのか、現場の負担が増えたのか、目的の成果が出なかったのかを特定します。企画自体の効果がなかったのか、実施方法でつまずいたのかによって、今回の対策は変わります。
  • どの資料で確かめられるか：当時の計画書、変更履歴、問い合わせ記録、障害報告、担当者への聞き取りなどを確認します。原因とされた説明が単なる推測なら「原因候補」として残し、確定した事実と区別します。
  • 前回の問題が起きた条件は何か：作業が集中する時期、対象部署の数、旧データの扱い、研修の時間、承認の役割などを調べます。「研修不足が原因」と言うだけでは、誰にどんな準備が足りなかったのかは分かりません。
  • 今回も同じ条件があるか：制度やシステムの種類だけでなく、担当者、手順、作業量、切り替え方、支援体制が同じかを確認します。同じ問題が残っていれば、新しい企画でも注意が必要です。違っている場合は、なぜ違いが重要なのかまで考えます。
  • 前回とは別の問題がないか：旧データの移行が不要でも、今回は個人情報の取り扱いや承認権限に別の課題があるかもしれません。前回と違うことを確かめただけで、今回が安全だと決めないようにします。

当時の資料が少なく、失敗に至った経緯を追えない場合は「前回の原因が分からない」と明記します。記憶が食い違うなら、ひとつの説明を正しいと決めず、確認できる事実から整理します。

当時と今回の違いを、判断に使える形に整理する

先ほどの経費精算改革と購買申請改革の仮の例なら、次の表のように整理できます。これは実在の企業の記録ではなく、比較する観点を示すための例です。

確認する点 前回の記録（仮の例） 今回の案で確かめること
切り替え範囲 全社で同じ日に移行した 業務を分けられるか。一斉変更が必要な理由はあるか
旧データの扱い 移行作業の遅れが記録された 移すデータは何か。移行の検証や戻す方法はあるか
利用者の準備 実際の操作練習の機会が少なかった どの担当者が新手順を使い、いつ練習できるか
通常業務との重なり 繁忙期と切り替え時期が重なっていた 今回の実施時期の業務量と支援要員は十分か
成果を確かめる方法 処理の停滞が起き、部分的に旧手順へ戻した 何を測るか。どの状態なら修正・停止するか

表を埋めるときに大切なのは、違いを数えることではありません。たとえば今回は対象人数が少なくても、承認者の役割が曖昧なら同じような停滞は起こり得ます。逆に前回の問題が旧データの移行に集中していて、今回は移行自体が必要ないなら、少なくともその問題が同じ形で起こる可能性は違ってきます。

この比較は過去の失敗をなかったことにするためではなく、今回の計画にどの教訓を引き継ぐべきかを選ぶためのものです。

違いが分かったら、改革案をどう扱うか

ここからは上記の研究を参考にした実務上の提案です。研究で直接検証された「改革の成功手順」ではなく、各職場の条件に合わせて判断するための進め方です。

  1. 前回の失敗から引き継ぐ条件を明示する。当時の記録で確認できた問題について「今回も起き得るか」「誰が対策を確認するか」を並べます。原因が特定できなければ、その不確実性も残します。
  2. 変わった条件が本当に対策になっているか確かめる。「今回は研修を行う」だけではなく、どの担当者がいつ練習し、必要な作業を進められるかを確認します。対策の名前ではなく、以前の問題との対応を見ます。
  3. 残る障害と今回特有の障害を検討する。前回と同じ重大な問題が未解決なら、導入時期や対象範囲を変える、計画を見送る判断も必要です。前回の懸念に対策があっても、新たなリスクが残るなら別途確認します。
  4. 判断に足りない情報を集める。運用の負担など、限定した範囲で確かめられる点は事前の手順確認や試行を検討します。ただし、一部の試行で問題が出なかっただけでは、全社での運用やまれな重大障害まで確認できたことにはなりません。
  5. 続行・修正・見送りの理由を記録する。新しい改革を採用する場合も、見送る場合も、前回との共通点・違い・未確認点を示します。見送るなら「何が変われば再検討するか」も残します。

会議でのやり取りなら、たとえば次のように相談できます。これは説明用の仮の会話例です。

「前回は切り替え直後に処理が止まり、現場に負担をかけたことを重く見ています。今回は同じ混乱を避けたいので、前回の障害記録を確認し、旧データの移行、担当者の練習時間、実施時期がどう違うか整理しませんか。前回と同じ問題が残るなら計画を修正しますし、対策を確認できるなら今回の案をその条件で評価したいです」

「過去に失敗したから進めない」という判断も、「前とは違うから問題ない」という判断も、どちらも確かめるべき条件を飛ばしてしまうおそれがあります。過去の結果と当時の判断、失敗に関わった条件と今回の条件を分けて比べることで、反省を新しい企画の判断材料にできます。

参考文献・出典