相殺フィードバック

TSPの本で「相殺フィードバック」というフレーズがあったのでメモ。

【1】フィードバックは、マネジメントの基本技術の一つだ。
フィードバックがあるからこそ、PDCAのうちCheckとActionが稼動する。

フィードバックはゴールまでの進捗を表す。
フィードバックを受けて、ゴールまで後どれくらいあるか、自分のポジションが分かる。

しかし、フィードバックは諸刃の剣でもある。
相殺フィードバックとは、フィードバックを受けると、問題がどんどん吹き出す現象を指すらしい。
つまり、フィードバックを受けて改善しようとしても、問題が多すぎて制御できない。

TSP本で面白かったのは、IT業界は相殺フィードバックが多いという指摘だ。
よくある例は、結合テスト工程でバグを見つけ始めたら、どんどん膨れ上がってしまって、品質はおろかバグ修正の制御もできなくなってしまうことだろう。

あるいは、顧客からフィードバックが寄せられるけれども、改善要望や障害報告が多すぎて、どれから手をつけたらよいか分からない状況もあるだろう。

特に、ウォーターフォール型開発では、フィードバックに対応する手戻り作業を制御するのはそもそも難しい。
フィードバック作業を裏プロセス、あるいは裏で動く並行プロセスとして隠して実行するしかない。

【2】アジャイル開発では、フィードバックを受け入れる余地がある。
むしろ、顧客からのフィードバックに対応することを、一つの戦略として取り入れている節もある。

でも、アジャイル開発であろうとも、無制限なフィードバックは受け入れがたい。
うまく制御できなければ、単に混乱しているだけだ。

アジャイル開発では、イテレーションあるいはスプリントというタイムボックスで対応できる範囲内でしか、フィードバックを受け入れないようにする手法がある。
この手法のおかげで、イテレーションで実現すべきフィードバックを優先順位付けして、ふるいにかける。
これが本来のマネジメントなのだ。

SW開発で特にフィードバックプロセスを制御しにくい理由は、変更管理というプロセスの難易度が高いからだと思う。
改善要望や障害報告と言う要件から、仕様化して、実装して、テストして、要件が実現されたことを追跡する仕組みが非常に難しいのだ。

チケット駆動開発は、この変更管理プロセスを補完してくれるだろうと直感している。
単にチケットでタスク管理できるだけでなく、チケットを経由して要件からタスク、ソースまで追跡できる仕組みがあるからこそ、フィードバックを追跡できる。

【3】アジャイル開発から派生したプロジェクトファシリテーションでは、KPTというフィードバックプロセスがある。
これは、Keep・Problem・Tryと言う観点でフィードバックを促すプロセスだ。

フィードバックの質を高めるために、KPTを使うのはすごく有効だと思う。
イテレーションの単位でKPTを開発者と行ってみると、イテレーションをこなすたびに、KPTにあるイシューが変化しているのが分かる。

KPTがうまくいっている時の流れは、Problemにあがった問題点がTryの対策に変わり、その対策が成功したら一つのノウハウとしてKeepに現れること。
現場リーダーとしては、この流れにのせるためにフィードバックを使いたいのだ。

でも、KPTがうまくいかない場合は、Problemにいつも同じ問題が滞留したり、Tryに実現不可能な対策、あるいは忙しくて忘れ去られた対策が放置されがちになる。

現場リーダーは、フィードバックプロセスが何故うまく稼動しないか、観察しなければならない。