制御を少しでもかじったことがある人なら、間接業務における「ミスのフィードバック展開」に、どこか言語化しづらい違和感を覚えたことがあるのではないでしょうか。
「大事なことだとは思う。でも、これって本当に制御になっているのか？」というズレです。
多くの職場では、プロジェクトが終わった後に反省会を開き、「前回はここがダメだったから次は注意しよう」と共有します。一見、ちゃんと改善に向かっているように見えますが、制御の観点で見ると、実はかなり危うい運用です。
この記事では、フィードバック制御とフィードフォワード設計の違いを軸に、なぜ「確認を増やしているのに手戻りが減らないのか」、そしてどうすれば構造的にミスを減らせるのかを整理していきます。
専門分野に限らず、間接業務やプロジェクト運営全般に共通する原理原則として、噛み砕いて解説します。
「フィードバックしているつもり」が制御になっていない理由
まず押さえておきたいのは、フィードバック制御とは何かです。
制御工学におけるフィードバック制御は、「実行中」にアウトプットを観測し、目標との差（偏差）を見て介入し、許容時間内に収束させる運用を指します。
ここで重要なのは、実行中であることと、介入点・介入方法・時間軸が決まっていることです。
一方、間接業務でよく見られる「ミスのフィードバック」は、次のような形になりがちです。
- プロジェクト終了後に振り返りをする
- ミス事例を一覧化して共有する
- 「次回は注意しましょう」と周知する
これは改善活動としては意味がありますが、制御という言葉で表すには要素が足りません。
なぜなら、実行中の偏差を見て、どこにどう介入するかが定義されていないからです。
結果として、「確認項目」や「注意事項」だけが増えていき、現場の負荷は上がるのに、同じ種類のミスが形を変えて再発します。
確認を増やしても制御にはならない
よくある誤解に、「確認を増やせばミスは減る」という考え方があります。
しかし制御の観点では、確認は単なる観測に過ぎません。
制御として成立させるためには、少なくとも次の点が必要です。
- どの指標を監視するのか
- どの値を超えたら「偏差あり」と判断するのか
- 偏差が出たとき、どこに介入するのか
- 何をどう調整するのか
- いつまでに収束させるのか
これらが決まっていない状態で確認だけを増やすと、「見てはいるが、何も変えられない」状態になります。
これは制御ではなく、単なるチェックリスト運用です。
さらに重要なのが、フィードバックには必ず遅れがあるという前提です。
人が確認する以上、報告・判断・対応には時間がかかります。その遅れを織り込んだ設計をしていないと、気づいたときには手遅れ、という事態が起きやすくなります。
プロジェクト後の学びは「フィードフォワード」で生かす
では、プロジェクト終了後の振り返りや反省は意味がないのでしょうか。
もちろん、そんなことはありません。ただし、使いどころを間違えてはいけないのです。
プロジェクト後に得られる学びは、フィードバックではなくフィードフォワードとして使って初めて価値を持ちます。
フィードフォワードとは、実行前に条件や仕組みを設計し、問題が起きにくい前提を作ることです。
具体的には、次のような考え方になります。
- 過去プロジェクトで得られた知見を整理する
- 今回のプロジェクト条件（規模、メンバー、制約など）を洗い出す
- 両者の差分（ギャップ）を明確にする
- ギャップを埋めるために、進め方や条件を事前に設計する
- それを個人の注意事項ではなく、仕組みとして組み込む
ここで重要なのは、「前回失敗したから気をつけよう」で終わらせないことです。
それでは、人の注意力に依存するだけで、構造は何も変わりません。
ギャップ分析を飛ばすと同じ轍を踏む
フィードフォワード設計で最も重要なのが、過去と今回のギャップを理解することです。
たとえば、前回はベテラン中心のチームでうまくいった進め方が、今回は経験の浅いメンバーが多いプロジェクトでは通用しない、ということはよくあります。
この違いを無視して「前回のやり方を踏襲しよう」とすると、途中で詰まります。
逆に、「前回はここで失敗したから、今回は確認を増やそう」とだけ考えると、確認コストだけが増え、作業は遅くなり、結局ミスも減らない、という結果になりがちです。
ギャップ分析とは、単なる反省ではなく、
- なぜ前回はそうなったのか
- 今回は何が同じで、何が違うのか
- どの前提が変わっているのか
を言語化する作業です。
これを踏まえて初めて、「今回に合った進め方」や「先に入れておくべき条件」が見えてきます。
フィードバックは「実行中の運用」として設計する
一方で、フィードフォワードだけでは不十分です。
どれだけ事前に設計しても、実行中には想定外のズレが必ず発生します。
そこで必要になるのが、本来の意味でのフィードバック制御です。
間接業務やプロジェクト運営におけるフィードバックは、次のように設計されている必要があります。
- 実行中のアウトプットを定期的に観測する
- 偏差を検知するための指標を決める
- 偏差が出たときの介入先（工程・役割）を明確にする
- 具体的な調整内容を事前に決めておく
- いつまでに正常範囲に戻すかを定義する
ここまで決めて初めて、「運用できる仕組み」になります。
単に「おかしかったら報告してください」では、制御としては弱すぎます。
仕組みは2つ必要で、セットで回す必要がある
ここまでの話を整理すると、手戻りを構造的に減らすためには、2つの仕組みが必要だと分かります。
フィードフォワード（事前設計）
- 過去の知見と今回条件のギャップを分析する
- 進め方や前提条件を事前に最適化する
- 個人の注意ではなく、仕組みとして組み込む
フィードバック（実行運用）
- 実行中のアウトプットを監視する
- 偏差に対して、どこに何を調整するかを決める
- 収束までの時間を含めて運用設計する
この2つをセットで回さない限り、手戻りは一時的に減っても、長期的には減りません。
どちらか一方だけでは、不安定な運用になります。
反省は情報、再発防止は設計
最後に、この記事の核心となる考え方をまとめます。
- 反省そのものは悪くない
- 反省は「情報」として扱うべきもの
- 再発防止は「設計」に落として初めて意味を持つ
制御の原理原則は、決して専門分野だけの話ではありません。
間接業務やプロジェクト運営においても、「確認して注意する」から一歩進んで、「どう設計すればズレにくくなるか」「ズレたときにどう戻すか」を考えることが、本質的な改善につながります。
フィードバックとフィードフォワード。
この2つを意識的に使い分け、セットで回すことができれば、手戻りは個人の頑張りではなく、構造として減らせるようになります。
コメント