計画不在が引き起こす集団麻痺
「Ａくん、例の『働き方改革検討」の件どうなっている？
状況を教えてほしいんだけれど」
課長からの突然の問いかけにうろたえます。
「あー、ええと…ううん……。正直、芳しくありません」
「芳しくないって、いったい何がどうなっているの？」
「〇〇部からの回答がなくてですね……」
「は？ちょっと待って。〇〇がこの件にどう関係するんだっけ？」
課長は思わず首をかしげます。
「はい。在宅勤務のシステムを扱っているベンダーを調べてもらうよう
〇〇部に依頼しました。
たぶん、ベンダーからの回答がまだなんじゃないかな…。」
「あ、そういうこと？でもさ、システムも大事だけれど、
まず世の中の事例を調べようってことにしてなかったっけ？
別に働き方改革＝在宅勤務じゃないしシステムは手段でしかないよね」
「そういう考え方もありますね」
「それと制度をどう変えるかも考えないと。制度面の検討は進んでる？」
苛立ちを抑えつつ、問いを続ける課長。
「なるほどです。たしかにそれも大事ですね。これからやります」
「いや、『なるほどです』じゃなくて……」
そもそも計画がない。→ あいたっ！
あるのかもしれないけれど、担当者の頭の中にしかない。→ あいたたっ！
あっても抜け漏れだらけで、とても計画とは言えない。→ あいたたたっ！
そんな状況でとりあえず仕事を進めて路頭に迷っている現場やプロジェクト…とてもよく見かけます（次に多いのは計画を立ててはみたけど、体裁を整えただけで計画通りに進める気なんて一切ないプロジェクト…）。
仕事の大小を問わず、計画を立て、それを上司・部下・関係者と共有して、
計画通りに進行できるようコントロールし、その通りに実行できているのか状況を監視・管理をするのはセルフマネジメントでも、集団マネジメントでも基本中のキホンのはずです。
では、なぜマトモな計画がないのでしょうか？
そこには３つの原因が考えられます。
①「勘や経験則で何とかなるだろう」と思っている
②計画の標準形がない
③やるべきことがわかっていない
さらに言えば、真因は
それを教えられる実力を持った人材が管理職や経営者に存在しない
ということなのかもしれません。
「勘や経験則で何とかなるだろう」と思っている
わざわざ計画を作るなんてメンドクサイ。
そう思わせる背景の１つがこれです。
野生の勘でナントカしようとする。
過去の経験からしか学ぼうとしない。
そもそも「メンドクサイ」と言う理由が気持ちの中だけにとどまらず、仕事に持ち込まれる時点で社会人としては下の下ですがそれにしてもお粗末です。
いままで、計画なんて作らなくてもナントカなっていた。ナントカなってなくても、過去の痛い経験をキレイさっぱり忘れてしまっている。だから今回も大丈夫なはず！
そんな過去の成功体験や、根拠のない自信が、計画を作る習慣を妨げるのです。
計画を作る習慣が身につかないのは「メンドクサイ」が許される風土にも問題がありますが、それ以上に過去の痛い経験から何も学ぶ機会を作ってこられなかったことだけでなく、そういうった情報を組織の中で共有してこなかったことに原因があります。
世の中、二度同じ仕事は存在しません。
時代も変われば、背景も変わります。
たとえ過去に成功体験があったからといって、今回もうまくいく保証はどこにもありません。特に"プロジェクト"には
『独自性』という特徴があり、過去に2つとしてまったく同じモノは存在しないことが前提となっています。当然ながらすべてを経験に頼ろうとしても、自らの経験から学べることには限界があるのです。
よほど経験数が豊富であれば、様々な経験の組み合わせによってすべてを補填できるかもしれませんが、逆を言えばそれほどまでに豊富になるまでの間、経験にばかり頼っていれば決して成功率は高くならないことを意味します。そうするとあとは「勘」に頼るばかりです。
結果、
・コミュニケーション（報連相）の計画がない
→言われ（聞かれ）なければ気付けず、動けない
・行き当たりばったりで行動しがちになる
と言った弊害を生み出すのです。
計画の標準形がない
「そもそも計画ってどんなことをすればいいんですか？」
そこで思考停止してしまう若手社員（だけではないですが）。学生の頃だってさんざん計画と呼べるものを見てきたはずなのに、ただ目の前に出されたものを受け入れるだけしかしてこなかったのでしょうか。
たとえば「遠足や修学旅行のしおり」
たとえば「文化祭や運動会のプログラム」
たとえば「友達との旅行プラン」
いくらでもあったと思うのですが、スッポリ頭から抜け落ちてしまっています。ほんの少し思い起こしてみれば、計画書にはどんなことがかかれるべきかわかってくるのですがそれも考えない。そして、そうした人たちが集まった組織ではそもそも
計画の標準形がない
という事態を生み出します。それは別に経営者のせいでも、管理職のせいでもプロジェクトマネージャーのせいでもありません。「作ろうとしなかった」すべての人が他人任せにしてきたせいです。
だから、どんな観点を計画に盛り込んだらいいのかわからないし、どんな粒度で計画を作ればいいかもわからないわけです。とりあえず想像で作ってみたけれどやっぱり抜け漏れが多くて話にならない…と言う事例は少なくありません。
気の利いた会社なら、予算計画・受注計画・プロジェクト計画・業務計画など、ジャンルごとに計画の「ひな形」（標準形）があります。
すべての業務を網羅するのは難しいにしても、繰り返し性のあるものについては標準形を作っておきたいものです。もちろん用意した標準形を利用しようとさえしなければ意味はないのですが…。
たとえば１つ例を取ってみると「ソフトウェアテストの計画書」というとどうでしょう。IEEEではstd829に最低限計画すべき事項としてテンプレートが用意されていたりしますよね。
IEEEはアメリカに本部を置く電気・情報工学分野の学術研究団体（学会）ですが、国際規格ほどではないにしてもそれなりに世界中で名の知れた研究機関です。そのまま鵜呑みにする必要はありませんが、少なくともテーラリングのネタ元として活用できるだけの信頼性はあるのではないでしょうか。
やるべきことがわかっていない
とりわけ新しい仕事に取り組む場合、「計画を作れ」といわれてもどんな活動や作業が必要なのか見当すらつかない場合もあります。
冒頭の事例で考えてみましょう。
『働き方改革検討』は担当の子にとって、課長にとっても、そもそも会社にとっても初めての試みかもしれません。「働き方改革？なにそれ、美味しいの？」くらいに思っている社員もいるかもしれません。
でも「何をすべきかわからない」という状況は容易に想像できます。
では、どうしたらキチンとした計画を作れるようになるか？
１つ１つ捌いていきましょう。
ポイントは４つです。
①目的／目標を定める
②現状の業務を構造化してみる
③構造化された一つひとつのタスクに対して計画をたてる
④「未知」か「既知」かを皆で判断する
これらの手順で進めれば、完璧とはいかないまでもそれなりに筋の通った計画が作成可能です。
目的／目標を定める
新しい仕事を振られたら、まず一番最初にするべきことは
「なぜそうしなければならないのか」
を明確にし、自身も含めチーム内で理解することです。先の例で言えば「なぜ「働き方改革」の取り組みを会社はしなければならなかったのでしょうか。今の会社の規則やルール、働き方では法に触れるということでしょうか。
もしも「いや、それを一つひとつ確認して、法に触れる可能性があるところは改善してほしい」という場合、計画のスタートは"事業全体の現状把握"から始めなければなりません。
もし「うちは残業過多になりやすい業務があるから、その状況を改善してほしい」というものであれば、計画のスタートは"各部門の残業状況の確認"や、"業務フロー、業務内容の確認"から始めなければならないかもしれません。
なぜそうするのか？という『目的』によってスタートラインは大きく変わってくるのです。そして同時にゴール（目標）も変わってきます。
「何を」「どこまで」「どうすれば」
完了と言えるのかは、目的の成否によって決まるからです。
多くの従業員は上司に「〇〇やっといて」と言われると、目的を理解しないまま言われるがままに「わかりました」と言ってしまいがちです。些細な雑務ならまだしも、プロジェクト活動にするような規模であれば「なぜそうする必要があるのか？」はとても重要なファクターとなります。
構造化してみる
次に目的を達成するためにするべきミッションを洗い出しましょう。
Excelでも手書きでもかまいません。雑でも結構。とりあえずまとまらないならまとまらなくてもいいんです。個人的には、雑多に整理するならマインドマップもどきでどんどん書き込んでいくなかで脳内整理ができればいいと思っています。
大事なことは「その目的達成のためにできること（やること）ってなんだっけ？」をとにかくありったけ吐き出すことです。活動や作業項目を洗い出すことが重要で、これができないとそもそも一つひとつの活動や作業に対して「スケジュール」が立てられません。
計画において「タスクの構造化」は必須と言っても過言ではないのです。
図や表という形にすれば、まわりの人（上司・同僚など）に見せたときの
「抜け」「漏れ」チェックが速くなります。
ただ単純に制度やシステムを改めても、それらを実用する各従業員が理解していなければ運用することは困難ですよね。すると、
「『教育』って項目も必要じゃないかな？
新しい制度を開始するには、社員への周知展開の活動が必要だよね」
という意見も出てきやすくなります。出てきやすくしようと思ったら"言語化"・"可視化"は絶対に必須となってきます。他にも
「『管理職』か『一般社員』かで内容を変えたほうがいいと思うな…」
「コストについては考えなくていいんだっけ？」
観点や項目の「抜け」「漏れ」をチームの仲間たちと補完しあいましょう。
三人寄らばなんとやら、です。職場のコミュニケーション活性化にもつながりますね。
ポイントは、MECE（Mutually Exclusive Collectivety Exhaustive：ミッシー：「モレなくダブリなく」の意）でチェックすることにあります。活動や作業を洗い出す時は特にMECEの視点でチェックしましよう。
わかりやすく言えば
「それさえすれば目的は絶対に達成できるんだっけ？」
「その作業をしないと絶対に目的を達成できないんだっけ？」
を明確にし、落とし込むということです。
ものごとをＭＥＣＥに整理するためには、次の３つの考え方が役立ちます。
①「ＡとＡ以外」で考えてみる
例「男性と女性」「日本と海外」「管理職と非管理職」
②計算式に当てはめてみる
例「総売上＝単価×売上」←「単価」と「売上」の観点
「サービスの価値Ⅱ有用性×保証」←「有用性」と「保証」の観点
③プロセスの各段階に当てはめてみる
例「構想」と「設計」と「試作」と「製造」と「販売」
「開発」と「運用」
実はMECEの考え方は、ソフトウェア開発において非常に重要です。
「モレなくダブリなく」とは、すなわち
・品質は完璧と言えるか？（モレなく）
・生産性を最大限高めた仕事になっているか？（ダブリなく）
と言うマネジメント上の発想と完全に一致するからです。
たとえば、データパターンなどを想定する場合
で切り分けたり、
と言って、すべてのデータパターンを過不足なく網羅し、そのうえで重複することもなく必要十分＋最低限＝必要最低限の労力で、品質を最大限確保することは、開発業務のマネジメントにおいて必須と言えるでしょう。
知識の引き出しが多ければ多いほど、ササッとMECEな項目を思いつけるようになります。ほかの人が作った構造図を見て、
「へえ、こんな切り口があるのか」
「この観点もらい！」
のように、項目案を日々ストックしておきたいものです。
そして大事なのが、１人で悩まずにとっとと他人に構造図を見せて相談することです。あなたがMECEだと思っていても、ただの思い込みだけに終わっていたり、ほかの人から見たら「抜け」「漏れ」があったり、そもそもまったく異なる観点でそのテーマを捉えているかもしれません。
それもそのはず。
あなたと他人は別の人間ですから、違っていて当然です。
そして、完壁なMECEなど存在しません。
計画段階で「抜け」「漏れ」や意識違いを明確にしておけば、軌道修正も早くできます。これが、無計画のまま進んで後で発覚した日には目も当てられません。
構造化されたタスクに対して計画をたてる
下手でもいいから、計画を表にしてみる。書いてみる。
書かなければ、チームメンバーとの意識合わせもできなければ、進捗フォローもできません。
「何を書いたらいいかわからない」
そんな時はてっとり早く、
縦に「何を（構造化した活動や作業を）」
横に「いつまでにやる（いつから始めるかは後回し）」
を記すだけでもＯＫです。
端的・初歩的ではありますがそれも立派な計画です。十分とは言えませんが、何も無いよりはずいぶんマシになるはずです。「何を」は最初に作った構造化のなかで洗い出せていますよね。
計画表を書いたら、できる限り早く上司・同僚・部下などまわりの人に見せましょう。そして
・項目や考え方の「抜け」「漏れ」「誤り」がないかチェックする
・そのテーマに関する知識・経験が自組織にあるのかないのかを判断する
とにかく書いてみなければ計画も何も始まりません。そして自分の中で「バッチリ」だと思っても、決して過信してはなりません。必ず第三者の評価を受けることで自らの目が曇っていないか確認する必要があります。
「未知」か「既知」かを皆で判断する
また、計画の実現性を考慮した場合、
「自組織（あなたのチーム）にとって『未知』か『既知』か？」
という情報の把握はとても重要です。
「既知」とは、社内、部内、チーム内などどこかに経験や知識がある状態。
「未知」とは、文字どおり、だれも未経験で、知識がない状態です。
この判断をチームで迅速におこなうためにも、早く構造図や計画表を作って、チーム内で見せ合いましょう。当たり前ですけど、既知と未知とでは仕事のパフォーマンスに大きな違いがあります。
既知であれば１日で終わる作業であっても、未知だと２日以上かかってしまう…ことだってあるかも知れません。チーム内のメンバー一人ひとりがどういう状態なのかを正しく把握していなければ、立てた計画自体が皮算用になっている可能性だってあるわけです。
いわゆる"キックオフミーティング"はそのためにあると言っても過言ではありません。既知であれば、アタリをつけて過去のデータを探す、あるいは担当者に聞きに行く。そうすれば、以前考えた観点や活動項目を流用できますね。
一方、未知であれば外から知識や経験を仕入れるしかないでしょう。講演を聞きにいく、研修を受ける、外注する、調査する。選択肢はさまざまです。しかもその知識を自分のモノにしてパフォーマンスを最大値化するまでにはそれなりの時間を要することも考慮しておかなければなりません。
「既知」か「未知」かをチームで素早く判断し、必要なアクションをスピーディにとっていきましょう。
まとめ
ここまでは、活動開始前の計画段階でやっておいてほしいことです。
ですがそれだけでは上手くいきません。
計画実現性を高めるには、計画を立てるだけで満足するのではなく、計画通りに遂行できるよう日々コントロールする必要があります。PMBOKの「監視・コントロール」とはまさにそのことを言っています。
まず監視（モニタリング）によって最新の状況を把握し、その内容が計画と乖離しないようコントロール（やりくり）するわけです。こちらは常日頃やっておきたい活動です。
チーム内のだれが、どんな知識をもっているか？
社内のどの部署が、どんな仕事をして、どんな経験があるのか？
何がトレンドで、どんなソリューション（解決策）が提供されているのか？
これらを常に情報収集しておくのも、大事な仕事です。
「そんなヒマないよ！」と言う人もいます。わかります、よくわかります。
みんな日々の仕事に一生懸命で、情報を集めて共有している時間なんてありません。だからこそ
情報共有を「仕事」として定義し、旗を振る役割をだれかに任せる
…すなわち『仕組み化』が肝心なのです。
で、その旗振り役をする（だれかに役割として任せる）のはだれか？
仕組みを作るのはだれか？
ズバリ、管理職です。
というか管理職はそのためにあると言っても過言ではありません（だからこそ管理職がプレイングマネージャー寄りの組織は、あまりうまくいかないわけですが）。
管理職が率先して情報共有をする、あるいは情報共有する役割と仕組みを作りましょう。管理職がこの役割／責任を放棄したら、その組織は徐々に衰退します。
属人的にすすめて、ある時だけ調子が良かったとしても、それはただの延命措置でしかありません。属人的である以上、その中心人物が欠けた先には必ず衰退が待っています。
・ひと仕事終わったら、振り返り会をやる
→その知識をドキュメント化して、所定のフォルダに格納する
・社外や社内の講演会や勉強会に積極的に参加する
→そこで得た知識を、定例のチームミーティングで話す
・毎日イントラネットをチェックする
→他部署の面白そうなニュースを見つけたら、メールで全員に共有する
この程度のことでかまいません。ただこの程度のことでも、旗振り役を決めておかないとうまく回りません。「各々自発的にやりましょう」では続かないのです。それはなぜか？
だって、人間だもの
管理職とは、人間の弱いところを認識したうえで、それをカバーする役割や仕組みを作る人のことです。部下に仕事を割り当ててあとはのほほんとしている人ではありません。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。