SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

翔泳社の本(AD)

優秀なエンジニアほど「余白」を設計する 稼働率100%がチームを破滅させる理由

 忙しい。やることは多い。学ぶべきことも増え続ける。それなのに、思うように前へ進めている実感が持てない。そんな感覚を抱えながら働いている人は、少なくないのではないでしょうか。そういった感覚は、じわじわと私たちを消耗させ、日々の活力を奪っていきます。そこで重要となってくるのが、「セルフマネジメント(自己管理)」です。セルフマネジメントについて学びたい方におすすめする1冊は『エンジニアのための自己管理入門 堅牢でスケーラブルな働き方を構築する技術』です。その中から、「2-1 余白の価値」を抜粋してお届けします。

エンジニアのための自己管理入門 堅牢でスケーラブルな働き方を構築する技術
 

Amazon  SEshop  その他

 
エンジニアのための自己管理入門 堅牢でスケーラブルな働き方を構築する技術
 

著:小田中 育生
発売日:2026年06月24日(水)
定価:2,948円(本体2,680円+税10%)

本書について

エンジニアほど多くのストレスに晒される職種はありません。本書は、そんなエンジニアに向けて、「負担を軽減し、よりよく働くための自己管理術」を解説した書籍です。「モチベーション」「時間管理」といったテーマごとに、自己管理のための自分と向き合い方、課題・問題との付き合い方・解決法を紹介します。

余白のつくり方

 タイムマネジメントは、単に「限られた時間を効率よく使う」ための技術ではありません。本質は「余白」を意図的に生み出すためのスキルにあります。ここでの「余白」とは、カレンダーをただ空けることではありません。自分自身のリソース(予定、認知資源など)を100%使い切らず、変化や学習、検査と適応に振り向けられる予備の時間、そして認知の余力を意図的に残しておくことです。ここでは、タイムマネジメントを「余白をデザインする技術」と捉えます。

 渋滞が起きているときに必要なのは、気合いでアクセルを踏むことではありません(そんなことをしたら大事故になってしまいますね)。必要なのは道路の混雑を避け、迂回や停止ができるスペースを確保することです。エンジニアの仕事でも同じで、予定や割り込みで稼働率が上がりきるほど、重要な仕事は前に進みにくくなります。だからこそタイムマネジメントの核心は、作業を詰め込むことではなく、余白を設計して渋滞を解消する・回避することにあります。

直進し続けるか、立ち止まり方向を変えるか
直進し続けるか、立ち止まり方向を変えるか

 ここで紹介する余白には2種類あります。

  1. 時間の余白:予定の詰め込みを避け、予期せぬ割り込みや検討のための時間を残すこと
  2. 認知の余白:注意・ワーキングメモリの占有を減らし、考える余力を残すこと

 どちらも、変化に適応する力を支える土台となります。変化に適応する力は、現代の知識労働において競争力の源泉です。市場や技術の変化が年単位ではなく月単位・週単位、それどころか一日で状況が変わるような現在、立ち止まり方向を変える時間を確保できるかどうかが、成果の持続性を左右します

 効率化が声高に叫ばれる中で、仕事における「余白」は効率化を損ねるものとして「なくすべきもの」とみなされてきました。産業革命以降の労働観は「稼働率を最大化する」ということをよしとする傾向が強くありました。これは工場や製造業において顕著なものでしたが、その考え方は知識労働にもそのまま持ち込まれています。

 近年では行き過ぎた効率化を見直す向きもありますが、いざ少しでも余白が生まれると「いかんいかん、仕事で埋め尽くさなくては」というマインドセットの組織、そして個人はまだまだ存在しています。 そのため、タイムマネジメントは「なんとかやりくりして時間を捻出する」だけでは不十分です。余白は怠惰である、という誤解を解き、余白が生み出す価値に対しての深い理解からマインドセット、そして行動を変えていくことが大切です。たとえば、「会議と会議の間に10分のバッファを入れる」「週に60分、計画と優先順位を見直す枠を固定する」といった余白を確保することは、サボりではなく変化に追随するために必要なアクションです。

 では、あらためて、「余白」がもたらす価値とは何でしょうか。余白の価値には様々ありますが、ここではまず押さえたい、

  • 変化への適応
  • 創造性の獲得
  • 燃え尽きの回避

 の3つに絞って紹介します。

変化への適応

 余白は、方向転換するための余裕をもたらします。

 たとえば、3か月間の計画を詳細に立て、その期間は完全に計画通りに進めるケースと、一週間ごとに立ち止まり、計画を見直すケースを比較してみます。変化というものは、発生した瞬間からその影響を広げていきます。そのため、変化が起きたところからなるべく早い段階で検査し適応していきたいものです。しかし、検査の間隔が変化の頻度よりも大きいと、ずれた状態で作業が積み上がり、手戻りが大きくなるという課題があります。よって、外部環境の変化が頻繁に起きる状況では、一週間ごとに立ち止まり、計画を見直す場合のほうが圧倒的に変化へ追随しやすくなります。

 この違いは、リソース効率とフロー効率の対比にも表れます。

  • リソース効率:個々のリソース(人や機械)が常に100%稼働している状態を追求する考え方
  • フロー効率:仕事の流れ全体をスムーズにし、価値が顧客に届くまでの時間を最短にする考え方

 リソース効率は「全員が常に手を動かしている状態」へと最適化します。たくさんのことを同時に進めることになるため同時に進めるものごとの調整が必要になり、会議や定例などが生まれていきます。

 一方、フロー効率は「価値を届けるためのリードタイム」を重視しています。ひとつの仕事をこなしてから次の仕事に手をつけ、仕掛中の仕事であるWIP(Work In Progress)の数を減らしていきます。フロー効率で重要なのは「価値を届けるためのリードタイム」を短くすることであり、仕掛中の仕事を持ちうる限り持つことではありません。

 そして、価値を届けるリードタイムを短くするために仕掛中の仕事の数を絞る、というこの考え方は結果的に余白をもたらし、変化に対しての強さをもたらします。

WIPの観点でのリソース効率・フロー効率の対比
WIPの観点でのリソース効率・フロー効率の対比

 また、トヨタ生産方式のカンバンシステムやリーン開発の思想では、余白を持たせることが重要視されます。この考え方であれば、途中で仕様変更や優先順位の変更が入っても、迅速に切り替えることができます。トップスピードは100%稼働したほうが出せるかもしれませんが、変化が大きい環境ではこまめに方向転換できるほうがゴールにたどり着くまでの所要時間は短くなるでしょう。

 トム・デマルコは『Slack(邦訳:ゆとりの法則)』の中で、「余白は変化のための自由度であり、これがなければ組織は硬直化する」と述べています。変化のスピードが極めて速いソフトウェア開発のような環境では、この自由度こそが生命線です。

 また、方向転換のために立ち止まる余白をもつことは、自身の成長にもつながることです。筆者がこれまで関わってきたチームはたくさんありますが、そのほとんどのチームで、「一週間単位で小さく計画し、その結果を検査し適応する」ということをしています。そして一週間ごとに、「もっと自分たちがよくなるためにはどうしたらいいか?」を、その一週間にあったこと、起こったことなどをふりかえりながら考え、アクションしていきます。

 このように、毎週のように自分たちの行動をふりかえり、アクションしていくと、一年間でおよそ50回くらい変化・成長のチャンスがあることになります。

創造性の獲得

 方向転換できるということは、新しい可能性を試す余裕がある、ということでもあります。余白は「変化に追随していく」という守りのためだけではなく、「新しい価値を生み出す」という攻めのためにも欠かせないものなのです。

 創造性は、既存の知識や経験を新たに組み合わせることで生まれます。この「組み合わせ思考」には、情報を咀嚼し、関連づける時間が必要です。計画で埋まった状態では、このプロセスが機能しません。余白は脳が組み合わせ思考を行う余裕を与え、意外なひらめきを生み出す土壌になります。

 また、創造性を発揮するためには、普段から幅広い領域に対してアンテナを張っておき、様々な情報を自分の引き出しに入れておくことが必要です。

 Googleが実施していた「20%ルール」は、従業員が自分の関心に基づくプロジェクトに週の20%を使えるという仕組みでした。そこからGmailをはじめとした革新的なサービスが誕生したことは有名です。これは、余白が直接的に新しい価値を生み出す事例の好例です。

 筆者の現場では年末年始など、いつも以上に計画が立てづらい期間には思い切って計画を立てず、メンバー一人ひとりが普段やりたいけどできていないことにコミットする「自由研究」という期間を設けることがあります。その期間においては、自分だけの開発環境を速やかに立ち上げるツールを作ったり、新しいアルゴリズムの実装にチャレンジしたり、生成AIを活用して実験的なチャットボットを作ったりと様々な創造性の発揮が観測されます。

燃え尽きの回避

 予定をこなすだけで精一杯という状況は心身の疲弊を招きます。世界保健機関(WHO)は、バーンアウト(燃え尽き症候群)を「慢性的な職場ストレスが適切に管理されないことによって生じる症候群」と定義しています。燃え尽き症候群の傾向は以下のようなものです。

  • 消耗感(Exhaustion):エネルギーの枯渇、疲れ切った感覚
  • シニシズム(Cynicism):仕事に対する距離感や否定的な態度
  • 効力感の低下(Inefficacy):業務上の達成感や能力に対する自信の低下

 燃え尽きたい……。『あしたのジョー』の主人公である矢吹丈のように全力を出し、あとには真っ白な灰だけが残る、そういう生き方を望む人もいるでしょう。筆者の考えですが、そういった自ら燃やし尽くすことを選ぶ人がそうなることは決して否定はしません。命は燃やし尽くすためのもの、かもしれませんから。

 しかし、それを望まず、意図せずして燃え尽きてしまうことはできれば避けたいですね。では、なぜ人は燃え尽きてしまうのでしょうか。

  • 責任の重圧:成果へのプレッシャー、人材育成・評価・コンフリクト対応など、精神的負荷の大きさ
  • 孤独感:上司にも部下にも本音を話しにくく、相談相手がいない
  • 役割の曖昧さ:期待される役割が多様・矛盾しており、達成基準が不明確
  • 承認の欠如:自身が承認・評価される機会が少ない
  • 自己犠牲の常態化:長時間労働、チーム優先の思考が続き、自己ケアがあと回しになる

 こういった理由が、人々が燃え尽き灰のように真っ白になる状況を作ってしまいます。人が燃え尽きてしまう背景には様々な理由がありますが、適度な余白は「自己犠牲の常態化」を防ぎます。精神的・肉体的な余裕をもたらし、私たちを燃え尽きから遠ざけてくれます。

 燃え尽きについては書籍の第3章で詳しく触れていきますが、燃え尽きを防ぐ土台となるのが日常的な余白の確保です。

リソースを使い切らない

 余白の価値についてはなんとなくわかったけど、やることが明確に定まっていて変化しないなら、リソース効率を突き詰めたほうがよいのでは? と疑問を持たれるかもしれません。

 では、あなたが開発しているシステムで考えてみましょう。もしシステムのリソースを100%使い切るとしたらどうでしょうか。

 CPU使用率でも考えてみましょう。サーバーのCPU使用率が常に100%に張り付いていたら、新しいリクエストが来ても処理が追いつかず、タスクは待ち行列に積み上がっていきます。結果としてレスポンスは遅くなり、利用者から見ると「動かないシステム」になってしまいます。

CPU使用率のイメージ
CPU使用率のイメージ

 メモリについてはどうでしょうか。プログラムが必要以上にメモリを確保し続けると、やがてガーベジコレクション(GC)が発生しやすくなります。GCは健全性を保つために不可欠な仕組みですが、発動が多すぎればパフォーマンスは大幅に落ちます。

 人間の脳とコンピュータは同一ではありませんが、処理能力には上限があり、上限付近で使い続けると、待ちや切り替えのコストが急増するという点は類似しています。情報や予定を詰め込みすぎると、切り替えや整理に余計なエネルギーを使わざるを得ず、本来の仕事に割けるリソースが減ってしまうのです。心理学のタスク切り替え研究では、作業を切り替えた直後に反応が遅くなり誤りも増えるスイッチコストが繰り返し観察されています。

 この切り替えコストが増えると、1日の総作業時間が同じでも、成果物に変換できる時間が削られます。タスクAからBに移るたびに再理解・再計画・再探索が発生し、その分だけ純粋な前進が減るためです。結果として、単位時間あたりに終えられるタスク数、つまり実効スループットが下がりやすくなります。スループットが低下するため、結果として「待ち」が増えやすくなります。

 待ち時間と仕掛の関係を捉える近似として、行列理論で有名な「リトルの法則」があり、

 平均来客数(L)=到着率(λ)×平均滞在時間(W)

 という非常にシンプルな式で表されます。これは、系が安定していて長期平均が定義できるときに成り立つ関係です。

 銀行や病院の受付をイメージするとわかりやすいでしょう。1時間あたり10人が来る(λ=10)窓口に平均で30人(L=30)が滞留しているなら、一人あたりの滞在時間(W=3)は3時間になる、という具合です。

 この法則は、広い条件下において行列の形や分布に依存せず成り立つ関係式として知られています。だからこそ、様々な分野に応用されています。エンジニアの仕事に近い形に言い換えると、

 平均滞留時間=平均仕掛数÷平均スループット

 となります。

エンジニアの仕事に近い形で言い換えたリトルの法則
エンジニアの仕事に近い形で言い換えたリトルの法則

 「平均仕掛数」は並行して抱えているタスクの数、「平均スループット」は単位時間あたりに処理できるタスクの数と考えられます。つまり、WIP、同時進行のタスクが多ければ多いほど、1つのタスクが終わるまでにかかる時間は必然的に長くなるのです。逆に仕掛を減らせば、平均滞留時間は短縮されます。

 これが「タスクを抱え込みすぎると全体の進みが遅くなる」理由です。そして、あえて余白を残し、仕掛数を制御することが、結果としてスループットを最大化することにつながるのです。

 人間が予定を詰め込みすぎてしまうと、CPUに常に100%の負荷をかけ、タスクを待ち行列に積み上げるのと同様に、待ち時間や切り替えコストの増大を招きやすくなります。余白を残すことでWIPを減らし、スムーズなフローを取り戻すことができます。

 今回の抜粋記事はここまでです。続きは書籍を確認いただけますと幸いです。ぜひ6月24日の発売日に書店でお手に取ってみてください。

エンジニアのための自己管理入門 堅牢でスケーラブルな働き方を構築する技術
 

Amazon  SEshop  その他

 
エンジニアのための自己管理入門 堅牢でスケーラブルな働き方を構築する技術
 

著:小田中 育生
発売日:2026年06月24日(水)
定価:2,948円(本体2,680円+税10%)

本書について

エンジニアほど多くのストレスに晒される職種はありません。本書は、そんなエンジニアに向けて、「負担を軽減し、よりよく働くための自己管理術」を解説した書籍です。「モチベーション」「時間管理」といったテーマごとに、自己管理のための自分と向き合い方、課題・問題との付き合い方・解決法を紹介します。

この記事は参考になりましたか?

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/24455 2026/06/18 09:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング