業務を自動化しても評価されないとき、成果をどう伝えるか

業務を自動化した成果は、「ツールを作りました」だけでは伝わりにくいものです。誰の、どの仕事が、どのくらい変わったかを、改善前と改善後の同じ単位で並べてみます。

作成したプログラムの行数よりも、利用する人の負担や、確認作業の変化から説明するための報告例をまとめます。以下の数字は説明用の仮定であり、実際の改善実績ではありません。

最初に、何を成果として見てもらうかを合わせる

自動化の前に、上司や利用者へ「何が改善すれば役に立つか」を確認します。

たとえば、転記時間を短くしたいのか、集計の間違いを減らしたいのか、担当者が休んでも処理できるようにしたいのか。同じツールでも、目的によって集める記録が変わります。

すでに完成しているなら、使っている人に「作業のどこが変わったか」「まだ手間がかかる箇所はどこか」を聞くところから始められます。作る側が便利だと思っている点と、使う側の評価が一致するとは限りません。

月次の集計作業を、1回30分から5分へ短縮したとします。月20回処理する場合の計算例です。

初期作成に10時間かかったなら、それも別に記載します。この条件が続くという仮定では、600分 ÷ 440分で約1.4か月が、作成時間を回収する目安です。実際には処理回数や保守負担が変わるので、固定の成果として扱わず、計測期間を添えます。

また、空いた時間がそのまま支出削減になるとは限りません。「人件費を削減した」と言い切るより、「確認業務に回せる時間が月7時間20分生まれた」と、確認できる範囲で伝えます。

「ミスがなくなった」と書く場合も、何回の処理を見た結果なのかが必要です。期間も件数も違う数字を並べると、改善の効果なのか、単に仕事が少なかったのか判断できません。

数字を取っていなかった箇所は、「利用者から再確認がしやすくなったという感想があった」など、測定値と感想を分けて書きます。後から都合のよい改善前の数字を作る必要はありません。

対象業務：
困っていたこと：
改善した内容：
計測期間・処理件数：
改善前の作業時間：
改善後の作業時間（結果確認を含む）：
初期作成と維持管理にかかった時間：
利用者・担当者からの反応：
対応できない条件、残っている手作業：
次に相談したいこと：

長い資料を作る前に、この項目を1枚に収めます。冒頭の説明は、たとえば次のようになります。

月20回の集計を対象に、結果確認と月1時間の保守を含めて、月7時間20分の作業時間を減らせる試算です。初期作成は10時間でした。まず1か月運用し、実測値と例外処理の件数を報告します。

これはまだ試算の段階の書き方です。運用後は、実際に記録した数字へ置き換えます。

説明を整えれば人事評価が上がる、とまでは言えません。担当業務や評価制度との関係もあります。上司へ「この改善は、今期の目標のどの項目として扱えますか」と確認しておくと、次に何を求められているのか話しやすくなります。

依頼が増えた分をすべて無償の追加作業として抱えず、運用・保守の担当と時間も相談します。自動化を続けるなら、成果の報告と同時に、維持できる体制を作ることも仕事の一部です。