新しいシステムを公開した日。説明会は終わり、マニュアルも配り、「本日から新システムで運用します」という連絡も出しました。
長かった導入が、ようやく一区切りついた。そう思ったのに、三週間たっても電話は鳴り続けている。写真はメールで届き、担当者は届いた依頼を、昔からの表計算の台帳に書き写している。
ここでは、説明のために作った架空の例で考えてみます。複数の営業所や倉庫を持つ会社が、設備の修繕依頼を受け付けるシステムを入れた、という場面です。
「もう一度、説明会を開きましょうか」
こういうとき、導入した側が最初に考えるのは、だいたい次のどちらかです。
- もう一度、説明会を開く
- 「新しいシステムを使ってください」と全体に呼びかける
どちらも悪い手ではありません。ただ、説明会の内容を皆が忘れていたとは限らないのです。
「操作は分かるんです。でも、急ぎの修理もシステムに入れていいのか分からなくて」
「登録しても、受け付けてもらえたのか分からないので、電話のほうが安心なんです」
足りなかったのは、操作の説明ではなく、別のところだったのかもしれません。
公開した日と、仕事が移った日は違う
導入の計画は、公開日をゴールに置きがちです。要件を決め、作り、テストし、説明会を開いて公開する。計画表の最後の行は、たいてい「本番公開」です。
でも、現場の仕事が新しいやり方へ移るのは、公開日と同じ日ではありません。そのあいだには、誰の担当なのかがはっきりしない期間ができます。開発側は公開で一区切りをつけ、業務部門は「あとは使うだけ」と考える。その間で、使う人は一人で新しいやり方に慣れようとしています。
利用者が元のやり方に戻ると、「変化を嫌っている」「説明が足りなかった」と考えたくなります。そうした面がまったくないとは言えません。ただ、理由をそれだけに絞ると、打てる手が「もう一度説明する」「呼びかける」に限られてしまいます。
どこへ戻ったかを見る
そこでおすすめしたいのが、利用者が「どこへ戻ったか」に目を向けることです。
- 急ぎの修理を電話で頼んだ
- 写真をメールで別に送った
- 登録したうえで、紙の控えも残した
こうした戻り方には、それぞれ理由があります。急ぎの場合の扱いが示されていなかったのかもしれません。写真を撮る道具と、登録する道具が別だったのかもしれません。紙の控えは、拠点の中で誰かに見せるために必要なのかもしれません。
戻り先は、「使ってくれない人」の証拠ではなく、新しいやり方へ移るために何がまだそろっていないかを教えてくれる手がかりです。
明日、一件だけ聞いてみる
全員に呼びかける前に、一件だけ聞いてみてください。
「先週お電話でいただいた件、システムに入れにくい事情がありましたか」
答えが聞けたら、日付、誰が（名前ではなく役割で）、どんな場面で、どこへ戻ったか、本人が挙げた理由を、一行で書き留めておきます。理由が聞けなければ、そこは空けたままで構いません。
古いやり方を止める権限がなくても、この一行は書けます。一件、二件とたまってくると、つまずきがどこに集まっているかが見えてきます。
Kindleで、この続きを
Kindleシリーズ「IT会議の翻訳者」第25巻では、利用者が戻る理由を「仕事を移す六つの足場」として整理しました。使う理由、変わる仕事、最初の一歩、困ったときの支え、例外の扱い、旧手段の終了条件の六つです。公開前に仮決めし、公開直後に観察し、公開後に更新していく進め方を、架空の設備修繕依頼システムの例で追いかけています。
全員がすぐに新しいシステムだけを使うようになる、という本ではありません。それでも、どこまでが新しいやり方で、どこからが正式な例外なのかを、関係者で共有していくことはできます。
