プログラムが失敗する形で一番多いのは、途中で止まることではありません。全部作り終えたのに、成果が出ないことです。

システムは動いています。テストも通っています。それでも数字が変わらない。原因はほぼ決まっていて、現場のやり方が変わっていないのです。

■ 稼働日は、途中の1日でしかない

プロジェクトの計画では、稼働日がゴールです。プログラムでは違います。稼働日は、成果が出るまでの長い工程の真ん中あたりにあります。

図のとおり、稼働の前後には次の作業が必要です。

• 新しい手順書を作る（システムの操作マニュアルとは別物）

• 現場に説明し、練習してもらう

• 例外的なケースの扱いを決めておく

• 旧のやり方を止める

• 使われているかを確認し、使われていなければ理由を調べる

これらは、プログラムの計画に行として存在しないと、実行されません。「業務部門がやるもの」として計画の外に置かれたとき、誰も担当しない状態になります。

■ 手順書は、業務側の人が書く

操作マニュアルはシステム側で作れます。しかし業務手順書は違います。

業務手順書を業務側に書いてもらうのは、時間がかかります。本業がありますし、文書を書き慣れていない人も多いです。だからこそ、計画に入れて、時間を確保する必要があります。

進め方のコツは、白紙から書いてもらわないことです。こちらで叩き台を作り、「ここは実際どうしていますか」と聞きながら直していく。この形なら、数回の打ち合わせで形になります。

■ 旧を止める日を、最初に決める

定着で一番効くのが、これです。新しい仕組みと古いやり方が並んでいると、人は慣れたほうを使います。

並行運用は必要ですが、期間を最初に決めておくことが重要です。「様子を見ながら」にすると、半年経っても旧が残ります。

4行目も忘れがちです。旧の依頼経路が生きていると、そこから仕事が流れ込み続けます。

■ 使われているかを数える

定着しているかどうかは、感覚では分かりません。数えます。

• 新しい画面から入力された件数 ÷ 全件数（システムで取れる）

• 新手順で処理された件数の割合（一定期間、記録してもらう）

• 旧帳票の残数（現場を回って数える）

この数字が低い場合、責めても上がりません。使いにくい理由が必ずあります。よくあるのは、例外的なケースの扱いが決まっていないこと。1件でも扱えないケースがあると、現場は「じゃあ今までどおりでいいか」となります。

■ 定着を担当する人を決める

最後に、この一連の作業を誰が持つかです。プログラムマネージャーが全部やるのは無理があります。

おすすめは、業務部門側に「定着の責任者」を1人置くことです。システム側ではありません。現場に顔が利き、手順を決められる人。この人がいるかどうかで、定着の速度が変わります。

そしてこの人の作業も、プログラムの計画に行として書きます。

■ まとめ

プログラムの計画には、システム側・業務側・旧のたたみ方の3つの行を置く。業務手順書は業務側が書き、旧を止める日は最初に決める。そして、使われているかを数える。

いま関わっているプログラムの計画を見て、「旧を止める」という作業が書かれているか確かめてみてください。なければ、そこが成果を止める場所になります。