法則一覧

第113条組織

メイカーの時間割、マネージャーの時間割

ものを作る人には途切れない長い時間が要る。一時間刻みで回る予定表は、その時間を使えないほど細かく切ってしまう。

Paul Graham

心得

会議の代償は、一時間ではなく壊す時間のまとまりで数える

どうするか

会議は一日の端に寄せるか、決まった曜日にまとめる。作る人には、会議のない半日以上のまとまりを残す。メイカーの予定を押さえる前に、取る一時間ではなく壊すまとまりを数える。障害対応はすぐ答える。レビューを待っているチームメイトには、次の区切りで、遅くとも一日以内に答える。

なぜ起きるか

Paul Graham は一日の使い方を二つに分ける。「マネージャーの時間割は上司のためのものだ」。一日は一時間ごとに区切られ、会議は枠がひとつ埋まるだけだ。プログラムを書いたり文章を書いたりするメイカーは、ふつう少なくとも半日単位で時間を使いたがる。難しい仕事は、動き出すまでに長い助走が要るからだ。メイカーにとっては「会議がひとつあるだけで午後がまるごと吹き飛ぶ。午後が二つに割れ、どちらも難しいことをするには短すぎるからだ」。どちらの時間割も間違いではない。「どちらの時間割も、それだけならうまくいく。問題は両者がぶつかったときに起きる」。会議を入れる側には自分の予定表の一時間しか見えないので、メイカーの損は数えられないまま終わりがちだ。Google のコードレビューのガイドも、レビューする側に同じ線を引いている。"If you are in the middle of a focused task, such as writing code, don’t interrupt yourself to do a code review."

実際にあったこと

Pinterest のプロダクトエンジニアリング組織は、火曜から木曜まで、エンジニアの予定表に 9 時から 17 時の会議禁止枠を入れる「週三日は会議なし」を試した。約100日後、マネージャーにはとても好意的な声が届き、調査でも大半のエンジニアが同じ意見だった。月曜と金曜の会議がよくはみ出すという声もあった。その後、Pinterest のほかのエンジニアリング組織もいくつか同じやり方を取り入れた。

記録を読む

当てはまらなくなるとき

ラインを止めて対処する:トヨタは、問題が起きたら誰でもラインを止められるようにして、問題を後工程に溜めずにその場で扱う。メイカーのまとまった時間を同じように守りすぎるチームは、止まっている仲間や欠陥を、その後ろで待たせてしまうことがある。

出典

Paul Graham『Maker's Schedule, Manager's Schedule』(paulgraham.com, 2009年7月)。二つの時間割と、会議ひとつがメイカーに負わせる代償の出典。Google「Speed of Code Reviews」『Google Engineering Practices Documentation』は、集中している作業をレビューのために中断しないこと、そして一営業日以内に答えることの出典。Pinterest の事例は Brian Donohue「Three day no-meeting schedule for engineers」(2018 年。Pinterest のエンジニアリングブログに載り、本人のサイトに転載)。対抗原理はトヨタのアンドンで、出典はトヨタ自動車『Toyota Production System』(global.toyota)。

原典を読む

肖像:Kevin Hale, CC BY-SA 2.0 · Wikimedia Commons

引用するとき

Hammurabi『第113条 メイカーの時間割、マネージャーの時間割』 https://kanywst.github.io/hammurabi/ja/laws/makers-schedule/

BibTeX
@misc{hammurabi-makers-schedule,
  title  = {メイカーの時間割、マネージャーの時間割},
  author = {{Hammurabi contributors}},
  note   = {Hammurabi, § 113},
  url    = {https://kanywst.github.io/hammurabi/ja/laws/makers-schedule/}
}

本文は CC BY-SA 4.0 です。Hammurabi の名前と記事へのリンクを添えてください。

XBlueskyはてブLinkedIn

関連する法則

GitHub で誤りを指摘する