HOW TO TD(User Engagement)Treasure Data User Engagement

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

ホーム » プロジェクトマネジメント実践(2)

こんにちは、カスタマーコンサルティングチームの小谷 将来です。

前回、プロジェクトマネジメントについて、どのような問題がプロジェクトにおいてクリティカルな失敗要因となるのか、についてお話をさせていただきました。今回は、失敗における根本的な原因について、お伝えしていこうと思います。端的に言えば、私は以下の3つの事柄が最も根源的な原因と考えます。

  1. 「品質」をプロジェクト内で未定義、もしくは不十分
  2. プロジェクトにおける組織・体制の役割が不明確
  3. プロジェクトマネージャー(以下PM)が小さいリスクを放置

それでは1つずつ解説してまいります。

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

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

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

よくあるのは期間(ローンチタイミング)を意識し過ぎて、品質は二の次とし、ローンチ前のテスト工程でユーザから根本的なダメ出しを喰らい、プロジェクトがストップすることです。

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

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

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

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

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

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

PMが小さいリスクを放置

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

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

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

”見ぬふり”になれてしまうと小さいリスクは工程を追う毎に大きくなり、行く行くはプロジェクトを根幹から揺るがしかねない大きな課題になりうるかもしれません。

まとめ

プロジェクトマネジメントは一概に割り切れるものではなく、人により異なったやり方、考え方はあって然るべきだと思います。ただ、社内では意外と成功事例は共有することはあっても。失敗事例を共有することは少ないかと思います。

ただ、私自身、何度も失敗しており、失敗こそ成功の母であると実感しております。今後、またお伝えする中では、失敗をしないための解決方法や心得のようなものをお話しさせていただければと思います。

小谷 将来

Customer Consultingチーム

2006年よりNTTデータ系列の都市銀行の金融システム開発SEに従事。要件定義から開発、運用まで、一貫したSI開発を経験。経営層へのビジネス参画を若くして経験したく、2012年にアクセンチュアに転職し、銀行業界向けのITコンサルティングに6年半携わる。大規模プロジェクトのマネジメント支援を中心に、IT戦略立案、業務プロセス改善、AWSをベースとした情報系システム構築、BIベンダー選定等、様々なコンサルティング業務を経験。その後デジタルの最前線を肌で感じるため、2020年にトレジャーデータに参画し、カスタマーコンサルティングチームにて、Treasure Data CDP活用のためのコンサルティングを担当。現在は、大手製造メーカーへの新規プロジェクトのPM支援、および大手自動車メーカーへのCDP導入支援に従事。

得意領域 : プロジェクトマネジメント、コンサルティング、システム統合プロジェクト推進、銀行業界知識、DX

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

Back to top button