外部コンサルや開発会社がいる間は改善が進んだのに、契約終了後は要望が止まり、問題が起きると旧Excelへ戻ることがあります。手順書とシステムは残っていても、自社で変更できません。
移管で必要なのは成果物の受け渡しだけではありません。何を変えるか、どこまで許容するか、誰が決めるかという判断能力を社内へ残すことです。
外部へ残りやすい5つの機能
- 現場の要望を仕様へ変える
- 複数部署の優先順位を決める
- 例外を通常ルールへ追加するか判断する
- データ不一致の原因を調べる
- 継続・改修・撤退を比較する
これらが外部に残ると、社内担当者は操作できても改善できません。
移管できていないサイン
- 操作質問には答えられるが、例外が起きると外部へ聞く
- 要望は集まるが、採用・保留・却下を社内で決められない
- アカウントは受け取ったが、連携先や契約更新日が分からない
- 数字が合わないとき、どのデータから確認するか決まっていない
- 担当者不在時に、旧Excelや個人メモへ戻る
- 「壊さないために何も変えない」が移管後の運用になる
資料の受領数ではなく、判断と復旧を社内で再現できるかを見ます。
知識は受け取る側の能力にも左右される
CohenとLevinthalは、外部知識の価値を認識し、取り込み、活用する組織能力を吸収能力として論じました。Absorptive Capacity: A New Perspective on Learning and Innovation
外部が詳しい資料を作るだけではなく、社内側が実案件で判断し、結果から学ぶ経験が必要です。
成果物移管と運用移管を分ける
成果物
- システムとソースコード
- アカウントと権限
- データ定義
- 業務フロー
- マニュアル
- 契約・外部サービス一覧
運用能力
- 例外時の判断
- 改善要望の優先順位
- 軽微な設定変更
- 不具合の切り分け
- 影響範囲の確認
- 外部へ依頼する条件
両方を検収します。
移管台帳に残す項目
| 対象 |
正本・保管場所 |
社内責任者 |
外部依存 |
更新・確認日 |
| 業務ルール |
|
|
|
|
| データ定義 |
|
|
|
|
| アカウント・権限 |
|
|
|
|
| 外部サービス・契約 |
|
|
|
|
| 障害・復旧手順 |
|
|
|
|
| 改善要望・判断履歴 |
|
|
|
|
「資料あり」だけでなく、最新版、更新者、確認日まで揃えます。
社内へ残す4人の役割
| 役割 |
決めること |
| 業務責任者 |
ルール、例外、正本 |
| 運用担当 |
日常処理、問い合わせ、記録 |
| システム窓口 |
権限、設定、外部連絡 |
| 改善責任者 |
優先順位、効果測定、継続判断 |
小規模組織では兼任できますが、役割そのものは分けます。
逆向きの引き継ぎを行う
外部が説明し、社内が聞くだけでは移管できたか分かりません。
- 社内担当者が実案件を処理する
- 例外条件を説明する
- 設定を一つ変更する
- 不具合を切り分ける
- 改善要望の採否を決める
- 外部担当者は観察し、不足だけ補う
説明できるかではなく、社内だけで結果を再現できるかを確認します。
30・60・90日で移管する
30日：外部が実行し、社内が判断理由を記録する
通常案件と例外案件を選び、外部担当者がどの情報を見て、なぜその処理を選んだかを社内側が記録します。操作手順より判断分岐を優先します。
60日：社内が実行し、外部がレビューする
社内担当者が実案件、例外処理、設定変更、問い合わせ切り分けを行います。外部は代行せず、誤りと不足をレビューします。
90日：社内だけで運用し、必要時だけ外部へ上げる
一定期間を社内だけで運用します。外部へ問い合わせた内容は、専門家依頼として残すものと、次回から社内対応するものに分けます。
期間は業務量に応じて変えて構いません。重要なのは、支援終了日に一度だけ引き継ぐのではなく、役割を段階的に反転させることです。
外部へ頼る範囲を明確に残す
内製化はすべて自分たちで作ることではありません。
- 社内で変更できる範囲
- 外部レビューが必要な範囲
- 専門家判断が必要な範囲
- 緊急時の連絡先
- 追加費用が発生する条件
- 外部サービス停止時の代替運用
依存をゼロにするより、依存先と境界を把握します。
内製化しすぎない
頻度が低く高度な専門性を要する障害、法令・セキュリティ判断、大規模な設計変更まで社内へ抱えると、維持費が上がります。
社内に残すべきなのは、すべての作業能力ではありません。
- 何が起きているかを説明できる
- 業務上の優先順位を決められる
- 外部へ渡す情報を揃えられる
- 提案を受け入れるか判断できる
- 外部が変わっても業務とデータを引き継げる
この状態なら、専門作業を外部へ依頼しても主導権は社内にあります。
移管完了を資料数で測らない
- 社内だけで完了した案件の割合
- 例外判断を社内で行えた件数
- 外部への問い合わせ内容
- 設定変更から反映までの時間
- 判断理由と変更履歴の記録率
- 担当者不在時の継続可否
- 改善案を社内で採否決定できたか
資料が多くても、判断できなければ移管未完了です。
移管完了の判定表
| 確認項目 |
合格条件 |
| 通常案件 |
社内だけで期限内に完了できる |
| 例外案件 |
判断者と上申先を説明し、記録できる |
| 数字の不一致 |
正本から原因候補を切り分けられる |
| 設定変更 |
影響範囲を確認し、安全に反映・復元できる |
| 障害 |
暫定運用へ切り替え、必要情報を外部へ渡せる |
| 改善要望 |
採否、優先順位、見直し日を社内で決められる |
| 担当者不在 |
代替担当者が同じ結果を再現できる |
すべてを一人が満たす必要はありません。社内の役割を合わせて再現できればよい状態です。
まとめ
外部コンサルが抜けると元へ戻るのは、システムやマニュアルが不足しているからだけではありません。例外対応、優先順位、変更判断が外部に残っているためです。
成果物と運用能力を分け、社内担当者が実案件、例外、設定変更、改善判断を実演する逆向きの引き継ぎを行います。
マニュアルの設計は業務マニュアルを作っても読まれない理由、継続的な改善運用は現場から改善提案が出るチームの作り方で解説しています。シクミAIでは、業務の判断基準と変更方法まで社内へ引き継ぎます。
