DX時代に求められるプロジェクト マネジャーの立ち回り方とは

Xspear Consultingが提供したプロジェクトマネジャー（以下、PM）支援について、3つのプロジェクト事例を取り上げながら、進め方や求められる役割をご紹介します。

1. A社：新規事業立ち上げプロジェクトの全体PM

既存事業での加速度的な収益拡大が難しく、既存事業・商品の競争力維持とグループ間連携によるシナジー創出を狙い、新規事業立ち上げを目指していたクライアントA社。
グループ会社を巻き込んだ事業検討が必要となるため、検討当初は社内でも秘密裏に進められた。ハイレベルな業務要件やスケジュール、マイルストーンを決めたうえで、A社内でも経営陣から新規事業開始に向けた取り組みがアナウンスされ、社外向けにもグループ会社との業務提携契約の締結の旨とあわせてプレスリリースが発行されました。
社内外で事業立ち上げの目途感を公表したことでより一層、新規事業立ち上げに向けてA社内だけでなく、業務提携契約を締結したグループ会社、その他関係各所との調整を滞りなく進め、スケジュールの順守や品質の担保を徹底する進め方が重要視されました。

プロジェクト内の各ブランチごとに、新業務・システム要件の定義は着々と進めていく一方、全体ＰＭには、経営陣のリクエストを適宜汲み取りながら、プロジェクト全体としての運営を推進していく役割が必要とされました。

まずは関係者と調整のうえプロジェクト会議体を早急に整備し、経営陣とプロジェクト各領域リードの方々との間に立って、各会議でのファシリテーションや会議後のフォローアップを行いました。会議調整のみにフォーカスすると、日次、週次、月次の定例に加えて、プロジェクト状況に応じて適宜差し込む突発的な打ち合わせ、関係者の休暇や別予定との調整をかけるだけの単なるロジ調整と勘違いされがちですが、全ての会議の開催趣旨・目的、会議実施後に経営陣・プロジェクト内外で抱えている懸念点を汲み取り、それらの解消に向けやるべきことと今後見据えておくべきことを言語化し、対応策を考えることが重要です。クライアントにとって、我々は外部パートナーの位置付けにいるからこそできる言動があることを意識して、日々のプロジェクトワークをすることが求められます。
ご支援のなかでは、会議中だけでなく、日々のコミュニケーションのなかでも、我々が誰の立場で、何の解決に向けて動いているのか、常に明確にしながら行動することが必要です。
即ち、全ての関係者に“良い顔”をすればよいわけではなく、時としては現場目線で、プロジェクトリーダーに対して改善の要求をし、時としてはプロジェクトリーダー目線で課題解決に向けて進捗が芳しくない際には厳しい言葉を投げかけ、どのようにしたら解決に向かえるか、膝を突き合わせながら検討するなど、非常に高度なコミュニケーターとして立ち回ることが求められます。

2. B社：新商品開発・サービス提供に伴うシステムPM

マーケティング部門、商品企画・開発部を中心に新商品開発の具体化や顧客の新たな囲い込みに向けたオンライン機能の充実やCXの向上、ヘルプデスク運営の高度化の検討を進めていたクライアントB社。
並行して進行する、新商品リリースに向けてシステム部門を中心として既存システム群の改修を進めるプロジェクトにて、新業務要件やシステム要望をもとにシステム要件定義を開始するタイミングでご支援を開始しました。
我々は、複数ITベンダーへの既存の仕様確認などを含めたアプリ／インフラ・非機能要件の整理や進捗の確認と、全体マイルストーンやスケジュールに対する遅延やリスク検知などのPMO支援を実施しました。
プロジェクトにはクライアント社員だけなく、多くのベンダーが参画する状況だったので、各ベンダーリーダーとの連携、状況把握に時間を要することから、状況把握だけでなく課題やQA管理プロセスの統一化を徹底し、属人的な要素を排除する形を目指しました。

またB社では、プロジェクトの要員調整も苦労されており、定常業務や他案件との兼ね合いから社員を当該プロジェクト専任で確保することが難しかったため、ITベンダーに依存してしまう構図が生じていました。
そのため、必然的に多様なメンバーがプロジェクトに出入りすることになり、従来は会議のなかで口頭確認に済ませていたことも文書化しておかないと、意思疎通を図ることが難しい状態でした。
そこで、弊社は週次で全ベンダーの進捗サマリーシート作成と、課題やリスクの解決に向けた取り組みのウォッチ、プロジェクト全体リスクとして捉えるべきものを明文化し、透明性の高いプロジェクト運営を行いました。加えて、経営陣の意見や業務ユーザの仕様変更の依頼を踏まえた、進め方のアジャストメントやそれに伴う作業レベルでの変更事項も全て文書として見える化し、プロジェクトの全体管理を担いました。
昨今、システム開発や運用・保守の内製化を進める動きが強まっていくなかで、当該プロジェクトはB社にとってその過渡期にあり、ベンダーに溜まった知見を文書化して社内に蓄積することも本プロジェクトの課題でした。プロジェクト専任の社員を確保することが難しいB社の状況は内製化にとって高いハードルではありましたが、我々は内製化に向けた動きにドライブかける施策を打ちながら、一方で、目の前のプロジェクト進捗への影響も極小化するという点を特に意識しながらご支援を行いました。

3. C社：バック基幹業務システム刷新時の海外ベンダーマネジメント

レガシー技術でホスト上に構築し、スパゲッティ化が進んでしまった基幹系システムの刷新を目指していたクライアントC社。国内外の複数ベンダーでコンペのうえ、従来から付き合いのあった国内ベンダーではなく、日本国内での導入実績がまだ少ない海外ベンダーが提供するパッケージシステムをクラウド上で運用することを選択されました。
弊社は、ベンダー選定のタイミングからご支援を行い、プロジェクトのマスタスケジュール作成や全体予算概算の算出から、RFP記載内容の精査まで、中立的な立場でプロジェクトに関与しました。
C社が海外ベンダーを選択した理由には、発注金額が既存の国内ベンダーと比較して安価であったことに加え、システム刷新とあわせてバックオフィス業務にグローバル標準モデルを適用させ、徹底的に業務の標準化、効率化を進めたいという意図がありました。

そういった背景もあり、このプロジェクトでは、パッケージシステムの適用とあわせ、業務オペレーションの標準化を推進するためには、PMはプロジェクト全体管理をするだけでなく、プロジェクトが躓きがちな勘所を持ち、必要な局面においては現場におりて検討に介入することも必要になりました。

例えば、クライアントと一緒に取り纏めたRFPの内容とベンダーが提供するパッケージシステムのギャップが徐々に見えてきた局面です。
現状と同様レベル乃至は現状を上回る機能要件やサービスレベルを求める要求仕様に対し、パッケージ標準でカバーできない場合、ベンダーからはアドオン開発するか、連携する別システム側で要件を吸収するか、問われる局面がありました。
その際、PMとして我々が提案したのは、アドオン開発か、別システム側で機能追加する、という2択に限定するのではなく、業務標準化に向けてパッケージ標準機能を使いこなす前提を再周知して、業務オペレーションを見直す代替案が取り得ないか、関係する現場メンバーを集めながら検討を推進することでした。
この局面において現場に任せてしまうと、特にアプリ設計を担当しているチームが、業務ユーザとベンダーの双方から挟まれて意思決定を求められ、判断がしにくい状況に陥り、結果として現状と同様の機能仕様の採用、すなわちアドオン開発に落ち着いてしまう、ということが危惧されました。
このリスクを防ぐためPMは、大きく2点を意識してプロジェクトへ発信し続けなくてはなりません。
1点目は、業務ユーザに対して、nice to haveに相当する業務要件は追加開発を許容しない首尾一貫した姿勢を保つこと。
2点目は、運用オペレーションとシステム機能の検討を同時並行で進めることを促し、システム対応できない業務内容をどの部署でどうやって運用するか、明文化していくことでした。
アプリ設計だけでなく、インフラ・非機能検討や運用検討など、トピックベースで必要に応じて巻き込みながら、システム・業務を一体で検討すること、そしてそれをファシリテートすることが必要でした。

また、海外ベンダーとのやり取りの中で、欧米と日本のビジネススタイルの違いが露見しました。欧米では「Role & Responsibility」が明確に定義されており、業務ステップごとに意思決定すべき特定の人物が存在します。海外メンバーにとって当たり前である意思決定のスピードと推進力、スケジュール順守への強いこだわりは、一般的な日本のそれらとは大きく違うものでした。
我々は、海外ベンダーとの会議の前に、C社と共に、海外ベンダーへのヒアリングポイントをまとめることにしました。海外ベンダーとの会議では、それらを一点一点確認し、不明点を解決したうえで遅延なく意思決定することを徹底しました。
このやり方は、会議準備の工数はかかるものの、事前に不明点や確認したい点を明確にし、確実に解決し、内容を理解しながら進められるため、結果的にはC社内での認識齟齬を極小化することにもつながりました。
良くも悪くも、教科書的にはやるべきだが、日本の商習慣上では実行できていないことを、強制力をもって改善していくという点も、海外ベンダーを活用して業務標準化を進める際のメリットになり得ると感じられるプロジェクトでした。