業務の属人化で本当に危ないのは、引き継ぎではない

受発注メールの転記を自動化するスクリプトを、一つ作ったとする。動く。翌月も動く。半年動く。誰も触らない。触れるのは書いた本人だけで、本人も月に一度ログを眺めるくらいしかしていない。この状態を、社内では業務の属人化と呼ぶ。

属人化について書かれた記事は、たいてい同じ結論に着地する。手順書を作れ、共有せよ、標準化せよ。正しいのだろうと思う。ただ、その結論は当事者の実感と一つもかみ合っていない。当事者にとって、自分にしか触れないスクリプトは負債ではない。会社に入って初めて手に入れた、自分にしかない持ち物である。手放せと言われて手放す人はいない。

この記事は、属人化の解消を勧めない。かわりに、属人化の本当の危険がどこにあるのかを、自分の運用で実際に起きた事故の記録から書く。結論を先に言う。危険なのは引き継げないことではない。壊れているかどうかを、作った本人にも判定できなくなることである。

以下に出てくる事故は、すべて自分の個人プロジェクトで実際に起きたものだ。日付と数値はそのまま書く。他人の失敗談として読むより、自分の自動化を1つ思い浮かべながら読んだほうが早い。

属人化の定義は、管理側と当事者でずれている

管理側から見た属人化の定義は明快だ。その人が辞めたら止まる業務、という一点に尽きる。だからリスク管理の言葉で語られ、対策は共有と標準化になる。

当事者の側から見ると、まったく別のものが見えている。EC実務の現場は、代わりのきく作業で埋まっている。受注データの転記も、在庫数の更新も、問い合わせの一次返信も、手順さえ渡せば誰でもできる。そういう仕事を数年やってきた人間が、あるとき自動化を一つ作る。すると初めて、自分がいないと成立しないものが手元にできる。

属人化が生まれる経路は、だいたい決まっている。最初は自分の手作業を減らすために作る。次に、隣の席の人が「それ、こっちの分もできない？」と言ってくる。範囲が広がる。そのうち、月次の締めの数字がそのスクリプトの出力から作られるようになる。ここまで来ると、もう止められない。誰も設計を決めていないのに、いつのまにか業務の一部になっている。

この経路のどこにも、悪意も怠慢もない。全部、目の前の面倒を減らそうとした結果だ。だから危機感の言葉で上書きしようとしても通らない。属人化を悪と決めつける記事が現場に刺さらない理由はここにある。読者はリスクを抱えているのではなく、影響力を手に入れたと思っている。そして、その認識自体は間違っていない。

だから問題の置き場所を変える必要がある。自分にしか触れないものを持つこと自体は、悪くない。悪いのは、それが壊れたときに気づける仕組みを、誰も持っていないことだ。作った本人を含めて、である。以下は全部その話になる。

「無音の合格」に名前をつける

自分の運用に、チェック用のスクリプトを一本置いている。ファイルの書式や、手順書に書いたリンクが実在するかを、公開前に機械的に見るためのものだ。手順書には「全部チェックする」という呼び出し方を書いてあり、実際その通りに毎回叩いていた。

あるとき、そのスクリプトの中身を読み直して、分岐が一箇所だけ他と違う書かれ方をしていることに気づいた。書式のチェックは「全部」でも「個別指定」でも動く条件になっていたのに、リンクの実在確認だけは「個別指定したときだけ」動く条件になっていた。つまり手順書が案内している呼び出し方では、リンクの確認は運用開始から一度も実行されていなかった。

問題はそこで終わらない。実行されなかったとき、画面に出るのは「対象となるファイルがありません」という一行だった。異常が無かったときの表示と、そもそも何も動かなかったときの表示が、区別できなかった。毎回それを見て、通ったと判断していた。

この状態に名前をつけておく。無音の合格である。定義は一文で足りる。チェックが何も言わなかったことを、合格と読んでしまう状態のことだ。

見分け方も一つでいい。そのチェックが最後に「不合格」を出したのはいつか、を思い出してみる。一度も見たことがないなら、正常なのではなく、動いていない可能性のほうを先に疑う。品質の高い仕組みと、何もしていない仕組みは、出力が同じになる。

厄介なのは、この状態が時間とともに強くなることだ。動き続けている期間が長いほど、疑う理由が減る。半年間ずっと問題が出ていない仕組みを、わざわざ点検しようとは思わない。だが「半年間、異常が報告されていない」と「半年間、点検されていない」は、外から見て同じに見える。信頼が積み上がっているように見えて、実際に積み上がっているのは未検証の期間だけ、ということが起こる。

無音の合格は、属人化した仕組みでだけ起きる現象ではない。ただ、属人化した仕組みでは、訂正される機会が来ない。他人が触らないということは、他人が「これ本当に動いてる？」と聞いてくる機会もないということだからだ。他部署から質問が来る仕組みは、それだけで検査されている。

終了コードは「仕事が終わった」を意味しない

毎日決まった時刻に処理を走らせる仕組みを、Windowsのタスクスケジューラで組んでいる。管理画面には前回の実行結果が表示され、そこにはずっと正常終了を示す値が並んでいた。

その裏で、タスクは実際には動いていなかった。

終了コードが返しているのは「呼び出しに成功した」という事実であって、「やらせたかった仕事が終わった」という事実ではない。この二つは日常語だとどちらも「動いた」になるので、区別する習慣がないと一生気づかない。スケジューラの画面は、呼び出しの成否しか知らない。中で何が起きたかは、中で記録しない限りどこにも残らない。

似た形で、もう一つ引っかかったことがある。手元で対話的に実行すると正常に動くのに、無人で自動実行したときだけ落ちる、という現象だった。原因は認証情報の優先順位で、環境変数に入れていたキーが、ログイン情報より先に使われていた。手元で動作確認をしている限り、この差は表に出ない。

「自分の環境では動く」は、属人化のもっとも典型的な症状である。動作確認の場所と、本番の実行場所が違うのに、確認は手元でしかしていない。実行ユーザーが違えば、見えるフォルダも、使える権限も、参照する設定も変わる。

EC実務の言葉に置き換えると、こうなる。毎朝9時に在庫データを取り込む設定にしてあり、履歴には毎日「成功」と記録されている。だが取り込まれた件数は0件かもしれない。連携先がファイル名に日付を付ける仕様に変わっただけで、対象が見つからず、処理はエラーを出さずに終わる。成功したかどうかを見るのをやめて、何件処理したかを見る。この記事で挙げた事故のうち、半分はこれで検出できたはずのものだ。

受注メールから住所を抽出して一覧に流し込む処理でも、同じ形になりうる。メールの本文テンプレートがモール側の仕様変更で少し変わると、抽出結果は空になる。だが処理は最後まで走りきる。空の行が増えていくだけで、赤いエラーは一度も出ない。

数字は見ているのに、スケールが違っている

2026年8月19日、自分のサイトに記事を1本公開した。公開後の確認として、URLが正常に開くか、ページの大きさが妥当か、という2点を見ていた。結果は正常応答、ページサイズは312,915バイト。問題なしと判断して次に進んだ。

その記事は、本文が0字のまま公開されていた。

あとから調べたところ、本文が正しく入った状態のページは323,902バイトだった。差はおよそ11キロバイトで、それがまるごと本文である。使っているテーマはヘッダーとサイドバーと関連記事の一覧だけで30万バイトを超えるため、本文が全部消えてもページの大きさは3.4%しか変わらない。桁が違いすぎて、サイズでは空を検出できない。

さらに悪いことに、その記事は編集履歴が空だった。復元機能から本文を取り戻すことができず、手元に残っていた原稿ファイルからしか戻せなかった。原稿を消していたら、書いた記事は消えていた。

ここで学んだのは、確認していなかったことが問題なのではない、ということだ。確認はしていた。数字も見ていた。ただ、見ていた数字のスケールが、検出したい異常のスケールと合っていなかった。

監視の指標を選ぶときの基準は、一つに絞れる。異常が起きたときに、その数字は何%動くのかを先に見積もる。3%しか動かない指標は、正常時のばらつきに埋もれる。本文の有無を見たいなら、ページ全体のサイズではなく、本文だけの文字数を数えるしかない。指標が対象より大きすぎると、何も見えなくなる。

この見積もりは、仕組みを作った直後にしかできない。動き出して数か月経つと、指標が妥当かどうかを再検討する機会はまず来ない。属人化した仕組みでは、その指標を決めた人と見る人が同じなので、なおさら来ない。

もう一つ、指標を選ぶときに効く問いがある。その数字は、処理が全部失敗したときにどうなるか。ゼロになるなら使える。ゼロにならない指標、たとえば「実行時間」や「ファイルの更新日時」は、失敗しても正常時と似た値を返す。更新日時は、中身が空で上書きされても新しくなる。件数と文字数が強いのは、失敗が値に直接出るからだ。

商品ページの一括更新でも、同じ形になりうる。更新件数が想定通りでも、説明文が空で上書きされている可能性は残る。件数ではなく、更新後の文字数の最小値を見る。見る対象を一段変えるだけで、検出できるものが変わる。

鳴りっぱなしの警報と、鳴らない警報は、同じ理由で役に立たない

前述のチェックスクリプトには、対になるもう一つの事故があった。

ファイルの書式を判定する条件が緩すぎて、実際には何の問題もない3本のファイルが、毎回不合格として報告され続けていた。毎回同じ3本が赤く出る。しばらくすると、赤い表示を見ても内容を読まなくなる。読まないので、本物の不合格が混ざっても気づかない。

片方は条件が狭すぎて無音になり、片方は条件が緩すぎて鳴りっぱなしになった。方向は正反対なのに、結果は同じだった。どちらも、本物の異常を隠した。

これは同じ穴の裏表だと考えたほうがいい。チェックの役割は、異常があると教えることではない。異常がないことを、異常がないという理由で保証することである。無音の合格が成立してしまう設計は、この保証を最初から放棄している。鳴りっぱなしの設計は、保証をこちらが読み飛ばすことで無効化する。

現場でこれが起きているかどうかは、簡単に分かる。毎日届く自動送信のアラートメールを、最後に開いたのはいつか。開かなくなったメールは、届いていないのと同じである。むしろ「アラートは動いている」という誤った安心を配っている分だけ悪い。

実務でこれを直すのは難しくない。チェックが通ったときに、何も出さないのをやめる。「対象12件、うち異常0件」と出す。件数が出ていれば、対象が0件だったときに一目で分かる。手順としては一行の変更だが、無音の合格をここで潰しておける。

読んで正しく見えるコードが、読めない層で壊れる

生成AIにコードを書かせて業務を自動化する人が増えている。自分もその一人だ。そして、書かせたコードが壊れるとき、壊れ方には偏りがあると感じている。

実例を一つ挙げる。複数の処理が同時に走らないように、実行中であることを示すファイルを一つ置く仕組みを組んでいた。処理が終わったら、そのファイルが自分の置いたものかを文字列の先頭一致で確認してから消す、という書き方をしていた。読む限り、何も問題がない。

実際には、そのファイルの先頭に目に見えない1文字が入っていた。文字コードの種類を示すための印で、画面には表示されない。空白を取り除く処理を通しても、この文字は空白として扱われないので残る。結果、先頭一致の判定が静かに外れ、自分で置いたファイルを自分で消せなくなった。消し損ねたファイルが残っていると、次の自動実行は「他の処理が実行中」と判断して、何もせずに降りる。実際に、残ったファイルのせいで夜の実行が1回まるごと飛んだことがある。

同じ文字コードの問題で、スクリプトが構文エラーになったこともある。実行しても、何のメッセージも出ずに終わる。承認を求める画面まで出るのに、そのあと何も起きない。

共通しているのは、ロジックは正しいのに、ロジックの外側で壊れているという点だ。生成AIが書くコードは、読んで意味が通る。処理の筋道は妥当に見える。壊れるのは文字コード、パスの解決、実行ユーザー、権限、タイムゾーンといった、読んでも見えない層である。そして、そこはコードを読んでも検証できない。動かして、結果を確かめるしかない。

ここに、生成AIを使った自動化に特有の落とし穴がある。動かないコードは、その場で分かる。だから直す。困るのは、最初は動いたコードのほうだ。動いた時点で確認は終わり、以降は触らない。数か月後に前提が変わって壊れたとき、そのコードは自分が書いたものではないので、どこを見ればいいのかの見当がつかない。書いた記憶がないものを、記憶を頼りに直すことになる。

この非対称は、けっこう厄介だ。コードの意味を理解する力は、生成AIに書かせているうちにある程度は身につく。だが実行環境の知識は、書かせても身につかない。生成AIは自分の実行環境を知らないので、そこについては何も教えてくれないからだ。結果として、読めるが直せない、という状態ができあがる。

GASで組んだ自動化が属人化する場合も、構造としては同じ場所が危ないと考えている。トリガーを誰のアカウントで作ったか、実行者の権限は何か、時刻はどのタイムゾーンで解釈されているか。このあたりは、コードの本文だけを読んでも分からないことがあるのではないか。ここは自分の一次経験ではないので断定はしない。GASを使っている人が、自分の環境で確かめるべき観点として挙げておく。

手順書に書かなかった工程は、必ず抜ける

記事を公開するとき、自分は毎回いくつかの作業を続けて行っていた。公開する、トップページの一覧を書き換える、書き換え前の状態を退避しておく、実行の記録を1行残す。4回連続で、全部やっていた。

2026年8月8日、その5回目に後ろの2つが抜けた。公開とトップページの更新だけやって、終わった気になって離れた。

抜けた理由ははっきりしている。手順書に書いていなかったからだ。自分の場合、4回できていたのは覚えていたからにすぎない。そして抜けたことに気づいたのは数日後で、そのときにはもう、その回の所要時間も、チェックが通ったかどうかも復元できなくなっていた。

属人化した業務の実体は、コードではなく、この「頭の中にある手順」のほうだと思う。コードは残るが、コードを動かす前後にやっていた確認作業は、どこにも残らない。本人の記憶が唯一の仕様書になった瞬間から、本人が忘れた分だけ、仕様は静かに欠けていく。他人に引き継げないことが問題なのではない。去年の自分に引き継げないことが問題である。

手順書の書き方にも、効く形と効かない形がある。効かないのは、作業の名前だけを並べたものだ。「バックアップを取る」と書いてあっても、どこに何を置くかが無ければ、思い出せないときには役に立たない。効くのは、そのまま実行できる形で書いてあるものだ。実行するコマンドや、開く画面の名前まで書く。自分用の手順書は雑になりやすいが、雑な手順書は数か月後の自分にとって他人の手順書と変わらない。

この欠け方には特徴がある。抜けるのは、やらなくても即座には困らない工程からだ。退避、記録、事後確認。どれも、飛ばした日には何も起きない。困るのは、事故が起きてから戻そうとしたときで、そのときには何か月分も抜けている。

もう一つ、自分で書かなかった条件のほうで動いた例もある。2026年7月17日、電源ケーブルを挿した瞬間に、登録していたタスクが一斉に起動してターミナルが立ち上がった。原因はおそらく、既定で有効になっている「AC電源で動作しているときのみ開始する」という条件だ。バッテリー駆動中に来た実行予定がそこで保留され、電源をつないだ時点でまとめて動き出した。自分で書いたトリガーは、一つも発火していない。自動化は、自分が書いた条件だけでなく、書かなかった条件でも動く。設定画面の、一度も触っていないタブに何が入っているかは、作った本人も知らない。

渡すのはコードではない。渡せるものは3つしかない

それでも引き継ぎを求められる日は来る。異動、休職、あるいは自分が別の仕事に移るとき。ここでコードを渡しても、まず読まれない。読める人がいれば、そもそも属人化していない。

自分がサイトの運用保守を学び直したとき、いちばん抜けていたのは、壊れたときにどう戻すかの手順を一つも持っていない、という点だった。技術の知識ではなく、事故が起きた前提の段取りが無かった。属人化した仕組みで渡す価値があるのは、そこだけだと今は思っている。渡せるものは3つに絞れる。

1つ目は、壊れたときの症状である。何がどう見えたら異常なのかを、画面の言葉で書く。「エラーが出ます」では足りない。「一覧の件数が0件のまま更新日時だけ新しくなっていたら異常」まで書く。前の章までに書いた事故は、全部この形で書けば伝わったものだ。

2つ目は、戻し方である。元に戻すために必要なファイルがどこにあり、どの順番で戻すのか。実際に一度戻してみて、その手順で戻ることを確認しておく。確認していない復旧手順は、手順ではなく願望になる。本文が消えた記事を原稿ファイルから戻せたのは、たまたま原稿が手元に残っていたからで、設計されていたからではなかった。

3つ目は、触ってはいけない場所である。ここを変えると連鎖して壊れる、という箇所を数行で書く。禁止事項は、説明が要らないぶん最も伝わりやすい。

この3つはコードを読めない相手にも渡せる。逆に、この3つが書けないなら、それは他人に引き継げないのではなく、自分が仕組みを把握していないということだ。引き継ぎ資料が書けない理由を相手の技術力に置いている間は、この判定ができない。

今日やるなら、失敗の証拠を一つ作る

属人化を解消する必要はない。手放すべきなのは、無音の合格のほうだけだ。一度で終わる分量でいい。対象は自分が作った自動化のうち、いちばん長く動いているものを一つ選ぶ。

順番はこうなる。まず、その処理が成功したときに何が出ているかを見る。何も出ていないなら、処理した件数を出すように1行足す。次に、その件数がゼロだったらどうなるかを確かめる。エラーになるなら問題ない。成功として通るなら、そこが無音の合格の入口である。最後に、わざと壊してみる。参照しているファイルの名前を1文字変えて実行し、ちゃんと失敗するかを見る。失敗しないなら、その仕組みは今日から壊れていても分からない。

わざと壊す工程は、飛ばしたくなる。動いているものを触るのは怖いし、実際に壊れたら復旧に時間がかかる。それでも、この工程だけは代わりがない。検査が機能していることを確かめる方法は、本物の異常を一度通してみることしかないからだ。

この作業で得られるのは、処理が正しいという確認ではない。壊れたときに、壊れたと分かるという確認である。持っているものは減らない。減るのは、自分でも判定できないという状態のほうだ。

そのうえで、多くの人が次にぶつかるのは別の壁になる。件数を出す1行を足そうとして、生成AIに書かせたコードのどこに足せばいいのか分からない、という壁だ。ここから先は、書かせる技術ではなく、書かれたものを読む力の話になる。独学でどこまで行けて、どこで止まるのかについては、プログラミングの独学に限界を感じたとき、金で解決できるのは3つのうち1つだけであるで、自分が詰まった場所を分解して書いた。

現場の業務を知っていて、かつ自分の自動化が壊れたときに気づける人は、そう多くない。属人化を怖がる必要はない。判定できない状態だけ、今日一つ潰しておけばいい。