INSIGHT
描いた。作った。教えた。では、誰が仕事を変えるのか
各担当の成果物がそろっても、誰が運用の変更を引き受けるか。
構想をまとめる支援が終わった。仕組みは納品され、研修も実施した。部門ではAIの試行も行い、「便利だった」という声が出ている。それぞれの報告書には完了と書ける。それでも翌月、参照資料の更新先は分からず、現場の改善要望はどの契約にも予定にも入っていない。
これは、コンサルタント、開発者、研修担当、利用者の誰か一人が仕事をしなかった、という話ではありません。それぞれが受け持った仕事は完了していても、成果から次の成果へ渡す仕事が別に残るからです。単発の成果を日常業務へつなぐには、職種の境目ではなく、受渡しの境目を見ます。
四つの「完了」は、受け取るものが違う
構想、開発、研修、試行には、それぞれ別の完了があります。
| 終わった仕事 | 受け取った成果 | 次に必要な判断 |
|---|---|---|
| 構想を描く | 対象業務、優先順位、実施案 | 最初に変える仕事を誰が決めるか |
| 仕組みを作る | 画面、設定、動作結果 | 誰が受け入れ、変更を依頼するか |
| 使い方を教える | 教材、演習、受講記録 | 実案件で迷った人を誰が支えるか |
| AIを試す | 利用記録、感想、測定結果 | 続ける範囲と直す点を誰が決めるか |
左側の成果を納品した担当者へ、右側の社内判断まで当然に求めることはできません。反対に、社内側が「支援会社が考えるだろう」「システム担当が直すだろう」と置いたままでも、次の仕事は始まりません。
分断は職種の間にあるのではなく、完了した成果を、次の判断へ渡す役割が空欄になった場所に生まれます。
一件の仕事を追うと、つながっていない場所が見える
部門名や契約名で体制図を作る前に、実際の一件を追います。たとえば、社内規程への問い合わせなら、次の順です。
「質問を受ける → 入力してよい内容か見る → 規程を探す → 回答案を作る → 根拠を確認する → 送る → 誤りを訂正する → 規程の変更を反映する」
各工程の下に、担当、使う資料、完了の合図、困ったときの相談先を書きます。空欄があったら、仕組みの欠陥と決める前に、誰の仕事として引き取るかを話します。回答案は作れるのに規程更新が反映されないなら、開発のやり直しだけでなく、正本を更新する部署から仕組みへ渡す手順が必要です。利用者が迷っても窓口がないなら、研修の追加だけでなく、質問を集めて利用範囲を見直す人が必要です。
ここでいう工程間の仕事は、前の成果を次の担当が使える形へする作業です。資料を更新する、例外を記録する、改善要望へ返事をする、利用範囲を決め直すといった、日常では目立ちにくい仕事が含まれます。
次の担当者が、増えた仕事を引き受けられるか
AIを使った本人の作成時間が短くなっても、確認者の負担、差戻し、次の担当の待ち時間が増えていれば、部門全体の仕事が軽くなったとは言えません。逆に、確認時間が残っても、問い合わせの滞留や手戻りが減り、重要な案件へ時間を使えたなら、作成時間だけでは見えない変化があります。
顧客対応担当5,172人を対象にした査読研究Generative AI at Work では、AI支援を段階導入した条件で、時間あたりの解決件数が平均15%増えたと報告されています。これは特定の顧客対応業務、人を支援する使い方で得られた結果です。バックオフィス全般、完全自動応答、全社利益や人員削減を直接示すものではありません。
自社では、同じ一件について、少なくとも次を見ます。
- 作る人：作成時間、修正した理由
- 確かめる人：確認時間、差戻した理由
- 受け取る人：待ち時間、やり直し、使えなかった結果
- 続ける人：資料更新、問い合わせ対応、変更に必要な時間
個人の時短は成果の入口です。前後工程で減った仕事、増えた仕事、その引受人まで見て、組織の成果として判断できます。
引受人には、名前と一緒に三つを渡す
「現場が運用する」「DX担当が改善する」と書くだけでは、引継ぎは成立しません。引受人の名前や部署と一緒に、判断できる範囲、使える時間、相談先の三つを決めます。
受け取る側が「いまの業務と兼務では無理です」と答えたら、それは引継ぎの失敗ではなく、計画に足りなかった条件です。作業を減らす、担当時間を確保する、外部支援の契約を追加する、利用開始を遅らせる。その選択を責任者へ返します。担当欄に名前を書いても、相手が引き受けられると確認するまでは完了にしません。
たとえば、現場代表は使わなかった例と修正理由を月に一度まとめる。業務責任者は利用範囲と改善順位を決める。情報管理担当は入力情報やサービス条件の変更を確認する。仕組みの担当は変更の影響と戻し方を説明する。外部支援を続けるなら、相談できる内容、回答時期、契約外になる変更も書きます。
ソフトウェア開発の年次調査DORAの2025年レポート は、AI利用と成果の関係を扱い、既存の組織条件の重要性も報告しています。これは、AIが組織の安定性を必ず良くする、または悪くするという因果証明ではありません。ツールの利用有無だけで結果を説明せず、仕事を支える体制も見るための資料です。
改善の時間は、月に短時間でも予定へ置きます。記録を見る日がなければ、使われなかった理由や例外は集まっても判断へ渡りません。提案を受け取ったら、実施、保留、対象外のどれかを返し、理由を残します。
次の一か月だけを、共同の引継ぎ表にする
すべての分断を一度に解こうとすると、新しい体制づくりが目的になります。まず、次の一か月でつなぐ一件を決めます。関係者が同じ一枚を見て、次の五つを埋めます。
- 変えたい仕事と、変えない条件
- 今回までに得られた成果と、確認済みの範囲
- 前後に残る手作業、判断、未確認
- 引き受ける部署、判断範囲、相談先
- 見る記録、判断する日、続ける・直す・止める人
この表は、誰の成果が足りなかったかを採点するためのものではありません。構想資料、納品物、研修、試行記録を、同じ業務判断へつなぐためのものです。「契約に含まれない」「担当の時間がない」「正本が決まっていない」と分かったなら、それも次の判断に必要な結果です。
次へ渡す人、受け取る人、受け取った後の判断日が書ければ、単発の成果は日常の運用へ移り始めます。
構想・開発・研修の間に残る、業務の受け渡しと判断を決める
構想を描いた。仕組みを作った。使い方を教えた。AIも試した。その一つひとつは、次の工程へ進むための成果です。日常の仕事を変えるのは、どれか一つの職種や契約ではなく、成果の間に残る判断を会社が引き受けたときです。
次の打合せでは、一件の業務を横に書き、「ここから誰が受け取るか」「何を決めてよいか」「いつ記録を見直すか」を埋めてください。人への批判を始めなくても、止まっていた受渡しは見つけられます。