こんにちは、村です。 当連載では、数々のデータ基盤構築PJのマネジメントをしてきた自身の経験をもとに、私のチームにおける ・データ基盤構築PJのマネジメント ・そのデータ基盤構築を推進する開発組織のマネジメント の2軸で、思ったことや言語化できたことをつらつらと述べていきたいと思います。
第一回はCDP（Customer Data Platform）構築プロジェクト（以下 PJ）の特徴です。 他にも同じようなことを記載している記事はあるかと思いますが、連載第一回ということで今後の記事の前提としてご容赦ください。
※あくまで私個人における解釈だとご理解いただけると幸いです。
私のチームにおける代表的なPJ体制とパターン
CDP自体の細かい説明は省きます。知りたい方は、是非生成AIなどで検索してみてください。
CDP構築PJでは、PJ全体を統括するコンサル組織、データ基盤自体を開発する私の組織、CDPとの接続先であるMAやCRMツールなどを専門に扱うコンサル＆開発組織が代表的なPJの体制例となります（当連載ではこの開発組織に特にフォーカスをしていきます）。
PJのパターンは顧客によりさまざまで、要件定義から初期構築、活用（運用・保守）までを一貫して行うものもあれば、『導入したものの十分に活用できていない』、『リプレイスを検討している』、『内製化を進めたいのでその支援をしてほしい』、といったケースもあります。
CDP構築PJにおける開発PMの難易度
CDP構築においては、バグが多発するような状況はもちろん問題ですが、細かいバグの対応や、多数の設計ドキュメント等の成果物を丁寧に整えること以上に、「スピード」「成果」「柔軟さ」が重要な特徴となります。
そのため、いわゆるSIの業務とは大きく異なる能力が求められます。
各社の開発スタイル
あくまで私の所感で簡単に比較をしてみました。（異論はあるかと思います。ご容赦ください。）ちなみに私はSIerと広告会社系列であるHakuhodo DY ONEの２パターンの経験があります。
開発と言っても、各社によって文化はさまざまで、雰囲気は割と違うのではと感じます。 全てで満点が取れる会社がベストだとは思いますが、理想は置いておいて、CDPという性格のものに関しては、ツールベンダーやデータコンサル、広告会社系列が得意なのかなと思います。
（ちなみに一般的には、広告会社系列はSIの観点がSIerなどと比べるとやや弱い傾向があるように感じますが、私の開発組織においては、その点もがっちりやらせていただきますw）
上手くいくPJの特徴
ズバリ「染み出す」ことが重要です。さまざまな組織や人が関わる中で、いかに互いの領域に踏み込み、相互理解を深められるかがカギになります。本来、縦割りを解決するためのシステムであるにもかかわらず、PJが縦割りになりがちだと感じることがあります。
上手くいっているなーと感じる時は、開発がコンサルの推進したい事を理解し寄り添って、コンサルは開発を信頼していて、顧客に"ONEチーム"として見えている時、むしろ顧客を含め"ONEチーム"になれている時です。
特に新規顧客においては、最初の数回の会議でこの状態に持っていけるか（この状態になれそうという実感を顧客が得ているか）というのは非常に重要なファクターだと感じます。 まあ結局これは、どんなPJでもどんな仕事でも一緒だとは思います。
最後に
記載のように全てが上手くいけばいいのですが、当然苦労したこと、失敗したこともあります。今後の連載でそのあたりに触れていきたいと思いますので、どうぞよろしくお願いいたします。
