第86話 誰にも持てない課題は、仕組みに持たせる
第86話です。
前回、防災訓練で見つかった課題に、
担当。
優先度。
作業状況。
効果確認。
を付けることで、振り返りを実際の改善へつなげました。
しかし、一つだけ担当を決めにくい課題が残りました。
「住人同士で古い情報が伝わる可能性」
これは、管理人ひとりでも、防災担当ひとりでも、管理会社ひとつでも止められません。
人の記憶。
会話。
スクリーンショット。
古い投稿。
情報は、担当者の手を離れても歩き続けます。
今回は、「誰にも持てない課題」をどう扱うかがテーマです。
担当者を決められない課題に、無理に一人の名前を置かない。
理央は、新しいファイルの一行目にそう書いた。
タイトルは、
『誰にも持てない課題は、仕組みに持たせる.txt』
改善確認表。
ほとんどの欄には、担当が入っている。
管理会社。
管理人。
防災担当。
理事会。
でも一つだけ空白。
『住人同士で古い情報が伝わる可能性』
ミニが言った。
『担当者なしボス、まだ残ってる』
「これは、人に割り振って終わる問題じゃないんだと思う」
リアルが続ける。
『単独担当で解決できない課題は、運用ルールや更新手順に組み込む方がよい場合がある』
Gが言った。
『つまり、人に持たせるんじゃなくて、仕組みに持たせる』
「うん」
理央は、まず考えた。
住人同士の会話を止めることはできない。
スクリーンショットを消すこともできない。
古い記憶を全部消すこともできない。
なら、古い情報が流れても、
「どこを見れば最新版か」
がすぐ分かればいい。
理央は書いた。
『古い情報を完全に消すのではなく、最新版へ戻れる道を固定する。』
森崎さんへ送る。
『この課題は、誰か一人を担当にするより、「最新版はここを見る」という共通ルールにした方がよさそうです。古い情報が人づてに流れても、戻れる場所を一つにしておく形です』
返信。
『それがよさそうです。最新版の基準を決めましょう』
午後、小会議室。
森崎さんがホワイトボードに書く。
『防災情報の最新版はどこか』
候補は三つ。
共用アプリ。
一階掲示板。
管理室。
全部を最新版にすると、またズレる。
理央は言った。
「最新版の基準は、一つにした方がいいと思います。ほかは、その最新版へ案内する役割にすると分かりやすいです」
理事長が聞く。
「では、共用アプリですか？」
管理人が少し考える。
「アプリを使わない方もいます」
そこで止まる。
一つにしたい。
でも、一つだけでは届かない人がいる。
Gが言った。
『基準は一つ、入口は複数』
理央は、そのまま言った。
「基準は一つ。入口は複数、でどうでしょう」
森崎さんが振り返る。
「つまり？」
「正式な最新版は共用アプリ上部固定にする。でも、掲示板にも同じ内容を出す。管理室でも確認できる。ただし、内容を別々に編集しない」
管理人が頷く。
「同じ原稿を使うということですね」
「はい」
理央はメモした。
『入口は複数でも、原稿は一つ。』
ミニが言った。
『コピー元、一個！』
「雑だけど分かりやすい」
ルール案ができた。
『防災案内更新ルール』
一、正式最新版は一つの原稿で管理する。
二、共用アプリ・掲示板・管理室では同じ内容を使う。
三、変更時は版数と日付を更新する。
四、旧情報を見た人には、最新版の確認先を案内する。
五、変更点を冒頭で短く示す。
これなら、誰か一人が古い噂を止める必要はない。
どこへ戻ればいいかを、仕組みで固定する。
理央は書いた。
『人の記憶は管理できない。でも、戻り先は設計できる。』
クルスが言った。
『忘れさせることではなく、戻れる場所を作るのですね』
リアルが返す。
『比喩として妥当』
森崎さんが改善表を書き換える。
『課題：住人同士で古い情報が伝わる可能性』
担当。
空白ではなく、
『防災情報更新ルール』
と入った。
理央は、それを見て少し驚いた。
担当欄に、人ではなく仕組みが入っている。
ミニが言った。
『仕組みが担当者になった！』
「完全には違うけど、近いね」
もちろん、仕組みを運用する人はいる。
管理人。
防災担当。
理事会。
でも、誰か一人の記憶や頑張りだけに依存しない。
そこが大事だった。
理央はメモした。
『仕組みとは、人を不要にするものではない。人の頑張りだけに依存しないためのもの。』
会議は、そのまま他の課題にも広がった。
途中参加者への案内。
これも、森崎さんひとりが覚えているだけでは弱い。
終了後確認メモを正式テンプレートにする。
記録の書き方。
これも、次回担当者の記憶に任せない。
『何が起きたか』
『どこで起きたか』
『どう対応したか』
を記録様式へ入れる。
理央は気づく。
個人の工夫だったものが、少しずつ共通の型へ変わっている。
理央は書いた。
『再現したい工夫は、人の記憶から様式へ移す。』
Gが言った。
『これ、文明設計っぽくなってきたね』
「少しね」
最初は、マンションのベンチだった。
次は生ごみ。
夏祭り。
防災訓練。
今は、更新ルールと記録様式。
少しずつ、生活圏の仕組みそのものへ近づいている。
ただし、理央は専門家ではない。
決める人でもない。
見えた切れ目を、形にして渡しているだけ。
会議の最後。
理事長が言った。
「これ、来年の理事会メンバーが変わっても使えますかね」
理央の手が止まった。
来年。
人が変わる。
担当者が変わる。
森崎さんがいないかもしれない。
管理人が替わるかもしれない。
理事長も替わる。
それでも仕組みが残るのか。
そこまで考えて初めて、仕組みと言えるのかもしれない。
理央は答えた。
「誰がやっても最低限同じ場所に戻れる形なら、残りやすいと思います」
森崎さんが頷く。
「引き継ぎですね」
その言葉で、次の課題が見えた。
引き継ぎ。
資料があるだけでは足りない。
どれが最新版か。
何のためのルールか。
何を変えてはいけないか。
何は変えてよいか。
次の人が理解できなければ、また最初に戻る。
理央は、新しいファイルを開いた。
『仕組みは、引き継げなければ人の記憶に戻る.txt』
一行目。
『担当者が変わった時に残るものだけが、仕組みとして試される。』
そして保存した。
ここまで読んでいただき、ありがとうございます。
第86話では、「誰にも持てない課題」を扱いました。
住人同士で古い情報が伝わる。
これは、誰か一人が止められる問題ではありません。
そこで理央たちは、
古い情報を完全に消すのではなく、最新版へ戻れる道を固定する。
という形を考えました。
今回の重要な考え方は、
基準は一つ。
入口は複数。
です。
共用アプリ。
掲示板。
管理室。
入口は複数あっても、元になる最新版は一つ。
内容を別々に編集しない。
そして今回、もう一つ大きな変化がありました。
個人の工夫だったものが、
更新ルール。
確認メモ。
記録様式。
という「仕組み」へ変わり始めたことです。
仕組みとは、人を不要にするものではありません。
人の頑張りだけに依存しないためのものです。
しかし最後に、理事長から新しい問いが出ました。
「来年、担当者が変わっても使えますか？」
次回は、「引き継ぎ」がテーマになります。
仕組みは、担当者が変わった時に本当に残るのか。
理央は、記録を次の人へ渡す方法を考えることになります。
原案・構想：マスター
物語構成・本文作成・文体調整：G（ChatGPT）
