1 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • 「素早く動くこと」が実務上の必要性を超えて、真剣さと野心の証拠になるにつれ、慎重な検討は推進力を妨げる態度として扱われる
  • 本当のスピードは、業務・制約・依存関係を理解し、明確に決定したうえで実行するときに生まれるが、多くの組織は曖昧な要求事項と未完了の意思決定をスピードとして包み隠す
  • 理解の段階を急ぐと、手戻りは「反復」、混乱は「整合」、防げたはずの失敗は「学習」として記録され、不信感を持たれるシステムと迂回手順が事業の中核構造として固まっていく
  • 緊急性とは重要な仕事に実際の時間的制約がある状態だが、性急さとは明確さを確保する負担なしに、行動から感情的な安堵を得ようとする状態である
  • きちんと仕事をするには、理解して決定したあと十分に検討してから動くべきであり、思考・文脈・責任を飛ばした代償は、壊れたシステム、疲弊したチーム、離脱した顧客、そして長期的な運用上の傷となって返ってくる

スピードが進歩と誤認される過程

  • 迅速なリリース・対応・採用・拡大・転換は、それ自体が野心と真剣さの証拠のように扱われる
    • スピードを落として考えようという要請は、推進力を妨げるものと見なされる
    • 構造的に脆弱な計画を指摘すると、否定的な態度として受け止められる
  • スピードは、判断の規律がなくても動いている感覚を与える組織的な麻薬のように機能する
    • 誰もが忙しく緊急だと感じ、活動そのものを前進の証拠にできる
    • しかしスピードと呼ばれているものの多くは、名前を変えただけの焦りである
  • 本当のスピードは、業務と制約が明確で、有能な担当者がきれいに完了した決定に従って実行し、再議論を繰り返さないときに可能になる
  • 一般にスピードと呼ばれる状況には、曖昧な要求事項、未完了の意思決定、検討されていない依存関係、不十分な文脈が残っている
    • 決まっていない問題は次の担当者が解決してくれると期待し、成果物が壊れると驚く構造である
    • 考えるプロセスこそが最も高くつく部分だという前提で作ったために失敗する
  • こうしたパターンはソフトウェアだけでなく、運用・管理・採用・物流・カスタマーサービス・製品開発でも、活動を前進と勘違いするときに現れる
  • 理解すべき段階を急いだあと、結果の収拾に10倍の時間を費やしながら、記録上の意味もすり替わる
    • 最初の性急な作業は「迅速な実行」になる
    • 収拾は「予期しなかったこと」、手戻りは「反復」、混乱は「整合」、防げたはずの失敗は「学習」になる
  • 小さな決定のたびに理解よりスピードを選ぶと、誰も信頼しないシステム、理解できない手順、望まない会議、信じていないダッシュボードが積み上がる
    • 一時的な回避策は、やがて事業を支える必須構造になる
    • その後の「モダナイゼーション」も、スピード崇拝はそのままに、目に見える混乱だけを置き換えがちである

急がずに正しく動く方法

  • スピードを落とすとは、ゆっくり働くことではなく、仕事を明瞭にするプロセスを省略しないということだ
    • 実際に何を作ろうとしているのか、誰が依存しているのかを確認しなければならない
    • 前提が間違っていれば何が壊れるのか、すでに何を知っていて、何を知らないふりをしているのかを見る必要がある
    • 過去の失敗点と、成功に必要な条件も確認しなければならない
  • こうした基本的な問いは、動くことから得られる即時の満足を消し去り、緊急性やPowerPointの陰に隠れられなくする
    • 仕事を実際に理解し、細部の決定に責任を負わなければならないため、回避の対象になりやすい
  • スピードは、決定を曖昧なままにし続け、詳細を他人の非常事態として押し付けられるようにする
    • 非常事態が起きると、より速い修正・採用・交代・リリースを再び解決策にし、同じ問題が治療法のように繰り返される
  • 緊急性は、重要な仕事に実際の時間的制約があるときには適切だが、性急さは明確さの負担なしに行動から感情的な安堵を得ようとするときに生じる
  • スピードを批判するからといって、わざと遅く動いたり、すべての決定を会議に変えたりしようというわけではない
    • 思慮深さを証明するために、デプロイ基盤を自作するのに6か月を費やす必要もない
    • 最初から正しく遂行できるだけ、仕事を尊重しようという立場である
  • 正しい順序は理解 → 決定 → 十分な検討 → 実行である
    • 順序を逆にすると、壊れたシステム、疲弊したチーム、静かに離れていく顧客という代償を払うことになる
    • 原因を改めて理解する忍耐がないために、何年も回避し続けなければならない運用上の傷も残る
  • 市場の変化、競争、厳しい顧客、小さなチーム、逼迫した予算、閉じつつある機会は、実際の制約であり得る
    • しかし、動き出す前に状況を理解するという、より遅く困難な作業を避ける口実として使われることもある
  • より良い方法は、落ち着きを保ちながらも決定とリリースを続けることである
    • パニックを真剣さと、あらゆる停止を弱さと、動きそのものを前進と勘違いしない
    • 思考・明確さ・文脈・責任を省略すれば一時的には速くなれるかもしれないが、システムと保守担当者はその結果を抱え続けることになる
    • 一部の仕事は、急ぐのをやめて初めて速くなれる

1件のコメント

 
GN⁺ 2 시간 전
Hacker Newsの意見
  • ゆっくりやれば滑らかになり、滑らかなら速くなる
    スピードについて学んだこととして、人は測定しないか、目先で楽な項目だけを誤って測定しがちだということがある。正しい測定は数値で客観化されるが、自己省察が苦手な人のように、測定そのものをきちんとできない人もいる。推測した数値は80%以上間違っており、桁単位で外れやすい。測定から生まれる小さな改善は予想外に大きく積み上がり、さらに速くなる最も確実な方法は、技術と手法を変えることだ。採用は遅く、遅延したプロジェクトに人を追加するとさらに遅くなる。また、技術スタックの下位レイヤーを改善するほど、速度と柔軟性を同時に得られ、それを活用して規模を拡大できる

    • ボート競技の選手たちは、摩擦なく動いている状態を**スイング(swing)**と呼ぶ。ブランコを無理に動かすのではなく、重力と運動量に身を任せるように、ボートも本来は速く進もうとするので、必死にもがいて邪魔をしないことが重要だ。過度な努力は速度を損ない、スイングは努力している状態ではなく、すでに到達している状態である — Houghton Mifflin, Mind Over Water
    • 一部の人が自己省察できない理由は何なのか、本当に自己省察そのものが不可能な人がいるのか理解しにくい
    • コードベースで初めてまともに測定する人なら、小さな改善にとどまらない。たいていは大きく明白な改善機会が至るところにある
    • すべてを測定できるわけではなく、何を測定するかを選ぶこと自体が、バイアスを持ち込む編集上の判断である
  • 技術的に間違っていなくても、顧客の問題に対する実用的な解決策を見つけるのに6週間ではなく6か月かけて顧客を疲弊させれば、プロジェクトは失敗しうる。顧客の視点では、スピードは機能であり経済的価値でもある
    テキサスの8月の午後に壊れたエアコンを直そうと技術者を呼ぶときの気持ちを思い浮かべればよい。複雑で不確実な分野では、素早く反復する手順が重要であり、速すぎるかどうかは顧客が示す反応から判断するほうがよい

    • ソフトウェアの顧客は、イベントアプリを発注した会社、ECプラットフォームを作るWalmart、AWSサービスを使う開発者、一般のWindows・iOSユーザーのように非常に多様だ。顧客が品質や信頼性、解決策をコントロールしているわけでもないのに、開発が速すぎるかを事前に知る方法はない
      エアコン修理は緊急修正に近く、より適切な比喩は、テキサスの暑さを避けるために家を数日で建て、その後、断熱材や固定されていない壁、外部配線、家の下へ流れ込む配管を6年間修理し続ける状況
    • この記事も、本当のスピードは作業と制約を理解し、熟練した人々が明確な判断を下して、繰り返し議論せず実行するときに生まれると見ている。計画と合意を妨げる性急さはミスとコストを増やし、プロジェクト・信頼・士気を損ないやすく、パニック状態をデフォルトにすると迅速な成果にも失敗する
    • 技術者が1週間に6回来て、そのたびに直ったと言ったのに、エアコンが壊れ続ける状況も考えるべきだ
    • この記事が緊急性そのものを無視しようと言っているのかは疑問であり、実際に緊急性を無視した会社や人がどれほどいるのかも気になる
      事業上重大な障害では、役職に関係なく何でも試して混乱を大きくしがちで、協力して問題を理解してから解決した場合よりも、全体の時間と影響範囲が大きくなった。少し息を整え、緊急性まで含めた問題全体を把握する落ち着いて着実なアプローチのほうが、結局は速かったし、顧客に進捗を伝えて不安を和らげることとも両立できる
    • まず実用的な解決策の基準を定義する必要がある。6週間で十分だという判断も6か月と同じくらい主観的であり、最初は使えそうに見えた成果物を更新し続けるなら、顧客が何回まで我慢するのか、7週目の問題はどれほど深刻なのかも考えるべきだ。ウォーターフォールモデルをアジャイルに変えた結果、絶えず更新される実用的な解決策の中で暮らすことになったわけだ
  • スピード崇拝はベンチャー投資の時間軸から生まれる。ベンチャー投資家には出資者へリターンを返す期限があるため、そのスケジュール内で10倍成長できると信じさせなければ関心を得られない
    そのスケジュールに本気で縛られると、技術的現実を無視した恣意的な期限を設定し、その期限に間に合わなかったという理由でプロジェクトを潰す人になりやすい

    • その期限はベンチャー投資家にとって恣意的ではなく、資金コストが決める。市場や技術の事情は重要ではなく、利益、売上、市場シェアのいずれかが十分な速さで成長しなければ、損失処理して会社を清算する
      狂ったように成長しなければ死ぬ構造と目標が合わないなら、ベンチャー投資を受けるべきではない。急がずに開発したいなら、検証済みのプロダクトマーケットフィット(PMF)と優れた営業チームが成長曲線を担うスタートアップを選ぶべきだ
    • ベンチャー投資を受けた会社は、会社全体のごく一部にすぎない。代替であるデットファイナンスには、期限と切迫感がむしろはるかに多い
    • ベンチャー投資なしで自力成長する会社の切迫感は、さらに大きい場合がある。早い段階で大当たりしなければ、早く納品して売上を作り、まともな給与を受け取りたいというプレッシャーは現実的で、人員を増やして業務を分担することも難しい
      ベンチャー投資を受けたスタートアップには潤沢な現金のバッファと追加支援の可能性があり、むしろ楽だった。投資家は株式市場より高いリターンを、創業者はFAANGで働くより大きな富を求めるため、リスクに見合う報酬への圧力は投資方式に関係なく生じる
    • 恣意的なプロジェクトのマイルストーンやスケジュールも有用だ。プロジェクトを潰す基準として使う必要はないが、外部の変化と比べて努力の成果を示す基準になる
    • 技術的現実だけでなく、価値を持って取り組むべきほとんどすべてを無視させるという点で、ベンチャー投資は世界のがんのようなものだ
  • 皮肉屋だった陸軍大佐は、「十分に短い時間単位では、周期運動でさえ進展に見える」「ゆっくりやれば滑らかになり、滑らかなら速くなる」とよく言っていた

    • トラックレースの急カーブでは遅く感じられて、もっと速く押し切りたくなるが、むしろさらに減速して、滑らかで制御された状態で正確に曲がったほうが、その後の加速が良くなる。遅く入って速く出るという原則だ
      計算上も、100フィートの遅いカーブで時速1マイル上げるより、4分の1マイルの直線で時速1マイル上げるほうが得だ
    • 基礎軍事訓練で教官たちはその言葉を絶えず繰り返していた。士官教育課程中、催涙弾の粒を加熱するコンクリート製バンカーに入ると目が激しく焼けるように痛んだが、意識的に考える前に防毒マスクを取り出して装着し、フィルターと除染クリームの手順まで正確に実行した
      防毒マスクを外して目をこすりたい衝動を抑えられたのは、ゆっくりした反復訓練が自動化された素早い行動につながったからだ。弾倉交換やボルトフォワードアシストの操作も同じ原理である
  • エンジニアリングの観点では、ゆっくり進めるほど滑らかになり速くなるが、営業の観点では遅いものは単に遅いだけ。6か月後により高い品質を約束している間に、競合が5〜10年もの希少な契約を取ってしまえば、ほかの仕事に集中するどころか、配置先のないチーム全体を解雇しなければならないかもしれない。
    会社が正しく作る時間を与えながら、最初から成果を求めることが失敗点になる。インフラ、デザインシステム、コンポーネントライブラリ、システム設計に6か月や1年を費やして見せられる成果がなければ、費用請求や追跡がおかしくなり、今後は開発が非常に速くなるという約束は経営陣には通じない。

    • 緊急性が実在することはあり得るが、計画を省いても速くはならない。数時間だけでも計画していれば、数週間分の無駄な作業や手戻りを防げたというケースは多い。
    • 短期的には急ぐほうが正しく見えるが、切り落とした角はいずれ追いついてくる。営業チームが大型契約のために、構造を考える時間もなく特殊機能を押し込ませたり、テスト完了前にリリースを求めたりした経験があればよく分かる。相手が契約1件では勝っても、長期戦まで勝つことはまれだ。
      徹底して責任を持ってゆっくり進めることと、無能だから遅いことは区別すべきだ。市場圧力は現実であり、遅いままのチームは消える。遅さが滑らかさと速さにつながることもあれば、単に遅いだけのこともあるので、その違いを知ることが核心だ。
  • キャリアの初期に、経営陣はストレスを表に出さないと、こちらが物事を真剣に受け止めていないと考える場合があることに気づいた。「切迫感が感じられない」といった言葉は、当時の私の精神を大きく揺さぶった。

    • 本当の経営とは、競合する選択肢の間で限られたリソースをどう配分するかを決める仕事だ。しかし多くのマネージャーやメンバーは、経営を人をコントロールすることだと捉えており、実際にはもっと熱心に働いているかを監視する監督者の役割にとどまっている。
    • 私もまったく同じことを言われたが、揺さぶられるというより、見かけと現実を区別できない人がCEOであってはならないと判断した。
    • 不安なマネージャーは、相手が不安そうにしていない様子にも不安を覚えがちだが、そうでないマネージャーも多い。
  • 「動きと進捗を混同するな。ロッキングチェアは動き続けるが、前には進まない」 — Alfred A. Montapert

  • 文章に同意するのは難しくないが、議論から締め切りが完全に抜け落ちている。速度への要求は常に真空から生まれるわけではなく、不当なら立ち向かうべきだろうが、現実的に常に選択肢があるのかは疑問だ。

    • この記事は仕事をやや理想的でのんびりしたものとして見ているように思える。完璧主義に陥ってフィードバックを待ったり、不要なものを作ったりするより、一部を壊してでも速く動くことには明確な利点がある。これはアジャイル管理の基本的な教訓であり、絶対ではないにせよ、一般的には快適だと感じる水準よりも速いペースが有利だ。
    • 書き手としては、締め切りはたいてい人工的な制約だと見ている。打ち上げ条件やサプライヤーの生産スケジュールのように変えられない期限もあるが、しばしば本当の目標から注意をそらし、急がせるための口実や心理的なムチとして使われる。
      期限に合わせることだけを目指して急ぐと、当面は速く見えても、チームが出せる最善より劣る結果になり、あとでひどい成果物を片付けるためにより多くの時間を費やすことになる。あらゆる状況にのんびりさを適用しようという意味ではなく、常に速く動いているのに目標をほとんど達成できない環境では、急ぐこと自体が失敗の原因なのかを検討せよという意味だ。
      FedExが配送スタッフ用の新しいダッシュボードを展開したあと、MacBookの受付手続き中にシステムが止まり、スタッフは手動処理後に領収書を渡したが、誤ったラベルが印刷された。その結果、AppleにノートPCが届かず、数週間にわたって複数のスタッフに状況を繰り返し説明しなければならず、1か月後にAppleが5千ドルの新しいノートPCを送らなければならなかった。任意の期限のために急いで作ったソフトウェア1つが膨大な時間と費用を浪費した事例であり、速度を落とそうというのは心理的な安楽さではなく、現在と未来の混乱を防ごうという意味だ。
    • ほとんどの締め切りは人工的で自分たちで作った制約だ。家の半分が燃えているのに会議を予約してSlackで議論しようという意味ではなく、実際により緊急な仕事もある。この記事は絶対論ではなく速度崇拝を批判しており、状況に応じて判断する規律を求めている。
  • 速さと速度ベクトルは違う。100階建てのビルから落ちている人は、ものすごい速さで飛んでいると思うかもしれないが、目標に向かう速度ベクトルは、多くの依存関係を熟考し、正しく航行するときに生まれる。
    大企業ではそのどちらも重要ではなく、成果物の大半はひどいものだ。締め切りは年次の業績評価に合わせて計画され、経営陣が好む人々が正しい指標を達成したという成功談を作ったり、マイルストーンを変更したりして報酬を与える。その成功を見事に監督したという理由で、経営陣自身も報酬を受ける。

  • キャリアが長くなるほど、この原則はより明確になる。ただし、若い同僚がまだそれに気づかないまま自分の管理階層の上に立つと、問題になり得る。
    「自分が出した最大の成果の一部は、書かないと決めたコードだった」といった言葉で内省を促すことがある。