本レポートの概要｜人員配置とマニュアル設計
この回のレポートは全４本に分割しています。本ファイルはその１本目、テーマは「人員配置とマニュアル設計」です。
セッションは村上氏の問い――中小企業で経理担当を1人から2人に増やせばリスクは下がるのか――という素朴な疑問から始まる。答えは「どちらでもない」であり、企業が使える資本とどこに危険が伏在しているかを見比べて人員配置を設計すべきだという議論が展開される。続くマニュアル論では、前田氏の「ハザードを書面にどう落とすか」という悩みに対し、マニュアルにハザードを組み込むのは構造的に難しいという答えが示される。
失敗は企業文化の側で扱うべきであり、「飛び込んでもクッションがある」という心理的安全性の議論に接続する。リクルートの企業文化戦略が例として挙げられる一方、医療従事者からの「ルーティンの硬直化をどう防ぐか」という質問には「常に粗探しをするしかない」という回答が返された。「完璧である」という前提を捨てることが硬直化を防ぐ唯一の方法だとされる。
この理論を裏づける実例として、マイキー氏が商社勤務時代に3人が同時に離脱した部署を、購買・物流・出荷のデータ統合によってパート1人で回せる体制に作り替えた経験が語られる。決定的だったのは業務そのものではなく、部署間の「コミュニケーションの断絶」を発見し、それを前提に設計し直した点だった。構造を知ることによって粗が見つかり、あとはそれを無視するか直すかだけの話になるという整理が示される。
経理担当は1人か2人か——人員配置をリスク設計として考える
セッションの口火を切ったのは村上氏の問いだった。中小企業では一人がすべての事務を兼務していたり、 複数の業務を重複して抱えていたりする。それを二人雇って業務を分ければ、一人が辞めてもリスクを低減できるのではないか。 この考え方は、それまで議論されていたレジリエンスの枠組みと通じるところがあるのではないか、という趣旨である。
これに対する応答は、問いをいきなり答えに変換せず、まず問題を整理するという手順から始まった。 経理部の人間が一人しかいない会社を想定する。その人が体調を崩し、急に辞めた。急な出来事だったため引き継ぎもない。 このとき、社内の誰かが経理業務を代替できるだろうか——できない。 では経理を二人にすればコストは上がるか、下がるか——上がる。 では急な離脱が起きたとき、対応できる能力は一人と二人でどちらが高いか——二人である。
ここで重要なのは、コストと対応能力が単純なトレードオフの関係にあることを認めた上で、 企業が持っている使える資本と、どこにどの程度の危険性があるのかを見比べて配置を設計するという二軸の作業に落とすことである。 人員削減という発想「だけ」で動くと、トラブルが起きた瞬間に何もできない会社になり、結果としてそれが原因で潰れることが起こりうる。 レジリエンスは抽象的な理念ではなく、この人員配置設計と地続きの問題として最初に提示された。
ここで語られている「二人にするとコストは上がるが対応能力も上がる」というトレードオフは、 組織論では冗長性（redundancy）と組織スラック（organizational slack）の問題として扱われてきた領域です。 高信頼性組織理論（HRO：Weick & Sutcliffe）は、原子力空母や航空管制のように失敗が許されない組織が あえて役割の重複を残していることを観察し、冗長性は無駄ではなく事故を止める最後の砦だと位置づけました。
一方で、リーン生産やジャストインタイムはこのスラックを削ることで利益を生んできました。 コロナ禍以降のサプライチェーン論では、この「効率性 vs 冗長性」の振り子が大きく冗長性側に戻っており、 本セッション後半で語られる「極端な最適化は脆弱性を生む」という指摘は、この潮流と一致しています。
マニュアルにハザードは組み込めない——マニュアルとは何のための道具か
前田氏から実務的な質問が出た。現在、作業のマニュアル化を書面で進めている。 ただしフェーズ1の段階のハザード（危険源）については、キュア（治療・是正）の技術から言えば、 どれだけ痛みを伴わせて覚えさせるかが重要になる。先輩が見て「これは大丈夫だ、ハザードで止まるな」と判断できる場面では、 むしろ事故を起こさせた方がいい。しかしそれを書面に落とすとき、どう表現すればいいのか——という問いである。
回答は明快だった。マニュアルにハザードを組み込むのは、そもそも構造的に難しい。 なぜならマニュアルとは、企業や個人が成長するために必要なルーチンを作ることに価値があり、 もう一つの機能として「マニュアルができない人は、つまり企業にとっては不要な人である」という葛藤を示す目安になっているからである。 あくまで学習の指針であって、危険を体感させる装置ではない。
ハザードは文化の側に置く
では失敗をどこで扱うのか。答えは企業文化である。「失敗してはいけない」ではなく「してもいい、ではどうやってしましょうか」という設計に切り替える。 たとえば広い庭のようなところで、これまでの経験値がこのくらいなら、まずこのレベルのここから試してみましょう、 そのときのチェックシステムはこうです——という形にする。つまりハザードの学習はマニュアル化ではなくシステム化の問題である。
ここで日本におけるマニュアル観への批判が入る。マニュアルは「決まったことをやるもの」というイメージで語られることが多く、 日本では実際にそう使われがちである。しかし本来のマニュアルは、技術や能力の進歩、そして時代の変化に応じてどんどんアップデートし、 社員の質を一定水準に保つための道具である。常に変更・改善・バージョンアップを繰り返さなければならない。 それをやらないと何が起きるか——組織の硬直化が起こり、組織が成長しなくなる。
企業文化の形成そのものが戦略になっている例として、リクルートが挙げられた。 早期に退職して独立することを、ある意味で企業文化にしている。 文化として何を許容するかを設計することが、マニュアルの運用と同じかそれ以上に効いてくる、という指摘である。
行動を起こす前に、行動し出せる環境を作らなければならない。 「失敗して怒られるから嫌だ」となれば、何もしないことが正解になってしまう。 失敗とは、やる人にとって心理的な摩擦が非常に大きい行為であり、要するに辛い行為である。 辛い行為だからこそ「やっても大丈夫だ」というクッションを先に置いておく必要がある。 どこかで飛び込んでも、そこにはちゃんとクッションがあるから飛び込んで大丈夫だ、という状態を先に作る。
「マニュアルは更新し続けなければ組織を硬直化させる」という主張の逆側の実例として、 2022年7月2日のKDDI大規模通信障害があります。原因はコアルーターの交換作業中の不具合と、 切り戻し時のデータ不整合がVoLTE交換機に輻輳を起こした連鎖でした。 復旧までに約80時間、影響は最大3,915万回線・3,091万人以上に及び、 24時間以上通話できなかった271万人への減算と全契約者3,589万人への一律200円返金という補償に至っています。
この事故については、作業手順書（マニュアル）の版を取り違えた人的エラーが起点だったと報じられています。 マニュアルは「あるかないか」ではなく「更新され、参照される版が一意であるか」で事故を分ける—— 本セッションの「常にバージョンアップし続けなければならない」という主張を、実損失を伴う形で裏づける事例です。
ルーティンの硬直化をどう防ぐか——「完璧である」という前提を捨てる
医療従事者の参加者から、より切実な質問が出た。医療現場ではヒヤリハットから事故を防ぐという流れがあり、 医療ミスの防止と本セッションの議論は重なる部分がある。しかし毎日同じルーティンを繰り返さなければならない業務はどうしても存在し、 そうすると硬直化し、なおかつ少し手を抜く、工程をサボるといったことが起きやすくなる。 決まったルーティンの硬直化を防ぐ方法はあるのか、という問いである。
回答は「常に粗探しをするしかない」だった。どんなことでも完璧なことはない。 同じことをやっているという前提に立つと、自分たちはすでに完璧なことができているという前提が忍び込む。 しかし同じことをやっていても、完璧にできているわけではない。 問題点を見つけて改善していくと、同じように見えることであっても、実は違うことをやっている場合がある。 制度が変わり、質が変わってくることもある。硬直化を防ぐのは新しい手法の導入ではなく、 「まだ完璧ではない」という前提を組織に維持し続けることである。
事例：入社直後に3人が同時離脱した部署をどう作り替えたか
ここでマイキー氏自身の実務経験が語られた。サラリーマンとして商社に入社した際、配属された部署でほぼ同時に三つの事態が起きた。 一人が過労で倒れ、一人が急病で長期休業に入り、もう一人が交通事故で入院した。これが約2週間の間に一気に起きた。 部署が担っていたのは購買・物流・出荷、すなわち輸出業務である。
会社が対応に困っている状況で提案したのが、この三機能の一本化だった。 購買ベースのデータベースと物流データを組み合わせ、出荷ベースも全てデータで統合すれば、 一連の流れになった時点でペーパーワークが不要になる。残るのは仕訳だけで、仕訳は人間の手でやらなければならないので改善できない。 実際の手順としては、まず購買データを全て確認してどのようなプロセスでメーカーに発注しているのかを把握し、 次にメーカーから出荷された後に横浜港の倉庫に入るまでの物流を追い、 その後の出荷までの流れと貿易実務の書類を全て読み取り、どこでコストが削減できるかを設計した。 結果として、この業務はパート一人で回せるようになった。
設計にあたって決定的だったのは、購買・出荷・物流、そして物流側の倉庫から出荷までの間で コミュニケーションがほとんど取れておらず、極めて非効率な運営になっていたという発見だった。 そこで「コミュニケーションがなくても回るように作ってしまえ」という方針で設計した。 復帰した人たちに対して「あなたの居場所はもうありません」という状態が生まれてしまったが、 これは組織としてのレジリエンス強化そのものである。
構造を知ることによって改善できる。粗が出るということは改善する場所ができるということであり、 あとはそれを無視するか直すかだけの話である。
この購買・物流・出荷の統合事例は、後述するCynefinフレームワークで言えば Complicated（込み入った）領域の典型的な解法です。 因果関係は存在するが、それを見抜くには専門知識が要る。だから「感知→分析→対応」の順で、 まず全書類とデータフローを読み込む分析フェーズに資源を投じている。 本人が後段で「自分がやったのは技術的課題だった」と自己分類している通りです。
逆に言えば、この手法は問題が曖昧で既存ノウハウが通用しないアダプティブ・チャレンジには使えません。 成功事例をそのまま横展開しようとすると領域を取り違える——これがセッション後半の分類学の必要性につながっています。