デキない人にありがちな「計画倒れ」の正体　なぜ、実行できないのか？

PDCAの実行フェーズでは、組織でいえば解決案を業務フローに落とし込み、チームであれば担当者にアサインし、行動スケジュールも切って予定通りにやりきることまでを含む。こう書くと比較的理解しやすいだろう。ただ、実際にこれから説明に入るにあたって紛らわしい用語があるので先に整理をしておく。

実行フェーズで最初に行うことは、前回の計画フェーズから受け継いだ解決案(課題解決のための方向性)を実現するために必要なアクションを考えることだ。このアクションを、本書では「DO」と表現する。

(本記事は、冨田 和成氏の著書『 鬼速PDCA 』クロスメディア・パブリッシング(2016年10月24日)の中から一部を抜粋・編集しています)

計画をうまく行動に移せるケースとそうでないケース

例えば、「会社の数字に強くなる」という解決案をDOにすると「簿記の本を読む」といったものが出てくる。

しかし、DOのままでは実際の行動に移しづらい。そこで、DOをもう一段具体的なタスクレベルに分解し、スケジュール設定までする。こうやってスケジュール化されたものを「TODO」と呼ぶ。

「今日中に駅前の本屋で簿記の本を3冊買う」「1週間ですべて読む」といったレベルの話になる。

つまり、解決案を分解したものがDOで、DOを分解したものがTODO。分解するたびに数は増えていく。わざわざアクションをDOとTODOで2階層にしている理由は、1階層だとDOの状態で仕事を抱えっぱなしになることが多いからだ。

簡単なDOや緊急性の高いDOならさすがにすぐTODO化して終わらせるだろうが、手間のかかりそうなDOや緊急度の低いDOほど「わかってはいるが着手しづらい」状態になりやすい。強制的に2階層で考える習慣をつけることで「DOまで考えたけど、まだTODO化していないな」と気づくきっかけとなる。

各ステップの解説に行く前に、PDCAサイクルがこのフェーズで頓挫(とんざ)してしまうケースを紹介しよう。

【実行できないケース1】計画自体が失敗している

ひとつ目が、計画自体が失敗しているときだ。計画が失敗する可能性としては次の3つが考えられる。

・計画がない =「まあなんとかなるんじゃないですか」
・計画が粗い =「課題はざっくり見えていますが、解決案はあまり考えていません」
・計画が無茶 =「課題も解決案もわかっています。絶対に無理だと思いますけど」

1番目の「計画がない」ケースはさまざまな職場で、時々起こることだ。例えば社長の思いつきで突然、新規事業が立ち上がるようなときだ。役員会レベルでは自分たちが実行役ではないことをいいことに、ノープランのままあるチームに丸投げをする。

言ってみればリレーで第2走者にバトンを渡し忘れている状態である。第2走者のチームリーダーはそのままでは走れないのでバトンを取りにスタートライン(計画フェーズ)に戻ろうとするが、社長の肝入りプロジェクトなので毎日のように役員が顔を出し、「まだ動いていないのか!」と怒り出す。しょうがないので手探りのまま動き出すも、課題すら見えていないので迷走を続けることになる。

または仮に役員会から計画が降ってきた場合でも、どう考えても人手が足りないのに、「それをどうにかするのが君の仕事だろ」と突き放されたら打つ手がなくなる。これが3番目の「計画が無茶」なケースである。個人のPDCAでは2番目の「計画が粗い」ことが非常に多い。

それを象徴するのが読書だ。ビジネス書からたくさんの刺激を受けて、「やっぱり自分ってこのへんが課題なんだよな」とせっかく気づいても、それを具体的な解決案に落とし込まないから9割の人は読んで終わりになってしまう。

【実行できないケース2】タスクレベルまで落とし込まれていない

計画はうまくいっても、それを組織の業務フローや個人のタスク、さらに具体的な行動スケジュールに落とし込むまで細分化していないので、結局やるべきことが不明瞭なまま時間だけが過ぎていくケースだ。あと一歩なのだが、その一歩が大きい。

世間でいう「計画倒れ」の正体はこれである。実はこのケース、積極的に権限移譲をする管理職が率いるチームでよく起きる。実際に職場で起きやすいのはこういった会話だ。

上司「本件で注意すべき点はこんなところだ。これ、お前一人でやってみるか?」

部下「あ、ありがとうございます! 課題も見えているので心配ありません!」

(1週間後)上司「そういえばあれ、どうなった?」

部下「実は、若干、方法で悩んでいまして……」

はたから見ると部下を信用している「いい上司と部下」の関係に見える。でもこの上司も部下も勘違いしているのは「計画ができていればすぐに行動に移せる」と思い込んでいることだ。

正直に言えば、私もかつて部下に同じことをしたことがある。私自身がPDCAの鬼だったので「これくらいなら部下も考えられるだろう」とタカをくくってしまったからだ。

権限移譲は部下のポテンシャルを引き出したり、短期的にはやる気を生み出したりするメリットもあるが、見極めを誤ると部下が苦しみ続け、逆に著しいモチベーションの低下にもつながりうる。

実行速度を上げたいのであれば上司は部下に対して「これをやれ」で終わらせずに、部下自身で「どうやってやればいいのか」を判断できる能力があるか正しく見極め、そのレベルに合わせてPDCAが軌道に乗るまで丁寧にフォローする必要がある。とくに曲者なのが優先度の高い解決案である。

優先度が高いものをいままでやってこなかったのにはそれなりの理由がある。実は想像以上に複雑な仕事で、前任者はそれを知って放置していたことかもしれない。その場合はやはり上司としても行動レベルのブレイクダウンまで手助けする必要がある。

ただし、逆にマイクロマネジメントになりすぎて、手取り足取り細かい指示を与えてしまうと部下の性格次第では著しくモチベーションが下がり、必ず成果に悪影響を及ぼすので、その点だけは注意したい。

【実行できないケース3】失敗することが恐い

いざ計画を立てても「情報が足りない」「思考の整理がついていない」「リスクが見えづらい」などの理由から仮説に自信が持てず、行動に気後れする人は大勢いる。中止にする決断を下すならまだしも、「どうしようかな。やっぱりやめようかな。でもなあ……」といつまでも煮え切らない態度をとるのだ。

当社で浸透している文化のひとつとして「行動ファースト」がある。「悩んでいるならやってみよう。やることで課題が見える」という発想だ。この発想のベースは仮説思考である。正解などそもそもないのだから、ある程度仮説を立てたらやるしかない。いくら調べてもわからないものはわからないし、不安を解消するための情報収集は往々にして莫大な時間を消費し、大した成果は得られない。

だとしたら最初から失敗しても擦り傷程度で終わる範囲で動けばいいというのが「行動ファースト」である。部下がチャレンジに失敗しても「これで仮説の精度が上がるね」と声をかける。「仮説は修正するためにある」と思っているからだ。

身近な例でいえば、私はプレゼン資料を作るときはいきなり目次から作る。浅い知識であっても仮説は立てられる。目次を作ったらそれを肉づけするために本を買って必要な箇所をピンポイントで読むといったように知識やデータを集めてくる。こうした肉づけ作業をしている過程で仮説も随時微修正していく(新しいことを学ぶので付け足すことが多くなる)。

心配性な人が同じ資料を作るとしたら、まずはひたすら情報集めに走るだろう。本を何冊も読み、ネットで調べ、人に聞く。確かにそこまでやれば仮説の精度は上がるだろうし、不安が解消されることもある。ただ、すべての判断で石橋を叩いていてはスピードは一向に上がらない。

5段階の実行フェーズ

ステップ①

さて、実際のステップの解説に入る。実行フェーズは、5つに分けられる。まずは、計画フェーズで絞り込んだ解決案を実際のアクションである「DO」に分解する。ただし、このDOにはさまざまな種類が考えられる。

解決案が具体的か抽象的か解決案が抽象的だと、ここで考えられるDOの数は増える。これは正常なので問題ない。一方で、計画段階でかなり具体的なアイデアが湧いていると、解決案がすでにDOレベルに落とし込まれているケースもある。

よって、すでにDOレベルの解決案があるのなら、それをそのままDOにしても構わないが、せっかくこのステップを踏むなら、あらためて他の手段(DO)はないのか検討してみることも大切である。

完結型のDOと継続型のDO例えばスキルアップを目指すときに「セミナーを受講する」というDOは1回で終わる完結型であり、「1日10分、トレーニングをする」というDOは継続型である。また、「後輩に優しく接する」「ハキハキしゃべる」といった定性的なDOも、KPIを達成するまで毎日続けることなので継続型に属する。ひとつの解決案に対して完結型と継続型のDOが混在するのは、いたって普通のことだと理解していればいい。

ステップ②DOに優先順位をつけ、やることを絞る

ここでは膨れ上がったDOを若干スリムにしていく。解決案につき最低ひとつは実行に移したいので、解決案に対してDOがひとつしかない場合は無条件に選ぶ。また、複数のDOがあっても「それをしないと始まらない」といった類のDOに関しては無条件で選ぶ(例えば、資格勉強をするときの「参考書を買う」といったDO)。

それ以外の複数の選択肢があるものについては、あらためて「インパクト」「時間」「気軽さ」の指標で優先順位をつけ、やることを絞り込む。このときの時間軸については、完結型のDOに関しては実際の行動にかかる延べ時間を概算すればいいが、継続型のDOに関しては効果が出るまで続けることなので、時間を記入する必要はない。

ステップ③ DOを定量化する(「KDI」を設定する)

計画フェーズで各課題をKPIという形で定量化したように、実行フェーズでは「DO」を定量化する。それが、KDI(Key Do Indicator)である。

端的にいえば、「どれだけ計画を実行できたか」を表す指標だ。KPIと区別するために私が作った言葉だ。KDIは、検証フェーズにおいて計画通りに行動に移せたかどうかを客観的に判断するための指標である。よって、もし週に1回ペースで検証を行うのであれば、KDIもその周期に合わせて分解しておくことがとても重要だ。

例えば1000ページに及ぶ大作の本を読むことがDOだとしよう。そのとき、KDIを「本を読みきったかどうか」といった0か1の数値にしたり、または「全体の何ページ読んだか」といった全体から見た達成率にしてしまうと、週に1回の振り返りをしたときに「その週の目標」が達成できたのかどうかが不明瞭である。このような大きなゴールを達成するには、「毎週200ページずつ読む」といったようにこまめな行動目標を立て、毎週その達成率を確認しながら軌道修正をしていくことが必要なのである。

この検証サイクルごとに細分化した目標のことを当社では「ラップタイム」と呼ぶ。これはKDIだけではなく、KPIでも同じである。

【KDIを設定する目的】
「KPIを決めてDOも決めたのなら、さっさと行動すればいいだけじゃないか」という指摘もあるだろう。ではなぜKDIが必要なのか?それは結果(KPI)は簡単にコントロールできるものではないからである。売上目標というKPIを設定したとしても、自分が気付いていない外的要因が潜んでいる場合もあるだろう。必ずしも100%の行動が100%の結果を生むとは限らない。それに結果が出るまでのタイムラグが発生するものがほとんどであるのだ。

一方で、行動はやるかやらないか、できるかできないかの話なのでコントロールしやすい。もちろん行動の成果がKPIに表れない事態もあるかもしれないが、かといって行動をしなかったら当然KPIも動かない。だから自分が確実に行動に移しているかどうかを見える化し、逐一チェックすることが重要なのである。

ステップ④ DOを「TODO」に落とし込む

PDCAの典型的な罠なので何度も書くが、「何かをしよう」と決めたことは大抵の場合、DOのレベルで止まっており、具体的なタスクとして落とし込まれていない。

具体的なタスクとは、「これならいますぐに手をつけられる」というレベルまで落とし込まれたタスクだ。DOのTODO化とはDOを実行の際に迷わないレベルまで分解することであり、当然ながら期日設定も含む。むしろ、期日を切らないからDOが放置されるといってもいい。

TODO化されたかどうかのひとつの基準はスケジュール帳に書き込めるレベルになっているかどうかである。唯一の例外が継続型のDOでなおかつ定性的なもの(例:早口でしゃべらない)だ。これについては「ルーチンチェックシート」に反映させておく。

個人のPDCAでTODOを考える場合はこれで十分のはずである。また、チームでPDCAを回しているときはTODOの割り振りが必要になる。TODOを言い渡されたメンバーが勘違いをしたり、迷ったりしないためには、定番の6W3Hに落とし込むと正確さが増す。

・WHOM(誰に)
・WHEN(いつ)
・WHERE(どこで)
・WHAT(何を)
・WHY(なぜ)
・HOW(どうやって)
・HOWMANY(どれだけ)
・HOWMUCH(いくらで)

DOがTODOに分解されると、もはや言い訳の余地もないので、必然的に「もうやるしかない」という気分になる。このメリットは実行力を考える上で果てしなく大きい。

ステップ⑤ TODOの進捗確認をしながら実行に移す

TODOが決まればあとは実行に移すだけだが、大事なポイントがひとつある。KDIの進捗確認は次の検証フェーズで行うが、TODOの進捗確認は実行フェーズに含まれるという点だ。

「この実行フェーズが終われば自ずと検証フェーズに入るのだから同じことなのでは?」と迷う学生に出会ったことがあるので簡単に説明する。冒頭のPDCAサイクルの説明で書いたように、PDCAサイクルといってもその実態は実行のサイクルである。それがこのステップ⑤だ。

この実行のサイクルを唯一脱するタイミングが検証を行うとき、つまり個人であれば週ごとの振り返りであり、会社であれば進捗会議などにあたる。

そして本来、検証のタイミングではKPIやKDIを扱うべきである。もちろんTODOを実行するにあたって大きな問題が発生していたら検証フェーズで打開策を検討するが、TODOが滞るたびに次の会議まで問題を保留にしていてはあまりに時間の無駄だからである。

よって実行速度を上げたいならTODOの進捗確認は実行サイクルのなかで行うべきであり、最低でも一日一回、理想を言えば一日数回行いたい。わかりやすく言えば、毎朝、仕事を始める前にはその日のTODOリストがある状態にして、予定より遅れていればペースを上げるといった「帳尻合わせ」を日中に何回かすべきということであり、継続型のTODOに関しては毎日ルーチンチェックシートで達成率を確認すべきである。

TODOをこまめに確認していればたいていのことは少しペースアップしたり、昼休みを少し短縮したりするくらいでなんとか間に合うものだ。フルマラソンを走るときの1キロごとのペース配分の確認が検証フェーズだとすれば、TODOの確認は絶えず行うフォームの確認のようなものである。

計画フェーズから散々考え抜いてきた結果として導き出されたTODOをこなすことは楽しい。それはロールプレイングゲームでレベル上げをしているときに似ている。

TODOもレベル上げも、やることはもしかしたら地味な作業かもしれないが、その行動の目的が明確になっているので迷いはないし、それを終わらせれば必ず前に進むことがわかっていれば頑張れるものだ。

結局、仕事が楽しくないときは、かけた労力に対して見返りがないからだ。金銭的な見返りの話であることが多いが、それと同時に自己実現を日々実感できることも非常に大事なことだと思う。さすがに内職作業のような単純なTODOになってくるとゲームでスライムを倒すときのように得られる経験値やお金はごくわずかで、仕事を楽しむことは難しいかもしれない。でも、普通のビジネスパーソンでそのような仕事だけで1日が終わる人はまずいないだろう。PDCAを回していれば「やることにすべて意味がある前提」で動くことになるので、日々の充実感が増すのである。

人に介在するリスクに気を付ける

実行サイクルを回すときに障害は付きものだが、当然ながらその障害を事前に察知して取り除いておけば、いち早く目的を達成できる。因数分解などで仮説の精度を高める必要があり、いかに事前にリスク、すなわち将来的に起こりうる課題を事前に想定できるかがポイントになってくる。

例えば営業マンが数値目標を達成するための課題として「新規開拓に力を入れる」と決めたはいいが、「既存顧客が不満を言い出す」というリスクを想定しなかったとしよう。因数分解の章で解説したように、最初の課題抽出の段階で特定の課題を忘れてしまうと、最悪の場合、問題が顕在化するまで気づかない。一度顕在化してしまうと課題解決には相当骨が折れるので、新規開拓どころの騒ぎではなくなるだろう。要するに、本来「既存顧客のケア」を課題として検討すべきだったわけである。

リスクの想定は何も計画フェーズでのみ行えばいいのではない。DOを考えるとき、TODOを考えるとき、または後の調整フェーズで改善案などを考えるときも、できるだけリスク要因に気を配る必要がある。

経験上、人は自分に直接的に損失をもたらしそうな経済的リスクなどについては想像力が働きやすい一方で、「人」に関するリスクを忘れがちだ。厳密に言えば「他人の感情」にまつわるリスクである。

「順調に仕事を進めていたら、報告を受けていなかった上司が怒鳴り込んできた」
「契約成立まではいったが、担当者は不服そうだった」
「これなら稟議は通ると思っていたら、思わぬ人が反対した」
「将来有望な部下を厳しく育てていたら、精神を病んで退社してしまった」

いずれも会社でよく見かける事態だが、共通しているのは自己中心的な発想に原因があることだ。「他人」または「他人の感情」にまつわるリスクを防ぐためにはコミュニケーションしかない。

若手社員によくある、途中経過を報告せずに完成形を上司やクライアントに見せて、こっぴどく怒られて修正を迫られるようなケースも、若手社員が事前にリスクを想定して意識的にコミュニケーションを密にとっていれば回避できた事態である。

もちろんコミュニケーションを怠るのにはそれなりの原因があるわけだが、それも結局「報告しても小言を言われるから嫌だ」「上から目線で発言されるから苦手だ」といった好き嫌いの話に集約されるケースがほとんどだ。

むしろ自分が苦手だと思う相手ほどコミュニケーションミスのリスクが潜んでいると考え、積極的に対話を仕掛けていく必要があると私は常々思っている。

ただ、リスクが思い浮かんだとしても、確率的に考えて低い、または許容範囲のダメージだとわかっているなら必ずしも新たな課題として追加する必要はない(つまりKPIを決めたり解決案を考えたりする必要はない)。万が一そうした事態になったときの対処法を考えておくだけでもいいだろう。いわゆる「想定内のリスク」にしてしまうだけでも対処の初動が早くなる。

冨田和成(とみた・かずまさ)
神奈川県出身。一橋大学在学中にIT分野で起業。2006年大学卒業後、野村證券株式会社に入社。本社の富裕層向けプライベートバンキング業務、ASEAN地域の経営戦略担当等に従事。2013年3月に野村證券を退職。同年4月に株式会社ZUUを設立し代表取締役に就任。

【鬼速PDCAシリーズ】
・ (1)多くの人が抱きがちな「PDCA」6つの誤解
・ (2)5割の人が失敗している「PDCAの計画」　圧倒的な成果の出し方
・ (3)「PDCA」の本当の回し方　精度を高める7つのポイント
・ (4)デキない人にありがちな「計画倒れ」の正体　なぜ、実行できないのか？
・ (5)仕事で「適度に忙しい」状態をつくり出す3つの原則

【関連記事】
・10年後も食える人・食えない人の決定的な違い
・老後破産に陥りやすい人の特徴とは 予防対策を考える
・油断大敵！高年収世帯でも陥るかもしれない老後破綻の現実
・実は不動産投資で失敗している人は多い！
・投資でよくある失敗事例。なぜ相場で負けてしまうのか？