キックオフで配られる体制表を見ると、そのプロジェクトが稼働後にどうなるかがだいたい分かる。ベンダー側の欄には役割ごとに氏名が並び、発注側の欄には部門名と、括弧書きで「兼務」と書かれている。経理部の代表として名前が入っているのは、たいてい月次の実務から少し離れた立場の人だ。そして半年後、設計レビューで「この処理は実際どうやっていますか」と聞くと、「担当に確認します」という答えが返ってくる。現場の主力を出し渋ったプロジェクトは、要件定義の遅れとして表面化するのでなく、稼働後の毎月の手作業として跳ね返る。 要員供出は人繰りの話ではなく、稼働後に何を手で埋めるかを先に決める設計判断だ。
エースを出し渋った分は、稼働後の毎月の作業として返ってくる
「今の締めが回らなくなるので、主力はプロジェクトに出せない」。この判断は、その瞬間だけを見れば正しい。月次は毎月来るし、止められない。プロジェクトは半年か一年で終わる。どちらを優先するかと問われれば、目の前の締めになる。
問題は、その選択のコストが後払いになることだ。現場を知らない人が要件定義に座ると、設計は現行の業務フロー図の写しになる。業務フロー図に書いてあるのは標準の流れだけで、実際の締めを支えている例外処理は書かれていない。締め日をまたいで届く請求書の扱い、金額が確定しない費用の見積計上ルール、部門をまたぐ配賦の例外、期末だけ手順が変わる処理、システムに乗らないので毎月Excelで処理している数十件。これらは設計書に載らないまま稼働日を迎える。
稼働後に起きるのは障害ではない。もっと静かで、もっと長く効く現象が起きる。担当者が自分でExcelを作り、そこで処理して、結果だけをシステムに入れ直す。これが二重管理の始まりで、いったん定着すると剥がすのに数年かかる。しかも二重管理の存在は誰も報告しないので、経営から見れば「システムは無事に稼働した」ように見える。
だから要員供出の議論は、人繰りの調整でなく、投資の一部として扱う。導入費用の何割かを、供出する要員の稼働という形で払っている。ここをケチると、導入費用は変わらないのに、得られるものが減る。
供出は「誰を」でなく「どの工程に何割で何か月」で決める
要員供出が難しく見えるのは、「エースを一年間フルで出せるか」という極端な問いの形で議論されるからだ。フルで出せる会社はほとんど無い。だから議論は「出せない」で終わり、兼務で二割という結論に落ちる。
工程ごとに必要な厚みは大きく違う。設計工程の中盤とベンダー内テストの期間は、発注側の稼働はそれほど要らない。逆に要件定義と受入テストは、薄い体制では絶対に成立しない。この凹凸を先に描いて、合計の人月で交渉するほうが現実的だ。
| 工程 | 期間の目安 | 経理主力の稼働率 | その工程で確定させること | 出さなかった場合に起きること |
|---|---|---|---|---|
| 構想・要件定義 | 2〜3か月 | 70〜80% | 業務要件、帳票要件、組織構造、勘定科目体系、分析軸 | 設計が現行フロー図の写しになり、例外が全部落ちる |
| 基本設計・詳細設計 | 3〜4か月 | 40〜50% | 設計レビュー、例外処理の扱い、マスタ項目定義、権限設計 | 設計書は出るが、締めが回らない設計になる |
| 開発・ベンダー内テスト | 2〜3か月 | 20〜30% | マスタの記入と名寄せ、移行データの突合、手順書の骨子 | 移行データの品質不良が、テスト直前にまとめて出る |
| 受入テスト | 1.5〜2か月 | 80〜100% | 締めを実データで一巡、合否判定、残不具合の運用回避 | 画面操作の確認だけで合格が出て、稼働後に月次が止まる |
| カットオーバー・初回締め | 1〜2か月 | 100% | 期首残高の確定、業務凍結期間、初回の月次 | 初回の締めで止まり、その混乱が数か月尾を引く |
| 稼働後の定着 | 3か月 | 30〜50% | 手順書の確定、問い合わせの一次受け、改善要求の仕分け | ベンダー依存が固定され、保守費が下がらない |
この表を体制の交渉材料にすると、話が動く。「一年間フルで」は無理でも、「要件定義の三か月を七割、テストとカットオーバーの三か月をほぼ全稼働、その間の四か月は二割」なら、合計は五人月前後になる。部門の年間工数から見て、出せない量ではないことが多い。
受入テストで八割から十割が必要な理由は、テストの中身が操作確認ではなく締めの一巡だからだ。実データを入れて月次を通し、詰まった箇所を潰す。これは実務を毎月回している人にしかできない（SAPの受入テスト（UAT）で経理は何を見るか｜シナリオの粒度とテストデータの決め方）。カットオーバーで全稼働が要るのも同じ構造で、期首残高の確定と業務凍結期間の運用は、実務の順序を体で知っている人が張り付かないと決まらない（SAPのカットオーバー計画｜期首残高の確定と業務凍結期間をどう決めるか）。
出す人の条件は、業務に詳しいことでなく例外を説明できること
「エースを出す」と言うとき、多くの会社は「いちばん処理が速い人」を想定する。処理速度は稼働後に価値を持つが、プロジェクトの工程では別の能力が要る。
要件定義とテストで効くのは、なぜその処理がその形になっているかを説明できる能力だ。「この費用は検収日でなく請求書の日付で計上している」という事実を知っているだけでは足りない。なぜそうしているのか、いつからそうなのか、変えると誰が困るのかまで言える人でないと、Fit-to-Standardの議論で判断ができない。理由が言えなければ、ベンダーの「標準ではこうなります」に対して「それで問題ない」とも「困る」とも答えられず、結論は先送りされる。先送りされた論点は、テストの直前に戻ってくる。
もう一つの条件は、部門をまたいで話が通ることだ。会計の設計は購買・販売・在庫の業務設計と地続きで、勘定科目一つの設計が営業の受注入力の項目まで影響する。部門をまたいで「これはそちらで持ってほしい」と言える立場と人間関係がないと、境目の作業が全部経理に落ちる。
逆に、出さなくてよい人もはっきりしている。手順書どおりに正確に処理できるが、手順の理由を聞かれると答えられない人は、プロジェクトに出しても価値が出にくく、現場に残ったほうが締めが回る。この見極めは、属人化の棚卸しとほぼ同じ作業になる（属人化した決算を組織知に変える 担当者が辞めても締まる引き継ぎ設計）。
- 出す人の氏名と、工程別の稼働率（「兼務」でなく数字で）
- 供出期間中、その人が持たない業務の一覧（誰に移すかまで）
- プロジェクトでの決定権限の範囲（どこまで自分で決めてよいか）
- 上位に上げる場合の相手と、上げてから返答が来るまでの期限
- 供出者の評価をどの部門が行うか（プロジェクト期間中の評価軸）
- 抜けた席を埋める手段と、その予算の出どころ
- 稼働後、その人がどこに戻るか（プロジェクト要員のまま塩漬けにしない）
最後の項目は軽く見られやすいが、供出を渋る心理的な理由はここにあることが多い。一年出したら戻る席が無くなるかもしれない、と本人も上長も思っている。戻り先を先に書いておくと、供出の交渉は驚くほど早く終わる。
抜けた席は増員で埋めない。作業を切り出して外へ出す
主力が抜けた穴を、採用や配置転換で埋めようとすると、たいてい間に合わない。締めの実務を一人前に回せるようになるまでの期間は、プロジェクトの期間より長いからだ。しかも教える側は、抜ける本人になる。
埋め方は逆向きに考える。人を足すのでなく、作業を減らすか、外へ出す。順番はこうなる。
この分解には副産物がある。作業を工程単位で書き出し、所要時間を実測した資料は、そのままプロジェクトの現行業務調査の入力になる。ベンダーが現行調査でヒアリングして作る資料と、内容がほとんど同じだ。先に自分たちで作っておけば、ヒアリングにかかる主力の稼働も減る。
作業を分解すると、月初に集中している負荷のうち、期中に前倒しできる部分が見えてくることも多い。締めの負荷が平準化されれば、供出できる稼働率そのものが上がる。また、一人抜けた状態で締めを回す設計は、欠員や休職への備えと同じ構造なので、供出を機に一度作っておくと後で効く（欠員・休職が出た期の決算をどう締めるか｜1人抜けても止まらない縮退運転の設計）。
兼務のまま出すと、プロジェクトも締めも両方遅れる
いちばん多い形が「兼務で二割」だ。そしてこの形が、いちばん結果が出ない。
理由は稼働率の低さではなく、優先順位が毎日揺れることにある。月初は締めが優先されるので、プロジェクトの会議は欠席になる。中旬に出席しても、前回の議論を追えていないので発言できない。下旬に設計レビューの宿題が出るが、月末の準備が始まるので手を付けられない。結果、二割の稼働すら実効では一割を切る。ベンダー側から見ると「発注側から回答が返ってこない」状態が続き、その間の工数は空転する。
この空転は契約上も不利に働く。ベンダーの前提条件に「発注側キーユーザの参画」が書かれていれば、回答遅延による工期延伸の責任は発注側に寄る。締結前に供出できる稼働率を握っておかないと、後から数字で詰められる（SAP導入の見積りと契約をどう読むか｜追加費用が生まれる境目を先に潰す）。
兼務を避けられない場合の折衷案は二つある。一つは、日で切ること。「週のうち月火はプロジェクト専任、水木金は経理」と曜日で固定し、その日は席も移す。時間で按分するより実効稼働が上がる。もう一つは、工程で切ること。要件定義とテストの期間だけ完全に専任にし、その間は締めから完全に外れる。中途半端に両方やる期間を作らないほうが、どちらも回る。
供出しなかった分は、稼働後に毎月支払うことになる
要員供出の判断は、コストを削る判断ではなく、コストをいつ払うかの判断だ。
稼働後に残った手作業は、金額として計上されない。だから経営には見えない。見えるのは、経理の残業時間が導入前より減っていないという事実だけで、その原因は誰も説明しない。ここを可視化するには、稼働後の運用を内製で回す前提に立って、問い合わせ件数と手作業の件数を毎月数える仕組みを持つしかない。
だから供出を決めるとき、社内の議論は「誰を出すか」から始めない。先に決めるのは工程ごとに必要な稼働率と期間で、数字が出れば、それを満たせる人は自然に絞られる。次に抜けた席の埋め方を決め、最後に人の名前を入れる。この順でやると、出す出さないの感情的な綱引きにならない。
戻す順番も先に書いておく。カットオーバーの後すぐ元の席へ戻すと、稼働直後の問い合わせが全部ベンダーへ流れる。稼働後の三か月は三割から五割で残し、手順書を確定させ、問い合わせの一次受けを内部に作る。ここで作った手順書が、次の担当者へ渡る唯一の資産になる（経理の手順書（決算マニュアル）の書き方：使われる手順書と死蔵される手順書の差）。そしてプロジェクトに出した人が、そのまま稼働後のシステムオーナーとして残る形が最も自然だ。設計の理由を知る人がシステムを持てば、ベンダーへの外部依存はそこで止まる。
