こんにちは。開発マネージャのAYです。
開発を行っているのであれば、知っておいた方がよさそうな（もちろん開発以外でも適用できますが）法則について、色々ありますが、そのうちの一つを紹介したいと思います。興味がある方は別途調べてみてください。
パーキンソンの法則について
パーキンソンの法則は、2つの法則で構成されます。
第一法則：仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する
第二法則：支出の額は、収入の額に達するまで膨張する
今回、特に取り上げたいのは「第一法則」です。これは、各個人のタスクに対する目標工数設定で利用したい法則ですね。
サンプルケース
こんな話は皆さんのところでもよく出てくると思います。
- 営業Aさん「この機能を開発するのにどのくらいかかりますか？」
- 開発Bさん「3日くらいかかります」
- 営業Aさん「わかりました」
営業Aさんの1)は、たいていの場合、依頼をしたらどのくらいの期間で出来上がるのか、ということを質問しています。
開発Bさんの回答の3日くらいかかります、って何が3日くらいかよくわかりませんね。
開発Bさんの回答の内容として想定できることは例えば以下の３ケースに分けられます。
- 開発作業の実工数（作業自体でかかる時間）として3営業日(8×3=24H)かかる
- 開発の実工数としては2日だが、バッファ(余裕)を1日見て実作業として3日見て欲しい
- 開発の実工数としては1日(8H)でできる内容だが、他作業の兼ね合いもあるので、納期として３営業日欲しい
普段みんな色々な仕事を抱えているわけで、忙しい中限られた時間でコミュニケーションを取るため緻密に話ができなかったりしますが、このやりとりでも、いろんな意味に取れますね。
理想的な回答としては、例えば
実作業として最短で1日。確実に終わらせるための工数として最大2日見ておけば十分です。ただし、他の作業も並行して行なっており、３営業日を納期として見ておいてほしい。
など、実工数と納期を回答するのが好ましいでしょう。ケースによっては、バッファや納期自体の回答はマネージャの仕事になるので、担当ベースでは実工数のみを提示するということで良いと思います。
この時、注意したいのが、開発担当としては、実工数に過度なバッファを含めるべきではない、という点です。
パーキンソンの第一法則の考慮
パーキンソンの第一法則の内容としては、「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」ですね。
具体的にいうと、例えば、納期を「3日」とした場合、以下のようなケースが考えられます。
- 当初納期3日（実工数も3日）として提示したが、スムーズに開発が進んで1日でほぼ完了した。開発担当者Bは、完成度を高めるために残りの時間を使ったり、十分な動作テストを行うことで残りの時間をしっかり使って機能をリリースした
- 当初納期を3日で提示した。時間に余裕があるので、仕様検討を十分に（過度に）行い、2日間開発に着手することなく、3日目に完了させなければ！と着手して開発を完了させた
- 1日あれば終わりそうな仕事だが、ピッタリの納期を自分で回答してしまって余裕がない状態に陥るのが嫌なので3日と回答した．．．
これ、頑張って1日で終わって次の仕事ができたのでは、、、ということです。１個目も２個目もちゃんと終わっていますが、１個目は余分な工数と次のタスク納期も十分に調整されていて、作業としてほぼ完了した作業に生産性の高くない作業に残った時間を割いたケース、2つ目は余裕がある状態でタスクが割り当てられた結果、仕様検討という名の「うーん、どうしよう」という実際の着手前の工数が過度に伸びてしまったケースです。3つ目は完全に守りに入っているだけの良くないケースですね。
その他でもこんなこともあるあるではないでしょうか。
- 取引先とのミーティングを1時間の枠として設定した。15分程度で会議で話すべき内容について全て結論が出たが、残りの45分があるので、せっかく取引先にも時間を調整してもらったし残りの時間もしっかりミーティングを行った
限られた定時の8時間の中で結果を出すための作業をするとした場合、忙しい中でできる限り成果をあげなければいけません。
当初から余裕がある納期を設定してしまうことは、特に経験をたくさん積んで成長すべき若い人にとっては良くないと感じています。
以下のようなところを考慮しつつ、予定工数の設定をしていただくのが良いと思います。
- 実工数として設定する工数は過度に伸ばさないこと（ちょっと足が出るかもくらいで良し）
- 必要な工程を明確化し、工程毎の工数も明確にして積算として実工数を出して仕事を進める（意味のわからない余裕を作らない。普段から細かい工程毎に作業を分割して計画を立てて進めることで、業務のスムーズな進行ができ、大きな工数のズレがなくなります。また、長期的には正しい工程設計や工数予測をするスキルが身に付きます）
- 実工数とは別に他部署やプロジェクト全体の中での遅延時リスクを考慮してバッファを別途設定する（実工数にはバッファを含めない）
- 早く作業が完了した時は、即時計画を見直せるなら見直すという文化を作る
最後に
今回の法則は生産性の低い時間を無駄に発生させないためのものです。私自身は過度な工数管理もまた時間の無駄であり、必要性が薄いものであると思っています。
その大前提として、以下2つが重要という認識です。
- 担当者が良い成果を出そうと前向きに取り組む文化があること
担当者が楽をしようという根本があったら厳しく管理をしていかないと成り立ちません。当たり前ですが各担当者が成果に対して前向きに取り組める環境を作ることが大切です。 - 計画の変化、失敗を前向きに受け入れる文化があること
計画の変化や失敗を受け入れない文化があると、当然のことながらリスクヘッジのためにみんな納期にバッファを持たせたがります。
計画の前倒しももちろんよし、計画が遅れることもある。全力で頑張っている上であれば仕方なし。失敗したとしても、同じことを繰り返さないように次に改善するための材料とできるのであれば良いのではないでしょうか。また、致命的な失敗が発生しないようにするのはマネージャの仕事だと思います。
前向きに仕事に取り組んでこそ、成長や将来に向けてのキャリアアップにつながっていくものと思います。そして、日頃の仕事のアウトプットの積み重ねが自分の資産としていずれ返ってきます。
弊社は失敗を恐れず、前向きにチャレンジすることを最優先とする文化を持って仕事をしています。
そんな環境で仕事をしてみたいけど「今そうではないなぁ」というあなた！弊社は一緒に働く仲間を募集中です。
文：開発マネージャーAY
