引き継げるデータ基盤の条件。属人化を外す書き方

前任者が作った仕組みが、誰も触れない状態になっています。引き継ぎの場面でよく出てくる話です。

作った本人に悪気はありません。動いているものを作ったのですから、仕事はしています。それでも引き継げません。理由は、作り方ではなく、残し方にあります。

引き継げない基盤に共通する症状

引き継ぎの相談を受けたとき、私はまず次の3つを確認します。

テーブルや処理の名前を見ても、中身が想像できません。tmp、test、new、data2といった名前です。こういう名前が並んでいると、どれが本番でどれが使っていないものか、開けるまで分かりません。

手順が本人の頭の中にしかありません。「毎月5日に、この画面からCSVを落として、このフォルダに置く」のように書きます。これが書かれていないと、引き継いだ人は初回で止まります。

止まったときに誰に聞けばいいか分かりません。外部サービスとつないでいる場合、契約者が誰か、管理画面に誰が入れるかが分からないと、調べるところから始まります。

この3つが当てはまるなら、引き継ぎではなく作り直しになります。作り直しは、元の構築と同じかそれ以上の時間がかかります。

条件1：名前を見れば意味が分かる

一番効くのに、一番後回しにされるのが命名です。決めるのは3つだけで足ります。

• 何のデータか（注文、顧客、在庫）
• どの段階のものか（取り込んだまま、整形後、集計後）
• どの単位か（日次、月次、明細）

この3つを決まった順番で並べるルールにしておけば、名前を見ただけで役割が分かります。凝った命名規則は要りません。全員が同じ順番で書く、それだけです。

すでに動いているものの名前を変えるのは危険なので、まずは一覧表を作り、それぞれの役割を1行で書き足すところから始めてください。名前の変更は、次に作るものからで構いません。

条件2：手順が文章で残っている

図や設計書より先に、文章の手順書です。書く内容は次の4つです。

• いつ動くか（自動なのか、人が動かすのか）
• 動かす手順（画面名とボタン名まで書く）
• 正常に終わったときに、どこを見れば確認できるか
• 失敗したときに、何をすればいいか

ポイントは3つ目と4つ目です。ここが抜けている手順書をよく見ます。動かし方だけ書いてあっても、成功したかどうかが分からなければ、引き継いだ人は毎回不安になります。

文章は上手でなくて構いません。箇条書きで、専門用語を使わずに書きます。1つの処理につき、A4で1枚が目安です。

条件3：止まったときの連絡先が決まっている

意外と抜けるのがここです。次の4点を1枚にまとめてください。

• 使っている外部サービスの一覧と、契約者の名前
• それぞれの管理画面に入れる人
• 費用が発生しているもの、その支払い方法
• 困ったときの問い合わせ先（サポート窓口のURL）

この1枚がないと、引き継いだ人は「そもそも誰に聞けばいいのか」から調べることになります。技術的な難しさではなく、情報がないことで止まるケースです。

引き継ぎ資料の最小構成

完璧な資料を作ろうとすると、いつまでも終わりません。次の4点だけ用意してください。

• 全体図1枚（どこからデータが来て、どこへ行くか。手書きでよい）
• テーブルと処理の一覧表（名前と役割を1行ずつ）
• 処理ごとの手順書（1処理1枚）
• 連絡先の一覧1枚

これだけで、引き継ぎの初回で止まる確率はかなり下がります。

外注するときに書いておくこと

外部に構築を頼む場合は、契約の時点で「引き継ぎ資料の作成」を成果物に入れてください。口約束にすると、ほぼ作られません。悪意ではなく、優先度が下がるためです。

あわせて、引き継いだあとの質問対応期間も決めておくと安全です。1か月でも構いません。期間が明記されていれば、聞くほうも遠慮しなくて済みます。

属人化は、人の問題ではなく、書き残す時間を工数に入れていないことから起きます。作る時間の1割を残す時間に回します。それだけで、次の人が困らなくなります。