社内プロジェクトが成果を出せずに自然消滅する原因は、次の3つです。
1）ゴールを決めずに、思いつきで始める
2）忙しい精鋭に丸投げし、時間を確保しない
3）進捗の各段階で議論しない
対策も3つあります。1つ目は、リーダーがトップとゴールと権限を先に決めることです。2つ目は、ガントチャートと部署長への根回しでメンバーの時間を確保することです。3つ目は、議事録と課題管理表で会議ごとに決定事項を残すことです。以下、原因と対策を順に説明します。
「社内で〇〇プロジェクトを立ち上げる！」とトップが決定し、
各部署から精鋭が集められて、「さぁ、やるぞ！」と息巻く。
が、半年後には何の成果も残さないまま、自然消滅…
これって、実は業種を問わず多くの会社で起きていることなんです。
いろんな業種の企業において、私がご相談を受けていると「うちの特殊事情なんだけど…」から始まり、どこも根っこが同じ話を聞かされます。
なぜ、こうなるのか？
プロジェクトが成果を上げるために必要なことは何なのか？
プロジェクトが失敗する3つの原因
1.思いつきで無計画に始まるから
トップの思いつきで始まったプロジェクトは意外とゴールすら決まっていないことが多いものです。
「新聞にAIとあるから、うちでもAIプロジェクトを立ち上げろ！」
「競合の〇〇が始めた取り組みをうちでも導入しろ！」
「リモートワークができるようにしろ！」
という具合です。
当然のことながら、このまま始めてもうまくいくわけはありません。何しろ、ゴールも指定期間も達成基準も何もないのですから…
2.現場に丸投げし、人手を確保しないから
プロジェクトは精鋭を集めて始まります。社内の精鋭とはどういう人でしょうか？
そう、バリバリ仕事をこなす優秀な社員ですね。
優秀な人には仕事が集まります。
ということは、メチャクチャ忙しい人なわけです。
メチャクチャ忙しい人に、さらに従来業務と並列して、プロジェクトに参加しろという話なので、当然参加すら難しいという事態になります。
3.プロジェクト進捗の各段階で議論が行われないから
どんなプロジェクトでも、精鋭メンバーの顔合わせはします。
しかし、先述した通り、招集段階ではたいてい何も決まっていません。いつまでに、何をどのように（これは後でも良い）行い、何をどの程度達成するために、誰が何をやるか。これをここで決めないプロジェクトが多いです。
そのようなプロジェクトでは、次に集まるときも、やる気のある数人が好き勝手に思いつきを発言するだけの会議が続きます。いつの間にかプロジェクトリーダーも他の業務にかかりきりになり、プロジェクトそのものを誰も思い出さなくなります。
精鋭の中でも、最も優秀なリーダーが最も忙しいのですから。
プロジェクトの失敗を防ぐ3つの対策
こうなってしまうのはトップが悪いのでしょうか？
いいえ、違います。人が悪いのではなく、プロジェクトリーダーの仕事のやり方に問題があります。
なにしろ、社内で一番優秀な人、つまり一番忙しい人がリーダーだからです。
（まぁ時にはそうではなさそうな企業も…）
対策1：リーダーがトップとゴールを決め、権限をもらう
トップ発案のプロジェクトであれば、プロジェクトリーダーがゴールから始まるプランを作り、トップに承認を受けて、実行権限をもらうことがスタートです。
つまり、ゴールを明確にするために、まず、トップとコミュニケーションを徹底的に行う必要があります。これは副次的に、トップのプロジェクトへのコミットメントを高めることにもなります。
「AIプロジェクトを立ち上げろ！」であれば、小売業にとってAIは手段であって、事業目的ではありません。AIを活用して事業成果の出る目的を明確にすることがスタートです。
いきなり、プロジェクトメンバーを招集してはいけません。
さて、責任と権限は一体のものですので、プロジェクトに責任があるならば、当然権限を確保する必要があります。
私の前職でいうと、統合マーケティングにおいて5年の中期計画を立てて、予算としては経常利益の◯％に当たる投資プランを承認してもらいました。
企業の規模によっては、中期で企業全体の単年経常利益を上回る予算が必要なプロジェクトもあります。そのため、トップのコミットがプロジェクトには必須です。
これは本社引っ越しプロジェクトのような小さなものでも同様です。
まず、トップとコミュニケーションを取り、ゴールを決める事が必要です。
次に、ゴールの達成基準と時期を決定します。
それが決まると、週次での実行プランが決まります。各部署の精鋭に協力してもらうのは、ここからです。前工程、後工程を考慮して、ガントチャートを作成します。
ガントチャートは、横軸に時間、縦軸にメンバーや作業内容を配置し、工程やタスク毎に作業開始日、作業完了日の情報を帯状グラフに表したものです。何かの作業を進めていく「段取り」を項目別にまとめた表です。
ガントチャートを作る目的は情報の可視化と共有の2つです。
1.情報の可視化
ガントチャートで部署、担当ごとのタスクが明確になることで、各担当者が行うことや週次でプロジェクト業務に必要な時間がおおよそ見積もれます。
また、各タスクの前工程、後工程が明確になるので、他部署と何をどう調整したら良いかが明確になります。
2.情報の共有
プロジェクトメンバーには、通常業務があります。各担当が上司や同僚への説明にもガントチャートを使うと、自身の遅れが全体の遅れにつながることを周りも理解できます。その結果、プロジェクトに使う時間を確保しやすくなります。
どのタスクが遅れているかも明確になるので、リーダーが遅れているタスクをサポートすることもしやすくなります。
なお、IT開発などのプロジェクトでは、ガントチャートと別に、WBS（Work Breakdown Structure）を作成し、工数管理することが必須です。通常の社内プロジェクトではWBSレベルは各部署に任せた方が完遂速度としては早くなるので、端折ることが多いです。WBS（作業分解図）は、プロジェクトを構成する作業を分解して構造化する手法です。プロジェクトの最終的な成果物を作るまでの作業を明確にすることが目的です。
対策2：ガントチャートと根回しで、メンバーの時間を確保する
この対策の一つは上述のガントチャート共有です。
もう一つの対策としては、プロジェクトメンバーの上司である各部署長への根回しです。プロジェクトメンバーのプロジェクトに充てる時間を確保してもらうのです。
「根回し」を忌み嫌うビジネスマンも多いですが、仕事を完遂するために極めて重要な手法です。
根回しとは
ブリタニア国際大百科事典によると
「 会議や交渉を円滑，有利に運ぶために，非公式の場で合意の形成をはかること。下工作，下相談ともいう。元は樹木の植え替え後の活着を容易にするため，1～2年前に行なう細根の発生を促す処置をさす園芸用語であったが，事前に工作するという意味合いから転用されるようになった。」
とのことです。
根回しで一番大事なのは、相手の立場に立って物事を考えることです。
まず、自分が話そうとしていることが、相手にどのようなメリットとデメリットを生むのかを考えます。次に、デメリットをどうやったら解消できるのかを考えます。そのうえで、自分の提案を相手にとって損の無い話として理解してもらい、同意してもらうわけです。相手を窮地に立たせるためにプロジェクトを進めているわけではないと理解してもらうには、相手の立場で物事を考えることが欠かせません。
トップ起案のプロジェクトに対して、ほとんどの部署長を説得して納得していただくことは難しくありませんが、なかには、それでも合意が取れない相手がでてきます。
そのような時に有効な手段は、
1）相手が話を聞いてくれる人、仲の良い人に協力をお願いする。
2）個別にあたった後に部署長会議など、大勢の部署長がいる場所で承認を求める。
の2つです。
対策3：会議ごとに議事録と課題管理表で決定事項を残す
ガントチャートにプロジェクト全体の会議を設定すれば、この問題はある程度なくなります。ただ、個別の議論に全員が参加すると時間効率が悪いので、課題が発生するたびに、関係者だけの小会議を設定する必要があります。
小会議での決定・懸案事項は、全体会議で発表するわけです。全体を把握する必要があるプロジェクトリーダーは、小会議にも可能な限り参加してリードすることが望ましいです。一般に、人数が少ないほど全員が発言します。一方で、話が横に逸れて時間内に議題が決まらないのもよくある話です。リーダーにはファシリテータースキルも必要です。
全体会議でも、小会議でも会議をはじめる前に必ずアジェンダを作り、事前に共有します。また、参考資料がある場合には、事前共有日数に余裕を持ち、事前に目を通して質問点などを用意してもらいます。
全体の会議においては、進捗の管理が主目的となります。各担当のタスクに問題や遅れが発生していないか、それを誰が手伝うことが出来るかを明確にし、必ず議事録を作成します。
議事録の形式は何でも良いですが、必ず、決定事項と各担当が次回までに行うことを明記します。
作成した議事録は各担当と同時に各部署長にも配信します。
次回会議は、前回議事録でのタスク（誰が・何を・いつやる）から入り、終わってからアジェンダの内容に入ります。
さて、プロジェクトが進んでくると、様々な課題が表に出てきます。
これは悪いことではありません。課題を1つクリアするごとに、プロジェクトは一歩前進します。
課題の発生と重要度・緊急度の仕分け、遂行状況の共有のためには、エクセルで課題管理表を作成して、ガントチャートと同じように扱います。
課題の中には、かかる時間とコストを考えて見送るものもでてきます。こういった課題はシステムリプレースなどの機会に共有します。
最後に
それぞれの細目（課題管理表の作り方等）は、また機会があれば書きます。
プロジェクトが成功するための条件はプロジェクトが成功するために最も重要なODSCに、計画を立てる時間がない緊急時の進め方は企業における緊急事態への対応10のコツに書きました。
業務フローや稟議の書き方については、電子書籍にも書きましたので、参考にしてみてください。
また、プロジェクトに関するご相談も仕事として請け負っておりますので、困ったときはお声がけください。
リソースの関係でプロジェクトマネージャーそのものとしての受諾は難しいこともありますが、アドバイザーレベルなら大抵は受諾できます。
