2026-10-03

余白をどうやって作るか

たまたま、とある方の退職エントリを読んだ。

全く面識のない方であったが、書かれている内容に「チームに余白を作ること」が書かれていた。こういった内容を考えて取り組んでいることが書かれている。

自分も常日頃チームになんとかして余白を作ることが必要だなーと考えており、そのために何をしているかを改めてふりかえってみるのがいいんじゃないかと、今キーボードを叩いている。ちょっと元エントリの余白とは異なる内容かもしれないが、しばしお付き合いいただきたい。

なぜ余白が必要か

私たちのチームはスクラムはやっていないが、基本的には近しいことをやっている。

1週間を1イテレーションとする
開始時にプランニングをして、今回のゴールを決める
決めたゴールを達成する課題に集中する
イテレーションの最後にはふりかえりを行う
- 今週の仕事内容や進め方、うまくいったことやうまくいかなかったことを共有
- そのまま続けたり、改善したりするには何をするかアクションを決める

特筆すべきこともない、一般的な流れだと思っている。

問題と思っているのは、先のエントリでもリンクが貼られているスライドとも近いのだが、チームとして行うべき仕事があると、そちらに意識がいってしまうことだ。これ自体はなんの問題もない。ただ、目の前の仕事に追われていると、どうしても視野狭窄に陥る。仕事そのものは大事だが、メタ的な視点で今の仕事を見つめる機会がなくなってしまう。自分でも実感があり、スプリントの時間全てをめちゃくちゃ集中して仕事をやった達成感はあるが、その進め方が良かったのかどうか、など俯瞰的な判断ができてないことが多くあった。

ある程度余白を作らないと、そういった俯瞰的な視点を設ける頭の領域が空けられない。チームとしても、何がうまくいってうまくいかなったか、そういったことを考える余地を残すことで、改善を進められるのではないかと思って、「余白を作る」ことを意識しているのだ。

自分がやってる余白の作り方

やらないといけないことは常にあるので、1イテレーションでMustな仕事をしつつ他に何をやるかを調整していくことが、基本ラインと思う。イテレーションで達成したい目標に関連する課題は最優先で取り組みつつ、全ての時間をそれに注がないようにする。

スプリントゴールで価値を駆動しよう　価値探索に焦点を合わせたスクラムの実践

作者:Maarten Dalmijn,藤井拓
丸善出版

Amazon

スプリントゴールで価値を駆動しよう　価値探索に焦点を合わせたスクラムの実践でも書かれている考え方だが、取り組む際の気持ちとして全ての課題が終わらないと達成できないのと、ある程度落としても問題ない課題もあるのとでは、心持ちが全く違う。メンタル的な余白ではあるが、これは大事だと思う。

ただもちろんMustな仕事をどう終わらせるかだが、ここには先のスライドでも触れられているフロー効率を意識した動き方、具体的にはモブプロなどがあげられる。あとはプランニング時点でどの程度チーム内の認識を合わせられるかは重要かな。レビュー時に設計の問題があったりすると、大きな手戻りになるのでプランニング時点である程度認識揃えるための動きをしておくことが必要になる。この辺はAIがコード生成する今でも、手戻りは大きな痛手なので常に意識してる。モブプロでもこの辺重要だしね。

ここまででなんとか重要な仕事やって、あと時間的な余白を手に入れられることになる。あとは先のスライドでも触れられているように、そもそも余白の時間取るのも有効だと思う。うちのチームだとあらかじめ学習のための時間を設けているので、丸一日とまではいかないが、チームとして必要な知識を取り入れたり、各々が必要な改善時間にあてたりしている。一時期雑談しながら、各々何かをするみたいな時間も作っていたこともあったけど、これはこのチームを離れた後になくなったようだ。

AIが余白を潰す

ここ最近気になっているのは、こういった余白を確保しても「やらないといけない仕事」と称するものがチームのキャパシティ以上に増えて、その調整に余白を潰されていることだ。人の理解以上に物事を進めようとする人が多く、結局のところスロップが増えてるだけと感じることも多い。

急いでものを出すんではなく空いた時間で、ユーザーに適切なものを提供するにはどうすればいいか、提供を素早くしていきたいならどう今のリリースまでのフローを改善するか、チームひいては組織の無駄な動きをなくしていくためにどうするか、そういったところに時間かける方がもっと遠くまで行けるんじゃないかなと考えている。

2026-09-19

「エンジニアリングマネージャーお悩み相談室」読了

読書日記開発

エンジニアリングマネージャーお悩み相談室【リフロー型】日々の課題を解決するための17のアドバイス

作者:新多真琴
翔泳社

Amazon

エンジニアリングマネージャーという立場ではないけど、立場的にリーダー的な役割を求められたりすることも多く、一つの目安がないかと思って手に取ってみた。すごい雑多に感想を書き連ねていこうと思う。

全部読み通してみた結果、やっぱり「対話」することに立ち返るのが必要だなと感じる。もちろんこれまでに、様々な対話はやってきたつもりではある。ただどうにも手応えがないときが多く、伝わってないなーと感じるときもある。「自律的なチーム」については本の中でもお悩みが出てくるが、これなんかそのものズバリだ。ただタスクをこなすだけでなく、どう進めると速く進められるか、コード書くにしてもどういう構造がいいのか、そういったことを自分たちで考えて進めてほしいなと思うも、人によってはなかなか難しい。どこまでサポートするか、とか考えているうちに全部やっちゃった方が早いか……という悪魔の囁きも聞こえてくる（なるべくやらないけど）。

個別のテクニック、例えばミラーリング・バックトラッキングと言われている、受け取った内容を自分の言葉で返すようなことはやってたりする。それで色々話が広がることも多い。自分がうまくできてないのは、ビジネスの言葉に直すこと。〜を移行した、とか言われてもわからないよ、とはメンバーにも話したりするけど、自分もこの辺の鍛錬をしないと、説得力がないよなと思うことが多くなってきた。

採用活動について書かれたところは、逆に転職活動に活用できそうな内容がちらほら。この辺はまた事を起こすときに再度読みたいところではある。

本に書かれていることは正論だし、この通りと思うばかりの内容が書かれているので、EMでない開発者だとしても、こういった視点を持って動くことができれば、一歩先を行く人になれるんじゃないかと思う。

ただ一方で「そうはいってもさー」という感情面もある。経営方針とのすれ違いとかさ。この辺の塩梅がまあ難しいよね。人間だもの。

2026-09-06

ヤバい日本の住所読了

読書日記

ヤバい日本の住所 (幻冬舎新書)

作者:河合太郎
幻冬舎

Amazon

単純に話題になっていたから、という理由で手に取ってみたが、スルスルと読めてしまうほど面白かった。

京都在住で、過去に新卒で入ったSIerで京都の住所のデータが欲しいので免許証かして欲しいというような話もあったので、京都の住所というのは珍しいんだなと、知識的に知ってはいた。が、そもそもの日本の住所というもの自体、なかなかカオスな代物であるというのは全然意識していなかったな。

京都の部分だけでも、西入、東入なんかは当然のように受け止めていたけど、確かに通りから見てどちらの方角かという話なので、相対的な位置関係がそのまま住所になっているのは、そりゃ珍しいよなと思った。システムとして曖昧さを含んだものになっているので、生み出されてくる住所は、時代の積み重ねもありシステマティックに決まらないなんていうのは、まーどこでも見かける現象ですね。

AIの絡みも少し書かれていたりしますが、こういった不確実性・曖昧さというのは、人の性なのかもしれませんね。

2026-08-16

「1泊2日で組織は劇的に強くなる！最高の「企業合宿」の創りかた」読了

読書日記

1泊2日で組織は劇的に強くなる！最高の「企業合宿」の創りかた

作者:茂木健太
ぱる出版

Amazon

この本は面白かった。

基本的な内容は、合宿における準備の大切さやどのような内容を作っていくかなど、具体的に合宿における必要事項が書かれているが、本質的には人と人の認識のずれをどう炙り出すか、どう揃えていくかが書かれている本だと思う。あまたのアジャイル系の本で書かれている改善のループ回すためにどうするか、とかそういった内容と同等の内容が書かれている印象を受けた。

個人的に非日常感というは大事だと思っていて、基本リモートで働く人間としては顔を実際に付き合わせて働くことが非日常になっているところがある。本書の場合だと合宿場だが、例えば自分が所属するチームが事務所で集まってなんらかのギャザリングするときなんかは、この本に書かれているような内容は割と意識して、スケジュールを切ったりしている。合宿でのなんらかの舞台を整えるのに、メンバー自らが構築していく話なんか、自律性の話になってくるし、チャレンジの創出みたいな話は目標とかにも関わってくるところだし、「そうそう」と思いながら読んでいた。

物事を前に進めるために自分はアジャイルにたどり着いたところがあるが、この本はそれに似たマインドとテクニックが書かれていると感じた。わりとあっさり読めるので、おすすめ。