特定のAI・サービス・本人がいなくても、直し続けられるか

社内システムが会社の資産になるかどうかは、作った瞬間ではなく、作った本人も、作るのに使ったAIも、動かしているサービスも変わった後に、まだ直せるかで決まります。動いている仕組みでも、その一つが抜けただけで誰も手を出せなくなるなら、それは資産ではなく、いずれ止まる仕組みです。

この記事は、実務編の最後の問いを扱います。何で、どう作られているかの記録。AIやサービスが変わっても続けられる作り。本人が抜けても会社として直せる状態。この三つを順に見ます。手順書の書式には降りません。

何で、どう作られているかを記録しているか

記録がなければ、後から来た人は、動いているものを前にして「何のために、どこで、どう動いているのか」を推測するところから始めます。推測は外れることがあり、外れたまま触れば壊します。だから、作った時点で記録を残します。記録の中身は、実務編の7つの問いへの答えそのものです。

何を残すか	どの問いで決めたか
運用の責任者は誰か。なぜ内製したか（買わず、外注せずに作った理由）	そもそも自分たちで作るべきか
誰が・いつ・何を見て・何を決めるかの流れ。担う工程と、人がやる工程。例外の一覧。変えないと決めたもの。作らないと決めたもの	業務は整っているか
正本はどれか。マスターとトランザクションの分け方。IDと型。履歴を残すか。データの置き場。入口と出口	そのデータは何で、どれを正とするか
誰が何を見てよく、変えてよいか。ログインの方式。退職者を外す手順。外に出してはいけない情報。鍵をコードの外のどこに置いたか	誰に何を見せ、何をさせてよいか
どんな形で届けているか。どこで動いているか。コードはどこにあるか。アカウント・契約は誰の名義で、どのプランか	どこで動き、誰のものか
止まったときの代わりのやり方と、直っていなければならない期限。直す往復をする人。戻し方。試す場。確かめる4項目と、確かめる人	壊れたら、間違えたら、変えるとき、どうするか
作るのに使ったAIとサービス。本人のほかに、記録とコードの場所を知っている人	この問い

勤怠管理なら、締め日と承認の順番。直行直帰は本人の申請で受け、上長が認めること。給与の計算はしないと決めたこと。記録はスプレッドシートにあり、集計はCSVで給与ソフトに渡すこと。この数行が、後から直す人の最初の手がかりになります。

これに、作るときにAIへ渡したプロンプトと、途中で決めたことを足します。何が、どこで、どう動いているかはコードを読めば分かりますが、「なぜこう作ったか」はコードには残りません。書式は問いません。箇条書きで足ります。仕組みの説明はAIに書かせられます。作った会話が残っているうちに「この仕組みの説明を、後から来た人向けに書いて」と頼めば、途中で決めたことも一緒に書き出せます。なぜそう作ったかと自社の事情は、人が書き足します。

作るのに使ったAIやサービスが変わっても、続けられるか

AIのサービスは、機能が変わり、値段が変わり、ときに終わります。作ったときのAIが、直すときにも同じ形であるとは限りません。ここで効いてくるのが、作りの「普通さ」です。

コードはテキストです（基本編の「テキストとバイナリ」）。だから、作るのに使ったAIでなくても、別のAIに渡して読ませ、直させることができます。特定のAIでしか開けない形ではありません。特定のAIの中でしか動かない形にせず、広く使われている普通の作りにしておけば、AIを乗り換えても続けられます。

サービスも同じです。動かす場所やデータの置き場は変わるものとして、閉じた作りを避けます。特定のサービスの中に閉じた作り、たとえばノーコードのサービス（プログラムを書かずに画面の操作で業務アプリを組み立てるサービス）の中だけで組んだ仕組みは、そのサービスをやめるとき、サービスが終わるときに、仕組みの部分は作り直しになります。データは取り出せることが多いので、取り出せる形で出せるかを先に確かめておきます。閉じることを選ぶなら、それを分かって選びます。

頼らないほうがよいもの	代わりに
AIとの対話の画面の中でそのまま動かしている仕組み。そのAIにしかない機能に頼った作り	AIの外の場所（スプレッドシートの自動化の仕組み、クラウド）で動く、広く使われている作りにする
特定のサービスの中だけで完結する作り	データは取り出せる形で。コードはリポジトリに
AIとのチャットの中にしかない情報	記録とコードは、AIの外の、会社の場所に

勤怠管理をスプレッドシートの自動化の仕組みで作ったなら、出退勤の記録はCSVで書き出せて、コードはリポジトリにあります。この状態にしておけば、作るのに使ったAIを乗り換えても、動かす場所をクラウドに移しても、一から作り直しにはなりません。

AIに頼むときは、「このAIにしかない機能に頼らず、広く使われている普通の作りで」と一言添えます。広く使われている作りは、AIが学習で大量に見てきた側なので、一言添えればたいていはそちらに寄ります。それでも、何に頼って動いているかは、できあがった時点でAIに説明させ、記録に残します。

作った本人が抜けても、会社として直せるか

作った本人にしか分からない状態——「そもそも自分たちで作るべきか」で属人化と呼んだもの——を解くことが、この問いの着地です。本人が抜けても直せる状態は、三つがそろったときにできます。

• 記録がある。 上の表の中身が、会社の場所に残っています。
• 仕組みが会社のものになっている。 アカウント・契約・コードが会社の名義で、複数の人が開けます（「どこで動き、誰のものか」）。
• もう一人、触れる人がいる。 直せる必要はありません。記録とコードの場所を知っていて、AIに頼んで直す往復ができれば足ります。

勤怠管理を経営者自身が作ったなら、もう一人は、月末の集計をしている担当者が自然です。「壊れたら、間違えたら、変えるとき、どうするか」で決めた、直す往復をする人や確かめる人と同じで構いません。

三つ目が、社員数十人の会社での現実的な答えです。記録とコードが会社にあれば、後から来た人はAIと一緒に直せます。 それが、AIによって作れる範囲が広がった今の、属人化の解き方です。本人がいなくなるのも、使っていたAIやサービスがなくなるのも、同じ一つの備えで受け止められます。記録とコードが会社の場所にあり、作りが特定のものに閉じていないことです。

つまずきやすいところ

• 記録を後で書こうとする。 作った直後がいちばん書けます。時間が経つほど、なぜそう作ったかを本人も忘れます。
• 本人が「自分が見るから大丈夫」と言う。 動いている間はそのとおりです。本人が忙しくなった後、辞めた後の話をしているので、本人の善意とは別に、記録と名義をそろえます。
• AIが覚えていると思う。 AIは、別の会話で作ったものを覚えているとは限りません。だから記録は、AIの外に置きます。

まとめ

「簡単に作れる」と「動かし続けられる」の間にあったものが、この7つの問いです。会社の資産として残るかは、本人・AI・サービスが変わった後に直せるかで決まります。何で、どう作られているかを、7つの問いへの答えとして記録します。特定のAIやサービスに閉じた作りを避け、コードはリポジトリに、データは取り出せる形にします。そのうえで、記録がある、仕組みが会社のものになっている、本人のほかにもう一人いる、の三つがそろえば、作った仕組みは、人が替わっても会社に残ります。

7つの問いは、これで一巡です。一つの業務を選び、順に答えていくためのワークシートを、この後に用意する予定です。全体は冒頭ページにあります。