タイトルは、ポール・グレアム氏（Yコンビネーター）の「メイカー（作り手）のスケジュールとマネージャーのスケジュール」(Maker's Schedule, Manager's Schedule) からの引用です。
マネージャーは多くのミーティングをこなすなど、1時間単位でタスクにあたりますが、エンジニア（プログラマ）は最低でもまとまった半日単位の時間を作業に必要とする、と書かれています。
日本語訳
エンジニア上がりのプロダクトマネージャーとして開発もプロダクトマネジメントも並行してこなしてきたのですが、意思決定のためのミーティングスケジュール、自身が開発を行うためのスケジュールをやりくりするバランスに腐心していました。
自身のタイムマネジメントで特に感じた点として、ミーティングとミーティングの間に1時間が3コマある時の開発生産性と、3時間まとまった程度の空きがある中での開発生産性は等価ではないことでした。同じ1時間あたりでも後者の生産性の方が数倍高かったように思います。この現象について2009年のポール・グレアム氏のブログで言語化されていました。
また、開発チーム自体のマネジメントや他チームとのやりとりも行うようになったことで、チームの生産性を上げるために気をつけるべきことを考えています。この記事では、エンジニアの時間の使い方と、チームの生産性を上げるためにマネージャーはどのように振る舞うべきかを考えてみます。
エンジニアには差し込みの入らない半日の時間が必要
They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started. 概してエンジニアは最低限半日の時間を使いたい。1時間単位ではろくにコードを書くことはできない。取り掛かるのにぎりぎり十分な時間である。
件のエッセイからの引用ですが、コードを書く仕事は取り掛かるエンジンがかかるまでに時間がかかります。私の感覚ではありますが、ビジネス的な意思決定や普段の生活での頭の使い方と開発とでは頭の使い方が異なっており、切り替えに時間がかかるように感じます。コードを書いたことない方には数学の証明課題など、普段と異なる頭の使い方を要する課題に取り掛かった記憶を思い浮かべていただくと良いかもしれません。
ビジネス業務と開発業務を1日の間に行き来していた時、頭のスイッチングコストが高く、自身のパフォーマンスについて「人と話していると、コンピュータと話すのが苦手になって、コンピュータと話していると人と話すのが苦手になる」と冗談を言っていました。
しばらく集中してコードを書いていると「フロー状態」と呼ばれるような集中状態になることがあります。楽しく作業に没頭している状態です。コーディングに限らず、作業に没頭して普段の数倍の生産性を出せた経験がある方は多いでしょう。
一方でマネージャーのスケジュールは、指示や意思決定のためのスケジュールです。1時間単位でミーティングを行ったり考えをまとめたり、開発などの実作業が伴うわけではないので、細切れの時間軸での動きになりがちです。
エンジニアチームのマネージャーには、チームメンバーがフロー状態を作りやすい環境の用意が求められます。
ミーティングを入れる時間
For someone on the maker's schedule, having a meeting is like throwing an exception. エンジニアのスケジュールにおいて、ミーティングは例外処理を行うようなものだ。
エンジニアが開発でフロー状態に入っているとき、ミーティングが入るとそのフロー状態は中断され、再度フロー状態に入るための時間を要します。これが「スイッチングコスト」です。
とはいえ、作業の進捗状況を確認することや、1on1などでミーティングは必要です。ミーティングはなるべく作業に入る前の朝か、作業が終わった後の時間帯である定時少し前に設定することが望ましいのだと思います。9~18時が定時の職場で15時などに入れると午後を完全に分割してしまうのであまり望ましくはないでしょう。
差し込みタスクへの対処
しかし、差し込みタスクはどうしても発生します。障害が発生したら今の作業を中断して対応しないといけません。ただし、障害もすぐに対処が必要なものと特に問題ないもの（誤報など）もあります。前者の深刻な障害はチームメンバー全員で対応にあたる必要がありますが、1人が対応に当たれば十分なものなどもあります。
障害対応の一次受けをする人を週によってローテーションしてみる取り組みを行うチームもあり、障害報がなるたびにフロー状態から呼び覚まされる人を減らす試みです。
スケールとコミュニケーションパス
人が増えると増えるほどにコミュニケーションパスが増加します。 n人がチームにいる時、それぞれがコミュニケーションをするとでコミュニケーションパスが増えていきます。
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiitaより引用
このパスが増えれば増えるほど、エンジニアにとって差し込みタスクになります。解決策としては、コミュニケーションのパスを1人に寄せるルール策定や、時間を寄せることなどが考えられます。例えば、仕様に関する質問はプロダクトマネージャーにまず寄せてパスを絞ることなどが考えられます。（プロダクトマネージャーは1時間単位でタスクにあたる「マネージャーのスケジュール」で動きます。）
また、特定の時間に答えるなどで作業中の差し込みが起きないように工夫することも考えられます。人が増えれば増えるほど、コミュニケーションパスが増えてコミュニケーションコストは増加します。この増加するパスに抗うことや、意識して断捨離することがマネージャーの役割の一つでもあるのだと思います。
おわりに
原文にあるように1時間単位でタスクにあたる「マネージャーのスケジュール」と半日単位でタスクにあたる「メイカー（エンジニア）のスケジュール」があることを見ました。
プロダクトマネージャーは概して「マネージャーのスケジュール」で動き、エンジニアのスケジュールとは違います。ここを頭に入れておかないとエンジニアの生産性を阻害してしまいます。エンジニアが少ない組織や、エンジニアへの理解が低かったりすると、「マネージャーのスケジュール」で仕事をするものだと思ってミーティングや差し込みをどんどん入れてしまうことがあります。これはお互いにとって不幸なすれ違いです。
また、フロー状態に入っているエンジニアに話しかけたらそっけない対応をされて悲しい思いをした方もいるかもしれません。これも不幸なすれ違いで、このスケジュールの違いをお互いに言語化して理解を進めることはなかなか難しいし伝える勇気がいることなのです。
Those of us on the maker's schedule are willing to compromise. We know we have to have some number of meetings. All we ask from those on the manager's schedule is that they understand the cost. メイカーのスケジュールにいる私たちは歩み寄りたいと考えているし、ミーティングに出る必要があることを理解している。ただ、マネージャーのスケジュールで動く人たちにはコストを理解しておいて欲しいのだ。
原文ではこのように書かれています。ただただマネージャーも、エンジニアもコストやスケジュールの違いを理解していることで円滑にチームが回るということなのだと思います。
「エンジニアリングマネージャーのしごと」でポール・グレアム氏の件のエッセイが紹介されていたのが記事を書いたきっかけになりました。
