クラウゼヴィッツは著書戦争論の中で、摩擦を軍事理論と現実とのズレとして定義している。

戦略においては、すべてはきわめて単純である。だが、それゆえにきわめて容易というわけではない。戦争においてすべてはきわめて単純だが、最も単純なことすら困難なのだ。こうした困難が積み重なり、戦争を見たことがない者には到底想像できない摩擦を生み出す。

摩擦の一例として、天候を挙げてみよう。あるところでは霧のせいで敵を適時に発見できず、砲台は適切な瞬間に射撃できず、報告は司令官に届かない。また別のところでは、雨のせいで大隊は到着できず、別の大隊は本来なら3時間で済むはずの行軍に8時間もかかったために定刻に間に合わず、騎兵はぬかるみに足を取られて効果的な突撃ができない。

これを読んで以来、ソフトウェア開発のあらゆる場面で「摩擦」を見出すようになった。

• ベンダーのAPIが思った通りに動かない。あるいは以前は動いていたのに、いつのまにか仕様が変わっている。
• バグ。セキュリティアラート。依存関係をアップデートしたら何かが壊れる。
• 誰かが病欠する。誰かの子どもが病気になる。誰かが退職する。誰かがバーニングマンに行くために休む。
• 要件が曖昧だったり、開発の途中でクライアントが要望を変えてきたりする。開発が終わったあとに要望を変えてくることさえある。
• ノートPCが壊れる、あるいは盗まれる。Slackが一日中ダウンする。
• ツールが壊れる。WordがすべてのフォントをWingdingsに変えてしまう。（これは実際に起こることだ）

このリストは網羅的なものではない。そもそも摩擦の発生源をすべて列挙することなど不可能だ。

摩擦のいくつかの性質

摩擦は、時間的なスパンが長く、スコープが大きいほど問題になる。単純に、うまくいかなくなる可能性のあることが増えるからだ。

摩擦はそれ自体で複合的に増幅する。2つのつまずきは、1つのつまずきの2倍以上に厄介だ。ほとんどのシステムはある程度のレジリエンスを備えており、一つの問題の周りでなんとか適応できるが、その分、次の問題への対処がより困難になるからだ。

（これは「金曜日にデプロイするな」という賛否両論のある考え方の一因でもある。デプロイ時のミスやロールバックの必要性がもたらす摩擦は、週末で人々がオフラインになるという摩擦によってはるかに悪化する。この論争は「やるべきではない」と言う人々と、プロセスへの体系的な変更を主張する人々のあいだで起きている。いずれにせよ目標は摩擦が問題を引き起こさないようにすることであり、論点はそのための具体的な方法なのだ。）

摩擦への対処自体が、別の摩擦を生むこともある。たとえばセキュリティアラートを解消するために依存関係をアップデートしたら、新バージョンが微妙に後方互換でなかった、といった具合だ。しかもそれを別のタイムゾーンにいるチームメイトと一緒に直そうとしているとしたら……。

摩擦への対処

摩擦は避けられず、完全になくすことはできない。そもそも完全に予測することすら不可能だと思う。だが、摩擦を減らすためにできることはあるし、計画をよりレジリエントなものにすることもできる。軍事のプランナーがどうやって摩擦を減らしているのかは知らない。ここで挙げるのは、ソフトウェア開発で見てきた方法だ。

より小さなスコープと短いイテレーション

これは「ウォーターフォール」に対する「アジャイル」の根拠だ。タイムラインが短ければ、摩擦が複合的に増幅する余地は少なくなる。やることが多く、期間が長くなるほど不確実性は増し、うまくいかなくなる箇所も増える。ただし、小さなスプリントを次々と連続して行えば、そこにも摩擦の入り込む余地はある。その場合は、ただ非効率なマラソンを走っているだけになってしまう。

より大きな自律性

摩擦とはモデルと現実とのズレであり、高い視点からはモデルしか見えない。現場で賢明な判断を下せるだけの自律性が人々にあれば、摩擦からの回復はより容易になる。だが、自律性が大きすぎて孤立してしまうと、事態をかえって悪化させることもある。かつて、大きな裁量を与えられたエンジニアが「遅すぎる」という理由でデータベースを削除してしまうのを見たことがある。

冗長性

たとえば倉庫に置いてある予備の機材、高いバス係数、あるいはスケジュールに余裕を持たせることなどがこれにあたる。そうしておけば、何か問題が起きてもより迅速に修正でき、別の問題が重なって悪化する余地を減らせる。ただしこれは通常時の効率を犠牲にすることになるため、プロジェクトは自然と冗長性を削る方向へ流れていく。

より良い計画

優れた計画ですべての摩擦の発生源を特定できるわけではないが、計画を立てればより多くの発生源を見つけられる。それ自体が大きな利点だ。たとえば形式的仕様を書けば、設計上の問題が露わになったり、未知の未知を既知の未知へと変えたりできる（そうなれば、より詳細に検討できるようになる）。これは、不意を突かれるのが5つの場合と15つの場合の違いを生む。私が形式手法にこれほど強気なのも、そこに理由がある。

自動化

これは諸刃の剣だ。一方で、プロセスを自動化すれば人がミスを犯す余地は減る。他方で、自動化されたプロセス自体にもバグがありうるし、それが新たな摩擦の発生源となる。また、自動化が長く稼働すれば、人々はそれがどう動いているのか、何をしているのかの全体像を忘れてしまい、いざ壊れたときに誰も対処できないという事態に陥る。自動化は経験を犠牲にすることがあるのだ。

経験

多くの問題に遭遇すればするほど、事前に問題を予見できるようになり、問題からのリカバリーの経験も増える。残念ながら、これはほとんど苦労して学ぶしかない。だが、一つ近道があるとすれば……。

ゲーミング

このトピックについて面白い本に、海軍大学のFundamentals of War Gamingがある。その本では、ウォーゲーミングには2つの目的があると論じられている。状況がどのように展開しうるかについての情報を集めることと、指揮官に安全な環境で（ある程度の）経験を積ませることだ。訓練生がウォーゲームの中で「天候が計画を台無しにしうる」ことを学べば、実際の人命をかけてそれを学ぶ必要はなくなる。同様に、削除してしまったテーブルを必死に復旧させようとしている最中ではなく、平時にデータベースのバックアップを取り出す練習をしておきたい。私の理解では、セキュリティチームも運用チームも、この理由からゲーミングを活用している。

（同時に、ゲームの実行や参加には時間を割かなければならず、その意味では冗長性を追加するのと同様に非効率でもある。）

チェックリストとランブック

特定の問題に対処するための暗黙知を形式化する方法だ。

摩擦について考えている問い

摩擦の発生源を細かく分類することに意味はあるだろうか？ たとえばツールの問題を「社会的」摩擦ではなく「技術的」摩擦と呼ぶことに、何か実用的な意味はあるのか？

他の分野では摩擦にどう対処しているのだろう？ 建設業界の何人かに摩擦について聞いてみたところ、概念自体には心当たりがあるものの、それを表す言葉はないとのことだった。イベントプランナー、看護師、士官たちはどうだろうか？

「Xをやれば摩擦の影響を減らせる」と「Xをやらない方が今は効率的だ」のあいだで、どう適切なバランスを見つければいいのか？

摩擦は個人にとっても重要なのだろうか？ チームの他の誰も考えていなくても、自分一人でプロジェクトにおける摩擦について考えることに意味はあるのか？

フィードバックをくれたJimmy Koppelに感謝する。この投稿が気に入ったら、ぜひ私のニュースレターに参加してほしい。毎週新しいエッセイを書いている。

私は企業向けに形式手法のトレーニングを行い、ソフトウェア開発をより速く、より安く、より安全にする手伝いをしている。詳細はこちら。

更新 2024-05-30

この投稿に寄せられたコメントをいくつかこちらにまとめた。