管理職やスーパーバイザーという立場にいると、「チームをまとめる力がある」「業務を回す能力が高い」と見られることがあります。
ただ、私の経験では、本当に現場を動かすには、“人を技術的に知る視点”が不可欠でした。
本記事では、150名のスタッフを統括していた私が、以下のようなアプローチで「人を知る技術」を業務設計に活かしてきたプロセスを記録します。
- 性格・傾向・判断速度などの“人間情報”を管理対象として捉える
- 属人性に頼らず仕組みで対応力を上げる
- 意思決定の遅延や相談の偏りを技術的に分散する
🧠 マネジメントの前提：「人はみんな違う」という事実から始まる
150名規模ともなると、毎日の業務の中で「人による対応差」「理解スピード」「質問頻度」「報告精度」に明確な偏りが生まれます。
私が着目したのは、以下のような“人間属性”です：
| 属性 | 説明 | 業務への影響 |
|---|---|---|
| 理解速度 | 業務手順を飲み込むまでの時間差 | 質問量・確認回数に影響 |
| 会話傾向 | 話しかけやすさ・会話のスタイル | エスカレーションが来る頻度に影響 |
| 業務適正 | 得意なタスク領域（ヒアリング・事務処理など） | 適材配置の判断材料になる |
| 情報過敏性 | ミスへの反応・指摘へのストレス耐性 | 報告漏れ・自己判断によるトラブルにつながる |
これらを把握せずに「皆に同じ情報を出す」のは、
結果として “届かないマネジメント”になる というのが、現場での実感です。
🔍 「人間情報の収集」は業務改善の第一歩
現場の声をどう拾い、どう蓄積するか──これには以下の手段を導入しました。
1. 週報・報告フォーマットに「個人の感覚」を記述させる
「業務で困ったこと」「前回の対応との違い」「感じた点」など、定量だけでなく定性面を記録できるようにフォーム設計。
2. 面談記録を蓄積・チーム共有
面談でのやり取りは、記録しておかないと当然意味がありません。
相談内容・性格傾向・過去の対話内容などをタグ付けし、保存していました。
3. 業務中の対応ログをBotやフォームから回収
Botで「○○への質問が多い人」などのメタ情報も記録。質問頻度・時間帯・傾向などを蓄積してスタッフごとの傾向を可視化。
💡 対応設計の分岐点：「人を知る」ことがエスカレーションを分散させる
人によって「すぐに相談する」「一人で抱える」「リーダーにだけ話す」など対応方針が異なります。それぞれに合わせた対応導線を用意することで、スーパーバイザーへの一極集中を防ぐことができます。
具体策：
✅ “相談ルートの分散”設計
- Bot → FAQ → シフトリーダー → 私への階層構造を導入
- 業務種別によって“誰に聞くべきか”が自然に分かる図解ツールも作成
✅ “相談しやすいUI”の設計
- Botやフォームの質問欄に「不安点」や「確認事項」を明示化
- 「曖昧でも聞ける」仕組みが相談頻度を最適化させる
✅ “相談傾向”を見える化
- 誰が・いつ・どんな種類の質問をしているかをデータ化
- スタッフ教育やシフト配置の参考にすることで、根本的な相談負荷を軽減
🧩 性格ごとの対応設計：パターンと事例で考える
例えば、以下のようなスタッフがいたとします：
| スタッフタイプ | 傾向 | 最適対応 |
|---|---|---|
| Aさん | 自信はあるが業務理解に誤差あり | Bot回答＋リーダーフォローで補完 |
| Bさん | 抵抗感があり質問を避ける | チャットで定期的に声かけ・心理的安全を確保 |
| Cさん | 質問が多く頻繁に確認を取る | FAQ参照頻度を上げてBot最適化、定期的な面談を導入 |
私が大切にしていたのは、「その人がどう受け取るか」に合わせて技術ツールの設計を変えることでした。つまり、Botやフォームも“人格に寄り添ったUX”を持つ必要があると考えています。
👥 ナレッジの横展開は「性格とスキルの掛け算」で加速する
単に「こうすればいいよ」という指導では、業務改善は進みません。ポイントは以下の3つ。
1. 教える側の性格×教えられる側の性格の相性を意識
- 説明が強めの人は、慎重なタイプに向かない
- 丁寧な人が雑なタイプに教えると、逆に「うるさい」と思われてしまう
2. 説明資料のトーンを複数用意
- 図解中心／文章中心／会話風など、複数パターンを用意し、相手に合ったスタイルで展開
3. フィードバック設計
- 教えた内容が「どう活きたか」「何が残ったか」を後日Botやフォームで回収し、改善へつなげる
人の成長には個性への適応が不可欠であり、それを“技術的に支える”のがスーパーバイザーの設計業務でした。
🔧 技術は「人を理解する補助輪」になる
Bot・DB・HTML・VBA・スプレッドシート──これらは、私が「人と情報を理解する手段」として用いてきた道具です。
| 技術要素 | 活用目的 |
|---|---|
| HTML/CSS | ログ入力フォーム設計。入力傾向から理解度を測る |
| VBA | 書類整形・作業ログ集計による精度の差分分析 |
| Python Bot | 質問傾向の記録、誰がどんなことで迷うかの把握 |
| DB化 | 対応履歴・相談傾向・説明回数などを時系列に保存 |
| Googleスプレッドシート | リアルタイム共有による相談導線の可視化 |
これらを「人を理解するためのセンサ」として運用したことで、マネジメントは“統率”ではなく“設計”であるという視点が定着しました。
📌 結び：人を知ることは、技術者としての最重要スキルだった
人の感情や行動はコードよりも曖昧で、時に予測が困難です。しかしそれを無視してシステムを構築すれば、業務は空回りします。私は「人の不確かさに寄り添うこと」が設計思想の出発点だと実感しました。
そして、マネジメントとは以下のような問いへの設計解であるべきだと考えています。
- この人は何が苦手か、それをどう補えるか
- この人はどんなタイミングで迷うか、その兆候をどこで見つけるか
- この人は何なら自信を持てるか、それをどう活かせるか
それらに対する答えを、私は人を観察し、仕組みに変換する技術者として導いてきました。
✍️ 締めに：人の情報は、組織の最強データベース
私は技術が好きです。しかしそれ以上に「人間が気持ちよく働ける設計」に興味があります。150人規模の現場統括で学んだのは、「人の情報は最強の改善資源」だということ。
Botも、フォームも、資料も、システムも──すべては“人を理解した技術”として設計するからこそ生きてくる。
今、私は過去のこの経験を基に、人間中心の業務設計をさらに深めたいと考えています。そしてこの連載では、「技術で人を支えることができる」という実例を今後も開示していきます。
📘 次回：
エスカレーション80件/日を捌く“構造化”の発想
── 業務が止まる前に、情報の流れを整える。過負荷対応の仕組み化