- 1ヶ月かけてパワーポイントで資料を作り、説明会まで開いた。でも、その資料の実物は、作った人のパソコンの中にしか残っていない。
- 同じような資料を、毎回別の人がゼロから作り直している。
- もらった資料をもとに人に説明していたら、途中で「あれ、これ古い情報かも」と気づいたことがある。
前回まで、「あの人しか分からない」業務を見える化し、勘を基準に変える話をしてきました（「あの人しか分からない」をなくす──AIを使った業務の見える化、5つの手順）。録音して、文字に起こして、流れを図にする。頭の中にあった判断を、言葉にする。
ここまでやると、達成感があります。「これで属人化は解消した」と。
でも、資料は完成した瞬間がゴールではありません。そこから先、現場が動き続ける限り、内容とのズレが生まれていきます。
「見える化した」の、その後に起きること
見える化して、AIで検索できる仕組みまで作った。ここまで頑張った会社ほど、油断しやすい落とし穴があります。
現場のやり方は、少しずつ変わっていきます。担当者が代わる。取引先の条件が変わる。ちょっとした改善が積み重なる。ところが、その変化のたびに資料を直す人は、たいてい決まっていません。
気づいたら、現実と資料がズレている。せっかく積み上げた資料が、静かに使いものにならなくなっていきます。
「更新しましょう」は、もう聞き飽きた
……という声が聞こえてきそうです。その通りだと思います。
「資料は最新に保ちましょう」。誰でも言えます。たいていの会社が、社内ルールにも書いてあります。それでも更新されません。本当の問題は、「で、どうやって更新させ続けるの？」のほうにあります。
ここで、犯人探しをしても意味がありません。担当者がサボっているわけではないのです。理由は、たいてい構造的です。
- 日々の業務に追われて、資料を直す時間が後回しになる
- 変更に気づいているのは、変えた本人だけ
- 「誰が直すか」が、そもそも決まっていない
- 直したところで、誰も見ていない気がして、やる気が出ない
「気をつけましょう」だけでは、文化になりません。人の善意だけに頼った仕組みは、忙しい時期ほど後回しにされやすくなります。
私自身も、これをやってしまっていました
これは他人事として書いている話ではありません。私自身、商品企画をしていたとき、仕様書を書きまくっていました。
パーツごとの開発仕様は、細かく書いていました。ここは開発者も見るので、さすがに更新します。でも、サービス全体としての仕様書は、更新が追いつかず、後回しになっていく。気づけば、パーツの仕様書だけが正しくて、全体像を説明する資料は数バージョン前のまま——ということが何度もありました。
業務の話でも同じです。業務改善でシステム化まで終わらせたのに、その反映が資料に追いついていない。たくさん業務フロー図を作っても、棚卸しをしていないので、実はもう終わっている業務のフローがそのまま残っている。「これ、まだ必要だっけ？」というものが、たいてい見つかります。
見える化も、仕様書づくりも、「作った瞬間の完成度」は高くできます。難しいのは、そのあとです。
なぜ、プログラムの変更は記録されるのに、資料の更新は後回しになるのか
システム開発では、Gitという仕組みを使って、コードの変更を「コミット」として記録します。コードを直すこととコミットすることは別の操作ですが、変更を記録・確認してから、レビューやリリースへ進む流れが、開発工程にあらかじめ組み込まれています。
これは「コードだから自動的に最新に保たれる」という話ではありません。実際、資料と同じようにコードにも、書いた説明とズレたまま放置される部分はあります。違うのは、変更を記録・確認して次の工程（レビューやリリース）に進む、という流れがあらかじめ用意されているかどうかです。
業務の資料は、たいていここが用意されていません。変更した本人が気づいていても、それを資料に反映する作業は、日々の仕事とは別の"もう一手間"として存在しています。だから、忙しいときに真っ先に後回しにされます。
つまり、こういうことです。
資料が古くなるのは、人が怠けているからではありません。変更と、資料を直す作業が、同じ工程になっていないからです。
「更新される仕組み」の作り方
結論から言うと、更新を「気が向いたときにやる、別のタスク」のままにしていると、後回しにされやすくなります。私が意識しているのは、コードの世界のように、更新を本来の作業の中に組み込むことです。
① 同じ情報を、複数の場所に手作業で入れ直さない
同じ内容の資料が、あちこちにコピーされていませんか。共有フォルダ、チャットの固定メッセージ、個人のパソコンの中——コピーが増えるほど、全部を直すのは誰の仕事でもなくなります。基準となる情報の入力元を1つに決め、他は「そこを見てね」というリンクにする。手作業での二重入力をやめるだけで、更新のハードルはぐっと下がります。
② 「直さないと、次に進めない」場所に更新を埋め込む
承認をもらう・次の工程に引き渡す、といったもともと避けて通れない工程の条件に、資料の更新を含めてしまう。「変更を資料に反映してから、次の担当に渡す」を手順そのものにすると、更新漏れに気づきやすくなります。ただし、緊急対応のときまでこれで止めてしまうと本末転倒なので、急ぐときは後から更新する担当と期限を決めておく、という抜け道もセットで用意しておきます。
③ 「責任者」「最終確認日」「次に確認する日」を、見える場所に出す
資料の一番上に、次の項目を書いておきます。
text
資料名：
内容の責任者：
最終確認日：
次回確認日：
変更に気づいたときの連絡先：
ポイントは「最終更新日」ではなく「最終確認日」にすることです。内容に変更がなかった場合でも、「確認はした」という記録が残ります。これだけのことですが、確認期限が近い資料が一目で分かるようになり、担当者を責める前に、更新の工程自体が回っているかを見直せます。
そして、資料には必ず責任者（持ち主）を決めます。前回、「勘を基準に変えたあと、その基準の持ち主は本人にしてもらう」という話をしました。資料も同じです。誰の仕事でもない資料は、誰も更新しません。
役割は、最低限この3つに分けておくと迷いません。①変更に気づく人（実際にその業務をやっている本人）、②資料を直す責任者（持ち主）、③正式なルールとして承認する人（必要な場合のみ別に置く）。小さな組織なら、一人がいくつか兼任してかまいません。
AIの役割──差分の確認や下書きは任せる。決めるのは人
ここで、AIが役に立つ場面の話をします。
AIは、整理された情報を要約したり、変更前と変更後を比べて差分を説明したりするのが得意です。ただし、AIには苦手なことがあります。担当者が口頭で決めた新しいルールや、現場だけで起きたちょっとした変更は、誰かが記録として残さない限り、AIにとっては「存在しないこと」と同じということです。資料を最新に保つ仕組みがなければ、AIは古い情報をもとに、自信満々に答える道具になってしまいます。
これを補うために、私が実際に取り組んでいることを紹介します。パーツごとの仕様書はConfluenceを正本にし、Difyの検索用データベースに取り込んで、AIが答える前に関連箇所を検索できるようにしています。この「答える前に関連資料を検索してから答える」仕組みは、一般にRAGと呼ばれます。これとは別に、ChatGPTやCodexなど一部のAI製品では、「どの資料を確認し、どんな形式で差分を出すか」という作業手順を、Skillとして持たせられます。RAGとSkillは同じものではなく、目的に応じて使い分けます。
業務マニュアルのほうは、今ある資料を少しずつMarkdown（AIが扱いやすいシンプルな文章形式）に変換しているところです。既存の資料も、AIに手伝わせながら形式を揃えています。手順の中でBPMNの業務フロー図を作ったときは、その画像もマニュアルからリンクで結びつけています。
正直に言うと、最初はかなり大変でした。仕組みの意味を理解してくれるメンバーがまだいない段階では、一人で進めるしかありません。実際に成果物を見せながら、続けられるやり方を少しずつ固めていって、ようやく根づき始めたところです。
もともと、業務マニュアルは半年に一度、棚卸し（内容を見直して古い部分を直す作業）をする運用にしていました。AIをここに組み込んだことで、この棚卸し自体が、以前より楽になったというのが、今のところの実感です。
ここで一つ注意があります。資料を検索用のデータベースに取り込む構成では、原本を更新したあと、検索対象への再取り込みや同期が必要です。製品によっては自動化できる場合もありますが、同期の設計がなければ、AIは古い内容を参照し続けます。「資料を直せば自動でAIの答えも最新になる」わけではありません。
もし社内でAI（ローカルLLMなど）に社内FAQを答えさせる仕組みを検討しているなら、検索を賢くする前に、「どれを正本にするか」「誰が更新するか」「AIの検索対象をどう同期するか」を決めておく必要があります。ここを飛ばすと、参照する資料が古いままの、使われないシステムになってしまいます。
線引きをまとめると、こうなります。
▼ AIに任せられる
- 変更前と変更後の内容を比べて、差分を説明する
- 資料と確認日を一か所に集めておけば、次回確認日を過ぎている資料を一覧で洗い出す
- 更新のたたき台となる文章を、下書きする
- つないだ参照元をもとに、質問に答える（RAGの仕組み。同期の運用込みで）
▼ 人が確認・決定すること
- 口頭や現場だけで起きた変更を、最初に記録に残す
- どの変更を正式なルールにするか、最終的に決める
- 資料の責任者を決め、所在をはっきりさせる
- AIが出した差分や下書きが、事実として正しいか確認する
ポイントは、前回・前々回と同じです。AIの出力を、正解として扱わないこと。特に「資料にない変化を推測してください」と頼むと、AIはもっともらしく埋めてしまうことがあります。何が変わったかを最終的に知っているのは、現場の人だけです。
Q&A
Q. 資料のアップデートは、どのタイミングでやるべきですか？
A. 基本は、業務や仕様の変更を承認したとき、または次の担当者へ引き渡すときです。変更と資料更新を、同じ一つの工程に入れてしまいます。緊急対応で更新が後回しになる場合は、その場で「誰が・いつまでに直すか」を決めておきます。AIは差分の抽出や改訂案づくりに使い、正式な内容は責任者が確認します。
Q. 資料の“持ち主”は、どう決めればいいですか？
A. 「変更に気づく人」「資料を直す責任者」「正式なルールとして承認する人」の3つに分けて考えます。小さな組織なら、一人が兼任してかまいません。大事なのは、誰かに固定して、うやむやにしないことです。
Q. 社内でAIに資料を検索させる仕組みを作ろうとしています。順番として気をつけることは？
A. 検索や自動応答の仕組みを作る前に、「どれを正本にするか」「誰が更新するか」「AIの検索対象をどう同期するか」を決めてください。ここが曖昧なままでは、検索機能を整えても、古い資料を参照し続ける可能性が残ります。
Q. 個人事業主でも、この話は関係ありますか？
A. あります。冒頭のパワーポイントの例のように、資料が自分のパソコンの中にしかない状態そのものが、実はいちばん身近な「属人化」です。外注先や次のパートナーに引き継ぐ場面を考えると、早いうちに整えておく価値があります。
おわりに
見える化も、基準づくりも、資料整備も——一番大変なのは、作ることより続けることです。会社が動き続ける限り、現場は変わり続けます。だからこそ、「変わったら直る」仕組み自体を、業務設計の一部として組み込む必要があります。
まずは、社内にある資料をひとつ選んで、「責任者」「最終確認日」「次に確認する日」を書き足してみてください。それだけでも、古くなっていく資料を見つけやすくなります。
ただ、「どの資料を正本にするか決められない」「変更をどの工程で反映すればいいか分からない」——そこで止まったら、外部に相談するという手もあります。業務の流れと更新責任を整理する“要件定義”から、AIを使った差分確認や検索の仕組みの設計まで対応しています。
ご相談はこちら：https://crowdworks.jp/public/employees/6942778
ママゴトラボは、業務の自動化ツールを要件定義から設計してつくる開発ラボです。
「この作業、自動化できないかな？」がありましたら、お気軽にご相談ください。
👉 https://mamagotolab.com