カスタマーコンサルティングチームの小谷 将来です。
私は、ご契約企業様に対しより有効かつ効率的にTreasure Data CDPをご利用いただくためのご支援をしております。特にプロジェクトの立ち上がりから、推進までを横並びで走らせていただく役目を担っております。自身としては過去に数度の大規模プロジェクトのシステム刷新に携わった経験があり、ポジジョンはPM支援として品質、コスト、進捗の管理・運営等の推進をしてまいりました。
私からは、「プロジェクトマネジメントの実践」という視点からTreasure Data CDPの活用だけに止まらず、自分の経験・知見から、少しでもお役に立てて頂ける情報をご提供できれば幸いです。まず、前提として、大規模プロジェクトのノウハウを用い、中・小規模プロジェクトの当てはめた場合のエッセンスをご紹介させていただく形とさせていただきます。そもそもTreasure Data CDPを導入するプロジェクトは、大規模（数十億規模）のようなものではなく、Saasという性質上、比較的短期、かつ安価に導入すること目的としております。
加えて、昨今のプロジェクトについては、リスクを分散させる意味を含め、PoCを行ってからのシステム導入や、要件を段階的に取り込むアジャイル開発が求められるケースも多く見られます。そのため、皆さまにお話しする内容は中・小規模のプロジェクトに対しての実践方法や考え方を数回にわたり、お伝えすることが最適と考えました。
本稿では、まずプロジェクトマネジメントにおける「品質」の重要性について、お話をさせていただければと思います。
そもそも、プロジェクトマネジメントとは？
まず「プロジェクトマネジメント」を改めて定義したいと思います。その際「プロジェクト」と「マネジメント」を分けて考えてみてみましょう。「プロジェクト」とは、PMI*1が制定しているPMBOK*2の定義によると「独自の製品、サービス、所産を創造するために実施される有期性の業務である。」 とされています。ここで重要なのは「有期性」すなわち期間が決まっており、かつ、そのスタートとゴールの基準が明確に決まっていることです。
また「マネジメント」は、この場合「管理」と置き換えてよいかと思いますが、日本だと「管理」は、中間管理職の方があれやこれやと色々なことを引き受けているイメージでしょうかね。一方、英語では「管理」は様々な意味があり「統制（Control）」「やりくり（Management）」「事務遂行（Administration）」等の表現があります。ここでは「プロジェクトマネジメント」は「決められた期間の中で目的（GOAL）に向けて、組織を統制し、諸々の事務遂行をしつつ、PJ全体の諸問題に対しやりくりをすること」と、定義し説明いたします。
脚注
*1 PMBOK *2を作成した組織、Project Management Instituteの略。
*2 Project Management Body of Knowledgeの略。プロジェクトマネジメントに関するノウハウや手法を体系立ててまとめたもの。
顧客にとっては、何よりも品質が大事
プロジェクトにおいて、最も重要なのは「品質」です。ここでの「品質」は、いかに顧客の要望を満たしているか、ということに他なりません。いくらシステム開発ベンダーが、製造したものを品質として問題ないと言おうが、顧客が満足していなければ品質上問題があるということになります。重要なのは、いかに顧客の要求事項をシステム開発側がズレなく捉えることができるか、です。これは当然伝える側にも問題があります。伝え忘れや曖昧にしている箇所、前提のズレなど数えればキリがないほど問題が発生する箇所です。
QCDの関係性
プロジェクト運営においては、QCDを「管理」することを目的としています。ここでいうQは「品質」、Cは「コスト」、D「期間」を指します。しかしながら、C「コスト」、D「期間」はプロジェクトにおける失敗要因とはなり得ません。もちろん、極端な例でコストが不足し、途中でストップすることや、急遽期日が極端に狭まり、納品することが出来ない等もありますが、通常のプロジェクトの話としてご理解ください。
よくあるお話として、とある工程までに成果物が間に合わなかったという話も、その工程までに達すべき品質となっていないことが本質的な要因ですし、コストが不足しているというお話も、もともと投入できるコストから目指すGOAL（品質）が定められていなかったことが原因です。すなわち品質をしっかりと管理することがプロジェクトの成功のカギとなります。
失敗事例から学ぶ品質の重要性
いくつか、実例を交えて品質の重要性について、大別すると以下の2点になります。
- 要件定義漏れによる品質の低下
- 設計・実装の製造工程による品質の低下
要件定義漏れによる品質の低下
最初の要件定義の際に、実装すべき内容が正しくシステム構築サイドに伝わらず、クライアントを交えたテスト工程にて、本来実装すべき機能が実装されておらず、障害が多発し、品質基準に達せず、失敗する事例です。経験したことのある実例を２つ申し上げます。
１つめは、現行業務をシステム含め、クライアント（システム企画部的立ち位置）がよく理解していないパターンです。実際は、お抱えのベンダーしか把握しておらず、属人化した業務が多くあり、のちのテスト工程でその存在が発覚し、要件定義漏れとなります。２つめは、要件定義時点でやりたいことが決まっておらず、システム構築側に業務要件を担当させるパターンがあります。システム構築サイドから見てわかる業務の範囲は限定的です。そのため、システム構築側は、できることベースで要件を組み始めます。それらについて、良し悪しを判断をクライアントで下すことは困難なため、のちの工程（ユーザを交えたテスト等）で、実はそんな業務があったのかと、発覚するパターンです。
設計・実装の製造工程による品質の低下
設計・実装の製造段階でシステム構築側に丸投げをし、プロジェクトの途中経過で品質を把握せず、蓋を開けてみたら、全く想像と違うものや、そもそも出来上がっていない等の状態となり、品質未達により失敗する事例です。
これも経験した実例を申し上げますと、特に海外プロジェクトに多い傾向にあります。要件定義段階では問題なく、すり合わせを実行し、成果物も問題なく作成していました。ただ、担当するシステム構築ベンダーがコスト・期間の問題で別パートナーに依頼せざるを得ない（要件定義時とは異なる会社）プロジェクトだったため、そのままお願いしてました。クライアント側は、進捗のみを追いかけ、深掘りした成果物の品質確認はせずにいたところ、テスト工程で想像もしないような機能や、抜け漏れが発覚し、後の工程に進めず、プロジェクトが中止となったパターンです。
まとめ
プロジェクトマネジメントは一概に割り切れるものではなく、人により異なったやり方、考え方はあって然るべきだと思います。ただ、社内では意外と成功事例は共有することはあっても失敗事例を共有することは少ないかと思います。ただ、私自身、何度も失敗しており、失敗こそ成功の母であると実感しております。今後、またお伝えする中では、失敗をしないための解決方法や心得のようなものをお話しさせていただければと思います。
まだまだ、私自身も発展途上の身ではありながらの内容ではありますが、皆さまの一助になれば幸いです。拙い文章を読んでいただきありがとうございました。また次の機会があれば、ご一読ください。
