【初級者用】課題解決プロジェクトの「実行計画表」の作り方
「ベンチャー企業のマネージャーが知っておきたい」シリーズと銘打って今まで2本記事を書いてきましたがついにこの記事で完結の第三段です。
本稿は下記の２記事を読了している前提で執筆していますので、もしよければまずは下記２記事にお目通しください。
▼今までの記事
１．「課題とはなにか？」「課題解決」はどう進めるのか？
２．課題解決の進め方第二弾【目標設定・施策検討編】
さあ、ついに本稿では課題解決の『実行スケジュール』を作成します。
今まで２記事にわたって自部署の「課題を特定」し「施策を考え」、「どうしたいか（目標設定）」を考えてきました。
パワポでキレイに理想→現状→課題→施策 と整理できると、なんだかもう課題が解決できたような気にすらなってきます。
でもですね、断言できるのは、この段階で「よしやってみよう」と開始してもあなたの課題解決プロジェクトは限りになく100％に近い可能性で失敗します。
なぜか？
それは「物事は実行の計画を作成しないと前に進まない」からです。
そう、課題を解決するためには
・誰が
・いつまでに
・何をやるのか
を示す「実行スケジュール」を作成する必要があるのです。
もしかしたらこれがあなたにとって初めての実行計画の作成かもしれません。
不安ですよね。でも大丈夫です。
なぜなら今までやってきた整理で、実行計画作成の50％はもうすでに完了しているからです。
計画表とはどんなものなのか？
一般的に、コンサル会社での経験がある方や、プロジェクトマネージメントの経験がある方は、「WBS」や「ガントチャート」というものを作成します。
ガントチャートはきいたことがある方も多いと思いますが、WBSと言われてもピンと来ない人の方が多いですよね？
実際に僕もベンチャーで役員を４年、その後転職して取締役を２年やらせてもらっていますが、WBSという言葉は１年ほど前に初めて出会いました。
僕がこの記事でご紹介する手法は一般的なガントチャートを少し変形・簡略化したものです。
書籍も色々出てますから、本記事で物足りなければ読んで見るのもよいと思いますが、おそらく大多数の方はこの記事に書いてあることを実行するだけで十分だと思います。
さて、
少し前置きが長くなってしまいましたが、計画表を作る上で注意しなければいけない点は下記の３つです。
１．やるべきことが分解して記載されている
２．「誰が」やる作業かがわかる
３．作業を「いつまでに」やればいいのかがわかる
ちょっと乱暴に言ってしまえば上記３つを満たしていれば十分に計画表として成立します。
前までの記事で作成してきた例を用いて計画表をつくってみましょう。
実行する施策を選定し、計画表におとしこむ
前述の通り、いつまでに・何をやるのか、が明確でなければいけませんから、下の画像の右にあるような表形式で作成されます。
下記フローでまずは計画表の骨組みを作成してみましょう。
１．いままでに整理した図のプロセスを縦に記載
２．プロセスごとの理想状態・KPIをその右列に記載
計画表を見るたびに目指すべきものを再認識できるため、「なんのためにこれやってるんだっけ？」となりづらいためおすすめです。
３．その右列に施策を記載
もし施策が数多く思いついている人はここで施策を選定する必要があります。一般的には、下記のような基準で絞り込みます。
・施策によるインパクト
・施策完了までの期間
・施策実施にかかるコスト（実費＋工数）
作業を分解する
次に施策の右に、施策を実行する上で必要な作業を分解して記載します。（画像の青枠部分）。
例えばこの例で言ったら「顧客への商談前ヒアリングシートを利用して商談前に顧客の情報を把握する、ために
ヒアリングシート草案作成
上長確認・調整
スプレッドシート化
顧客メールテンプレ作成
計測方法設定
運用
計測
シート内容調整
運用
計測
このように作業を分解しました。
どこまで細かく分解するかは絶対的な正解はありません。
例えば上記の例で言えば一度シート内容を調整する予定を組み込んでいますが、これを２回にすることも可能です。あるいはヒアリングシート草案を作成する際に、競合調査→整理のような作業に更に分解することも可能です。
これはやりながらコツを掴むしかありませんが、
システムを作成するような現場でも無い限りそこまで作業を細かくブレイクダウンしすぎる必要はありません。
しかし例えばチームに新人が多い場合、
かなり作業を細かいタスクレベルまで砕いてあげないと「ヒアリングシートの草案つくっといてね」と指示出ししても「え、あ、、はい！」とか言って思考停止して提出期限に「すみませんまだ何もできてません、、、」みたいなことになります。
なのでチームの熟練度にあわせて分解の粒度を調整するのがよいでしょう。
スケジュール感を記入して「マイルストーン」を記入しよう
前ステップで分解した作業を、いつやるのかを記入していきます。
矢印を記入したり色んなやり方があると思いますが僕はエクセルのセル色を塗る方法をとっています。
また、スケジュールは上記のように基本的には「週」単位で作成しています。
もちろん「日」単位で作成しても問題はありませんが、３ヶ月から６ヶ月スパンのプロジェクトを管理しようとなると日単位の表はかなり横長になります。
この計画表をつくる目的は第一に「誰が・いつ・何を」やればプロジェクトがうまくいくのかを見通し、運用後に計画と実態との差分を可視化することですが、
「この作業が終わらないと、あの作業に着手できない」や
「目標の期末までにこのプロジェクトで成果をあげようと思ったら３ヶ月前のこの時点では●●を終えとかなきゃいけない」
など、計画を俯瞰することで前もって成果から逆算して考え・準備することも非常に重要な目的なのです。
なので僕はできるだけ全体を見渡せるアウトプットの方がいいので週単位で作成します。
計画表をつくるとわかりますが、あなたの考えた施策をすべて実行しようと思ったらかなりの数の作業が発生するはずです。
上記の例で見ても１つの施策に対して10個です。
上の画像の例の残りの施策も作業レベルに分解していったら20から30個の作業になるでしょう。
前述の通り、この計画表をつくる目的の１つは
「計画と実態（実績）の差を把握すること」です。
しかし、あなたがこの20から30個の作業の進捗をすべて完璧に把握する必要があるのか？
また、あなたは上司にこのすべての進捗を報告するのか？
僕の答えはNOです。
特に後者に関しては明確にNoです。
あなたの上司はおそらくあなたの数倍以上の範囲を管轄しているケースが多いと思います。
つまり各部署の作業ベースでいうと100近い作業の進捗を随時報告されたらそれをきいているだけで日が暮れます。
あなたが自部署のメンバーに作業を依頼する場合も近しいことが起こります。
そのため、
「ここはズレちゃいけない」
「ここに間に合わせることが重要」
という中間地点を設定して、それだけを報告の対象とするのがおすすめです。
この中間地点のことを「マイルストーン」といいます。
これも前ステップの作業の分解の粒度と同じく、
これが絶対という設定の仕方はありません。
チームのメンバーの力量や、
上司が求める報告の頻度（や粒度）にあわせて設定しましょう。
※あなたの上司が、まだあなたのことをそこまで安心して任せられるマネージャーでないと判断している場合、「細かくマイルストーンを設定してくれ」と依頼がくるはずです。
最後に作業単位で担当を記入すればOK。
これで計画表は完成です。
あとはこの計画表をもとにプロジェクトを運用し、PDCAを回しまくって成果にむかってひた走ってくださいｗ
本来であればこの後の「運用しながら計画を修正する」という実行フェーズは非常に重要なのですが、一旦本シリーズでは取り上げません。必要に応じて続編を検討します。
（もし読者のみなさんの声があれば執筆します）
それでは本稿はここまで！
という前に皆さんの役に立つかもしれない「よくある計画表でミスっちゃうパターン」をご紹介します。
あなたの計画表を上司に提出する前に是非一度お目通しいただきたい！
実行計画作成時によくある「イケてない」例
１．計画のスケジュールがキツキツすぎて余裕がない
一度でもプロジェクトを推進してみるとわかりますが、プロジェクトというのはほぼ100％計画どおりにいきません。（だいたい遅延しますｗ）
他者や他部署と連携することが多いプロジェクトの場合特にこの傾向は顕著です。
そのため計画にはある程度バッファ（余裕）を持つ必要があります。
感覚的には全体の15-20％くらいは余裕があるといいなと思います。
※つまり６ヶ月の計画なら１ヶ月。３ヶ月の計画なら２週間くらいの余裕があると安心です。
２．作業分解の粒度が粗すぎる
「粒度はチームメンバーの力量にあわせてうまく調整してね」と前述したものの、慣れていない人の多くは作業を洗い出すことができず、粒度が粗すぎる計画をつくる傾向にあります。これは結構問題で、
例えば上記の例でいったら
１．ヒアリングシート作成（１ヶ月）
２．運用（２ヶ月）
の２行しか書かれていなかったら、
上司としては、
「え？じゃあこのプロジェクトがうまくいってるかどうかっていつ中間判断すればいいの？」
「運用２ヶ月って、、。中間計測してPDCA回さないの？」
となりますのであまりに粒度が粗すぎるのはだめです。
３．上司との調整がおりこまれてない
あなたがよっぽど上司から信頼されて権限移譲されているマネージャーで無い限り、プロジェクトは、方針ぎめなど重要なタイミングでレビュー（確認）をもらい、必要であれば調整をすることになります。
場合によってはこれに数週間から１ヶ月かかることもあるでしょう。
これを計画に反映していない人が多いです。
そもそもその作業として記載していない人もいるし、
書いているんだけど「プロジェクト方針確定で１週間」のような、レビューする前提でないものがほとんどです。
これをしっかりと織り込んでおかないと出鼻くじかれる、且つ全体的なスケジュール遅延の原因になりますので注意です。
４．PDCA回す前提で計画されていない
優秀なマネジャーは、施策の第一案が100点にならないことを知っています。なので例えば本稿の例の場合、
「顧客への事前ヒアリングシートをつくる」
という項目がありますが、最初につくったヒアリングシートの形は「結果をみて修正するものだ」と考えます。ヒアリングシートのベストな項目や記載の仕方を最初から予想するのは無理だからです。
例えば3ヶ月でこのヒアリングシート運用を通じて事前の情報取得率をあげよう、という計画なのであればせめて1回はどこかで中間計測（見極め）をしてPDCAをまわす計画にしておきましょう。
以上です。
長々と説明してしまいましたが、
1度経験すれば「ああ、そういうことだったのか」という気付きがあるはずです。
全3回にわたり「課題解決はどのように進めればいいのか」について説明をしてきましたがいかがでしたか？
マネージャーに抜擢されたものの、どうしていいのかわからない。。
誰も教えてくれない。。絶望。。
そんなかつての自分のような境遇にいる方の救いになればと思い執筆に至りましたがその目標が達成できていれば幸いです。
もちろん最初から完璧にできる人はいません。
私も20代後半でマネージャーの機会をいただいてから、約10年。
何度も失敗してきました。
でもそのたびに少しずつ何がいけなかったのかを考えレベルアップしていきました。
大事なのは
１．セオリー（一般的にどうやるかの型）を知り、
２．使いこなせるように訓練することです。
あなたはもう１を理解したはずです。
あとは回数をこなすだけです。
あなたの課題解決が、先が見えない苦しいものでなく、
目標達成のためにチームとクリエイティブに試行錯誤する充実したものであることを心から祈っています！
Twitterのフォローお願いします！
noteで書いてるようなビジネスモデルに関する考察系やマネージャーに向けてのビジネススキル系のネタに加えて、普段僕が社員のみんなに教えていることをカジュアルにツイートしてます。もしよければフォローお願いします！
いいなと思ったら応援しよう！
