第85話 課題には、次に見る人がいる
第85話です。
前回、防災訓練の内部記録を、そのまま住人向けに出すのではなく、
今回確認できたこと。
当日見えてきたこと。
次回までに見直すこと。
この三つに分けて整理しました。
失敗を全部並べることが、正直さではない。
見えた課題を消さず、次へ渡せる形にする。
そうして住人向けの振り返りはまとまりました。
しかし最後に、参加者からこんな声が出ます。
「次回までに、何が直ったのか知りたい」
今回は、「課題を誰が持つのか」がテーマです。
振り返りを書いただけでは、改善したことにはなりません。
課題には、次に誰が見るかを付ける。
理央は、新しいファイルの一行目にそう書いた。
タイトルは、
『振り返りを出しただけでは、改善したことにはならない.txt』
防災訓練の記録には、課題がいくつも並んでいる。
『館内放送の聞こえ方』
『共用アプリの旧版』
『途中参加者への案内』
『移動開始時の情報差』
『スタッフ記録の書き方』
『集合場所変更時の周知』
どれも大事。
でも、書いただけでは動かない。
ミニが言った。
『課題リスト、置物化の危険！』
「そうなんだよね」
リアルが続ける。
『改善項目には、担当、確認状況、次回確認時期を付けると追跡しやすい』
理央は、表を作った。
『課題』
『次に見る人』
『今の状態』
『次に確認する時』
最初の項目。
『館内放送の聞こえ方』
次に見る人。
『管理会社・管理組合』
状態。
『確認必要』
次。
『共用アプリの旧版表示』
担当。
『管理人・防災担当』
状態。
『編集・削除・固定方法を確認』
次。
『途中参加者への案内』
担当。
『防災担当』
状態。
『終了後確認メモ案あり』
理央はメモした。
『課題は、名前だけでは動かない。持つ人と次の時刻が必要。』
Gが言った。
『夏祭りの役割分担と同じ構造だね』
「うん」
誰かがやる。
では、誰もやらない。
また同じだった。
森崎さんへ表案を送る。
『振り返りの課題ごとに、「次に見る人」「今の状態」「次に確認する時」を付けると、置きっぱなしになりにくいと思います。理央が担当を決めるのではなく、担当者側で入れてください』
返信。
『これで整理します』
午後、小会議室。
森崎さん、理事長、管理人、自治会長。
理央は、いつものように最初に言った。
「私は担当者を決める立場ではありません。今日は、課題が止まらない形だけ整理します」
理事長が笑う。
「そこはもう分かっています」
理央も少し笑った。
森崎さんが表を開く。
「まず、放送の聞こえ方。これは管理会社へ確認します」
状態欄に、
『管理会社へ問い合わせ予定』
と入る。
次。
「アプリの旧版は、管理人さん」
「はい。編集・削除・固定の仕様を確認します」
次。
「途中参加者向けメモは、防災担当で次回までに正式版を作ります」
一つずつ、課題に持ち主が付いていく。
理央は、その様子を見ながら書いた。
『担当を付けると、課題が文章から仕事へ変わる。』
ミニが言った。
『課題、実体化！』
「そういう感じ」
ただし、また問題が出る。
自治会長が言った。
「これ、全部『次回までに』でいいんですか？」
全員が止まった。
たしかに。
次回まで。
便利な言葉。
でも、次回が半年後なら遅いものもある。
すぐ確認すべきもの。
次回訓練前でいいもの。
日常運用で直せるもの。
理央は、状態を三つに分けた。
『早めに確認』
『次回訓練前に確認』
『継続して見る』
放送の聞こえ方。
早めに確認。
アプリ旧版。
早めに確認。
途中参加メモ。
次回訓練前。
記録方法。
次回訓練前。
住人同士の情報伝達。
継続して見る。
理央はメモした。
『課題には、担当だけでなく時間の優先順位もいる。』
リアルが言った。
『妥当。安全や設備に関わるものは、正式担当者側で優先度を判断すべき』
森崎さんが頷く。
「優先度は、こちらで確認します」
次に、理事長が別の疑問を出した。
「完了したかどうかは、誰が決めます？」
また止まる。
たとえば、
『アプリ旧版の固定表示を確認』
が終わったとして。
それで改善完了なのか。
実際に住人が迷わなくなったかは、次の運用でしか分からない。
理央は言った。
「『作業完了』と『効果確認』を分けた方がいいかもしれません」
森崎さんが、すぐに表へ追加する。
『作業完了』
『効果確認』
たとえば、
『最新版を上部固定できるよう設定した』
これは作業完了。
でも、
『旧版を見て迷う人が減った』
これは次回の効果確認。
理央は書いた。
『直したことと、直ったことは同じではない。』
Gが言った。
『今回の中心っぽいね』
「うん」
設定を変えた。
紙を作った。
担当者を決めた。
それで終わりではない。
実際に機能したかを見る。
そこまでが改善。
森崎さんが言った。
「では、改善表はこうしましょう」
『課題』
『担当』
『優先度』
『作業状況』
『効果確認』
五列。
シンプルになった。
ミニが言った。
『五列で収まった！』
「今日はそれでいい」
会議の終わり。
理央は、住人向け報告への一文も提案した。
『今回見つかった課題については、担当者ごとに確認を進めます。対応状況は、次回の防災案内や必要な共有時にお知らせします。』
理事長が頷く。
「何を直すかだけでなく、あとで返すと書くんですね」
「はい。全部の内部作業を逐一出す必要はないと思いますが、改善した内容は戻した方がいいと思います」
自治会長が言った。
「やりっぱなしにしない、ですね」
理央はメモした。
『改善は、直すだけでなく、戻して知らせるところまで。』
夕方。
改善表の初版が完成した。
『防災訓練_改善確認表_v1』
理央は、それを見て少し安心した。
振り返り。
課題。
担当。
優先度。
作業。
効果確認。
ようやく、記録が次の行動へつながった。
でも、その時。
管理人が一つの項目を指した。
「これ、担当を決めにくいですね」
理央が見る。
『住人同士で古い情報が伝わる可能性』
担当欄は空白。
管理人でもない。
防災担当でもない。
管理会社でもない。
人の記憶と会話の中を歩く情報。
誰か一人が直せるものではない。
ミニが言った。
『担当者なし課題……』
リアルが続ける。
『単独の担当で解決できない課題は、個人担当ではなく、仕組みとして対応する必要がある場合がある』
理央は、新しいファイルを開いた。
『誰にも持てない課題は、仕組みに持たせる.txt』
一行目。
『担当者を決められない課題に、無理に一人の名前を置かない。』
そして保存した。
ここまで読んでいただき、ありがとうございます。
第85話では、「振り返りを改善へつなぐ」ことを扱いました。
課題を書いただけでは動きません。
そこで、
課題。
担当。
優先度。
作業状況。
効果確認。
を付けました。
今回の重要な気づきは、
担当を付けると、課題が文章から仕事へ変わる。
ということです。
さらに、
設定を変えた。
資料を作った。
担当者を決めた。
それだけでは、本当に改善したか分かりません。
今回のもう一つの大事な一文は、
直したことと、直ったことは同じではない。
です。
作業を終えることと、効果を確認することを分ける必要がありました。
そして最後に、新しい課題が残ります。
「住人同士で古い情報が伝わる可能性」
これは、誰か一人を担当者にすれば解決する問題ではありません。
次回は、「誰にも持てない課題」がテーマになります。
担当者を決められない課題に、無理に一人の名前を置かない。
理央は、個人ではなく仕組みに持たせる方法を考えます。
原案・構想：マスター
物語構成・本文作成・文体調整：G（ChatGPT）
