仕事が遅れるメカニズム
残業ってなぜ発生するんでしょう。
答えはもちろん「期限に遅れそう」だからですね。正直それ以外で行う業務は残業とは言いません。もしする必要性も特にないのに「残業代が欲しい」等、個人的な理由でにやっているのだとしたらそれは"生活残業"ということになります。
では、必要に迫られて残業をしなければならないシチュエーションってどういうものがあるのでしょう。それは大別して
①期限内に終わらないボリュームの仕事を与えられたから
②想定したスケジュールより遅れるように進めているから
の２つがあるのではないでしょうか。前者はそもそも仕事を与えた側の責任であり、また与える資格を持つほど能力が足りていないために起きる人為的労災…通称『人災』です。端的に言えば、与えた人間が無能だったわけです。こればかりはそんな現実感覚のない人を昇格させた人事制度を恨むしかありません。私なら社長のところに直談判に行くかもしれません。直談判に行って、素気無く追い返されるところまでがワンセットですが。
しかし、後者は基本的に自分自身の責任で発生しているものがほとんどです。
「割込みが入った」
「想定外のことが起きた」
など理由は色々あるのでしょうが、それすらも予測して対応できるよう準備ができていなかったこと…つまりはリスクマネジメント不足が問題なだけです。
プロジェクトとは「やったことがないことを、期限までに終わらせること」であり、その本質は"不確実である"ことにあります。この不確実性というリスクを乗りこなすには、
「不確実性をそのものを小さくする」
「発生時の影響に備える」
「徐々に不確実性を小さくする」
３つのアプローチで攻める必要があります。
３つのアプローチのうち「不確実性そのものを小さくする」というのは、言い換えれば
プロセスを設計すること ＝ 仕組み化すること
です。マネージャー、あるいはマネジメントを行う立場の方は、まずこのプロセスを設計することから始めなくてはなりません。国で言えば「法・制度」を作る、企業であれば「規則・手順」を作るのと同じです。プロジェクトを進めるにあたって、そのプロジェクト進行上のルールや手続き、手順などを明確にしなくてはチームメンバーは何もできません。できたとしても、無法地帯でできることなんて問題しかありません。
たとえば、スケジュールの進行状況を確認する際を例に挙げると、私の場合は「プロセスの設計」として上記リンクのようなルールで行っています。チームメンバーにもそれをつたえます。初日は安全運転でできるだけ多くの人に実際に例を挙げてやっているところを見てもらったりします。どのプロジェクトでも汎用的に使えるのでこの辺までは必ず実施します。
こうすることで、ルールや手順などがまったくないことによる「不確実性」をギリギリまで減少させるわけです。
ですが、それだけでは完全に不確実性が無くなるわけではありません。かならずプロジェクト固有の事情や条件があって、「こういう場合はどうすればいいんですか？」と聞かれるような状況になることがあります。
マネジメントは結果にコミットしてはいけない
よくビジネスの世界では「結果にコミットしろ」と言います。これは間違いではありません。『コミット』とは、
・約束を守る
・強くかかわる
という意味で使います。
プライベートジムであるライザップのコンセプトで、CMや広告で「結果にコミットする」という言葉を大々的に使っているため、見たことがある人もいるかもしれません。要するに、「結果（鍛えられた肉体になること）をお約束します！そのために当社は皆様のトレーニングに深くかかわってお手伝いいたします！」と言っているわけですね。
ビジネスにおいては「結果」「成果」がなければ成立するものではないので、契約や評価などは結果にコミットするのは当然です。それはわかります。
ですが（プロジェクトに限らず、すべての）マネジメントに限って言えば、「結果」を管理するものではありません。あってはいけません。結果にいたるまでのプロセスを管理するものでなくてはなりません。自分自身の仕事であれ、チームの仕事であれ、結果にコミットしていては遅すぎます。手遅れになってしまうのです。
たとえば、世の中の多くのマネージャーが「マネジメント」と聞けば、これしかやっていない…と言う人も多い、先述と同じ「進捗管理」を例にとってみましょう。プロジェクトの現場でも「進捗会議」という名の定例会議がよく行なわれていると思います。
ですが、考えても見てください。
進捗管理とはいったい何を管理するのでしょう。
「先週より〇％進みました」
「いま進捗率〇％です」
「オンスケです」
これらは進捗会議などで非常によく耳にするフレーズですが、進捗率を聞いたからといって何かできることはあるのでしょうか。進捗率というのは既に出てしまっている「結果」です。結果となってしまった状況は、もうコントロールすることはできません。それを聞いても何もコントロールはできないのです。
そもそも進捗の管理は、仕事が遅れないようにコントロールすることを目的にしているにもかかわらず、結果論として
「〇日遅れです」
と聞かされてから慌て始めることしかできていません。つまり「進捗管理」と言っていながら結果となってしまったものを確認しているだけで、管理（監視・コントロール）することは何一つできていないのです。
そう言ったマネージャーによくあるのは、
「なんでこんなやり方してるんだ！」
「なんでこんなに遅れているんだ！」
「なってこんなに不良が発生しているんだ！」
「あーあ、もっと〇〇しとけばよかったのに…」
と言ったように、後出しジャンケンのように結果から持論を導き出そうとします。「そう思ってたんなら、最初から言えよ！」と言いたくなりますが、彼らはプロセスにコミットしなければならないというマネージャーの原理原則を理解していないため、絶対にそうなることはありません。
出てしまった結果に対して「何で…」と言うだけなら、別にマネージャーでなくても新人でも誰でもできます。「結果」しか見ようとしないマネージャーと言うのは、もうそれだけでマネジメント領域の不良在庫のようなものです。
みなさんの周りにはこういう上司…いたりしませんか？
（余談）責任の所在
ちなみに。
なにか起きてから「責任をとる」と言うタイプの人は、多くの場合がこの「結果にコミット」するタイプの人です。「プロセスにコミット」しないタイプの人…と言った方が良いかも知れません。こう言う人は、多くの場合が『無責任』です。
「何かあったら俺が責任取るから」
なんてカッコイイこと言ってる風な先輩や上司って憧れますよね。でもこれ、実は責任感があるわけでもなんでもないし頼れもしないんです。少なくとも「責任」と言うカテゴリにおいては、ただの無責任でしかありません。
このことはビジネスにおける「責任」の所在のあり方について、今一度想いを馳せてみればわかると思います。
そもそも、責任感が強い人は「失敗しない」ように取り組みます。
ビジネスはお客さまがいて初めて成立するものです。失敗してお客さまに迷惑をかけていいはずがありません。仮に失敗した後に謝罪してくれる…と言われても、ビジネスとして失敗した結果はかわりません。
「結果にコミット」するというのであれば、失敗しないために最大限努力する姿勢が重要です。
「何かあったら俺が責任取るから」
というのは、「何か（問題が）起こるまで何もしてくれない」「失敗するまで完全放置する」と言うことの裏返しでもあるのです。よく企業が不祥事を起こして経営層が記者会見などで謝罪するシーンがありますが、これも「結果にコミット」しようとせず、無責任を貫き通したからこそ起こしているにすぎません。
だいたい…一緒に謝ってくれる先輩や上司って…問題起こすだけ起こさせておいて「謝ればなんとかなる」と思っているだけの無能と一緒じゃないですか。
私なら「謝らなければならない状況なんて、絶対作らせてやんない」という気概で部下や後輩に接しますけど…まぁそれはそれでウザがられることもあるので、どうしても自分でやりたいっていうのであれば、私も無理強いはしません。ただし、強い責任意識だけは求めるようにしていますけども。
マネジメントができるのはプロセスだけ
時間軸が行き過ぎてしまって問題を起こしてもすぐに気付いて戻ることができるようなものであれば警戒する必要はないのでしょうが、マネジメントの場合、通常はそうはいきません。時間軸上の管理では後戻りが出来ないからです。
ビジネスをマネジメントするときに必要なことは出てしまった結果に対して文句を言うことではなく、結果が出るまでの「プロセス」に働きかけて理想とする結果を導き出すことです。
現在地を常に確認し、ここまま進めばどうなるのか見通しを立てながらこの先に対してどうすべきなのかを「案内」をする。カーナビのような精緻なコントロールが求められているのです。
プロジェクトマネージャーはもちろん管理職もそうですし、経営層だってコントロールする対象や規模が異なるだけで、同じような役割が求められます。少なくともエラそうにふんぞり返っていること、会社の経費で飲み食いすることが仕事と言うわけではありません。
ここで問題となってくるのが、「現状」と「見通し」をどうやって知るかという点です。多くのマネージャーは先述の通り「現状」にしか焦点が当たっていません。だから結果ばかり気にします。
ですが結果ばかり気にする割に、その結果すらまともに把握できていないマネージャーも多く存在します。これは、マネージャーが持つ典型的な悩みの一つで、「プロジェクトの現実をつかむことができない」という課題があるからです。
この記事の中でも進捗報告を例にして説明していますが、プロジェクトマネジメントに関わった経験がある人なら、「オンスケです」「あと10パーセントです」という報告が現実を必ずしも表していない、むしろそうではない場合が多いことをよくご存知でしょう。
中間報告であっても、その内容が結果をベースとした報告である以上、そこから「現状」を正確に把握するのは想像以上に難しいことなのです。
つまり、結果ではなくプロセスを管理するには「現状」だけでなく…と言うかそれ以上に「見通し」を正確に把握する仕組みが必要だということになります。
ここでも書いていますが
私の場合、チーム内では「進捗率」基準による報告は原則用いません。用いても意味がないからです。進捗率は、主におおよその達成率を認識、共有するためのものであり、報告に用いるものとしては適切ではありません。マネージャーが本当に欲しい情報は、「どれだけ進んだか？」はなく、期日に対して「本当に間に合うかどうか」です。この目的が達成できるような報告でなくては意味がありません。
例）（順調な場合）
「あと〇日で終わる予定です」
（少し遅れ気味の場合）
「あと〇日で終わりますが、少々残業が発生します」
少なくとも私の行うマネジメントのなかでは、「現状」よりも「見通し」を重視しています。「現状」を確認しないわけではありませんが、「現状」オンリーでは信憑性に欠くため、「見通し」とセットにして初めて信用に足る報告として受け取るわけです。
従来の進捗管理には問題がある
そもそも、一般的な進捗管理をおこなう場合、基本的には「計画」に対して
①できるだけ計画を守る
②計画と実績の差が開けば計画を見直す
③計画に対して「どれだけ進んだか」を見る
というのが当たり前…と言われていました。しかし、これらのアプローチには大きな問題があります。それは、「計画には、計画を立てた時点で分かっていることしか盛り込めない」という点です。何を当たり前のことを…と言われるかもしれませんが、この大前提を理解していないまま管理しているマネージャーは意外と多いものです。しかも、そもそもプロジェクトとは"独自性"といって、必ずどこか「ゃったことがない」ものに取り組むわけですから、全てがわかっている…なんてことは絶対にありません。分かっていることのほうが少ないことも多いのです。
先ほどの「不確実性」を視覚的に表現すると、一般的に
プロジェクトの進行とともに、見積りのバラツキ（変動幅）がどのように推移していくのかを表す「不確実性コーン」によって説明されています。
プロジェクト開始時には、お客さまやスポンサーの要求はあいまいです。
最終成果物のイメージもモヤーッとしいています。中間成果物を定義しようにも、最終成果物があいまいで、さらに「ゃったことがないこと」に取り組むのですから限界があります。
このような状態で立てた計画に対して割込みや想定外を一切無視して「スケジュール遵守！」と盲目的に強制すれば、無理が生じないわけがありません。そして無理が生じると
「仕事が遅れている」
状態となるわけです。明らかにマネジメント自体に問題があるにもかかわらず、一人ひとりの担当者にしわ寄せが行き、あまつさえ遅れている責任を叩挙げして、遅れているというそのこと自体に対し、担当者の評価が下げられてしまう事態にまで陥ってしまうわけです。
元来、見積り時点、計画時点から徐々に変化する状況にあわせてスケジュールだって変化していくべきですが、基本的に「仕様変更」と言われるようなビッグイベントでも起きない限り、スケジュールそのものを見直すようなことをせず、メンバーに一方的に負担をかけているマネージャーは非常に多いのではないでしょうか。
見積りはギャンブル
先ほどの不確実性コーンを見てもわかるように、プロジェクト活動に対する見積り精度というのはそもそも低いものです。工場ラインの単純作業の繰り返しのようにはいきません。そしてこれは金額的な見積りだけでなく、工数見積り…つまりスケジュールの見込みに対しても同じことが言えます。
もちろん「だから適当でも構わない」といっているわけではありません。
お客さまの目線に立てば、そうはいっても契約した以上は、「その見積りで進めてくれないと困る」と言う想いはあるでしょう。最初に計画した予算にも限りがあるので、いくらでも無尽蔵にポンポンと出せると言うものではありません。価格が下がる分には喜ぶかもしれませんが、増えるのは困るはずです。
今後も良好なビジネスパートナーであり続けようと思ったら、極力お客さまの望みに適った運用を心がける必要はあります。
そういった事情を鑑みれば、見積りの精度は高い方が良いに決まっていますが、それでも当初の見積り時点の見込みを100%満たすようにマネジメントするのは、確率的に考えれば、相当な軌跡を期待するしかないでしょう。まずはその前提の上でコントロールすることを意識できなければ、前に進むことはできません。
仕事が遅れるメカニズム
プロジェクトは「ゃったことがない（=独自性）」を含む課題への取り組みであるため、本質的に不確実性が強くつきまといます。この不確実性をうまくコントロールして組織やチームをゴールまで案内することが、リーダー／マネージャーの役割であり、責任であると言っても過言ではありません。
不確実性とは「やってみないと分からない」ことですから、さすがにすべてのことを予測して、計画に盛り込むことは不可能です。
たとえば、
「メンバーが体調を崩して長期離脱するかもしれない」
「ユーザーによる要求の変更が頻発するかもしれない」
「設計に予想以上に時間がかかるかもしれない」
「不具合の数が想定より多かったりするかもしれない」
これらのことは「起こるかもしれないし、起こらないかもしれない」ことで、一般的に「リスク」と呼ばれるものです。リスクは、頻繁に起きやすいようなものなどはある程度予測しておかなければなりませんが、その対策には限られた選択肢しか存在しません。
そしてリスクが目の前にあるとき、私たちがとる最も一般的な行動は「余裕をみる」ことではないでしょうか。
たとえば、これから友人と食事に出かけるシーンを考えてみてください。
お店の平均的な予算は5000円です。このとき、財布に5000円だけ入れて出かける人は少ないでしょう。何かあってもいいように、少し余分に持っていこうとするはずです。
プロジェクトにおいても、私たちは意識的あるいは無意識的に、この余裕をみて見積るという行動をとっています。
ある作業に対して「10時間で終わるだろう」と見積っても、10時間で申告すればもしかすると割込み等が発生して遅れてしまうかもしれない…と考えてしまいます。そこで、各自が余裕をみて15時間、20時間、場合によっては30時間などと申告してしまうわけです。これは何も楽をしようとしているわけではなく、「約束を守らなければならない」という意識がそうさせています。
こうした余裕のことを「バッファ」と呼びます。
バッファとは衝撃を吸収する緩衝材のことです。想定外の何かが起こったとき、見積りよりも時聞がかかったときなどに、スケジュールへの衝撃（=影響度）を減らす役割を持ちます。
しかし、このバッファの適性な見積り方…と言うものは存在しません。だって、未来予知ができるわけでもないのに、起こるか起こらないかわからない、起こったとしてもどんな内容かもわからない、内容もわからなければ規模もわからないものをどうやって見積もれというのでしょう。しかも、プロジェクト計画時には「遅れないこと」を前提で見積っているため、
プロジェクト全体 ： プロジェクトメンバー個々人
で見積ったバッファの基準値は全く異なっているかもしれません。
たとえば、マネージャーは、プロジェクト全体の平均値として、適正工数のおよそ1.2倍くらいを見積っていたとします。けれども個々人は先ほどの例でいえば、１つの仕事をするのに10時間で終わるところを、念のためにと多めに見積って「15時間かかる」と言ってしまえば、既に1.5倍かかってしまうことになってしまいます。
『不確実性』という曖昧を助長させる要素があるがゆえに、バッファの見込みも不確実すぎて、正しく見積ることなんて不可能なのです。
また、せっかく見込んだリスクも杞憂に終わって、オンスケ（ジュール）で進められた場合は、バッファを返還すればいいのですが、多くの場合、そうはなりません。それは、
パーキンソンの第一法則
（仕事の量は、与えられた時間を消費するまで膨張する）
学生症候群
（余裕時間があればあるほど、開始する時期を遅らせてしまう）
といったバイアスが邪魔をするからです。
こうして、作業が早く終ってもバッファが消費されてしまいますが、逆に終わらなかった場合や遅れてしまう場合にはどうなるでしょう。
プロジェクトは多くのタスクが相互に依存し合っていて、それらが統合される流れを持ちます。
最終成果物を生み出すために、中間成果物とタスクにブレークダウンされているのですから当然です。ここで、ある中間成果物が早く生み出された、あるいはタスクが早く終ったとしても、その分プロジェクトの進行が早まるでしょうか？
…そうとは限りませんよね。
たとえば、メンバーの３人がある作業をしていて、その３人ともの作業が完了すると、次のステップに進めるようなスケジュールがあったとします。
もし、作業Aが予定よりも２日前倒しで完了し、作業Bが１日前倒しで完了していたとしても、作業Cが完了しなければ、作業Dを開始することはできません。
このことから言えることは、つまるところ「遅れだけが後ろに伝わる」とい
う事実です。チームでは、自分がせっかく頑張ってあるタスクを早く終わらせても、他のメンバーが担当しているタスクが遅れてしまえば水の泡になってしまいます。
こうした課題を、メンバーや部下一人ひとりに「なんとかしろ」と言っているだけでは、プロジェクトをコントロールしているとは言いません。そしてコントロールできていないからこそ、仕事はふとしたことから遅れるようになっているわけです。
仕事の遅れをコントロールするには
「じゃあ、どうすればいいの！？」
と聞こえてきそうですが、もしそう思っているのがマネージャー職、管理職、経営者だというのであれば、もう一度１からマネジメントを学びなおした方が良いかも知れません。
この「仕事」「ビジネス」をコントロールする／できる能力があるからこそ、多くの部下やメンバーの人生の上に立って指揮・指導する立場にいるわけですから、その役割と責任を忘れて他人に答えを教えてもらおうという姿勢はいただけません。そう言う人には、生暖かい目で「そんなことだから、組織や部下は仕事が遅れるんじゃないですか？」という言葉を贈りたいと思います。
とは言え、そうでない人、これからマネージャー職になっていく人たちに向けて、あえて答えの一例を挙げるならば
ＣＣＰＭ（Critical Chain Project Management）
がオススメです。ＣＣＰＭは簡潔に言うと、
プロジェクトの各タスクの予算やスケジュールをぎりぎりに抑え、バッファをメンバー個人に見積らせず、その分をプロジェクトバッファという余裕を設けておく管理手法
のことになります。純粋なＣＣＰＭでなくても構いません。ＣＣＰＭのエッセンスを取り入れて、バッファコントロールをするだけで見違えて対応できるようになっているはずです。
ここでは、あくまで仕事が遅れるメカニズムについて触れたかったので、あえてＣＣＰＭの詳細には触れませんが、少なくとも私が活用してきた中では、
プロジェクトを中心にした、最もコントロールしやすい
マネジメント手法であったと思います。
ＥＶＭ（Earned Value Management）よりも断然やりやすかったし、コントロールしやすかったです。ただまぁＣＣＰＭを運用しようと思ったら、マネージャーが相当プロジェクト内容に精通し、かつメンバー全体をコントロールできるだけの権限…と言うか、メンバーに信頼されるだけのコントロールスキルを持たなければなりませんけどね。
どちらにしても、「結果」を「確認」して、「問題」が起きてからギャーギャーわめくだけで「邪魔」しかしない上司やマネージャーでは、ＣＣＰＭに限らず、どんなマネジメントも不可能です。
結果にコミットするため、「プロセス」を「監視」して、必要に応じて「コントロール」できる準備と、体制作り、そしてそれらを実行する意識と意欲が無ければ、正しいマネジメントを行うことは難しいでしょう。
ちなみに、このことは自分で自分の面倒をみる「セルフマネジメント」でも同様のことが言えます。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。