原題: Doing nothing at work
著者: Sean Goedecke
公開日: 2026年6月8日
ソースURL: Doing nothing at work
アーカイブ日: 2026-06-30
多くのソフトウェアエンジニアはもっと仕事を減らすべきだ、とSean Goedeckeは主張する。コードの量や変更回数を減らすという意味ではない。文字通り、1日のうちで働く時間を減らすのだ。作業するときも、よりゆっくりとしたペースで取り組む。著者は「デフォルトで80%稼働」を目指している。高負荷なプロジェクトに携わっていない限り、1日の20%はコンピュータから離れて過ごす。
この主張の背景にある洞察はこうだ。テクノロジー企業におけるパフォーマンスは、外れ値となる出来事によって支配される。著者がこれまでに行った最もインパクトの大きい変更の多くは、驚くほど些細な作業量で済んだ。ソフトウェア開発には「努力点」など存在しない。重要なのは、正しい問題を正しいタイミングで解決することだ。大規模なエンジニアリング組織には、ほんのわずかな工数で数千万ドルから数億ドルの価値を生み出せる仕事が転がっている。著者は3つの典型例を挙げる。
第一に、会社が大口のエンタープライズ契約を結ぼうとしているとき、機能追加やバグ修正で介入すれば契約を成立させられる。優れた機能である必要すらない。具体的な変更を行う意志と能力を示すだけで十分なことがある。
第二に、インシデントを早期に防止または緩和できれば膨大な金額を節約できる。適切なフィーチャーフラグをオフにする方法を知っているだけでも、インシデント中の即時の収益損失と、顧客が取引を引き揚げたり保留中の契約への署名を拒否したりすることによる将来の収益損失の両方を防げる。
第三に、会社が注目度の高い機能をリリースしようとしているとき、成否は些細だが分かりにくい変更にかかっていることが多い。たとえばユーザー設定に新しい項目を素早く追加する能力や、何年も誰も触っていない古びたエンタープライズデータエクスポート機能を更新する能力などだ。システムへの習熟度が、こうした変更に数時間で済むか丸一週間かかるかの分かれ目になる。
これらの例に共通するのは、すべて時間依存性があることだ。朝ログオンして「今日は大口取引のブロックを解除しよう」と決められるものではない。適切な場所に適切なタイミングでいるだけでは足りない。すでに忙しくないことも必要だ。
著者はこのテーマを以前の記事「JIRAチケットを粉砕するのは宴会芸であってインパクトへの道ではない」でも書いている。常に100%の稼働率で低優先度の作業の安定した流れに追われていると（たとえばバックログからチケットを拾っては片付け、次を拾うだけの状態）、高インパクトな仕事の機会を二重に逃すことになる。第一に、忙しすぎて機会に気づくことすらできない。他のことをやっている人と話したり、チームのアップデートを読んだり、進行中のインシデントに目を光らせたりする余裕がない。その結果、高インパクトな仕事に関わる最良の方法——自分の専門知識を自発的に提供すること——を逃してしまう。第二に、常に忙しそうに見えると、マネージャーがあなたを推薦してくれなくなる。これが二番目に良い方法だ。マネージャーやプロダクトマネージャーは通常、どの仕事が高インパクトかについて、はるかに優れた見取り図を持っている。彼らはあなたのいない会議に出席しているからだ。
では、高インパクトな仕事のために時間を空けておくべきで、チケットをただ消化すべきでないとしたら、日々の細かい時間に何をすべきなのか。ただ何もしなくていいのか。そう、その通りだと著者は言う。
「何もしない」ことは実は良いことだ。ソフトウェアエンジニアリングはストレスの多い仕事になりうるが、通常は一貫してストレスフルなわけではない。ストレスは時折のインシデントや、プレッシャーの高い緊急の仕事、（最近では）レイオフから来る。プレッシャーの比較的低い時期に切迫した強度で取り組んでいると、高圧的な部分を処理しなければならないときにすでに消耗し、疲れ切ってしまう。
高圧的な状況でも、「何もしない」ことは依然として有益だ。著者がオンコールに初めて就くエンジニアに勧めるのは、急がないことだ。通話に参加する前や発言する前に数回呼吸を整え、一般的に「スローモーションで考える」ように心がける。ほとんどのインシデントは自然に解決する。「これで直るかも」という慌てた変更のほとんどは、状況を改善するどころか悪化させる。一般的なルールとして、単にパニックを避けられるだけで、インシデント対応において大多数のエンジニアより優れた対応ができる。
「何もしないこと」は何かが起こりうる空間だ。著者はRich Hickeyの講演「Hammock Driven Development」からの影響を認めつつ、違いも指摘する。Hickeyは本当に難しい問題の解決策を設計するために必要なことを論じており、コンピュータから離れた時間を難しい問題に集中するために使うことを勧めている。一方Goedeckeは、単に脳を休ませ、解決策が自然に頭の中で固まるのを待つことを重視する。Zvi Mowshowitzの「slack（余裕）」についての記事とも通じるものがある。脳に休息の機会を与えれば、新しいアイデアが浮かびやすくなる。誰かから重要なタスクを手渡されたら、バックグラウンドで同時に進行中の他の3つのことをやりくりするのではなく、全注意を向けて取り組める。忙しくないときは、ただものを見る時間があり、新しいデータを取り入れられる。
多くのエンジニアは、やる必要のあるタスクを見つけながら手を出さないことに居心地の悪さを感じる。著者自身もそうで、「「役に立つこと」への依存症」で書いている。これは多くのソフトウェアエンジニアが共有する心理的傾向であり、（ある程度までは）その傾向があるからこそ仕事に向いているとも言える。「何もしない」時間を確保するためには、時に自分に手を出さないよう強制する必要がある。
たとえば著者は、エンジニアは一般的に「糊仕事（glue work）」を避けるべきだと考える。糊仕事——人々が互いに話すようにすること、自分がリードしていない仕事のドキュメント更新、技術的負債への対応を自発的に申し出ること——のほとんどは、組織がその仕事を明示的に優先していないことを反映している。優先していれば、誰かが自発的にやる必要はないはずだ。それが問題ないなら、手を出すべきではない。時間を無駄にし、マネージャーを苛立たせるだけだ。もしそれが大きな過ちなら、それでも手を出すべきではない。会社を自身の過ちの結果から守ることになり、その代償を自分のキャリアと精神的健康で支払うことになるからだ。それは自分にとって悪い取引であり、後輩の同僚にとって悪い模範であり、自分が必然的に燃え尽きたときに誰か別の人が同じ立場に飛び込むという悪しき前例を作る。結果が本当に深刻なら、それを起こさせればいい。組織が痛みを感じ、方針を変えられるようにするのだ。
著者はまた、親切すぎると捕食者に対して無防備になるとも考える。テクノロジー企業には、ソフトウェアエンジニアから無報酬の労働を引き出そうとする人々が溢れている。これは通常のチャネルを通じて来る仕事——昇進やボーナス（そして通常の給与）によって報酬が支払われる仕事——とは異なる。著者が問題にしているのは、裏チャネルを通じて来る仕事で、その仕事が正式に自分の名前で記録されるようにする能力も意思もない人々からのものだ。たとえば、別の組織のプロダクトマネージャーが「あなたはデータ抽出が上手ですね、Xについての統計を少し取ってもらえませんか」とメッセージを送ってくる場合や、別のチームのエンジニアが「ペア作業」を依頼してきて、最終的に自分がすべてのコードを書き、相手が静かに自分の名前で変更を提出する場合などだ。こうした仕事をある程度こなすのは構わない。助けられるなら助ければいい。しかし、ノーと言うか、単に返信を数時間か数日遅らせることで、逆圧をかけられる必要がある。
また、消えそうな仕事に投資しすぎないことも良い考えだ。たとえば、デザイナーがリアルタイムで要件を考えている場合を想像してほしい。午前9時にページヘッダーをある見た目にしてほしいと言い、10時に微調整、11時にさらに変更、という具合だ。毎時間ページを全面的に書き直すべきではない。代わりに、何もせず（散歩に行くなりして）、午後に最新のデザインに基づいて一度だけページを書き直せばいい。もう一つのよくある例は「政治的影響力のないマネージャーからの『大きなアイデア』」だ。多くの場合、プロジェクトが必然的にキャンセルされるまで時間を潰していればよい。
ソフトウェアエンジニアリングのアドバイスやツールの多くは、技術的努力を発揮する能力をスケールアップすること——より多くのことを同時に行い、より大きなスコープのプロジェクトに取り組み、より多くのコードを書くこと——を中心に設計されている。しかしソフトウェアエンジニアリングの成功は、これらのどれによっても決まらない。正しいことを正しいタイミングで行う能力によって決まる。それには、通常の仕事の間に意図的に努力の一部を抑えることが必要だ。
著者の経験では、80%の努力で「ハイパフォーマンスエンジニア」であることは依然として可能だ。実際、より容易ですらある。ストレスによる馬鹿げたミスをしにくくなり、桁外れのリターンをもたらす種類の高インパクトなタスクに飛びつける立場にいられるからだ。
これは決して100%の努力で決して働くなという意味ではない。著者は年に2、3回は可能な限り懸命に働く。長時間労働、強烈な集中、朝起きてから寝るまで問題について考え続ける。しかしこの働き方は、報酬が本当に高いときのために取っておく。それ以外の時期は、比較的のんびり過ごすのだ。
「生産性を最大化するにはどうすればいいか」という問いに対し、より多くのことをこなす方向——ツールの習得、ワークフローの最適化、マルチタスク——ではなく、「あえて手を抜く」方向から回答した点がこの記事の最大の独自性だ。著者は抽象的な自己啓発論に逃げず、エンタープライズ契約の成立やインシデント対応といった具体的な状況で「暇であること」がどのように価値に変換されるかを描き出す。この具体性が説得力の源泉である。
テクノロジー業界の主流言説——「情熱を持て」「全力を尽くせ」「常に学び続けろ」——への解毒剤として読める一方で、この記事は単なる逆張りではない。Rich Hickeyの「Hammock Driven Development」という先行する知的伝統に接続しながら、そこからの差異（Hickeyは「離れた時間を難問に集中せよ」、Goedeckeは「ただ休め」）を明確にしている点に、思想としての成熟がある。特に「糊仕事を避けよ」「捕食者から身を守れ」というセクションは、単なる効率論を超えた権力分析に踏み込んでおり、中級以上のエンジニアにとって実践的な価値が高い。
この記事が5年後も参照されるかというと、参照されるだろう。理由は二つある。第一に、AIによるコード生成の普及によって人間のエンジニアの役割が「量をこなす人」から「何を作るべきか判断する人」へとますますシフトするなかで、「あえて手を空けておく」という戦略の重要性は高まる一方だからだ。第二に、この記事が依拠する洞察——ソフトウェア工数とビジネス価値は比例しない——は多くの現場で経験されているにもかかわらず、明文化されることが少ない。著者はその構造を言語化した点で、Will LarsonやTanya Reillyといったエンジニアリング文化の書き手の系譜に連なっている。