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