プロジェクトを推進していく術とは？
あなたが今まで担当してきたプロジェクトは、”順風満帆プロジェクト” でしたか？
もしくは、”一難去ってまた一難、泣きっ面に蜂プロジェクト” でしたか？
今日の社会を見渡すと時代の流れと共に様々な業界で新たな技術やビジネスが生まれ、その価値を企業間、国家間でせめぎ合っています。
この過程には、共通の目標をもった組織が有機的に目標に向かって働き、成果を出し続けているわけですが、このような組織が生まれたとき、その目標を達成するためには必然的に物事を前へおし進めること、”推進すること” が必要になります。
この”推進すること”を任された者が、”推進者”と呼ばれ、責任をもって推進していくことになりますがどのようなことに気を付けながら推進をするかによって結果が変わります。
それは、なぜでしょう。
今回は、プロジェクトを推進することの重要性と推進時のポイントをお話したいと思います。
推進することの重要性について
PL：「いままでの進捗報告では問題ないと言ってたじゃないか...！」
PL：「なんで期日になって資料が出来上がってこないんだ...！」
メンバー：「PLが指示した通りにやったのに怒られた...」
メンバー：「PLがこの前言ってたことと今日言ってることが全然違う...」
こんな風に思ったことや、ぼやきを耳にしたことはありませんか？
冒頭でお話した”共通の目標をもった組織”というのは、目標やその粒度によって規模や呼び方が異なります。
たとえば、新しい製品を開発する新製品開発部（100名が在籍）の配下にデザインを担当するデザイン課（30名が在籍）があり、その配下に、特定の部分だけを担当するデザイン課1グループ（10名が在籍）等々が考えられます。
その他にも、XX部隊など様々な呼び方が考えられます。
私が属するIT業界では、一般的に”プロジェクト”という有期性のある役務業務に対し、担当するメンバーが複数人アサインされ、プロジェクトチームという１つの組織が構成されます。
プロジェクトの規模や難易度によって、アサインされるメンバーの人数は異なります。
メンバーの中からプロジェクトマネージャー（以下、PM）もしくはプロジェクトリーダー（以下、PL）という肩書で推進者を任されます。
どちらが推進者としての役割を果たすかは、その企業や部の文化によって異なりますがここではPLとします。
たとえば、みなさんが”フレンチおもてなしプロジェクト”のメンバーにアサインされたとします。お客さんがリクエストしたフレンチのフルコースを時間内に提供するプロジェクトです。
そのプロジェクトチームはあなたを含めてフレンチの料理人5人で構成されています。
ここまでの話だけを聞けば、プロジェクトの難易度は低いと感じませんか？
各メンバーがお客さんのリクエスト通りに料理を作り、時間内に提供すればよいのですから。
さらにメンバーはフレンチの料理人です。料理を失敗するリスクも極めて低いでしょう。
しかし、メンバーが全員外国人だったらどうでしょう。
あなたは英語を話せない上に、指示しないと誰も動く気配がなく、てんでばらばらです。
困ったことに英語を話さないフランス人までいます。
この状況下でPLは、お客さんが望む料理を各メンバーへ正確に伝え、ばらばらのメンバーを統率し、推進していく必要があります。
全員外国人の設定なんて卑怯と思うかもしれません。
では、全員日本人、料理人20人で構成されている場合はどうでしょう。
この場合、日本人なので各メンバーへの指示には困らないでしょう。日本語でOKです。
しかし、各メンバーに作業を割当てて進捗を把握しようとしたとき、1人で20人を把握できるかという点です。
すくなくとも私には厳しいと感じます。
したがって、4チーム（5人編成）を作成し、各チームリーダー（以下、TL）に作業を指示し、進捗を報告してもらうなど、進め方に工夫が必要です。
しかし、指揮系統に属する人が多くなるにつれ、末端まで正確な指示が伝わらない可能性があるので気を付けなければいけません。
この状況下でPLは、認識齟齬が大きくならないように気を付けつつ、TLから進捗を確認して時間内に完成するよう推進していく必要があります。
どちらのケースも目指すゴールは同じですが、メンバーを統率し、ゴールまで引っ張ってくれるPLがいないと時間内に料理を提供できないことでしょう。
また、少し状況が異なるだけで進め方や留意するポイントを変える必要があります。
推進者はその場の状況に鑑みながら進め方やリスクを見極め、適した方法で推進していく必要があります。どこかでこれらを誤ってしまうと前述した”ぼやき”が夕暮れ時のカラスのように聞こえ始めるのです。
プロジェクトの雰囲気も徐々に暗くなっていくことでしょう...
さて、ここまでが推進することの重要性になります。
最初の節で”どのようなことに気を付けながら推進をするかによって結果が変わります”と言った所以がお分かりいただけたと思います。
では、もう少し踏み込んで推進していく際のポイントをお話します。
円滑に推進するために
ここまで読んでくると推進することの重要性は大体分かったから、手短にポイントを教えて欲しいといったところでしょうか。
もしくは、もう言わんとしてることは大体わかってるよ。といったところでしょうか...
では、さっそく手短にご紹介します。
ずばり、プロジェクトを推進していくうえで押さえたいポイントは下記です。
①認識齟齬（コミュニケーション管理）
②リスク回避（リスク管理）
③作業進捗の把握（スケジュール管理）
これだけ？と思うかもしれませんが意外とボリューミーです。
では、それぞれ解説します。
まず①ですが、進めていく上で１番避けたいのは認識齟齬です。
”フレンチおもてなしプロジェクト”でもメンバー間でゴールが正しく認識ができていないとリクエストを100%満たす料理が作れないと思います。
つまり、要求とは異なるものを提供しているので正しくゴールできていません。推進失敗です。
ちょっとした認識のズレから今までの努力がすべて無駄になってしまいます。
そうならないために、PJの関係者すべてのコミュニケーションを管理します。
お客さんはもちろんのことスポンサーやステアリングコミッティなどプロジェクトの規模が大きくなるにつれて範囲も広くなる傾向があります。
ここで注意すべきは、後々言った言わないの言い争いを回避すべく言質をとることです。
記録として残し、ステークホルダーと共有しましょう。議事録などがこの例にあたります。
弊社のOBPMでは、問合せ管理、レビュー管理、障害管理という機能が用意されており、顧客とのやりとりやレビュー記録などを残せます。
OBPMのメインメニュー画面
問合せ機能の登録画面 顧客とのやりとりをOBPM内に記録できます。
ただし、ここまでのお話は推進者自身がプロジェクトのゴールをきちんと理解している前提です。
推進者自身がプロジェクトのゴールを誤って理解した暁には、スタート時からあらぬ方向に奔走する姿が目に浮かびます。
このようなプロジェクトのメンバーになるほど気の毒なことはありません。
したがって、きちんとプロジェクトの内容を理解し、プロジェクトオーナーとの認識齟齬がないか確認するところから重要です。
もし不安であれば合意の取れたプロジェクト憲章を作るのも１つの手段ですし、後々困ったときに使えます。
②については、プロジェクトに支障をきたすリスクが顕在化した際に無為無策では困ります。
事前に考えられるリスクを洗い出し、対応方法を考えておくことでリスクが顕在化しても得々と対応できます。
これは、避難訓練と同じ理屈で次のアクションが分かっていれば、いざ直面しても迷わず行動できます。
”フレンチおもてなしプロジェクト”でも、いざ食材をとってみたら腐っていたり包丁でメンバーがケガしたりなどリスクは考えつきます。
この際に気を付けるポイントは、2次リスク以降も検討することです。
食材が不足している状況を考えたとき、近くのスーパーへ買い出しにいくとしましょう。
当然、その間はスーパーへ向かったメンバーが不在になり、そのメンバーが行う予定だった作業が止まってしまうかもしれません。
こういった具合にリスク→対応策→新たに生まれるリスク→対応策と掘り下げて検討していきます。
ここで百戦錬磨の経験豊富なツワモノたちは、「ふむふむ、あれとこれと...」という調子でポンポンと思いつきます。
しかし、これは経験が多いからであって、経験の少ない若手にとっては難しいです。
弊社のOBPMではプロジェクトにリスクを登録でき、あらかじめテンプレートとしておくことでPJ開始時に自動で展開されます。
つまり、先人たちが熟考し年季の入ったリスクを登録しておけば、新たに考えなくて済むうえにはるかに信頼もできます。
また、いつでもリスクを追加できるので、秘伝のタレのように進化しながらその後のプロジェクトに受け継がれていきます。
リスク一覧画面 テンプレートとして登録していたリスクが展開されます。
最後は③作業進捗の把握です。
リクエスト通りにものができても、納期までに完成しなくては意味がないです。
そのためにも作業進捗を把握し、管理する必要がありますが、メンバーからの報告に具体的な根拠がないものは注意が必要です。
偽りの進捗かもしれません。
この対策としては、進捗率を定義することが考えられます。
玉ねぎを炒めるというタスクを考えたとき、①玉ねぎの皮をむき、②包丁で切り、③炒めるという３ステップが必要です。
①まで終われば40%、②まで終われば70%、③まで終われば100%といった具合です。
ルールとして指標があれば、報告する側も従わざるを得ません。
弊社のOBPMでは進捗率の定義が可能です。進捗率の入力時に指標が表示されます。
ガントチャート画面 あらかじめ定義した進捗率が入力時に表示されます。
タスクを細かく分解するのもありでしょう。
1ステップをタスクとして用意することで進捗報告がシンプルになり、作業が止まっていたらすぐに分かります。
（専門的にはアクティビティと言いますが今回は説明を割愛します。）
あとは、メンバーも人間ですから問題があると報告したくない心理が働きます。
報告すると怒られ、他のメンバーに迷惑が及ぶと考えるからです。
これを防ぐには報告が遅れるほど迷惑が大きくなることを皆が理解し、ネガティブな報告をウェルカムとする雰囲気作りが重要です。
報告をうけて頭ごなしに怒ってしまうのは逆効果です。メンバーはさらに報告しづらくなってしまいます。（現に私がそうですから...）
プロジェクトを推進していく術 最後に
ここまでプロジェクトの推進についてお話しましたが、いかがでしたでしょうか。
つい先日、毎年行っている弊社のOBPMユーザー会があり、たくさんのユーザー様にお越しいただきました。
第10回という節目の会で、私はその企画段階から推進者を任されましたが、思うように推進できず...
推進の術とか言いながら私もまだまだと自省した次第です。
冒頭に伺いました、”順風満帆プロジェクト” か ”一難去ってまた一難、泣きっ面に蜂プロジェクト” ですが、これまでの経験上、想定どおりに進むプロジェクトは少なく、不測の事態がつきものです。この意味で一難去ってまた一難であり後者のプロジェクトがほとんどです。
しかし、不測の事態が起きても軌道を修正することができれば、結果として順風満帆プロジェクトになると思います。
したがって、どちらの“プロジェクト”も分別することはできず、２つで１つだと私は考えています。
大事なのは”いつもの進め方”でゴールできるとは限らず、プロジェクトの状況に応じて臨機応変に対応が必要ということです。
そのためには、状況の変化から適切な進め方を見極め、ステークホルダーを巻き込んで恐れず自らアクションすることが求められます。
私はここに推進することの意義があると思います。
今回「知っておきたい、プロジェクトを推進していく術」と題していくつかご紹介した”術”が
少しでも皆さまのお役に立つことと弊社のOBPMにご興味を持って頂ければ誠に幸いです。
