事業や拠点の立ち上げには、本来3つの層がある。
- 拠点をつくる — 設備、回線、什器、備品、警備、竣工、資金
- 運用の型をつくる — 法定検査、保安管理、業者窓口、清掃、購買ルール
- 組織を立ち上げる — 役割、指示経路、報告、権限、採用、教育、働き方
順番には意味がある。少なくとも②が固まってから③に人を入れる。そうでないと、現場に立った人が「何をどうすればいいか」を判断する拠り所を持てないからだ。
私がいま関わっている新設データセンターでは、この順序が崩れていた。人が先に入り、②が無いまま運用が始まっていた。しかも私自身は東京にいて、拠点の①のPM・②の設計者・③のマネージャーを1人で兼任している。
この状態を、Claude Code で書いたハーネス12本・約6,000行で支えた9日間の記録である。
型が無いと、何が起きるか
現地からいちばん多く上がってきたのは、こういう類の声だった。
- 「知らない物品が届いた」
- 「点検が入ると言われたが聞いていない」
これは現地の注意力の問題ではなく、構造の問題だ。①（本社が発注した設備や備品、契約した保守）の情報が、②（受け入れ手順、業者窓口、台帳）を経由せずに、いきなり③（現地の人)に届いている。経由すべき層が無いのだから、届いた側は毎回その場で判断するしかない。
そしてもうひとつ。私の負荷が高いのは、能力の問題ではなく役割の重複による。現地3名からの相談、業者6社との調整、本社・経営への報告が、すべて同じ1人に集まる。①②③を分業できていれば起きないことが、兼任しているというだけで全部同じ受信箱に流れ込む。
ハーネスは、この重複を1人で持ちきるために作った。
9日で何を作ったか
集中稼働は9日間。ハーネス12本・6,118行、コミット153件。内訳はこうなった。
- 購買と稟議 — 備品の選定 → グループウェアへ購入稟議 → 法人向けECで発注 → 着荷 → 検品 → 台帳反映。この一連を、申請内容をJSONで書いて起票するところまで機械に寄せた
- 台帳の維持 — 備品リスト、鍵管理簿、工程表。すべて共有ドライブの表計算で、現地も本社も同じ物を触る。版チェック付きで更新する
- 日程の調整 — 複数人の空き時間を突き合わせて候補を出す
- 経費精算 — 領収書付きの明細をクラウド経費に登録するところまで
- 組織図の生成 — 定義ファイルを正本として、図とドキュメントを生成物として吐く
- ポータル — 恒久ルールを置く運営課ポータルを別途構築（1,900行）。手順・業者一覧・鍵と入退館のルール・回答待ちカードが載り、現地3名が見る唯一の正本にした
補足すると、この期間の記録は HANDOFF.md に3,502行残っている。「いま動いていること」と「なぜそう判断したか」を書き戻す先で、次のセッションはこれを読ませてから始める。
遠隔から現場を回すとは、どういうことか
抽象的になりすぎるので、実際の1日を書く。キックオフ当日で、私は現地にいない。東京から3件を処理した。いずれも「調べる → 直す → 返す」まで通しでやっている。
備品リストの反映漏れ（約1時間15分） 現地から「3点届いたがシートに反映されていない」。手がかりは発注画面のスクリーンショット2枚だけ。画像から品名と金額を読み、備品リストを版付きで取得し、該当行が無いことを確認して、抜けた原因を2種類に切り分けた。3行を追加し、集計タブの参照範囲も追随させ、再ダウンロードして検証してから返す。
このとき検品欄は「未」のまま残した。現地が見たのは配送履歴であって現物ではないからだ。過去に数量欄だけを見て「不足」と誤読した件があり、同じ轍を踏まないようにした。ハーネスがあると処理は速くなるが、速いからこそ、確認していないことを確認したことにしない規律が要る。
鍵タグの確認と管理簿への反映（約8分） 現地から鍵3本の写真1枚。写真からタグ番号とラベルを読み、前日に決めた割り当てと突き合わせ、3本とも一致を確認。管理簿を版付きで更新し、埋め込み写真15枚が保存前後で残っていることまで検証して返す。
ここでは、台帳の行番号が13なのに割り当て番号が016になっている点が効いた。013は別の鍵で使用済みだったためで、この照合が崩れていたら鍵が二重番号になっていた。物理的な鍵は、貼ってしまってからでは直すコストが跳ね上がる。
顔認証システムのログイン復旧（約1時間40分） ベンダーからの回答が転送されてきたが、1年半前に発行された管理者アカウントに入れない。納品物からアカウント一覧を開いて本番URLとIDを特定し、本番と検証でURLが別であること、パスワードは招待方式のため納品物に含まれないことを確認。実際にログイン画面を開いて二要素の状況まで確かめたうえで、画面の案内どおり再設定リンクの送信を依頼する文案を作って送った。
結果として「管理者アカウントは追加しても無償」が確定し、当初考えていたアカウント共用案が不要になった。管理画面には認証者の氏名・住所・電話番号が出るため、操作ログを人ごとに分けられる意味は大きい。
3件とも、ハーネスが台帳を安全に触れる状態にしていなければ、「現地に電話して確認して、あとで直す」で半日溶けていたと思う。
効果は「置き換わった操作」と「落ちなくなった失敗」で書く
導入前後の所要時間は実測していない。だから「何%速くなった」とは書かない。代わりに、事実として確認できるものを載せる。
落ちなくなった失敗:
- 台帳の版ずれ — 上書き前の版チェックで、他人の編集を消す事故が構造的に起きない
- 番号の重複 — 鍵タグの重複は、実物に貼る前に台帳側で検出できた
- 「言った/言わない」 — 現地への連絡は、送る前に文案をファイルに書く運用にした。9日で59本が残り、いつ何を伝えたかが引けるようになった
- 宛先違いの書式 — チャットツールにMarkdown記号がそのまま出ていた問題を、規約化して止めた
- 時刻の思い込み — 投稿時刻は体感で書かず、APIの送信時刻から引く運用にした。ただし本日1回やらかして訂正している。規約があっても外れる
最後の1行を消さずに残しておくのが、この種の記録では大事だと思っている。
できていないこと
正直なところも書く。
- ハーネスは1台のローカルにしかない。 資格情報も環境変数にあり、他の人は動かせない。私が単一障害点になっている
- 外部との窓口ほど自動化が届いていない。 外部共有チャネルや一部のチャットツールへの投稿は権限的に通らず、手作業のままだ
- ポータルの更新権限が現地へ移っていない。 現地が自分でルールを直せない状態が続いている
- 効率の実測がない。 所要時間のログを取っていないので、改善幅を数字で言えない。取るなら着手と完了の時刻をタスク管理側に残すのが早い
- そして、②「運用の型」はまだ埋まっていない。 ハーネスが吸収しているのは①と③の負荷であって、型そのものを作る仕事はこれからだ
この経験を一般化すると
ハーネスは、②の代わりにはならない。②を作る時間を捻出するための足場だ。
型が無い現場に人が入ってしまったとき、選べる道は3つしかない。(a) 現場に耐えてもらう、(b) 型が固まるまで止める、(c) 型ができるまでの間、誰かが手作業で全部を持つ。多くの立ち上げでは (a) か (c) になり、(c) を選んだ人が潰れる。
AI駆動開発が変えたのは、(c) を人ではなくハーネスに持たせられるようになったことだ。9日で12本という速度は、従来の「社内ツール開発」の感覚では絶対に出ない。出ないから、これまでは (a) を選ぶしかなかった。
ただし条件がある。ハーネスを書ける人間が、①②③のどこかに実際に立っていることだ。外から要件を聞いて作るのでは、この速度は出ない。判断している当人が、その場でコードに落とせることが効いている。
拠点や事業の立ち上げで似た状態にある場合、どの層から手を付けるべきかは状況によって変わる。各論はご相談の場でお伝えできる。