以下はSoftware Frictionに寄せられた反応の一部です。

類似のトピックを扱ったブログ

Laurie TrattがWhat Factors Explain the Nature of Software?という記事を書いており、こちらでも摩擦というトピックに触れています。

メールとコメント

私は米海兵隊の歩兵将校で、摩擦についてはよく話し合っています。クラウゼヴィッツを読まれているなら、興味を持たれるかもしれない一冊が『Marine Corps Doctrinal Publication 1 (MCDP 1) Warfighting』（PDFへのリンクは末尾にあります）です。すぐに読める分量です。

私たちは基本的にはあなたが示されたような形で摩擦に向き合っています。キャリアの早い段階で摩擦について教育することで、経験を積むにつれてその解決策を見つけられるよう心構えを作るのです。

あなたが触れていなかったものの、ソフトウェアチームにも非常に有効だと思う、私たちがよく使っている戦術の一つに「hot washes（ホットウォッシュ）」があります。基本的に、訓練であれ実戦であれ作戦直後に主要メンバー全員で集まり、何がうまくいったか、何がうまくいかなかったか、そして今後のパフォーマンス向上のために標準運用手順（Standard Operating Procedures）を更新すべきかどうかを検討するものです。これを定期的に行うことで、他に適当な言い方が思いつきませんが、いわば「自尊心の痛み（ego sting）」も和らぎます。同僚の前で公の場でミスを指摘されるのはつらいものですが、他のことと同じで繰り返すうちに楽になっていきます。また、定期的なホットウォッシュはチームメンバー間の共通理解を築き、コミュニケーションを円滑にし、摩擦を減らすのにも役立ちます。

私は「hot washes」はポストモーテムとどう違うのか尋ねました。その返答は次のとおりです：

一番の違いは（もしかするとアジャイル界隈では一般的で私が知らないだけかもしれませんが）、通常「scribe（書記）」が決まったフォーマット（一般的にはTopic-Discussion-Recommendation〈トピック-議論-提言〉という形式）で要点を記録し、それを後世のために保存して部隊内、あるいは多くの場合は軍全体のレベルでライブラリに蓄積する点だと思います。これにより、過去に自分たちが犯したミスを参照できるだけでなく、これから直面する問題と似た問題に何年も前に直面した部隊のミスを参照することもできます。海兵隊教訓センター（Marine Corps Center for Lessons Learned）が、軍全体レベルのライブラリを管理しています。

大規模なソフトウェア企業と比べて私たちにやや特有だと思う課題の一つは、人の入れ替わりが激しいことです。通常、2年ほどで部隊から異動していきます。そのため、知識をスタッフの頭の中だけで持続的に蓄えておくのは難しく、効果を持たせるには書き残しておく必要があるのです。