- 「素早く動くこと」が実務上の必要性を超えて、真剣さと野心の証拠になるにつれ、慎重な検討は推進力を妨げる態度として扱われる
- 本当のスピードは、業務・制約・依存関係を理解し、明確に決定したうえで実行するときに生まれるが、多くの組織は曖昧な要求事項と未完了の意思決定をスピードとして包み隠す
- 理解の段階を急ぐと、手戻りは「反復」、混乱は「整合」、防げたはずの失敗は「学習」として記録され、不信感を持たれるシステムと迂回手順が事業の中核構造として固まっていく
- 緊急性とは重要な仕事に実際の時間的制約がある状態だが、性急さとは明確さを確保する負担なしに、行動から感情的な安堵を得ようとする状態である
- きちんと仕事をするには、理解して決定したあと十分に検討してから動くべきであり、思考・文脈・責任を飛ばした代償は、壊れたシステム、疲弊したチーム、離脱した顧客、そして長期的な運用上の傷となって返ってくる
スピードが進歩と誤認される過程
- 迅速なリリース・対応・採用・拡大・転換は、それ自体が野心と真剣さの証拠のように扱われる
- スピードを落として考えようという要請は、推進力を妨げるものと見なされる
- 構造的に脆弱な計画を指摘すると、否定的な態度として受け止められる
- スピードは、判断の規律がなくても動いている感覚を与える組織的な麻薬のように機能する
- 誰もが忙しく緊急だと感じ、活動そのものを前進の証拠にできる
- しかしスピードと呼ばれているものの多くは、名前を変えただけの焦りである
- 本当のスピードは、業務と制約が明確で、有能な担当者がきれいに完了した決定に従って実行し、再議論を繰り返さないときに可能になる
- 一般にスピードと呼ばれる状況には、曖昧な要求事項、未完了の意思決定、検討されていない依存関係、不十分な文脈が残っている
- 決まっていない問題は次の担当者が解決してくれると期待し、成果物が壊れると驚く構造である
- 考えるプロセスこそが最も高くつく部分だという前提で作ったために失敗する
- こうしたパターンはソフトウェアだけでなく、運用・管理・採用・物流・カスタマーサービス・製品開発でも、活動を前進と勘違いするときに現れる
- 理解すべき段階を急いだあと、結果の収拾に10倍の時間を費やしながら、記録上の意味もすり替わる
- 最初の性急な作業は「迅速な実行」になる
- 収拾は「予期しなかったこと」、手戻りは「反復」、混乱は「整合」、防げたはずの失敗は「学習」になる
- 小さな決定のたびに理解よりスピードを選ぶと、誰も信頼しないシステム、理解できない手順、望まない会議、信じていないダッシュボードが積み上がる
- 一時的な回避策は、やがて事業を支える必須構造になる
- その後の「モダナイゼーション」も、スピード崇拝はそのままに、目に見える混乱だけを置き換えがちである
急がずに正しく動く方法
- スピードを落とすとは、ゆっくり働くことではなく、仕事を明瞭にするプロセスを省略しないということだ
- 実際に何を作ろうとしているのか、誰が依存しているのかを確認しなければならない
- 前提が間違っていれば何が壊れるのか、すでに何を知っていて、何を知らないふりをしているのかを見る必要がある
- 過去の失敗点と、成功に必要な条件も確認しなければならない
- こうした基本的な問いは、動くことから得られる即時の満足を消し去り、緊急性やPowerPointの陰に隠れられなくする
- 仕事を実際に理解し、細部の決定に責任を負わなければならないため、回避の対象になりやすい
- スピードは、決定を曖昧なままにし続け、詳細を他人の非常事態として押し付けられるようにする
- 非常事態が起きると、より速い修正・採用・交代・リリースを再び解決策にし、同じ問題が治療法のように繰り返される
- 緊急性は、重要な仕事に実際の時間的制約があるときには適切だが、性急さは明確さの負担なしに行動から感情的な安堵を得ようとするときに生じる
- スピードを批判するからといって、わざと遅く動いたり、すべての決定を会議に変えたりしようというわけではない
- 思慮深さを証明するために、デプロイ基盤を自作するのに6か月を費やす必要もない
- 最初から正しく遂行できるだけ、仕事を尊重しようという立場である
- 正しい順序は理解 → 決定 → 十分な検討 → 実行である
- 順序を逆にすると、壊れたシステム、疲弊したチーム、静かに離れていく顧客という代償を払うことになる
- 原因を改めて理解する忍耐がないために、何年も回避し続けなければならない運用上の傷も残る
- 市場の変化、競争、厳しい顧客、小さなチーム、逼迫した予算、閉じつつある機会は、実際の制約であり得る
- しかし、動き出す前に状況を理解するという、より遅く困難な作業を避ける口実として使われることもある
- より良い方法は、落ち着きを保ちながらも決定とリリースを続けることである
- パニックを真剣さと、あらゆる停止を弱さと、動きそのものを前進と勘違いしない
- 思考・明確さ・文脈・責任を省略すれば一時的には速くなれるかもしれないが、システムと保守担当者はその結果を抱え続けることになる
- 一部の仕事は、急ぐのをやめて初めて速くなれる
1件のコメント
Hacker Newsの意見
ゆっくりやれば滑らかになり、滑らかなら速くなる
スピードについて学んだこととして、人は測定しないか、目先で楽な項目だけを誤って測定しがちだということがある。正しい測定は数値で客観化されるが、自己省察が苦手な人のように、測定そのものをきちんとできない人もいる。推測した数値は80%以上間違っており、桁単位で外れやすい。測定から生まれる小さな改善は予想外に大きく積み上がり、さらに速くなる最も確実な方法は、技術と手法を変えることだ。採用は遅く、遅延したプロジェクトに人を追加するとさらに遅くなる。また、技術スタックの下位レイヤーを改善するほど、速度と柔軟性を同時に得られ、それを活用して規模を拡大できる
技術的に間違っていなくても、顧客の問題に対する実用的な解決策を見つけるのに6週間ではなく6か月かけて顧客を疲弊させれば、プロジェクトは失敗しうる。顧客の視点では、スピードは機能であり経済的価値でもある
テキサスの8月の午後に壊れたエアコンを直そうと技術者を呼ぶときの気持ちを思い浮かべればよい。複雑で不確実な分野では、素早く反復する手順が重要であり、速すぎるかどうかは顧客が示す反応から判断するほうがよい
エアコン修理は緊急修正に近く、より適切な比喩は、テキサスの暑さを避けるために家を数日で建て、その後、断熱材や固定されていない壁、外部配線、家の下へ流れ込む配管を6年間修理し続ける状況だ
事業上重大な障害では、役職に関係なく何でも試して混乱を大きくしがちで、協力して問題を理解してから解決した場合よりも、全体の時間と影響範囲が大きくなった。少し息を整え、緊急性まで含めた問題全体を把握する落ち着いて着実なアプローチのほうが、結局は速かったし、顧客に進捗を伝えて不安を和らげることとも両立できる
スピード崇拝はベンチャー投資の時間軸から生まれる。ベンチャー投資家には出資者へリターンを返す期限があるため、そのスケジュール内で10倍成長できると信じさせなければ関心を得られない
そのスケジュールに本気で縛られると、技術的現実を無視した恣意的な期限を設定し、その期限に間に合わなかったという理由でプロジェクトを潰す人になりやすい
狂ったように成長しなければ死ぬ構造と目標が合わないなら、ベンチャー投資を受けるべきではない。急がずに開発したいなら、検証済みのプロダクトマーケットフィット(PMF)と優れた営業チームが成長曲線を担うスタートアップを選ぶべきだ
ベンチャー投資を受けたスタートアップには潤沢な現金のバッファと追加支援の可能性があり、むしろ楽だった。投資家は株式市場より高いリターンを、創業者はFAANGで働くより大きな富を求めるため、リスクに見合う報酬への圧力は投資方式に関係なく生じる
皮肉屋だった陸軍大佐は、「十分に短い時間単位では、周期運動でさえ進展に見える」「ゆっくりやれば滑らかになり、滑らかなら速くなる」とよく言っていた
計算上も、100フィートの遅いカーブで時速1マイル上げるより、4分の1マイルの直線で時速1マイル上げるほうが得だ
防毒マスクを外して目をこすりたい衝動を抑えられたのは、ゆっくりした反復訓練が自動化された素早い行動につながったからだ。弾倉交換やボルトフォワードアシストの操作も同じ原理である
エンジニアリングの観点では、ゆっくり進めるほど滑らかになり速くなるが、営業の観点では遅いものは単に遅いだけ。6か月後により高い品質を約束している間に、競合が5〜10年もの希少な契約を取ってしまえば、ほかの仕事に集中するどころか、配置先のないチーム全体を解雇しなければならないかもしれない。
会社が正しく作る時間を与えながら、最初から成果を求めることが失敗点になる。インフラ、デザインシステム、コンポーネントライブラリ、システム設計に6か月や1年を費やして見せられる成果がなければ、費用請求や追跡がおかしくなり、今後は開発が非常に速くなるという約束は経営陣には通じない。
徹底して責任を持ってゆっくり進めることと、無能だから遅いことは区別すべきだ。市場圧力は現実であり、遅いままのチームは消える。遅さが滑らかさと速さにつながることもあれば、単に遅いだけのこともあるので、その違いを知ることが核心だ。
キャリアの初期に、経営陣はストレスを表に出さないと、こちらが物事を真剣に受け止めていないと考える場合があることに気づいた。「切迫感が感じられない」といった言葉は、当時の私の精神を大きく揺さぶった。
「動きと進捗を混同するな。ロッキングチェアは動き続けるが、前には進まない」 — Alfred A. Montapert
文章に同意するのは難しくないが、議論から締め切りが完全に抜け落ちている。速度への要求は常に真空から生まれるわけではなく、不当なら立ち向かうべきだろうが、現実的に常に選択肢があるのかは疑問だ。
期限に合わせることだけを目指して急ぐと、当面は速く見えても、チームが出せる最善より劣る結果になり、あとでひどい成果物を片付けるためにより多くの時間を費やすことになる。あらゆる状況にのんびりさを適用しようという意味ではなく、常に速く動いているのに目標をほとんど達成できない環境では、急ぐこと自体が失敗の原因なのかを検討せよという意味だ。
FedExが配送スタッフ用の新しいダッシュボードを展開したあと、MacBookの受付手続き中にシステムが止まり、スタッフは手動処理後に領収書を渡したが、誤ったラベルが印刷された。その結果、AppleにノートPCが届かず、数週間にわたって複数のスタッフに状況を繰り返し説明しなければならず、1か月後にAppleが5千ドルの新しいノートPCを送らなければならなかった。任意の期限のために急いで作ったソフトウェア1つが膨大な時間と費用を浪費した事例であり、速度を落とそうというのは心理的な安楽さではなく、現在と未来の混乱を防ごうという意味だ。
速さと速度ベクトルは違う。100階建てのビルから落ちている人は、ものすごい速さで飛んでいると思うかもしれないが、目標に向かう速度ベクトルは、多くの依存関係を熟考し、正しく航行するときに生まれる。
大企業ではそのどちらも重要ではなく、成果物の大半はひどいものだ。締め切りは年次の業績評価に合わせて計画され、経営陣が好む人々が正しい指標を達成したという成功談を作ったり、マイルストーンを変更したりして報酬を与える。その成功を見事に監督したという理由で、経営陣自身も報酬を受ける。
キャリアが長くなるほど、この原則はより明確になる。ただし、若い同僚がまだそれに気づかないまま自分の管理階層の上に立つと、問題になり得る。
「自分が出した最大の成果の一部は、書かないと決めたコードだった」といった言葉で内省を促すことがある。