"掴まず、抗わず、流れとともに" 第187話
前回、第186話では、「上司・組織との摩擦を増やさずに降りる」を扱いました。
正しさだけをぶつけても、現場では物事は動きにくい。
必要なのは、闘争ではなく政治と運用であり、合意形成、期待値調整、説明コストの制御を通して、少しずつ降りることでした。
つまり、壊れるまで抱えるか、全部を壊して出ていくか、その二択ではない。
現実の職場の中で、配置を変えて降りる第三の道を持つこと。
そこまでを見てきました。
しかし、そこでなお残る大きな問題があります。
それは、「仕事ができない日」を、いまだに例外や事故としてしか扱っていないことです。
集中できない。
遅い。
判断が鈍る。
確認漏れが増える。
人と話すだけで消耗する。
そういう日は、誰にでもあります。
しかし多くの現場は、その日が来ない前提で組まれている。
すると何が起きるか。
できない日は、そのまま人格の問題になります。
怠慢。
未熟。
自己管理不足。
やる気の低下。
こうして、「仕事ができない」という最大の悪口が、運用の失敗ではなく、人間の失格として機能し始める。
そこで今回の主題はこれです。
プロトコル16。
仕事ができない日を前提化する。
結論を先に言います。
仕事ができない日を無力化するには、精神論では足りません。
必要なのは、できない日を制度に織り込むことです。
つまり、例外ではなく前提にする。
そのために必要なのが、稼働率の設計、バッファの設計、品質の下限設定です。
このプロトコルの役割は、「できない日」を擁護することではありません。
また、サボりを美化することでもない。
必要なのは、仕事ができない日が来ても、そこから直ちに人格判決へ飛ばないよう、最初から運用側で受け止めることです。
できない日を運用問題へ戻す。
それが今回の目的です。
なぜ「できない日」はここまで危険なのか
第169話で見たように、「仕事ができない日」が怖いのは、単に仕事が進まないからではありません。
それがそのまま自己価値の崩れとして読まれやすいからです。
今日は遅い。
だから自分は劣っている。
今日は判断が悪い。
だから自分は価値が低い。
今日は何も生めない。
だから存在が薄い。
この変換が痛い。
しかし、さらに深い問題は、現場そのものもまた、その変換を促進していることです。
予定は常に一〇〇パーセント前提。
人員は平常時ぴったり。
品質期待は常に上限。
しかも、崩れた時の逃げ道がない。
この設計では、少し性能が落ちただけでも、個人が悪いことになりやすい。
つまり、「できない日」は個人の弱さというより、できない日を運用に織り込んでいない設計の問題でもあるのです。
できない日は異常ではなく、運用条件である
ここで最初に切り替えるべき前提があります。
それは、できない日を異常とみなさないことです。
体調には波がある。
集中力にも波がある。
睡眠にもムラがある。
感情にも揺れがある。
人間は、日ごとに性能が一定ではありません。
にもかかわらず、運用だけは毎日同じ出力を要求する。
これが無理を生む。
だからこのプロトコルでは、できない日を
まれな事故
ではなく
一定確率で起きる運用条件
として扱います。
雨の日がある前提で道路を作るのと同じです。
疲労の日。
集中が浅い日。
反応が鈍い日。
それが来る前提で、仕事の回し方を設計する。
この発想がない限り、できない日は何度でも人格問題に戻されます。
稼働率を一〇〇パーセント前提で組まない
まず最初のレバーは、稼働率です。
多くの人は、仕事を組む時に、自分の稼働をほぼ一〇〇パーセントで見積もっています。
朝から晩まで動ける前提。
集中が切れない前提。
判断速度が落ちない前提。
割り込みが少ない前提。
それで予定を敷き詰める。
すると、少しでもできない日が来ると一気に破綻します。
だから必要なのは、稼働率を下げて見積もることです。
常にフル出力ではない。
その前提を持つ。
たとえば、八割で見る。
重い判断を一日に何本も入れない。
午前と午後で同じ密度を要求しない。
このように、もともと余白を含んだ見積もりにする。
ここで大切なのは、怠ける余地を作ることではありません。
現実の人間性能に合わせることです。
一〇〇パーセント前提は、一見まじめに見えます。
しかし実際には、少し崩れた時に人格責任へ流れやすい危険な設計です。
だから、稼働率を最初から少し低く置く。
これが、できない日を制度に入れる最初の一歩です。
バッファは余り時間ではなく、人格防衛装置である
二つ目のレバーは、バッファです。
多くの人は、バッファを
余ったら使う時間
くらいに見ています。
しかし、そうではありません。
バッファは、できない日が来た時に、直ちに人格判決へ移らないための装置です。
予定がぎりぎりで組まれていると、少し遅れただけで
もうだめだ
が始まる。
一件の確認漏れで
今日は終わった
が始まる。
すると仕事上の問題が、すぐ自己価値の問題へ変換される。
つまり、バッファがないと、人はすぐ人格で補填し始めるのです。
もっと頑張る。
休みを削る。
夜で埋める。
休日で返す。
これが起きる。
だからバッファは、単なる時間の余白ではありません。
人格を補填材にしないための余白です。
予定と予定のあいだ。
判断の重い作業の前後。
人と長く接する日の後ろ。
そうしたところに、小さくても置く。
バッファがあるだけで、できない日は
破綻
ではなく
吸収可能な揺れ
になります。
品質の下限を先に決める
三つ目のレバーは、品質の下限です。
できない日が苦しいのは、その日に何を守れば十分なのかが決まっていないからです。
すると、人はできない日にも、通常日の上限品質を自分に要求し続けます。
それで当然、苦しくなる。
だから必要なのは、
できない日でも、ここまで守れれば十分
という下限を先に決めることです。
たとえば、
完璧ではなく、誤解が生まれない程度の明確さでよい。
深い整理ではなく、次に着手できる形まででよい。
即答ではなく、確認して返す予告まででよい。
詳細な改善案ではなく、問題点の切り分けまででよい。
こうした下限です。
下限がないと、人は毎回フル品質を目指し、届かなかった分を人格で埋めようとします。
しかし下限があると、今日はそこまでで止められる。
つまり、できない日を前提化するとは、
手を抜く
ことではありません。
その日に守るべき品質の最低ラインを、先に運用として持つことです。
「今日はできない」を申告ではなく運用にする
多くの人は、できない日を言葉にする時、告白のようになります。
すみません、今日は調子が悪くて。
本当に申し訳ないのですが、うまく回らなくて。
こうなる。
すると、できない日は運用ではなく、個人的な弱さの申告になります。
これがまた苦しい。
だから、このプロトコルでは
今日はできない
を個人の告白としてでなく、運用の切り替えとして扱います。
たとえば、
今日は縮小運転に切り替えます。
この件は簡易版で返します。
詳細は明日確認します。
優先順位の高いものだけ処理します。
こうした表現です。
大事なのは、できないことを隠さないことです。
しかし、人格の謝罪にしない。
できない日にも運用がある。
その感覚へ戻す。
これだけで、同じ状態でもかなり違います。
例外ではなく「短縮運転モード」を持つ
できない日を前提化する時に有効なのが、
短縮運転モード
を先に持つことです。
通常運転。
短縮運転。
この二段階があるだけで、かなり楽になる。
短縮運転では何をするか。
会議は必要最低限だけ出る。
返信は受領確認と次の時刻だけ返す。
判断が重いものは後ろに回す。
品質は下限で止める。
追加案件は受けない。
こうした運用です。
ポイントは、短縮運転が
緊急避難
ではなく
正規モード
であることです。
つまり、今日はだめだから仕方なくではなく、
今日は短縮運転の日として切り替える。
これが前提化です。
そうすると、できない日が来ても、自分を異常扱いしなくて済みます。
稼働率設計は「頑張れば埋まる」を前提にしない
ここで一つ重要なことを言います。
多くの人は、稼働率を低めに見積もっても、最後に
足りなければ頑張れば埋まる
を残しています。
しかし、それでは設計は変わりません。
結局、崩れた時の最終調整弁が人格になっているからです。
だから、本当に前提化するには、
埋めない日がある
ことを運用に入れる必要があります。
今日はここまで。
これ以上は品質が落ちる。
ここから先は明日。
そのように止める基準が要る。
そうでないと、稼働率を八割に置いても、最後の二割を気合で埋め続けることになります。
それでは意味がありません。
できない日を前提化するとは、
できない日の存在を認める
だけでなく、
埋めないという選択を運用に含めることでもあります。
ここが非常に大切です。
「できない日」を見越して先に置くべきもの
では、何を先に置くべきか。
このプロトコルでは三つです。
一つ目は、余白です。
予定の詰め込みをやめる。
判断の重い仕事を連続させない。
割り込み吸収の余地を少し持つ。
これはバッファ設計です。
二つ目は、下限です。
今日は何を守れれば十分か。
どこまでなら品質として成立するか。
これを先に決める。
下限がないと、できない日はただ全面敗北になります。
三つ目は、切り替え条件です。
どうなったら短縮運転に移るのか。
睡眠不足か。
集中切れか。
意味の空洞化か。
修正依頼の刺さり方か。
前兆との接続が要る。
これがあると、できない日が
気合で押し切る日
ではなく
運用を変える日
になります。
できない日を前提化すると、何が変わるのか
最も大きい変化は、
できない
が
人格判決
から
運用上の変数
へ戻ることです。
これが大きい。
今日は判断速度が落ちている。
では、確認を増やす。
今日は人と話すコストが高い。
では、会話量を減らす。
今日は注意が散る。
では、重いタスクは後ろへ回す。
このように読める。
つまり
できない
が
使えない人間の証拠
ではなく
今日の運転条件
になる。
この変化があると、仕事ができない日はまだつらいとしても、
そこから自分全体が崩れる感じはかなり減ります。
それがこのプロトコルの意義です。
サボりの美化とは何が違うのか
ここで、このプロトコルで扱わないことを明確にします。
サボりの美化はしません。
仕事を避けることそのものを正当化するのでもない。
責任を放棄することをすすめるのでもありません。
違いは明確です。
サボりの美化は、現実の役割や影響を見ない。
しかし、このプロトコルは逆です。
役割と影響を見たうえで、
その日に守るべき下限
と
削るべき上限
を運用で決める。
つまり、仕事を放棄するのではなく、仕事を成立可能な範囲へ戻すのです。
仕事ができない日を前提化するとは、甘くなることではありません。
無理な前提をやめることです。
その違いを崩さないことが重要です。
よくある失敗1 できない日を秘密裏に処理しようとする
真面目な人ほど、できない日を隠します。
表面上はいつも通りに見せる。
裏で必死に埋める。
夜で返す。
休日で埋める。
しかし、これは長く持ちません。
しかも、隠し続けるほど、できない日はますます人格の恥になります。
このプロトコルでは、全部を公表しろとは言いません。
しかし、少なくとも自分の中では
今日は短縮運転
と認める必要があります。
そして必要なら、運用の言葉で周囲へ出す。
そこがないと、前提化は起きません。
よくある失敗2 下限が高すぎる
もう一つ多い失敗は、下限のつもりで、実は通常品質を置いていることです。
最低限、きれいにまとめる。
最低限、気の利いた返信をする。
最低限、全部把握しておく。
これでは最低限になっていない。
真面目な人ほど、下限が高すぎる。
だから下限は、本当に
これ以下だと仕事として成立しない
ラインまで落とす必要があります。
それ以下でなければ恥ずかしい、ではありません。
成立ラインです。
この違いをはっきりさせないと、できない日は何度でも苦しくなります。
プロトコル16の出力は三つ
今回の出力を明確にします。
プロトコル16で手に入れるべきものは三つです。
一つ目。
自分の通常稼働を一〇〇ではなく、少し低く見積もる前提。
たとえば、重い判断は一日に二本まで。
予定は八割で組む。
こうした前提です。
二つ目。
短縮運転の日の品質下限。
今日はどこまで守れれば十分か。
一文で言えるようにする。
三つ目。
短縮運転へ切り替える条件。
何が起きたら
今日は通常運転ではない
と判断するか。
そこを決める。
この三つがあると、できない日は事故ではなく、運用上の条件になります。
プロトコル16の最小実装
この回を読んだあと、最小限やることは一つです。
自分にとっての
できない日
を一種類だけ選ぶことです。
眠い日でもいい。
集中が切れる日でもいい。
人と話すだけで消耗する日でもいい。
まず一つに絞る。
そのうえで、その日の
下限
を一文で書く。
たとえば、
今日は受領確認と次の時刻提示までできれば十分。
今日は会議では決定までいかず、論点整理までで十分。
そのくらいでよい。
それがプロトコル16の入口です。
このシリーズの立場
ここでも、主題は同じです。
掴まず。
仕事ができるかどうかに、自分の存在価値の全重量を預けすぎない。
抗わず。
できない日が来た時に、また自己否定と気合で埋める方向へ流れない。
流れとともに。
稼働率を設計する。
バッファを置く。
品質下限を持つ。
短縮運転へ切り替える。
そうやって、できない日を人格問題ではなく運用問題へ戻していく。
プロトコル16。
仕事ができない日を前提化する。
これは最大の悪口を、言葉で無効化することではありません。
できない日が来ても、その日がただちに
人間として終わっている証拠
にならないよう、最初から制度として織り込むことです。
ここができると、人はようやく
できない日があっても働ける
という現実的な構造を持てるようになります。
