「言わない訓練」より「言わなくて済む仕組み」を作れ
TL;DR
引き継いだはずの仕事にまだ口を出してしまい、自分も相手も消耗していると感じているリーダー向け。
レビューで毎回同じ指摘をしているなら、我慢を鍛えるのではなく仕組みで解決する方が速い
「かまってしまう」の正体は、責任を手放せていないだけ
仕組みに言わせれば、指摘する側もされる側も消耗しなくなる
「また同じこと言ってる」に心当たりはないか
「前提条件は？」「この資料で何を決めたいの？」「自分の意見は？」
引き継いだはずの仕事で、裏方に回ったはずなのに、資料が上がってくるたびに口を出してしまう。
指摘する側も、される側も消耗します。
しかも同じパターンの繰り返し。
似た経験がある方は少なくないと思います。
「かまってしまう」の正体
最初は「相手の成長のため」だと思っていました。
でも掘り下げると違いました。
気にしているのは相手ではなく、その先にいるステークホルダーでした。
チーム全体の品質が下がることが怖い。
自分が作った基準が崩れることが怖い。
つまり「かまっている」のではなく、責任を手放せていないだけです。
引き継いだはずなのに、品質への当事者意識だけが手元に残っている。
そういう状態です。
「我慢する」がうまくいかない理由
「今回は黙っておこう」と決めても、品質の低い成果物を見た瞬間に耐えられなくなります。
意志の力で抑え込むアプローチは、そもそも設計として筋が悪い。
これは運用の考え方で言えば、手動オペレーションで品質を担保しようとしているのと同じです。
属人的で、スケールしません。
「人が言う」を「仕組みが言う」に変える
解決策は2段階あります。
まず応急処置として、介入基準を決めます。
判断軸は「チームにとって取り返しのつかない問題か？」だけです。
YESなら言う。NOなら転ばせる。
これだけで「言うべきか悩む」時間が消えます。
次に根本対策として、テンプレートに事前の仕組みを入れます。
たとえばレビュー依頼のフォーマットに、こんな項目を入れておきます。
この資料で決めたいこと（空欄ならレビューを受け付けない）
前提条件・制約
検討した選択肢と推奨案
リスク・懸念事項
ポイントは3つあります。
1つ目は、書く側が自分で整理する効果があること。
テンプレートを埋めるだけで「何を決めたいか」が言語化されます。
2つ目は、指摘が「個人への注文」から「仕組みの要求」に変わること。
「この欄が空だから埋めて」は角が立ちません。
3つ目は、レビューする側の負荷が下がること。
何を見ればいいかが明確になるので、レビュー時間そのものが短くなります。
繰り返し作業の自動化と同じ構造
この話、運用の現場で言われている「繰り返し作業を自動化しろ」とまったく同じ構造です。
| レビューの問題 | 運用での対応パターン |
|---|---|
| 毎回同じ指摘をしている | 繰り返し作業の自動化 |
| 品質が人に依存している | 事前の仕組みで担保する |
| 「言うべきか」で悩む | 介入の基準を事前に決める |
| 全部の品質を拾い続ける | 許容範囲を先に決める |
レビューの繰り返し作業を仕組みで潰す。
品質を事前の仕組みで担保する。
介入の基準を事前に決める。
やるべきことは、運用の現場で日常的にやっていることと同じです。
レビューが「判断の場」に変わる
仕組みが基本品質を担保してくれると、レビューの役割が変わります。
仕組みを入れる前は、フォーマットの指摘、前提の確認、「で、あなたの意見は？」の引き出し。
これは消耗します。
仕組みを入れた後は、選択肢の妥当性チェック、リスク評価、意思決定の後押し。
これは生産的です。
レビューする側が最も価値を出せる「判断」に集中できるようになります。
そして何より、相手が自分で考える筋力がつきます。
テンプレートに沿って書くうちに「決めたいこと、選択肢、推奨、リスク」という思考パターンが身につく。
最終的にはテンプレートがなくても同じ構造で資料を作れるようになります。
まとめ
レビューで同じ指摘を繰り返しているなら、それは仕組みの不在が原因です。
「我慢する訓練」ではなく「言わなくて済む仕組み」を作る方が、全員にとって速い。
明日からできることは1つだけです。
次にレビュー依頼が来たら、テンプレートを渡して「これ埋めてからもう一度持ってきて」と言う。
指摘を我慢する訓練は要りません。
仕組みに言わせればいいのです。
