パーキンソンの法則：実在する法則を活用する
(theengineeringmanager.substack.com)- 仕事は与えられた時間を埋めるように膨らむため、締め切りのないプロジェクトは必要以上に長引き、機能追加やスコープ拡大の影響を受けやすい
- 挑戦的だが不可能ではない締め切りは、スコープ・リソース・時間のバランスを見直させ、チームがより明確な選択をできるようにする
- 締め切りは品質を下げるための仕組みではなく、健全な環境ではイノベーションと創造性を引き出す時間的制約として機能しうる
- 依頼でもソフトウェアプロジェクトでも、完了時点を明確に提案し交渉可能にしておくと、回答率や実行速度、組織のテンポとリズムが向上する
- 組織が大きくなるほど仕事が増える力も強まるため、週次の計画・実行・共有といった報告リズムが迅速な出荷を支える実務的な仕組みになる
締め切りがなければ仕事は増える
- Parkinson's Law とは、「仕事は完成のために利用可能な時間をすべて満たすように拡張する」という法則
- 締め切りのないプロジェクトは、実際に必要な時間よりはるかに長くかかることがある
- 自分たちで決めた締め切りすらなければ、緊急性が失われる
- 機能追加やスコープ拡大が起こりやすい
- 重要なのは、ただ無理やり短い時間に押し込むことではなく、プロジェクトの制約を意識的に扱うことにある
Iron Triangleから見る締め切りの役割
- Iron Triangleは、プロジェクトの3つの制約を合わせて捉える考え方
- スコープ(scope): 完了すべき作業
- リソース(resources): 作業に使える人員とツール
- 時間(time): 作業を終えるために与えられた期間
- 1つの要素を変えると、残りにも影響が生じる
- より多くの仕事をこなすには、より多くの人員かより多くの時間が必要
- 「良い・速い・安い」のうち2つは選べても、3つすべてを手に入れることはできない
- 時間の制約が緩いと、チームプロジェクトのスコープは残された時間を埋める方向へ膨らみやすい
良い締め切りと悪い締め切りの違い
- 締め切りに対するよくある反論は、「偽の締め切り」が質の悪い成果物を生むというもの
- しかし問題は、締め切りという手法そのものよりも、誤った適用に近い
- 健全な環境で挑戦的なタイムボックスを設定すれば、イノベーションや創造性が生まれうる
- 逆に有害な環境で不可能なタイムボックスを課せば、予想どおりの否定的な結果が生じる
- 良い締め切りは外部への責任感を生み、何を含めて何を除外するかを明確に判断させる
コミュニケーションにも締め切りは効く
- 誰かに仕事を依頼するときは、いつまでに終えてほしいかという明確な推奨時点を先に示したほうがよい
- 提案は明確であるべきだが、交渉可能な状態で開いておく必要がある
- アンケートを「いつでも回答可能」として送るのと、「明日までに回答が必要」として送るのとでは結果が変わる
- 締め切りがあれば、より早く、より高い回答率を得られる
- この違いは、大企業で1年間繰り返されるほど、さらに大きく積み上がる
週次リズムで実行力を高める
- 効果的なリーダーシップには、明確なテンポとリズムが重要
- 締め切りが快適圏の境界にあるとき、実際の前進が生まれうる
- たとえばプロトタイプに1か月かかりそうなら、今週末までに何を出せるかをチームに問いかけてみることができる
- 人は1週間でやり遂げられることを過小評価する傾向がある
- 複数のチーム、プロジェクト、作業に週次の報告リズムを組み込める
- チームは毎週計画し、実行する
- 進捗を誰でも見られる場所に共有する
- 金曜午後に進捗を整理して共有する習慣が生まれる
- 締め切りは、優雅さ、善意、人が動き心地よく働く方法への理解と合わせて使うと強力なツールになる
- 組織が大きくなるほど、パーキンソンの法則とより強く戦わなければならず、成功すれば数万人規模の組織でも素早く出荷できる
1件のコメント
Hacker News のコメント
新しい職場で数週間たったころ、上司に「私たちには仕事をするスピードがあり、あなたもそのスピードに合わせる必要がある……リーダーシップが、私たちはもっとずっと速く出せると考えれば、常にそれを期待するだろう」と言われたことがある
その仕事を辞めるころには、月曜の昼前に1週間分の仕事を終え、残りの時間は勘を鈍らせないために探索的なプロジェクトをしていた。だから、パーキンソンの法則が完全に病的な形で働くのも見た
ただし、間違ったものを速くリリースするのは、単に間違ったものをリリースすることにすぎず、無理に絞り出そうとすると自然に生じる結果である。「500万ドルの問題を100万ドルで解こうとするから、実際の問題を解決しない悪い選択を強いられ、結局は列車を戻して線路を敷き直すのに1000万ドルかかる」といった言い方をよくする。多くの場合、チームが選ぶ「近道」は、要件を満たしきれなかったり、急ぐあまり計画が抜け落ちたりして、かえってプログラムを長引かせる遠回りになる
要点は、人々は改善のために時間とリソースを再投資する価値をうまく見られないということだ。手が空いている状態は失敗ではなく、より高い強度の時期が来たときに備える方法である。時には、些細な作業により多くの時間があることも健全な状態だ
最近は最適化という考えに執着しすぎているが、時間が常に何かで埋め尽くされるときに生じる深刻な問題は、ますます見過ごされているように思う
彼らにしてみれば、どうせ複雑なプロジェクトに長時間を費やすことを強いられるなら、少なくとももっと金をもらえる場所でやったほうがいいからだ。結局残るのは、一生懸命働くが腕は劣る人たちである。健全な会社には、つらいが単純な仕事を進んでやる人たちと、炎上しているごみ捨て場のようなプロジェクトを救ったあとコーヒーを5杯飲む人たちが混在している必要がある
スコッティ：「実際にはどれくらいかかるんだ？」
ジョーディ・ラ＝フォージ：「1時間です！」
スコッティ：「本当にかかる時間をそのまま言ったわけじゃないだろうな？」
ジョーディ・ラ＝フォージ：「もちろんそのまま言いました」
スコッティ：「坊や、人々に君を奇跡を起こす人だと思わせるには、まだ学ぶことが多いな」
これを助言として受け取るのは奇妙だ。50ドルの問題を5000ドルで解こうとすれば、約5000ドルを無駄にし、次のプロジェクトは7000ドルになるだろう
大手クラウドプロバイダーで働いていて、これを直接見た
最初は、すべてにあまりにも時間がかかるのが本当に気に障った。以前は時間と財務のプレッシャーがあるスタートアップにいて、すべてを今すぐやらなければならず、終わらせるインセンティブがあった
そのクラウドプロバイダーは正反対だった。すべてが遅かった。1日で終わる仕事に1週間かかり、1週間で終わる仕事に1か月かかった。最初は、レビュー手順が多く、細部の確認が多いからだと合理化していた
振り返ると、パーキンソンの法則がドミノ倒しのように働いた結果だった。会社には全員に永遠に給料を払えるほどの金があり、そのため財務上の制約がなくなっていた。時間の制約も、いくらでも説明で回避できた。だから仕事は、ただいつか終わるという形になる。ほかのチームに依存すると、そのチームも外部からの責任をいつか処理し、そのせいで自分の仕事も遅くなる
より大きな組織は、スケジュールを延ばすことで対応する。ディレクターやVPは実際の実装ができないのでほかにやることがなく、延びたスケジュールはまた、より多くの無駄で埋められていく
粘り強く創造的な人たちがただ押し切れば、大企業に勝つことは多い。最近の例なら Cursor AI を見ればいい。Microsoft は Cursor を作るのに完璧な立場にあった。自社チームと OpenAI を通じて最も多くの AI の知識があり、AI 計算のための巨大なデータセンターもあり、最も使われているコードエディタである Visual Studio Code も持っていた。それでも Cursor が入ってきて、より良い製品を作った
Jeff Bezos は「あなたのマージンは私の機会だ」と言った。官僚制にも同じことが言える。官僚制があるところではどこでも、「あなたの官僚制は私の機会だ」と考えればいい
たとえば親しい友人と一緒に何かをするときは、いつも期待以上にやるだろうが、巨大企業に対しては何の関心も湧かない
初期資本主義の魅力的な効率性は、分散化され小規模な構造から生まれた。国を上から下まで統治することはできず、下にいる人々に自分の仕事をさせるのが最も効率的である
ところが今では、一部の企業はほとんどの国よりも大きくなり、私たちは出発点に戻ってしまった。ただし透明性と民主的な規制は欠けている
大きなシステムと複雑性を扱う、より良い方法が必要だ
ただし「なぜ」については別の結論に達した。法律事務所は本質的にリスク回避的である。だから細部を確認するのに時間がかかり、それが時間やコストよりも重要になる
プロジェクト管理の3つの制約である品質、時間、コストの観点で見ている。法律事務所、そしておそらくそのクラウドプロバイダーも、品質を優先したのだ。そうすると時間かコストのどちらかが打撃を受ける
高品質 + 高速 = 高価。高品質 + 低コスト = 時間がかかる
人によって動機づけられる対象は異なる。プレッシャーで動く人もいれば、報酬で動く人も、問題解決で動機づけられる人もいる。
問題は、一部の人にとって動機になる戦略を一律に適用すると、別の動機で動く人たちは動機が弱まったり、むしろくじかれたりする危険があるということ。
個人的には 問題解決 が動機であり、それは機能する解決策をリリースするという意味と強く結びついている。人工的な締め切り、見せかけの表彰イベント、報酬の中では丸め誤差程度でしかない金銭的報酬は、むしろやる気を下げる。みんな違う。
ただし、締め切りが自分を前に押し出してくれるという本文の前提にも同意する。個人的には、締め切りが プロジェクトの価値 に合わせて決められるのが好きだ。その価値は予算かもしれないし、別の外部制約かもしれない。
この考えは理論的には気に入っている。経験的にも良い観察に見える。ただし解決策には異論がある。
周囲の人たちの心をどうモデル化するかに左右される問題かもしれないが、こういう文章では解決策が 普遍的 であるかのように提示されるパターンが見られる。私の経験では、締め切り、とくに自分で決めた締め切りは、一部、たとえば40%ほどの人には非常に効果的だが、万能薬ではない。
パーキンソンの法則を説明し、人によって効くさまざまな解決策を提案する、より一般的な理論があるとよいのではないかと思う。
「締め切りは好きだ。締め切りが過ぎていくときのヒュッという音が好きだ。」 - Douglas Adams
私にとっては締め切りがあってもなくても大差ない。私の脳が時間をそういう形で重要なものとして認識しないからだ。
もちろん、それを管理するための戦略はあるし、薬もある程度は助けになる。だが自分で締め切りを決めても、守れる可能性はない。
どうすれば締め切り設定の支配階層に上がれるのかは分からないが、誠実な仕事、細心の注意、証明可能な成果によってそうなるのではないことは確かだ。
完全には納得できない。最大の問題は、管理者たちに「パーキンソンの法則は実在する」と教えると、不合理な締め切りを設定しようとする傾向が生まれ、全員が被害を受けることだ。
もちろん「私たちはあまり気にしないので10年後にリリースしてもよい」というのは反対側の極端だ。
開発者が基本的に自分の仕事がリリースされることに関心がない、というのはまったく事実ではない。関心がないのだとしたら、それは締め切り不足ではなく会社の問題だと思う。極端な締め切りを課しても開発者が気にしないなら、締め切りに合わせるためにゴミを作り出すだけだ。
マネジメントとは、部下をだましてもっと働かせることではない。従業員が実際に関心を持つようにすることだ。私の知っている開発者たちは、私も含めて、何もリリースしないことやゴミをリリースすることより、顧客に良い製品を届けるときのほうが幸せだ。
しかし、私がもはや気にしなくなる状況に置かれ、敵対的な構図になれば、自分自身を守るために 管理者を操作 するだろう。自分のメンタルヘルスを最適化するし、そこには職を維持し、燃え尽きを避けることも含まれる。管理者たちがこの考えを好まないのは確かだが、原文に付け加えるなら「管理者操作も実在するので、必要なら使え」となるだろう。
この記事は 締め切り について核心を外していると思う。
締め切りの主な問題は「誤って適用される」ことではなく、通常は他人の優先順位を反映していて、それが自分の優先順位と合わないことにある。
締め切りが自分の最も効率的な優先順位づけの方法と完全に一致するなら機能するだろうが、その場合はそもそも締め切りは必要ない。怠惰の話をしているのではなく、パーキンソンの法則と非効率を論じるときは、最初から善意を前提にしている。締め切りを導入した瞬間、自分の作業分布を変えることになり、特定の作業量は減らせても、全体としては作業分布の シャノンエントロピー を増加させる。
例えば、客が1時間後に来るとしよう。掃除には45分、料理には準備15分とオーブンで焼く45分が必要だ。私のやり方なら、まず料理の準備をし、焼いている時間に掃除をする。そうすれば締め切りに間に合う。
問題は、妻がまず家を掃除しろと要求するときに起きる。おめでとう。客は料理を45分待つことになる。
外部から強制されたほとんどの締め切りも同じ効果を生む。「掃除」はずっと早く終わるようにするが、その余波は完全に無視する。たいていは他の作業に関心がないからだ。ただし、前の余波に対処しているせいで次に設定した締め切りを逃す場合にだけ関心を持つ。
逆説的に、このため人々はもっと「速く」働かせようとして、ますますきつい締め切りを設定する。もちろんこれは余波をさらに大きくし、最終的にはすべてを止めてしまう。
https://news.ycombinator.com/item?id=30000296
このパーキンソンの法則の解釈とは反対の観点であり、元の引用の意図に比べると、現在の解釈は過度に単純化されていると思う。
定義上、ほとんどの人は、正しい時間順序のような交絡変数をすべて調整した後でさえ、テーブルに座っている他の全員の本当の優先順位を把握できない。
週に一度の30分会議の中ではなおさら不可能だ。全員の知能がおおむね同程度だからだ。
たとえば10人の委員会で、議長が文字通り天才一人で、残り9人が単純で容易に予測可能なメンバーである場合は非常に例外的だ。そのような状況であって初めて、議長は他の9人それぞれについて、あれこれの仕事を正確に予測できる。
先延ばしする人間として、その逆命題は確実に真ではないと言える。仕事は残りの利用可能な時間に合わせて縮まったりはしない。
だから、この記事が擁護しているように任意の締め切りを設定するのは最悪のアイデアだ。特に長く続く作業では、チームをデスマーチに追い込み、プロジェクト崩壊に至らせるだけだ。
自分にとって最も良い方法は、チームに小さな増分を定義させ、その増分を作る過程で生じる問題をメンバーと一緒にデバッグすることだ。そこに締め切りは必要なく、細やかな関与、作業フローへの集中、現在進行中の直近の作業がまだ価値を持つかどうかを頻繁に話し合うことが必要だ。
仕事が膨らむ問題への解決策は、価値の低い作業を切り捨てることだ。締め切りの設定は、関与していない、または未熟な管理者のための怠惰な答えにすぎない。
第二に、あなたの言う「小さな増分」アプローチは、毎週金曜日に作業者がステータス更新を行う方式とかなりよく合っている。金曜日に報告できる具体的な成果を得るには、1週間で何を達成できるかを決める必要があるからだ。
筆者は重要な点を見落としている。この方式が機能するには、まず適切な環境が整っていなければならない。
支援的で健全な文化がなければ、厳しい締め切りは利益より害のほうが大きくなり得る。
成功するには、ミスを罰する理由ではなく学習機会と見なし、人々が機械の歯車ではなく認められ価値があると感じ、経営陣が目標と意思決定を透明に共有して信頼を築き、チームの努力を共通のビジョンに合わせる必要がある。
同じくらい重要なのは、厳しい締め切りが続いた後には、チームがプレッシャーの中で下した性急な判断を修正し、技術的負債を減らし、新しいツールや技術を探索して能力と士気を高める時間が必要だという点だ。
こうした基盤となる文化なしに記事のアイデアを実装すると、有害な職場環境を作る危険が大きい。
誤った環境での厳しい締め切りは、極度のストレスやバーンアウトにつながり、進捗を遅らせたり離職を増やしたりし得る。人々が自分の能力に自信を持てなかったり、ミスを恐れたりすると、意思決定の麻痺、私の言う「チームの凍結」が起こり得る。急いだ個々の貢献がまとまりのある全体へ統合されず、協業が断片化する可能性もある。経営陣が「象牙の塔」から現実離れした任意の締め切りを押しつけると、優先順位がずれ、不確実性が生じる。最悪の場合、財政不安の噂まで生み、チームの集中を乱しかねない。認められていないと感じるメンバーは、期待以上のことをしたり独自のアイデアを出したりしにくくなり、個人の潜在能力も失われる。
さらに、締め切りが休息なしの日常になれば、チームは推進力とモチベーションを失う。全力疾走を続けるプレッシャーは収益逓減を生み、解消されない技術的負債はソフトウェアに長期的な痛点を残す。時間が経つにつれ、チームは抜け出す機会もなく穴を掘っているように感じるようになる。
このスレッドでは、人々は互いに異なる二つの状況を思い浮かべているようだ。1年中、実際に必要なものより50%短い締め切りが続く高圧環境と、分析麻痺を避けて仕事を前に進めるため、個人的な挑戦として望ましい完了日を設定する状況だ。
後者は、ラリードライバーが集中を保ち、前へ押し進むために目標を設定することに近い。
ある意味で、週5日勤務は締め切りだ。金曜日までに仕事を終えなければならないからだ。
この「締め切り」は成果を強制する仕組みだ。
では、もっと良い締め切りが何か分かるだろうか？
週4日勤務だ。
ばかげて見えるかもしれないが、人為的に勤務週を短くすると、より速く働くようになる。
これがパーキンソンの法則が働く様子だ。