FAXをやめる、という判断はゴールではない。
業務としては、むしろそこからが本番になる。
重要なのは、FAXの代わりに何を置くか、だ。
ツール選定の話に見えるが、実際には判断の置きどころの問題である。
※AS-IS側の記録は別記事に置いた。ここではTO-BE側だけを書く。
いきなりTO-BEを描かなかった理由
ボトルネックが見えた直後、人は早く答えを置きたくなる。
だが、私はTO-BEを先に出さなかった。
TO-BEを先に出すと、議論の主語が「ツール」に戻る。
すると、話は必ずこうなる。
- それは本当に必要か
- 誰が使えるのか
- 失敗したらどうするのか
この議論自体が悪いわけではない。
ただ、ここに早く入ると、現場は固まりやすい。
まず必要だったのは、変えていい前提が共有されることだった。
つまり、AS-ISが「事実」として場に置かれている状態である。
TO-BEに求めた条件
TO-BEとして何を置くか。
私は「機能」ではなく「条件」だけを考えた。
- 新しい操作を最小限にできる
- 特定の人だけが詳しくならない
- 業務の流れを壊さない
- 例外が出ても破綻しにくい
便利そうである必要はなかった。
高機能である必要もなかった。
欲しかったのは、「静かに置き換わる」ことだけである。
Teamsを選んだ理由
結果として、Teamsを選んだ。
理由は、新しいツールだからではない。
すでに組織の中にあり、一部では使われていた。
導入ではなく、配置の変更で済む。
この差は大きい。
新しいツールを入れると、必ず摩擦が増える。
- アカウントや権限
- 申請や手続き
- 「覚えること」の増加
- 問い合わせ対応の集中
今回の目的は「IT化」ではない。
FAX起点の停滞を減らすことだった。
Teamsは、業務の通り道として置ける。
その一点が決め手になった。
「全部デジタルにする」を選ばなかった理由
TO-BEを描くとき、「全部デジタルにする」という案も出る。
だが、私はそれを選ばなかった。
理由は、最初から完成形を作ろうとすると、
実務はかえって壊れやすくなるからだ。
例外や人の判断を前提にしない設計は、
現場では長くもたない。
- 一部が止まると全部が止まる
- 例外処理が増え、結局属人化する
- 「正しい手順」への逸脱が許されず、現場が疲れる
TO-BEは理想像ではない。
その時点で動く形として仮置きするものだ。
私は、完成度よりも定着の確率を優先した。
置き換えの仕方
FAXを「Teamsに置き換えた」というより、
FAXが通っていた場所に、別の通り道を作った、という感覚に近い。
そのとき意識したのは、急に切り替えないことだった。
段階的に、手順として馴染ませていく。
「誰が」「いつ」「何を」「どこに置くか」。
この粒度まで落とすと、反対は意見ではなく条件になる。
条件になれば、調整ができる。
導入後に起きることを前提にした
TO-BEは完成版ではない。
導入したあとに、必ず手順の微調整が起こる。
私は「戻れるか」よりも、こちらを優先した。
モニタリングして、なじませること。
導入後に見るポイントは明確だった。
- どこで詰まるか
- 誰が戸惑うか
- 想定外の動きは出るか
- 現場の負担は本当に減ったか
それを見ながら、手順を少しずつ整える。
この微調整が前提にあると、現場は動きやすい。
最初から正解を置こうとすると、現場は固まる。
未完成を前提にすると、現場は動き続ける。
振り返って思うこと
TO-BEは、正しさの宣言ではない。
現時点の仮置きである。
そして仮置きである以上、導入後のモニタリングと微調整がセットになる。
私は、ここまで含めてTO-BEだと考えている。
※このTO-BEも、モニタリングと微調整を前提に成り立っている。
コメント