自動化の元が取れるか3分で判定するテンプレ
「このスクリプト、作る意味あるかな」
ローカル開発でちょっとした自動化を思いついたとき、手が止まる瞬間がある。作業時間は減りそうだけど、作る時間と保守の手間を考えると、本当に得なのか分からない。結局「まあいいか」で手作業を続けてしまう。
この記事では、自動化の投資対効果を3分で判定できるテンプレートを紹介する。細かい計算は抜きにして「やるべきか、やめるべきか」を素早く決めるための道具だ。
回収期間で判断する理由
自動化の効果を測る指標はいくつかあるが、ローカル開発の小さな自動化なら「回収期間(Payback period)」が手軽で速い。
回収期間とは、投資した時間やコストを何か月で取り戻せるかを示す数字だ。計算式はシンプルで、
回収期間(月) = 初期コスト ÷ 月あたりの純便益
これだけ。NPV(正味現在価値)のように将来のお金を割り引いて計算する方法もあるが、数か月で回収できるような小さな自動化にそこまでの精度は要らない。
ただし、回収期間は「回収後にどれだけ得するか」を見ない。長く使うほど得する自動化と、すぐ陳腐化する自動化を区別できない点は覚えておきたい。3分判定で「微妙だな」と感じたら、そこで初めてNPVなど別の指標を検討すればいい。
3分判定テンプレート
入力項目を4つに絞った。これ以上増やすと3分で終わらない。
【自動化ROI判定シート】
■ 入力
① 月あたり削減時間:_____ h/月
② 時給(人件費込み):_____ 円
③ ツール月額コスト:_____ 円
④ 初期コスト(作成時間×時給):_____ 円
■ 計算
月次の純便益 = (① × ②) − ③ − 保守工数
回収期間 = ④ ÷ 月次の純便益
■ 判定
・1〜3か月 → 優先度高、すぐやる
・3〜6か月 → 条件次第でやる
・6か月超 → 要再検討(頻度増・設計簡素化など)
各項目の埋め方
① 月あたり削減時間
週単位で考えたほうが分かりやすければ、週の削減時間に4.33を掛ける。4週/月で計算すると年間48週分しかカウントしないので、52週÷12で出した4.33のほうがズレが小さい。
例:週に2.5時間かかる作業を自動化 → 2.5 × 4.33 ≒ 10.8h/月
② 時給(人件費込み)
給与をそのまま使うと実態とズレる。会社員なら福利厚生や間接費を含めた「loaded rate」で考えるのが本筋で、概算では基本給の1.3倍程度とする考え方がある。フリーランスなら請求単価をそのまま使えばいい。
自社の人件費ルールがあればそれに従う。なければ「時給 × 1.3」で仮置きして、あとで調整する。
③ ツール月額コスト
SaaSの月額料金や、APIの従量課金の見込み額。無料ツールだけで完結するなら0円。
④ 初期コスト
自動化スクリプトを作る時間 × 時給。3時間で作れそうなら、時給3,000円として9,000円。
保守コストをゼロにしない
テンプレートの「月次の純便益」に「保守工数」と書いた。ここを0にすると痛い目を見る。
自動化は作って終わりではない。API仕様が変わる、対象のフォーマットが増える、例外ケースに対応する。月に30分でも保守に時間を取られるなら、それを織り込んでおく。
私の感覚では、小さなスクリプトでも月0.5〜1時間は保守を見積もっておくと安全だ。実際にゼロで済んだらラッキー、くらいの気持ちでいい。
実際に計算してみる
毎週金曜にやっているログ集計作業を自動化する例で試す。
- 現状:週1.5時間、手作業でCSVを加工している
- 見込み:Pythonスクリプトで5時間あれば作れそう
- ツール:無料(ローカルで完結)
- 保守:月0.5時間と見積もる
① 月あたり削減時間:1.5 × 4.33 ≒ 6.5h
② 時給(人件費込み):3,000 × 1.3 = 3,900円
③ ツール月額コスト:0円
④ 初期コスト:5h × 3,900円 = 19,500円
月次の純便益 = (6.5 × 3,900) − 0 − (0.5 × 3,900)
= 25,350 − 1,950 = 23,400円
回収期間 = 19,500 ÷ 23,400 ≒ 0.83か月
1か月以内に回収できる計算になった。優先度高、すぐ着手していい。
判定が微妙なときに見直すポイント
回収期間が6か月を超えたら、まず以下を疑う。
頻度を増やせないか 週1回の作業を週3回に増やせるなら、削減時間は3倍になる。自動化したからこそ回せる頻度がないか考える。
対象を広げられないか 自分だけでなくチーム全員が使えるなら、削減時間は人数分に増える。
設計を削れないか 「あったら便利」な機能を削って、最小限の自動化にする。初期コストが半分になれば回収期間も半分。
それでも6か月を超えるなら、今は見送りでいい。状況が変わったときに再判定すればいい。
前提が崩れるパターンを書き出す
テンプレートの外に「前提が崩れる条件」をメモしておくと、あとで困らない。
- 処理件数が大幅に減る(対象プロジェクトが終了するなど)
- APIのレート制限に引っかかる
- 手作業の例外ケースが想定より多い
- 品質保証が必要になる(目視確認を省けない)
こういった条件が出てきたら、回収期間の計算をやり直す。自動化を作り始める前に「これが起きたらアウト」を言語化しておくと、判断が早くなる。
この判定が向かない領域
回収期間の計算自体は汎用的に使えるが、コストの算定に専門知識が要る領域では注意が必要だ。
税務処理の自動化ならコンプライアンスコストを、医療系なら規制対応のコストを織り込む必要がある。こうした領域で自動化のROIを本気で計算するなら、専門家に相談したほうがいい。
この記事のテンプレートは、あくまで「ローカル開発のちょい足し自動化」を素早く判断するためのものだ。大規模な業務自動化や、リスクの高い領域には使わないでほしい。
まとめ
自動化を思いついたら、まず3分で回収期間を計算する。1〜3か月で回収できるならすぐやる、6か月超なら設計を見直すか見送る。
判定の精度を上げようとして項目を増やすと、計算に時間がかかって本末転倒になる。粗くても速く判断して、実際に作ってみて、違ったら軌道修正する。そのサイクルを回せるのが、小さな自動化の強みだ。