ミスのフィードバック展開

いいか、しんのすけ。

制御をかじった人が感じるズレに、

間接業務の『ミスのフィードバック展開』がある。

大事なことではあるが、多くの場合“フィードバック制御”として運用されていない。

フィードバック制御は“実行中”に、偏差を見て介入し、収束させる運用だからな。

プロジェクトが終わった後の学びは、次回の プロジェクトに、フィードフォワード として前提条件や仕組みに落とされたときに価値が出るんだ。

過去プロジェクトの知見と、今回のプロジェクトとの差分（ギャップ）を理解し、進め方や条件を先に設計して手戻りを減らす、ということだ。

ここを飛ばして「前回失敗したから注意しよう」だけでは、確認コストだけが増えて同じ轍を踏むんだ。

確認だけでは制御にならない。そして、フィードバックとは『遅れ』があることを前提としている。

どの指標を監視し、どこに介入するか、収束までに許容される時間まで決めて初めてまともに運用できるものになるんだ。

■フィードフォワード（事前設計）

過去知見×今回条件におけるギャップ分析し、

進め方/条件を事前に最適化し仕組みとする。

■フィードバック（実行運用）

実行中アウトプットを監視し、偏差に対し、どこへ何を調整するか、いつまでに回すかを決めた仕組みとする。

仕組みは2ついる。

そして、その2つをセットで回さない限り、手戻りは構造的に減らないんだ。

原理原則は、なにも専門分野限ったことではない。

反省は情報、再発防止は設計という理解が大事だぞ。

https://pbs.twimg.com/media/G8BLhQ-aYAAVL8X.jpg

フィードバックは、実行中にズレを確認し、しかるべき状態に戻そうと介入すること

フィードフォワードは、終了後に分析し、その結果を次回の仕組みに組み込むこと

プロセス全体をものすごく長く捉えればどちらも同じようなものだと考えていたが、上記のように別物として考えることもできる。

フィードバックは、適宜発動されるものであり、アドホックな（アドリブな）要素を含む

フィードフォワードは、システム作りに反映されるものであり、恒常的（少なくとも可塑的）な要素を含む

行動・行為への介入にはこの二つのアプローチがある