「復習」というリスクマネジメントの最高峰を忘れていませんか?

プロジェクトに失敗やトラブルはつきものです。なかには、何事もなく期限どおりかつ予算どおりで完了するものもありますが、大なり小なり何かしらの問題が発生することがほとんどではないでしょうか。
世の中には「まったく同じ」というプロジェクトはないにしろ、「過去に同様の事例が一切ない」というプロジェクトも少ないと考えられます。これほど多くのプロジェクトが実行されているにもかかわらず、問題が発生するプロジェクトがなくならないのはなぜか――今回はリスクマネジメントの最高峰「復習」について考えてみたいと思います。

失敗は次に活かさねば意味がない!

間違った問題を復習することは学力アップ、知識定着において必須です。そしてビジネスにおいては、経験した失敗や問題を振り返り、次に活かすことこそがもっとも効率の良いリスクマネジメント法なのです。
問題が発生したら、直ちに何が原因なのかを究明し、早急に対策を練ることになりますが、これは後に「事例」という財産になります。次に活かすためには、同様のトラブルが発生したときに備えて事例を知識化し、使う人間の誰もが認識しやすいように整理しておく必要があるのです。
実際の事例を交え、失敗やトラブルの経験を次に活かすためには、どうするのが最善かについて考えてみましょう。

【事例紹介】大手生命保険会社システム開発における例

・プロジェクト規模:100人規模
・メンバー:
顧客→ 生保会社開発担当部門
開発→ プロジェクトマネージャー・プロジェクトマネジメントオフィス・開発チームリーダー・開発メンバー・協力会社(開発委託される会社を含む)
・原因と経過:
システム開発のプロジェクトにおいて、テスト段階において顧客の要望が大きく変わったにも関わらず、予算と期限は変わらない。

結果と解決方法:

エンドユーザーとの認識の相違が原因であると考え、キーパーソンとの認識のすり合わせを行った。また、顧客にサービスインの日程調整をお願いし、サービスイン時に必須の機能について認識合わせを行った。また、段階的に機能を盛り込むことを顧客と合意した。さらに、同顧客との過去のプロジェクトに参画したメンバーから開発案件の前提知識や条件などを共有した。

システム開発は、一般的に以下のような流れで行われます。
①顧客の要望を聞く
②要望どおりのものを設計し、確認する
③設計どおりに開発を行う
④設計どおりのものができているか、テストする
⑤顧客に納品する
④のテスト段階、もしくは④と⑤の間など納品前の段階で、顧客から「こんな機能を追加してほしい」「この画面は思っていたのと違う」などといわれることはよくあります。少しの変更であれば対応することもできますが、根本的なことに対して「実は〇〇だった」といわれてしまうことも多いものです。
こうなると①の要望を聞く段階からやり直しとなり、当初の期限や予算のまま顧客の要望を叶えることは難しくなります。この事例では、サービスインの日程調整と、必須以外の機能を段階的に追加するということで落ち着きましたが、それでも開発側に残業や休日出勤という無理が生じています。
もちろん①の段階で認識に相違がないか、後にトラブルとならないようすり合わせをしておくのが最善策ですが、この場合、過去に同顧客のプロジェクトに携わった経験がある者が、情報共有可能である場所にいました。その際の事例や、顧客に対する予備知識が事前に共有されていれば防げたトラブルだったかもしれません。

これらのことから、プロジェクトにおいて発生した問題や解決方法そのものだけでなく、エンドユーザー・キーパーソンの性格などについての予備知識などもプロジェクト内で共有化しておくことが重要だといえるでしょう。また、問題が起こってからの解決方法だけでなく、要件を聞く段階で進め方に問題がなかったかなどについても見直した方がいいかもしれません。

【事例紹介】製造業システム移行における例

・プロジェクト規模:50人規模
・メンバー:
コンサルタント・製造業担当部門・プロジェクトマネージャー・開発チームリーダー・開発チームメンバー(コンサルタントはコンサルティング会社、開発は協力会社を含む)
・原因と経過:
グループ全社のシステム移行プロジェクト。親会社とコンサルティング会社が作った計画にもとづいてプロジェクトを進めようとするものの、システムを使うエンドユーザーである各会社側は乗り気でない。当初の計画の10%程度しか進んでいないにもかかわらず、親会社からは早く進めるようにとの指示、エンドユーザーからは予算が取れないので移行できないとの反対意見。これらに板挟みされた状態のままプロジェクトが頓挫してしまった。

・結果と解決方法:

エンドユーザーにシステム移行後のイメージがないことが原因と考え、不安なことや質問などをヒアリングするなど、社内の情報共有を積極的に行った。また、プロジェクト内の各チーム間の連携を強化し、プロジェクトミーティングでの情報共有や引き継ぎも行った。

この事例の場合も、根本的な問題を最初に認識できていなかったことがトラブルの原因ですが、今後のためにも原因や経過・対策だけでなく、グループ会社全体の考え方などを細かく共有化しておく必要があるでしょう。ミーティングなどの機会が少なければ、プロジェクトグループ内で情報共有ツールなどを活用するのが効率的です。また「プロジェクトの計画そのものに無理がなかったか」を考える必要が生じることもあります。

事例の知識化が組織の社会性を広げる

プロジェクトの中で起こった問題の多くは、過去に同様の問題が起こっていることが多いものです。納品後はプロジェクトを解散し、メンバーはほかのプロジェクトに異動することが多々あります。いつまでもメンバーをかかえているとコストがかかるうえ、次のプロジェクトも控えているため、結果的にプロジェクトマネージャーが単独で最終処理をすることも多々あるでしょう。

ただし、このような流れのままでは、プロジェクトの中で起こった問題を次につなげることができず、プロジェクトマネージャーの経験値が上がるだけになります。
そのため「振り返り」という機会をもって、プロジェクトの中で起こった問題や事象をあらためて考え、そのときの対応が適切であったか、ほかに方法はなかったかということを今一度メンバーで考え直すことが重要なのです。それを文書やデータなど知識化しておくことで、事例は初めて「財産」となります。

そして、振り返った内容を次につなげるためには、管理することが必要です。ただ知識化するだけでなく、次のプロジェクトに過去の事例を活用することが大切なのです。次回の同顧客プロジェクトに携わるすべての者が、これらの事例を閲覧し共有しやすい構造にできれば、トラブルを未然に防ぐことが大いに期待できます。この「復習」こそが、組織の社会性を広げることにつながり、同時にプロジェクトにおいてのリスクマネジメント最高峰であるといえるのではないでしょうか。

まとめ

プロジェクトはいつも順風満帆であれば問題ありませんが、常にリスクが潜んでいるものです。起こってしまった問題を最小限のコストと時間で解決するためには、過去の事例を知識化・構造化し、想定されるリスクに対して万全に備えておくことが非常に重要です。そしてプロジェクトメンバー全員でそれらを共有できる状態にしておくことが、トラブルを未然に防止するための最善策だといえるでしょう。

つまりビジネスにおいても、勉学と同じで「復習」が重要なのです。起こった事例をメンバー全員で振り返り、話し合う機会を設けなければ、せっかくの経験が無駄になるといっても過言ではありません。問題が起こると「トラブルだ!」と嬉々として動くマネージャーもなかにはいますが、問題が起こったときの対応を個人の武勇伝にするだけでは意味がないのです。

せっかくの事例を経験値として活かさなければ、いつになっても効率化は図れません。プロジェクトはプロジェクトマネージャーだけのものでなく、プロジェクトに携わる全員のものです。関わったプロジェクトについてメンバー全員があらためて「復習」することこそが、次のプロジェクトをより確実に成功へつなげるためのスキルとなるのではないでしょうか。そして、その事例を知識化・構造化しておくことが、将来のトラブルを未然に防止するためのリスクマネジメントとなるでしょう。

参照サイト
株式会社ベイジHP
 
myコンテンツ工房

間違いないチームマネジメント

競争的な市場の中でビジネスを加速させていくためには、強力なチームの存在が欠かせません。効果的なチームビルディング術や、チームでの共同作業に役立つツールやポイントを押さえることで、最高のチームを作り出しましょう。

詳細を確認する

この記事が気に入ったら
いいね!しよう

最新情報をお届けします

同じタグのついた記事

同じカテゴリの記事