プロジェクトマネジメント実践(2)

「品質」をプロジェクト内で未定義、もしくは不十分

品質というものをプロジェクトとして定義していないため、同じGOALを描けていないのが大きな原因の1つめです。

プロジェクトのGOAL ≠ ローンチ

前述したとおり、プロジェクトにおいて期間はクリティカルな要因となり得ません。あくまでその期限に求められた品質に達していないのが重要です。一般的に大規模なプロジェクトでは工程ごとの開始・終了条件が定められます。中・小規模のプロジェクトでも、大規模プロジェクトほど形式張ったものは作成しないまでも、タスク毎に何がアウトプットになり、そのアウトプットが目指す品質基準を設けていくことが望ましいと考えます。よくあるのは期間（ローンチタイミング）を意識し過ぎて、品質は二の次とし、ローンチ前のテスト工程でユーザから根本的なダメ出しを喰らい、プロジェクトがストップすることです。

目指すのは顧客満足

「品質」というのは、ITプロジェクトにおいて最も重要であり、難しいものだと感じます。品物が実物としてあるプロジェクトは、その品質の定義や確認方法は非常にわかりやすく、マネジメント層の方々も理解が及びやすいものと考えますが、ITプロジェクトにおける品質は定義がときに曖昧になりやすいです。

PMBOK*2によれば、品質とは「一連の固有の特性が要求事項を満足している度合い」となります。これだけだとよく分かりませんが、言い換えると、「構築したシステム機能が、一定の基準を持って測定し、顧客の要求を満たしていること」を指します。すなわち、実際にシステムを利用するユーザが満足することが何よりも重要なことであり、目指すGOALであるということです。

プロジェクトにおける組織・体制の役割が不明確

大きな原因の2つめは、プロジェクトにおける組織・体制の役割が曖昧なため、プロジェクトの健全性が損なわれることです。

勇者が登場するのを待つ文化

プロジェクトというのは、様々な人・会社・システムが介在します。そのため、色々な思惑があり、自らの利益を優先するため、どこかが誰かが損をするような構図になりがちです。組織・体制の役割が明確でないがために、曖昧な課題・TODOはしばらく、上層で漬け置きにされ、期限間際になり誰かやってくれないかという話になり、弱い立場の勇気ある実務担当者が声を振り絞り引き受けるからです。一度、スコープを拡げてしまうと結果的に責任者扱いになり、似たような領域を拾い続けることになりかねません。

プロジェクトでの情報共有がなされない

また、他にも担当者間の情報のやりとりが横行し、本来PMが知らなければいけないことが共有されなかったり、またマネジメント層にエスカレーションすべき事項がPMで止まっていたりとプロジェクトの阻害要因になります。これらはプロジェクトを始める上で、重要視すべきポイントであり、方針が変われば都度見直しをする必要があります。

PMが小さいリスクを放置

大きな原因の3つめは、発見したリスクを小さいうちに消化せず、放置することです。

プロジェクトマネジメントはリスクの対処が全て

プロジェクトマネジメントはすなわちリスクの発見、判断、対応の繰り返しであると考えます。PMは、常にリスクに目を光らせ、発見した際には内容を精査し、QCDの観点から対応策を講じるべきか判断する。対応が必要となった場合、リスクを軽減するための策を講ずる。その上でプロジェクトを成功に導いていくのがPMだと思います。

小さなリスクでも共有できる雰囲気作りが大切

しかしながら、PMはとても多忙であり、様々な事柄に目を向ける必要があります。その際、ちょっとしたリスクを軽視しがちです。重要なのは”放置”しないことです。まずプロジェクトにおいて、それらを共有する場を設け、たとえ問題が発生せずとも共有できる場と雰囲気を作ることが肝要です。”見ぬふり”になれてしまうと小さいリスクは工程を追う毎に大きくなり、行く行くはプロジェクトを根幹から揺るがしかねない大きな課題になりうるかもしれません。

まとめ

プロジェクトマネジメントは一概に割り切れるものではなく、人により異なったやり方、考え方はあって然るべきだと思います。ただ、社内では意外と成功事例は共有することはあっても。失敗事例を共有することは少ないかと思います。ただ、私自身、何度も失敗しており、失敗こそ成功の母であると実感しております。今後、またお伝えする中では、失敗をしないための解決方法や心得のようなものをお話しさせていただければと思います。