システムを変える手間が大きく見えるとき|移行負担を具体的に見積もる
システムを入れ替えた方が便利そうでも、「データの移し替えが大変」「現場が使い方を覚え直さなければならない」と考えると、検討が止まることがあります。移行負担を軽く考えて進めるのも、手間が大きそうという印象だけで断念するのも避けたいところです。
まず、移行を「必要な作業」「起こるか分からない作業」「まだ調べていない条件」に分けて、対象件数・担当者・所要時間・費用を確かめます。 さらに、移行しない場合にも発生する手間と、切り替え後に期待する改善を同じ期間で比べます。そうすれば、全面移行・一部での試行・見送りのどれが妥当かを話し合いやすくなります。
移行の手間が大きく見えるとき、判断には何が影響するのか
例えば、営業部門の担当者が、古い案件管理システムから新しい仕組みへの移行を提案されたとします。今のシステムは入力に時間がかかりますが、担当者は操作に慣れ、独自の集計表も作っています。一方、新システムの画面や料金は分かっていても、過去のデータが正しく移るか、帳票を作り直せるか、他部署の作業が増えないかは未確認です。これは説明用の仮の場面です。
このとき、慣れた操作を失うことや移行直後の混乱は具体的に想像できても、新システムで毎月どれだけ作業が減るかは想像しにくいかもしれません。逆に、導入を急ぐ人は便利な機能に注目して、移行中の確認作業を見落とすかもしれません。どちらの立場も、印象と実際に確認した作業量を分けて考える必要があります。
今の状態を選びやすいことと、実際の切り替え負担
SamuelsonとZeckhauser(1988)は、大学院生ら486人に、投資先などの選択肢を提示する実験を行いました。同じ選択肢でも、その一つを「現在の選択」として示した場合には、特定の現状を示さない場合より選ばれやすい傾向が見られました。もっとも、本人がある選択肢を強く好む場合には、この傾向は弱くなりました。実験は主に仮想的な選択で、職場のシステム移行にかかる工数を測ったものではありません(Samuelson・Zeckhauser, 1988)。
実際の情報システムに近い研究もあります。KimとKankanhalli(2009)は、企業向け新システムの導入前という状況で利用者の抵抗を分析し、切り替えに伴う負担の認識が大きいことと、抵抗が強いことの関係を報告しています。一方、新システムの価値を高く評価することや、組織から支援があることは、抵抗が弱いことと関係していました。これは特定の企業向けシステムの導入前に検証されたモデルであり、どの職場でも移行費用が実際より過大評価されると示したものではありません(Kim・Kankanhalli, 2009)。
またPolitesとKarahanna(2012)は、使い慣れたシステムの習慣、移行コストや過去の投資への捉え方、今の方法を続けようとする気持ちと、新システムの受け止め方の関係を調べました。結果は、従来のシステムへの慣れや移行に関する負担が、新システムの受け入れを妨げ得るという研究モデルをおおむね支持していました。ただし、これは「慣れているから反対している」と個々の社員の理由を断定できるものではありません(Polites・Karahanna, 2012)。
仕事への応用で重要なのは、現状を続けたい気持ちが影響している可能性と、現実に発生する移行作業の両方を扱うことです。「抵抗は心理的なものだから説得すればよい」と考えるのではなく、負担の根拠を調べることが先です。
移行負担を見積もる前に確かめたいこと
最初に「どの仕事を、どこまで、新しいシステムへ移すのか」を決めます。対象が曖昧なままでは、全件移行が必要な作業と、古いシステムに残してよい作業が混ざってしまいます。
- 移すデータの範囲: 顧客情報、過去の案件、添付ファイル、独自の項目のうち、何件・何年分が必要でしょうか。古いデータを参照できれば足りるのか、編集まで必要なのかで作業が変わります。保存義務や個人情報の扱いも確認します。
- 業務のつながり: 会計、メール、承認、他部署への報告など、連携する仕組みは何でしょうか。データの出し入れが可能でも、権限設定や帳票の形が合うとは限りません。連携が再現できなければ、移行範囲や候補システムを見直します。
- 切り替えを許せる時期: 繁忙期の停止、二重入力、旧システムとの並行利用はどの程度まで許されるでしょうか。止められない業務では、安易な一斉切り替えを選ばず、復旧方法を含めて検討します。
- 習得と問い合わせ: 誰がどの操作を覚える必要があり、移行後の質問を誰が受けますか。管理者だけの研修費で済ませると、現場全体の時間を見落とします。
- いまのまま使う負担: 現在の入力し直し、集計、障害対応、更新費用はどのくらいでしょうか。移行費用だけ数えると、現状維持の手間が比較から消えてしまいます。
この段階で作業を「必要と確認済み」「条件が決まれば必要」「まだ不明」に分けます。不明な項目をゼロ時間と決めつけず、誰に聞くと確定するか、何を試せば分かるかも書き添えます。
作業量と費用を、確認できる数字に変える方法
以下は研究で効果が直接確かめられた標準手順ではなく、研究を参考に考えた実務上の提案です。費用見積もりで作業の範囲や前提を明らかにし、不確実性を分析する考え方については、米国政府監査院の費用見積もりガイド(2020)も参考になります。同ガイドは主に政府の事業・調達を対象にしており、以下の数値を保証するものではありません。
1.作業を細かく分け、量の根拠を残す
「移行が大変」という一行ではなく、データの整理、設定、連携確認、試験、研修、問い合わせ対応、並行運用、旧契約の終了を分けます。各作業に担当者、対象件数、1件当たりの時間、追加費用、分からない条件を記録します。ベンダーの見積額に含まれる作業と、社内で担う作業も区別します。
次の表は説明用に置いた仮の数値です。実際の相場や過去の企業実績ではありません。各作業を重複なく数え、研修以外の作業は各1人が行うという仮定で計算しています。ここで示すのは、何人分の作業時間が必要かを表す「人時」であり、移行が完了するまでの経過時間ではありません。
| 作業 | 仮の対象と所要時間 | 合計の目安 | 確認すること |
|---|---|---|---|
| データの手直し | 300件×1件3〜5分 | 15〜25時間 | 自動変換できる項目はないか |
| 利用者の研修 | 20人×1人1〜2時間 | 20〜40時間 | 部署・役割ごとに必要な操作は違うか |
| 動作の確認 | 12パターン×1件1〜2時間 | 12〜24時間 | 重要な連携・権限・帳票を網羅できるか |
| 上記3項目の合計 | 仮の計算 | 47〜89人時 | そのほかの作業は別途見積もる |
たとえば「300件の手直し」は、300×3÷60=15時間、300×5÷60=25時間です。この表の47〜89人時には、システム設定、既存サービスとの接続、データ移行本体、外部委託費、移行後の問い合わせ対応などが入っていません。ここだけを移行総工数と扱わないことが大切です。
2.不明な点は小さな実測で確かめる
データの一部を使って移行手順を試し、実際の手直し時間、変換できなかった項目、確認で出た不具合を記録します。例として300件のうち代表的な種類を含む少数件を試し、1件当たり時間の見積もりを更新します。ただし、例外的に複雑なデータもあるため、単純に平均を全件へ当てはめる前に、その種類と件数も見ます。
試行の前に、取り扱う情報の権限や持ち出し条件を確認してください。試用環境に顧客情報を無断で入れたり、復旧手順を決めずに本番のデータを変更したりしないことが前提です。検証で連携上の制約が分かれば、当初の範囲を変えるか、別製品を選ぶ判断につながります。
3.移行する場合と、しない場合を同じ期間で比べる
一度だけ発生する移行作業と、毎月続く費用・作業を分けます。たとえば今後1年間で比べるなら、移行案では「初期の社内作業時間と外注費+新システムの年間費用+切り替え後の運用時間」、現状維持案では「旧システムの年間費用+今の入力・集計・保守の時間」を確認します。移行による作業削減は、機能説明の数字をそのまま採用せず、試用で同じ仕事を行ったときの時間を材料にします。
作業時間は、担当者の勤務時間を使う負担として示し、金額へ換算する場合には人件費単価の前提を明記します。すでに支払った費用を「取り返すため」に移行や継続を選ばず、これから発生する費用と得られる便益で比較します。金額に直せない停止リスクや情報管理上の制約は、費用から消さず、別の判断条件として残します。
4.数字が分かった段階で進め方を選ぶ
- 負担が把握でき、効果と業務条件が見合う: 対象業務や移行時期、責任者を決めて具体的な計画へ進みます。
- 作業量の幅が大きい: 最も不確かなデータ変換や連携だけを先に検証し、再見積もりします。小さく試すことは、移行の可否を調べる方法であって、本番移行を保証するものではありません。
- 停止が許されない、または重要な機能が再現できない: 現状維持や候補の変更、段階移行の可否を検討します。二重運用がかえって危険になる業務もあるため、分割できるとは限りません。
- 今のシステムの負担が小さい: 新システムの利点があっても、現状維持が妥当な場合があります。反対に、保守終了などで継続の条件が悪化するなら、移行案の再検討が必要です。
移行への反対意見が出たときは、「何が一番不安ですか」だけで終わらせず、「どの作業が何件あり、何時間かかりそうですか」「何を調べたら見積もりが変わりますか」 と聞くと、確認すべきことが具体的になります。人の気持ちを変えることではなく、移行と現状維持の両方を同じ条件で判断できるようにすることが目的です。
参考文献・出典
- Samuelson, W., & Zeckhauser, R. (1988). Status quo bias in decision making. Journal of Risk and Uncertainty, 1, 7–59. — 現状として示された選択肢が選ばれやすい実験結果と、個人の選好による違いの根拠(原著の実験・結果部分を確認)。
- Kim, H.-W., & Kankanhalli, A. (2009). Investigating User Resistance to Information Systems Implementation: A Status Quo Bias Perspective. MIS Quarterly, 33(3), 567–582. — 企業向けシステムの導入前における切り替え負担の認識、利用者の抵抗、支援・価値の関係の根拠(出版社の要旨を確認)。
- Polites, G. L., & Karahanna, E. (2012). Shackled to the Status Quo: The Inhibiting Effects of Incumbent System Habit, Switching Costs, and Inertia on New System Acceptance. MIS Quarterly, 36(1), 21–42. — 従来システムへの習慣や移行負担の認識と、新システムの受け入れの関係の根拠(出版社の要旨を確認)。
- U.S. Government Accountability Office (2020). Cost Estimating and Assessment Guide: Best Practices for Developing and Managing Program Costs, GAO-20-195G. — 作業範囲・前提・実測データ・不確実性を分けて費用を見積もるための実務資料(公式概要を確認)。