型を残して、抜ける — 属人化した現場に“触媒”として入るという仕事
ある会社の業務が、数人の頭の中だけで回っていた。過去のミスやトラブルをまとめた一覧はどこにも存在せず、「この処理はあの人しか分からない」という業務がいくつも埋まっていた。合併を経て、システムに登録されたルールと現場の実態も大きくずれていた。よくある話だ。そして、たいていの会社はこの状態のまま何年も走る。
こういう現場に、外から一人で入って、混沌を仕組みに変える仕事がある。私たちはそれを「代行」ではなく「触媒」だと考えている。この記事は、その働き方を一つの事例から言葉にしておく試みだ。
「代わりの一人」を探すと、たいてい間に合わない
属人化した業務を前にしたとき、最初に出てくる対策は「その人と同じことができる人を採る」だ。だが、これはうまくいかないことが多い。
一つ目に、そういう人はたいてい採用市場にいない。業務の深い理解と、システムの実装力と、新しい道具を現場に落とす力。この三つを一人で持つ人は、意図的に育てるには時間がかかりすぎるし、求人を出しても集まらない。二つ目に、仮に二人目が見つかっても、止まると困る一点が二つになるだけで、構造は変わらない。属人化の解は、複製ではなく非属人化だ。
もう一つの誘惑は「まるごと抱え込む」ことだ。業務を外部に預けて回してもらう。短期的には楽になる。だが、判断基準が誰にも見えないまま外に移るだけで、依存の場所が変わっただけになる。
触媒がやること——反応を起こして、残らない
化学の触媒は、反応を速く進めるために入り、反応が終わると元の姿のまま残らない。消費されないし、生成物にも混ざらない。属人化した現場に入る仕事も、これでいい。
具体的には、五つの動きになる。
一つ、現場に入って、混沌から要件を掘る。 実務のヒアリング、チャットの履歴、システムの生データを全件たどって、「どこに何が埋まっているか」を可視化する。誰も持っていなかった過去のつまずきの一覧を、独自に作る。この調査そのものが、後の意思決定の前提条件になる。外部ツールを入れるかどうかの判断が、「この業務調査が終わってから」と設定される——そういう形で、掘ったものが効いてくる。
二つ、属人知を、読める構造に変える。 人の頭の中にある判断基準や例外ルールを言語化し、業務の人・エンジニア・AIが同じものを読める共通の形にする。ある現場では、散らばっていた業務ルール四十五件を構造化データに落とした。これが後で効く。ルールがコードの中に百箇所コピーされている状態と、一箇所にまとまっていて誰でも読める状態とでは、変更にかかるコストが桁で違う。
三つ、速く試作して、本番まで運ぶ。 動くものを早く見せて方向を合わせ、PoC(試作)で止めずに本番投入まで持っていく。ここが一番差が出るところだ。試して終わりの案件は多い。あるプロジェクトでは、ゴールの合意から六週間で、見積から請求までの十五工程を一気通貫でこなすAIエージェントを本番に載せた。速さの秘密は根性ではなく、検証の土台を先に作ったことだ。本番の依頼を安全な環境で再現して試せる仕組みを最初に組んでおくと、実案件のフィードバックで日々鍛えられる。
四つ、既存システムの中で、壊さずに動かす。 今あるシステムと実態はずれている——それを前提に置いて、「現場の実態を正とする」という原則で作る。そして守り(権限管理・安全・監査)を後付けにせず、最初から組み込む。攻め(新しいことを進める側)と守り(本番を壊させない側)を別々の人が持つと、たいてい衝突する。同じ設計の中に両方を入れておく。
五つ、組織に返して、いなくても回る状態にする。 これが一番大事で、一番忘れられる。手順書を書いて渡すのではなく、並走して移す。非エンジニアの社員が自分でAIの仕組みを運用し、改修できるところまで持っていく。判断の経緯そのものも、後から検索できる形で組織に残す。実際、この移し方で、業務担当の社員が一人で仕組みの改修から反映までを回せるようになった例がある。移転は、手順書ではなく時間で起きる。
うまくいくほど、自分は要らなくなる
この働き方には、正直な留保がある。
一つずつの作業を見れば、代わりが利くものは多い。システムの個別実装は専門のエンジニアがやれるし、業務フローの調査はコンサルタントの標準技能だ。代わりが利かなかったのは個々のタスクではなく、「三つの領域を一人で跨いで、翻訳のコストなしで、期限内に、しかも移せる形として残した」という結合の部分だった。
そして、この能力が最も効くのは移行期だけだ。基盤が整い、業務が標準化され、現場が自走を始めれば、触媒の必要性は消えていく。同じ会社に長くいて同じ価値を出し続ける類の仕事ではない。うまくやるほど、自分の必要性を自分で解消していく。
だが、それは失敗ではない。触媒は、反応が終わったら残らないのが正しい。私たちの成功条件は、私たちが要らなくなることだ。抱え込む依存をつくるのではなく、抜けても回る型を置いていく。「その人にしかできない」を、誰でも回せる型に変える。それが、属人化を構造の問題として解くということだ。
小さく始めて、仕組みを残す。私たちがやっているのは、たぶんそういう仕事だ。
属人化は「代わりの一人」でも「抱え込み」でも解けない。判断基準を読める型に変え、非エンジニアが自分で運用できる状態にして抜ける。うまくいくほど、その現場での自分の必要性は薄れていく——それが失敗ではなく、成功条件そのものだ。
Currentsは、申請・承認、見積、ナレッジ整理、記事公開など、業務手順を型にして自社運用しています。その現場で得た業務設計の知見を、組織のAI活用に役立てることを目指しています。 記事への質問・感想は X(@currents_non)へどうぞ。