【会社に行きたくない、を無くす】 プロジェクトが燃えないための、 一番シンプルな計画書の作り方🚒
こんにちは。つづく株式会社代表の井領です。
社員は僕をいれて3人、ちいさなITコンサル会社を経営してます。
突然ですが、みなさん。
プロジェクトの炎上、好きですか？🔥
私はめちゃくちゃ嫌いです。できることなら平和なまま一生過ごしたいと考える超・ビビリです。
私は過去、100以上のIT導入プロジェクトに関わりました。行政、自治体、企業...と支援先は色々です。
失敗もたくさん経験しました。つらい経験もいっぱいあります。
その経験を活かして、不幸な炎上プロジェクトを社会全体から無くせないのか？と考えました。
この記事は、読み終わった方々が
・なぜ炎上するのかの背景がわかった
・炎上しないプロジェクトの最低条件がわかった
・炎上対策となるドキュメントの作成方法がわかった
・炎上嫌いなんで、参考になった
と感じてもらえれば、幸いです。
対象となる読者は、
・ITコンサルタント
・SaaSのカスタマーサクセス、導入支援担当
・戦略立案中のマーケター
・新規事業企画などの立場の方
・クラウドサービスの導入等を行う税理士、社労士などの専門家
かなと思ってます
【結論】
長い文章になるので、先に結論を書きます。お時間ある方は、お茶でも飲みながら、少しずつ読んでみて下さい🍵
🚒：プロジェクト炎上させない最大のカギは「ゴール（目的）設定」にあり
🚒：炎上の背景には9つの要因(悪魔)が存在し、こいつらを手懐ければ炎上率はグンっと下がる
🚒：炎上を防ぐために必要な情報は10スライドでまとめられる
興味がある方はぜひ最後まで読んでみて下さい。
【自己紹介】
かんたんに自己紹介させていただきます。現在私は、行政や企業のデジタル戦略策定を支援するつづく株式会社という会社を経営しています。会社ですが、個人事業主みたいなものです。
最新では、富山県の働き方改革・DX推進副補佐官に就任しました。ヤフーニュースにも載ってました。
Careerは新卒でNTT Data intra-martという会社からスタートしてます。
その後「SaaSめっちゃ伸びそう」ということで、2015年にfreee株式会社に転職。
2017年に独立して今に至ります。
今は長野県の山の上で暮らしながら、全国のプロジェクトを支援しています。通勤経路にシカが10匹程度、集団で出てくるような山の中です。
長野県に遊びに来たい人、DXの戦略を相談したい方がいましたらお気軽にメッセージくださいませ。
さて、長いですがお付き合いくださいませ。
【1章】プロジェクト炎上が無くすためには「北風」ではなく「太陽」のマネジメントが重要
炎上は誰しもが嫌いであり、願わくば一生関わりたく有りません。
しかし、ITを始めとして「無形物」「非定形」なサービスと炎上🔥は常隣り合わせ。
なぜ炎上プロジェクトは無くならのでしょうか？
まず前提として、プロジェクト炎上は2パターンに別れます。
■原因1-【未達】の炎上
これは目的地にたどり着けない場合です。
言い換えれば、「走り切るだけのエネルギーが足りなかった」とも言えます。目的地に行く前に、ガソリンが切れてしまった場合です。
■原因2-【錯誤】の炎上
これはそもそも、走るべきレーンを間違えていた場合です。
スタート時には「業務効率化」を目指していたが、徐々に「コストの削減」を目指してしまった。結果、「かえって手間だ」と現場から不平不満が止まらない、などです。
■細かい進捗管理では炎上は防げない
失敗したくないプロジェクトマネージャーは、しつこい会議の開催、細かい進捗管理、ガントチャートづくりに没頭しがちです。
しかし、進捗管理だけでは、本質的な炎上対策にはならないのです。
プロジェクトを炎上させないためには、管理の努力ではなく、正しいやり方を確立しなければなりません。
【2章】成功プロジェクトにあって失敗プロジェクトにないもの、それは「ゴールの正しい設定」
成功するプロジェクトには共通するものがあります。
目的地（ゴール）を掲げ、メンバーを誘導するプロジェクトは成功につながりやすいのです。
一方で、手段やプロセスを監視し、メンバーを【コントロール】しようとするプロジェクトは失敗しやすいです。
失敗プロジェクトに共通するのは、どこかトップダウン式でプロジェクトが始まり、当事者意識が少なく、「音頭を取る人がいない」ケースです。（心当たりはありませんか？）
「北風と太陽」をイメージしてみて下さい。
■失敗：北風型マネジメント
ピュウピュウと風を吹き続けても、なかなか旅人は服を脱ぎません。
北風型プロジェクトマネジメントは、チームを力で押さえつけたり、定例会議をたくさん開催して前に進めようとする「コントロール型」です。
例えば、向かう方針が固まっていて、創造性の低いプロジェクトには向いています。
一方で、今の時代そんなプロジェクトはほとんどありませんよね。あるのは、不確実であり結果の読めないプロジェクトばかりです。
■成功：太陽型マネジメント
商品開発プロジェクト、営業業務改善プロジェクト、業務効率化プロジェクト...こういった、不確実で前例の無いプロジェクトでは、太陽型マネジメントが重要です。
あくまでプロジェクトマネージャーは「向かっていく先にHAPPYがあるよ」と掲示し、メンバーのモチベーション維持に徹します。
コントロールではなく、「ファシリテート」のイメージです。
不確実な時代だからこそ、マネジメントも支配的なものから、メンバーの力を引き出す手法が、ますます重要になってきています。
【3章】プロジェクトを炎上させる9匹の悪魔を手懐けろ！
■こんな声が出てきたら注意！炎上プロジェクトあるある
そしてプロジェクトが始まった後、様々な障害が出てきます。それをわかりやすくするため、プロジェクトを炎上させる原因を擬人化して解説します。
私はプロジェクト炎上の背景には「悪魔」がいるといつも表現しています。
プロジェクトを進めていると、様々ないや〜な発言にあふれるときがありませんか？
「忙しくて定例会に出られません〜、あとで議事録共有してください〜」
「え、私もこれ関係あったんですか？」
「いいよ、勝手にすすめといて」
「私なにすればいいんですか？」
「これやりたいの社長だけでしょ」
■プロジェクトの炎上を左右する9つの悪魔のリスク
炎上リスクを上げていく悪魔は「9種類」存在します。
①忘却の悪魔
ゴールを全員の頭から忘れさせ、議論を収束させなくしてしまう。
②無関心の悪魔
「俺が頑張らなくても、誰かやるだろう」という雰囲気を満たす。
③分担の悪魔
「これ誰がやるの？」と宙ぶらりんなボールを作り行動を抑制する。
④リソースの悪魔
「本業が忙しくてプロジェクトの時間がありません」という雰囲気を作る。各自のリソースをプロジェクトに割かせないようにする。
⑤期待値の悪魔
「思ってたのと違う」という最悪の事態を引き起こす。特にプロジェクトの風呂敷が大きくなると頻出する。
⑥利害調整の悪魔
誰かが幸福になる一方で誰かが不幸になるプロジェクトに暗雲立ち込める
⑦リスクの悪魔
いい事、メリットばかりに目がいき、リスクやデメリットを意識しなくなってしまう。
⑧不敬の悪魔
陰口、犯人さがし。外注先への罵詈雑言。上司から部下への愛のないオーダー。敬意のないプロジェクトに成功は近寄らない。
⑨1本道の悪魔
代替案に目を向けないことで、トラブル時にプロジェクト継続ができなくなる。
プロジェクト進行をする上で、この9つの指標に神経を尖らせ、異常を常にウォッチすることが重要です。
例えば、「メンバーの自発的動きがないな」と感じれば、「目的の再掲示」や「役割分担の再確認」をしつこく行います。
プロジェクトがいきなりワケもなく炎上することはなく、この悪魔のどれかが力を発揮すると、ズブズブと船は沈んでいきます。
【4章】炎上を防ぐシンプルなプロジェクト計画の描き方
■プロジェクト計画書を作ってみよう
ここからは炎上を防ぐプロジェクト計画書の書き方を説明します。
プロジェクトは水物であり、プロジェクトマネージャーは9つの悪魔をコントロールし、成功へ導く必要があると述べました。
そして、成功に導くのは、コントロール重視のの北風型プロジェクトではなく、ボトムアップの太陽型プロジェクトとも述べました。
太陽型マネジメントで必要なのは、常に掲げ続ける太陽として「プロジェクト計画書」が重要です。
■計画書が北極星となり、成功まで手助けしてくれる
プロジェクトでは「仕様書」や「要件定義書」といったドキュメントが様々存在します。しかし、プロジェクトのコミット具合は人によってばらつきがあり、全員がすべてのドキュメンテーションに目を通しきれるとは思いません。
ぶあつい資料を前にして、経営層や関与度の低いメンバーは読む気が失せるでしょう。
そこで重厚なドキュメンテーションから「ゴール設定」と「合意形成」に必要なものだけを抜き出します。
目線併せに特化し、目線がブレそうな時につねに立ち返る左記として機能する資料が「プロジェクト計画書」です。
これがあるだけで、ムダな会議を抑制することができます。また、新しく入ったメンバーなどにも読んでもらうことで、チームビルディングのスピードも上げることができます。
「プロジェクトの方向性を短時間で合わせる」ことができるのです。
では具体的に見ていきましょう。
-スライド1：プロジェクトタイトル
プロジェクトタイトルも重要です。わかりやすく、共感を呼ぶものを設定しましょう。プロジェクトの最後まで利用する名称ですから、後述のプロジェクトコンセプトを先に定めてから、再度ブラッシュアップしても良いと思います。
-スライド2：プロジェクトコンセプト
プロジェクト計画に内包され、最後まで最も重要なスライドがこちらです。
なぜプロジェクトをやるのか？ということを端的に解説したスライドです。
本当にこのスライドは、ズタボロになるまでよく使います。
関与度の低いメンバーや、プロジェクトの外部関係者（傍観者）に対しても、「このプロジェクト何やってんの？」と知ってもらうことは重要です。
このコンセプトをしっかり振り返り立ち返ることで、メンバー間のベクトルあわせをスピーディに行うことができます。
-スライド3：プロジェクト背景：なぜやるのか？
続いてはプロジェクト背景説明資料です。
たとえば業務改善プロジェクトが始まると、「コスト削減を目指す！」ということは大々的に表現されます。
一方で、なぜその議論になったかはスルーされがちです。
「それは当たり前でしょ」「経営会議できまったから」といったお決まりの作法ではメンバーの共感を呼ぶことができません。
結果、当事者意識の低いプロジェクトメンバーの量産につながる危険性があります。
背景スライドを細かく作る必要はありません。ホワイトボードや付箋で行ったブレインストーミングの写真などを掲載し、重要な背景をピックして記載するだけでも十分でしょう。
大切なのは、共感を呼ぶことです。
-スライド4：プロジェクトゴール
プロジェクトのゴールを作成しましょう。ここで重要なのは、ただゴールを掲げるだけではなく、具体的なタスク・施策と大ゴールの連動性をもたせることです。
私はこれをいつも、「大ゴール・中ゴール・小タスク（アプローチ）を書き出しましょう」と伝えています。
なぜ中ゴールや小タスクの連動が重要なのでしょうか？
タスクとゴールが連動していなければ当事者意識が芽生えず、プロジェクトに共感できないからです。
例えば、食品メーカーのプロジェクトとして、「日本人の食卓をゆたかに！」という大ゴールがあったとして、それをいち社員が自分の行動レベルに落とし込むのは難しい。
けれど、中ゴールが「赤ちゃんから大人まで食べられる食品開発」となり、「減塩・無添加な製造開発に特化した工場ライン戦略」とブレイクダウンすればどうでしょうか？ここまで具体的になっていれば、アクションに移しやすいでしょう。
メンバーとプロジェクトが一体となり成果に邁進するためには、このゴール資料が重要なのです。
-スライド5：理想 ← 現状 ← 課題 ← 原因
次にまとめるべきなのが、「理想 ← 現状 ← 課題 ← 原因」の整理です。こちらは、いろんな書籍でも説明されてますが、サイボウズさんが提唱する「問題解決メソッド」が一番わかりやすく、参考にしています。
よくプロジェクトを開始すると「課題の調査」から始めようとする人がいます。これは非常に危険です。
そもそも、「課題」とは「理想」が現状よりも高いから、発生しているわけです。そのため、課題の前に理想があり、そして、課題には原因があるという構造を忘れてはいけません。そこでこのスライドが活躍します。
プロジェクト関係者ごとに「課題」の感覚や粒度が異なっていては議論が収束しません。きっちり整理しておきましょう。
-スライド6・7：プロジェクト定義
ここまでゴールや課題の整理など、抽象度の高い議論でした。ここからは個別具体なプロジェクト情報を一言管理するスライドを用意します。
ここには、「プロジェクト名称」や「体制」「重要なマイルストン」といった、プロジェクトの要素を記載します。
加えて、「利用するツール」や「運営ルール」「スコープ」といった、後からプロジェクトに入った人がつまづきそうなポイントをまとめておきます。
社内外を巻き込んだプロジェクトだととくにこの定義書があるかないかで、新メンバーのキャッチアップに差が出てきます。
プロジェクト定義書は、「プロジェクトの成分表」として絶対的なものとして記録しておきます。
-スライド8：プロジェクトの進め方
次に、プロジェクトの進行方向をまとめましょう。
「何から行い、次に何をして、どう進めるのか」、をフローでまとめておきます。メリットは2つあります。
①全体を通してどのようなプロセスを経るのか一見でわかる
②現状どのプロセスにいるのか、随時、指差しで説明できる
経営者からすると、「細かい内容はいいけど、どんな感じで進めるのか」「今何をやっているのか」といった部分が気になります。
進め方を明らかにし、不要なチェックを減らし遂行するために重要な資料となります。
-スライド9：スケジュール
スライド9では、進める上でのスケジュールを「簡単に」まとめておきましょう。不確実なプロジェクトを進める上で、スケジュールの遅延は余裕で発生します。
細かく立てると破綻することもありますので、以下の2点に注意して簡素に作成することが重要です。
①細かいタスクは記載せず、重要なマイルストーンを記載すること。リリース予定日や報告会、検討期間、などです。
②見る人の目線にたって記載しよう。例えばIT担当者目線で「C/O」など表現してもなんのことかわかりません。「システム利用開始日」など、非IT部門でもわかる用語を記載しましょう。
-スライド10：プロジェクトリスクと対策
最後のスライドです。私個人的には、最も重要だと考えています。プロジェクトを悲観的に捉えて、将来起こりうるトラブル（炎上）を事前予測し、対策を記載しておくのがこのスライドの仕事です。
さて、なぜ事前にリスク（炎上）の対策を描くべきなのでしょうか？
もちろん、不慮の事故が起こった時に参照できるという実務的なメリットもあります。
しかし一番のポイントは、経営者含めてこのプロジェクトにはリスク、炎上の可能性があるという危機感を持つことです。
IT導入においてはシステム会社の営業が。コンサルタントがいればコンサルタント会社の営業が「うまくいく」というセールストーク、リップサービスを使うことがままあります。
経営者がそのいい話ばかりを鵜呑みにしていたらどうでしょうか？万が一トラブルが合った時に「そんなリスクは聞いてない」となるはずです。
これは期待値調整としても重要な観点です。ぜひ作成しましょう。
【最後に】炎上プロジェクトは無くせるのか？
はい、なくせると思います。
プロジェクトの炎上は、全て「人」に原因があります。
コミュニケーションや確認行為の不足。
期待値調整のミス。
登る山を間違えた、ルートを間違えた。
様々原因がありますが、基本「合意形成の問題」です。つまるところ、正しく合意形成がなされれば、必ず炎上しません。
様々なプロジェクトマネジメントノウハウがあるなかで、一番簡単でショボい、でも効果的な内容を私の短い人生経験からまとめてみました。
余すことなく伝えたつもりです。もしここまで利用したパワーポイントのスライドが欲しい！という方がいましたら、以下で販売しております。
※内容はここに書いてあるものと変わりませんのであしからず。
では。毎日が平和でありますように。
iryo
頂いたサポートを元に、様々なことにチャレンジしていきます！