なぜ締め切りは意味がないのか？ そして代わりにすべきこと
技術広報をしているとテックブログに携わることが多いと思いますが、記事の管理のために締め切りを設けている方も多いと思います。最近、この「締め切り」というものの必要性に違和感をもっていたところ、海外で参考になりそうな記事がありましたので、簡単に翻訳してご紹介します。
元の記事はこちらでコピーレフトです。
なぜ締め切りは意味がないのか？ そして代わりにすべきこと
締め切りはソフトウェアエンジニアにとって悩みの種です。2週間後に納期が迫っているのに全然終わらない……。なので、徹夜したり、いい加減なテストをしたり、手抜きをしたりして何とかやり遂げようとします。すると何が起こるのでしょうか？ プロジェクトはバグだらけになり、顧客は不満を抱き、エンジニアたちは疲れ果ててしまいます。
時にはバグが多すぎてソフトウェアエンジニアリングの基準に達していないこともあります。そのような場合、マネージャーは新しい期限を設定し、最初の期限はそもそも存在すべきではなかったことを明らかにします。さて、想像してみてください。2回目の締め切りを逃したらどうなると思いますか？ その通り、新しい締め切りが設定されるのです。締め切りが好きでしょう？
そろそろ「締め切り」を「プレッシャー」という本当の名前で呼ぶべきです。
締め切りがあるからといって、エンジニアのコーディングが速くなるわけではありません。ただ、労働時間が長くなるだけです。機能不全に陥っていないチームの場合は、締め切りの役割として、実装する機能の範囲を決められ、クライアントへ納品するための強制機能となり、早くクライアントへ納品でき早くフィードバックに対応することができます。
この記事では、なぜ締め切りがよくないことにも関わらず必要とされているのか、そして締め切りが生産性やモラル、ソフトウェアの品質にどのような害を及ぼすのかを説明します。
そして、より生産的でストレスの少ない代替案として「プリエンプションポイント」を提案します。プリエンプションポイントとは何か、なぜそれが有効なのか、そして締め切りと比較した場合の利点について説明します。
また、プリエンプションポイントについて説明した後、そのポイントの取出しポリシーがどのように価値を早期に提供し、締め切りを無意味なものにするかについても解説します。
この記事の最後には、チームを説得して締め切りを捨てさせ、これまで締め切りが役に立つと思っていた人たちを含め、すべての人がより快適に仕事ができるようにするためのちょっとしたまとめがあります。
なぜ締め切りは無意味なのか
締め切りの無意味さの根底にあるのは「結果をコントロールできない」という事実です。あなたがコントロールできるのはその結果を生み出すプロセスだけです。
たとえば今日からトレーニングを始めて、明日にハーフマラソンに出場することはできません。しかし、走る距離をコンスタントに増やしていくシステムを作ることはできます。
ベッドから出たくない日もあるでしょう。そのような日は、あまり走らないようにします。また、朝起きてから命がけで走る日もあるでしょう。バラツキがあるのです。それでも毎週コンスタントに走る距離を向上していけば、いずれマラソンを走れるようになります。
安定したペースで上達すれば、来年のマラソンを走れるかどうかの見通しがつくかもしれません。それまではどんな期限も無知な推測に過ぎないのです。
確かに、マラソンの時期がわかれば、その日に走れるように炭水化物の摂取量を調整したり、トレーニング方法を微調整したりすることができます。しかし、あなたが常に向上心を持ち、マラソン大会のかなり前の時期に走ることができなければ、期限を設定することは怪我やオーバートレーニングの元です。マラソンが開催させる日に走ることができない場合、参加することもできないのです。
長期的な目標には、一貫した短期行動と予測可能なパフォーマンスの向上が必要であり、無謀な一押しは必要ないのです。
また、締め切りは無意味であることに加え、次のような弊害もあります。
- 締め切りはチームのパフォーマンスを向上させません。締め切り目標を設定しても、納品が早くなるわけではありません。結果として、チームは実装する機能を減らすか、より長く働くようになります。
- 締め切りはインセンティブをずらし長期的な思考を妨げます。締め切りは長期的に予測可能で持続可能なパフォーマンスではなく、期限を守るために短期的な利益を優先させるインセンティブをチームに与えます。
- 締め切りは実行可能なものではありません。チームが期限に間に合わなかったとき、その後に生産的なことをするには遅すぎるのです。
それぞれのステートメントについてより詳しく説明します。
締め切りはパフォーマンスを向上させない
コンピュータの性能を上げるために「もっと頑張れ」「もっと危機感を持て」と応援する人はいないでしょう。コンピュータはいつもと同じ速度で数字を計算します。
確かにオーバークロックはできるかもしれませんが、マザーボードが石炭に変わり、電気代が破産宣告を受けるのは時間の問題でしょう。
コンピュータに特定の速度でプログラムを実行させたいなら、新しいハードウェアを買うか、より良いコードを書くべきです。目標を設定しても、システムの結果には影響しないのです。
ゴールを立てようが立てまいが、システムは出せるものを出す。
同様に、締め切りを設けたからといって、エンジニアリングチームのパフォーマンスが向上するわけではありません。
チームのパフォーマンスを向上させるには、マネージャーがシステムを改善する必要があります。たとえば、より多くの人を雇う、デプロイメントを摩擦のないものにする、自動テストを導入して手作業による検査の必要性を減らすなどの方法が必要です。
納期を早める唯一の方法は、プレッシャーによってチームを「過重労働」させ、メンバーの労働時間を長くすることです。一度や二度はうまくいくかもしれませんが、長期的に見れば過重労働は人を辞めさせることになり持続不可能な行為です。
一貫した体系的な改善によってのみ、チームはパフォーマンスの基準値を作成し、レバレッジを効かせ、継続的に成果を向上させることができるのです。
## 期限を区切ると、インセンティブがずれて長期的な思考ができなくなる
2つの営業チームがあるとします。一方は再現性のない予測不可能な収益の急増をもたらし、もう一方は一貫した継続的な成果を生み出しています。
期限に間に合わせ人に5万ドルのボーナスを支給するシステムでは、不安定なチームが運良く期限に間に合ったのか、過重労働をしたのかに関係なく報酬を受け取ることになります。
図1：5万ドルの期限を守る不規則なチーム
そのチームは、パフォーマンスの一貫した基準を設定していないため、四半期ごとに売上目標を単純に増加させることはできません。それは失敗のもとです。この場合、予測可能な収益がないため目標達成を運に頼ることになります。
さらにそのチームがすでに納期を守るために長時間労働をしていた場合、辞めてしまう人も出てくるかもしれません。
この矛盾は締切を設定することで生じることが多いです。そのせいでチームは長期的な一貫性や継続的な改善よりも、短期的な利益を優先するようになるのです。
W.E.デミングならこう言うだろう。
『短期的な利益は、経営のパフォーマンスを示す信頼できる指標ではありません。メンテナンスを先延ばしにしたり、研究を手抜きにしたり、他の会社を買収したりすれば、誰でも配当金を支払うことができます。- Deming, W. Edwards. Out of the Crisis, reissue (p.19). MIT Press. Kindle版』
では、その不安定なチームと、継続的にパフォーマンスを向上させながらも5万ドル達成の期限を逃してしまう予測可能なチームとを比べてみましょう。
図2：5万ドルの期限を守らない、一貫性のある予測可能なチーム
どちらのチームに所属したいですか？
私は間違いなく2番目がいいと思います。そのチームは、締め切りに間に合わなかったものの、常にパフォーマンスを向上させることができることを実証してくれたので、私は運に頼ることなく、より正確に売上を予測することができるようになりました。そうすれば、私は確かな根拠に基づいて意思決定ができるようになります。
さらに、長期的に見て継続的改善の原則を適用し続ければ、安定したチームはやがて不安定なチームのパフォーマンスを上回るようになるのです。
『余談ですが、私が「スナップショット測定法」を好まないのはそのためです。その代わりに、私はこの別の投稿で概説したように（https://lucasfcosta.com/2022/08/31/engineering-metrics.html）、一貫性と継続的改善のためにチームの勢いとコントロールを見る測定基準を好みます』
締め切りは実行可能なものではない
チームが締め切りに間に合わなかった場合、生産的な行動を起こすには遅すぎます。
締め切りに間に合わなくなったら、どのような行動をとればよいか考えてみましょう。
- 新しい期限を設定する
- 誰かを解雇する
- 機能をカットする
1つ目の新しい締め切りを設定することは、最初の締め切りがすでに無駄であり不要であったことを明らかにします。最初の締め切りがそうであったなら、2回目以降の締め切りもそうである可能性があります。
2番目の行動、つまり誰かを解雇することは、チームがすでに遅れているソフトウェアを提供する助けにはなりません。むしろコードを書く人が少なくなるため、ソフトウェアの完成が遅くなるのです。
3つ目の行動である機能をカットすることは、不要な作業をしていたこと、もっと早く納品できたことを明らかにするものです。機能をカットすることは有益ですが、締め切りのせいでそれを行うのは遅すぎるのです。
その他の行動には好きな名をつけてください。これらはすべて、行動が遅すぎたために非生産的なのです。
ルーカス、締め切りがないと何も納品できないぞ。パーキンソンの法則を知らないのか？
もし、あなたのチームが締切なしに納品できないのであれば、締切がないことが問題なのではありません。あなたのチームの顧客フィードバックに対する無頓着な態度が問題なのです。
顧客からのフィードバックにこだわるチームは、できるだけ早く納品し、顧客の声に耳を傾けることができます。
顧客中心主義のチームにとって、人為的な納期は無意味です。なぜなら、唯一の重要な「納期」はすでに存在しているからです。「価値あるものである限り、できるだけ早く」です。
さてここで「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」というパーキンソンの法則について触れておこう。
この法則が正しいかどうかは問題ではありません。なぜなら、締め切りを設けない場合、仕事は無限に拡大するとは言えないからだ。
さらに、パーキンソンの法則によれば、締め切りに安全バッファを加えると、仕事が膨張することになる。したがって、遅延の可能性と遅延の確実性を交換することになる。もしかしたら、仕事がわずかに膨張しただけで当初より遅れることになるかもしれない。
それは、パーキンソンの法則の当然の結果であることは言うまでもない。
"ギリギリまで待てば、1分でできること"
そして、たった1分でできることなら、どんなに素晴らしい結果が得られるか想像できるはずです。良いソフトウェアには時間がかかる。
締め切りでないとしたら、何でしょうか？
締め切りなしで活動するためには、チームはプリエンプションポイントを採用し、取り出しポリシーに注意する必要があります。
これでチームが短期間で同期的に実行可能なフィードバックを作成し、早期に軌道修正できるようにします。またチームが最も価値のある仕事を早期に、低コストで提供することを可能にします。
このセクションでは、これらの戦略についてそれぞれ詳しく説明します。
プリエンプションポイント
OSは特定のプログラムがいつ終了するかは知りません。実際、前もってそれを決定することはできません。したがって、プログラムが実行される時間のクォータを確立します。つまり、他のプログラムがCPU時間を確保できるように、そのプログラムの実行を停止するのです。さらに、OSは挙動不審なプログラムやメモリを過剰に消費するプログラムを終了させます。
製品開発ではOSの手法を模倣して、より良い結果を得ることができる。開発者が特定のタスクに取り組むとき、範囲を狭めるべきか、損失を減らすべきかを評価する一定の時間が存在することがあります。これがプリエンプションポイントです。
プリエンプションポイントは、同期的で一様なものであるため、締め切りとは異なります。
各タスクに任意に期限を設定するのではなく、タスクの状態を定期的にチェックすることで、同期的な決定論的フィードバックを実現するのです。
例えば、3日、5日、10日を超えたら、タスクマネージャーでタスクを色分けして表示させるのも一つの方法です。その都度、そのタスクを早く納品するための改善点はないか、機能を削減することはできないか、あるいは完全に破棄することはできないかなどを検討します。
朝会は、この同期的なプリエンプションフィードバックを導入する一つの方法です。朝会では、前述のようなアプローチについてチームと話し合うことができます。
プリエンプションポイントがうまく機能するのは、変動を蓄積させるのではなく、定期的にベースライン（望ましい最終状態）に戻すことで、望ましい最終状態からの逸脱を修正するのに役立つからです。
定期的なチェックと介入がない限り、このような小さな逸脱は蓄積していきます。そうなると、機能は当初意図したものとは全く異なるものになってしまいます。従って間違った機能を納品するか、その修正に余分な時間を費やすことになります。
図3：プリエンプションポイントにより、定期的に変動をベースラインに戻す
こうしたわずかなズレが時間とともに蓄積されていく様子を説明する方法のひとつに、ドナルド・ライナーセン氏が著書『製品開発フローの原則』で行っているコイントスの実験があります。この実験では、コインを何度もひっくり返します。コインを1回投げるごとに、表が出るたびに1加算し、裏が出るたびに1減算していきます。
下のシミュレーションでは、投げる回数が多いほど、合計がゼロ軸の上下に移動することがわかりますが、これは多くの人が予想するのとは異なるものです。
図4：トスの回数が増えるにつれて、合計が基準値からどんどん離れていく
プリエンプションポイントは、あたかもコイントスの回数を細かく分割してシリーズ化していくように作用します。その都度、蓄積された偏差を強引に基準値に戻す作業を行うのです。
それに比べて締め切りは、バラツキが蓄積されすぎてしまうことが多い。それは、タスクの状況を確認するのが遅すぎるか、不定期すぎるため、現状を基準値に戻すのが難しく、時間がかかってしまうからです。
先取特権は、変動要因の処理に有効であることに加え、次のような点でも締め切りより優れています。
- 実行可能で予測可能である。
- 見積もりが不要になる。
- 短期的な利益よりも継続的な改善を奨励する。
タスクの状態を定期的にチェックすることで、問題を早期に発見し、軌道修正することができるからです。もし、毎日タスクの状況をチェックしていたとしても、対策を講じるのがせいぜい1日遅れるだけでしょう。
また、プリエンプションポイントを使うと、特定の日に何かを完了させることから、「できるだけ早く」というタイミングに関係なく、小さな価値の積み重ねをできるだけ早く提供することに焦点が移るため、見積もりも不要になります。
プリエンプションポイントを使えば、3時間のミーティングを開いて物事がうまくいかない可能性のあるシナリオをすべて明らかにする必要はありません。その代わり、新しい情報には素早く対応することができます。
また、どんなに綿密な計画を立てても、すべてのエッジケースを予測することはできないため、プリエンプションポイントを使えば、本当の意味でアジャイルになる可能性が高くなります。
最後に、プリエンプションポイントは、短期的な利益よりも継続的な改善のインセンティブになります。なぜなら、締め切りが近づくと、開発者は、後で何が起ころうとも、締め切りに間に合うように手を抜かなければならないというプレッシャーを感じるようになるからです。
開発者が手を抜くと、バグが発生し、ソフトウェアのメンテナンスが難しくなり、さらにタスクが長引き、予測可能性が損なわれてしまいます。
締め切りとは異なり、先取りポイントでは、特定の期日までに納品する必要がないため、他のチームと協力しながら段階的に解決策を設計するスペースが自然に生まれます。
したがって、開発者とプロダクトマネージャーは、手を抜くのではなく、スコープを削減することに同意し、長期的な予測可能性とパフォーマンスを損なわないような代替戦略を考案するのです。
待ち行列のポリシー
あらゆるソフトウェア開発プロセスを待ち行列システムとしてモデル化することができます。このようなシステムでは、タスクが一方の端からソフトウェアに入ってきて、もう一方の端から結果が出てきます。
このシステムの性能は、時間に対する価値の関数で決まります。より多くの価値を提供し、その価値を提供するまでの時間が短ければ短いほど良いのです。
このシステムが提供する価値を高めるには、2つの方法があります。
1つ目は、システムの処理速度を上げてソフトウェアが結果を出す速度を速めること。
2つ目は、その時に最も短く最も価値のあるタスクをシステムに投入することです。そうすれば、処理速度に関係なく、常に最も価値のあるものを処理することができます。
この2つのアプローチの違いとして、1つ目の「処理速度を上げる」には、エンジニアの増員やプロセスの改善が必要なため、コストがかかることが多いです。
しかし、2つ目の方法はほとんど費用がかかりません。定期的にキューを見直し、タスクの優先順位付けを徹底することです。
病院が患者の健康状態に応じて治療を行うのと同じように、私たちはタスクの到着順ではなく、それぞれのタスクがどれだけ価値があるかによって処理を行う必要があるのです。
FIFO（先入れ先出し）は、エンジニアリングシステムにとって最適な待ち行列の規律であることはほとんどありません。つまり、作成された順番にタスクを処理しても、満足のいく結果が得られることはほとんどないのです。
私は、FIFOのキューイング規律を採用する代わりに、マネージャーには「重み付けされた最短の仕事」という手法を採用することを管理者に強く勧めます。
この手法は、最も短く最も価値のある仕事を次の仕事として選択するものです。
この手法を採用すると、マネージャーは特定の日付に価値を提供することにこだわらなくなります。その代わり、システムの処理能力が限られていることを認識し、その能力を最も価値のあるタスク処理に充てることに集中します。
つまり、システムがゴールの有無にかかわらずできる限りの出力をするのであれば、システムの処理能力を最大限に活用するためには最も価値のある仕事を投入する必要があります。
まとめ
私たちは締め切りを本当の名前「プレッシャー」と呼ぶようにしなければなりません。
締め切りがあるからといって、エンジニアが早く納品できるわけではありません。エンジニアを長時間働かせたり、不完全でバグだらけの機能を納品したりするだけです。
締め切りが無意味なのは、結果をコントロールできないという事実に起因します。コントロールできるのは、その結果を生み出すプロセスだけです。
結果をコントロールすることはできず、結果を生み出すプロセスしかコントロールできないという事実のほかに、締め切りの無意味さを示す理由が3つあります。
- 締め切りは、チームのパフォーマンスを向上させない。
- 締め切りは、継続的かつ一貫した改善よりも、短期的な利益を優先させる。
- 締め切りは、実行可能なものではありません。チームが期限に間に合わなかったときには、それについて生産的なことをするには遅すぎるのです。
「仕事は割り当てられた時間を満たすために拡張する」というパーキンソンの法則でさえ、締め切りが無意味であることは変わりません。
なぜなら、この法則は、締め切りが存在しない場合、仕事が無限に伸びるとは言っていないからです。むしろ、締め切りを設定すると、どんなに大きな安全バッファーを追加しても、その締め切りまで仕事が延びることを認めているのです。
それは、プロセスにプリエンプションポイントを導入することと、取出しポリシーに留意し冷酷かつ定期的に優先順位をつけることです。
プリエンプションポイントとは、チームがタスクの進捗状況を確認し、スコープを縮小するか、戦略を変更するか、タスクを中止して損失を完全に削減するかを決定するための一定の時間間隔のことです。
プリエンプションポイントは、実行可能で、予測可能で、ばらつきに強く、長期的な継続的改善のインセンティブを与えるので、締切よりも優れています。
最後に、待ち行列の規律に関して言えば、FIFO（先入れ先出し）がエンジニアリングシステムで使用するのに最適な待ち行列の規律であることはほとんどありません。それよりも、システムが常に最も短く、最も価値のあるものを処理していることを確認する必要があります。
そうすれば、システムの処理速度を向上させることはできなくても、その時点で可能な限り最高のものを供給することによって、システムが提供する価値を高めることができるのです。
