早期のPoC開始が必須のC2Cカーシェアサービス新規事業開発プロジェクト

背景

ある大手企業の新規事業として、C2Cカーシェアリングサービスを開発するプロジェクトが立ち上がりました。個人が所有する車を他の個人が借りられるマッチングプラットフォームの構築を目指し、新しく子会社を設立してサービス提供を行うという事業開発を伴うプロジェクトでした。しかし、設立された子会社には、当初、社員が2人しかおらず、2人とも、サービス開発・システム開発に関する知識が十分とはいえない状況でした。

このプロジェクトを難しくしたのは、開発期間の短さでした。プロジェクト開始時に企画が承認され、数ヶ月後には子会社が立ち上がり、翌年春にはPoCを開始するというスケジュール
でした。また、開発だけではなく、新規事業ということで、業務プロセス自体も新規に設計し、オペレーターへのトレーニングも必要でした。そもそも、新規のサービス開発という、要件があってないような不確実性の高いシステム開発でありながら、限られた予算とタイトなスケジュール、そして、やるべきことも多い、ということで、非常に難易度が高いプロジェクトでした。

プロセス

ゼロからの企画具体化とベンダー選定推進

私がクライアント側のPMOとしてプロジェクトに参画したのは、企画の承認直後で、新規事業の初期段階から立ち上げに関わることになりました。この段階では、C2Cカーシェアリングという大まかなコンセプトはあったものの、具体的な機能要件やアーキテクチャは決まっていませんでした。

要求事項もまだ曖昧な状態であり、スケジュールもタイトかつ、予算的にも厳しいものがあった為、何社かのベンダーにお声がけをしましたが、いずれの会社にもお断りされてしまいました。

そこで、まずは、あいまいな要求事項の具体化を進め、大枠でどんな機能を開発すればよいかをわかるようにしました。また、私の個人的なコネクションを活用して、カーシェアについて一定の知見があると聞いていた、知り合いのシステム開発会社に声をかけ、何とかプロジェクがスタートできる状況になりました。

困難な開発環境下でのプロジェクト管理と品質確保

要件定義から開発フェーズでは、システム開発会社と協働で行いました。同社がカーシェアについて一定の知見があると聞いていたためです。
しかしながら、要件定義工程自体のスケジュールも非常にタイトにもかかわらず、要求事項も膨れ上がっていき、要件定義工程も間延びしていきました。このままでは、PoCに向けたリリース期限を守ることが難しいと判断しつつも、機能の落とし込みが十分にできず、結果、できるところから開発を始めようということになりました。しかし、要件・仕様を調整、確定しながら、無理矢理開発を進めようとした結果、品質がさらに悪化するという悪循環に陥ってしまいました。

この状況下でさらに大変なことが起きました。開発会社側のPMが離脱したのです。この方自身は、経験豊富で信頼できる方でしたが、クライアント側の要求と、自社メンバーのスキルとのギャップ（要件を機能に落とし込む力に弱さ）を調整する重圧に耐えきれず、途中で体調を崩してしまったのです。その結果、我々とのコミュニケーションのギャップも生まれ、要件が正確に伝わらない状況が生まれました。

しかし、PoCに向けたリリース日は変えられません。こうなると、泥臭く対応するしかありません。できた機能から、クライアント側社員、我々PMO、また派遣スタッフも3名雇用し、総出でテストを行い、バグ出しをし、１つずつ、つぶしていく作業を行いました。正常な開発プロセスとは言えませんが、その結果、何とかPoCを実施可能な品質レベルまで引き上げることができました。

アジャイル運用とベンダー変更による品質改善

リリース後のPoC運用フェーズでは、アジャイル的に機能改善のスプリントを実施しました。利用者が少ない初期段階であったため、小まめに修正を重ねながら品質を向上させていくことができました。しかし、開発会社とのコミュニケーションギャップの問題は解決できておらず、クライアント側もフラストレーションがたまっている状況でした。

最終的には、クライアント側の判断でベンダーを変更することになりました。これまでのシステム開発会社のメンバーは外国人の方が多く、言葉の問題も生じていたのですが、新たに日本人のエンジニア主体のベンダーに切り替えることで、コミュニケーション面の問題の抜本的な解決をはかりました。ベンダーの変更には、引継ぎや体制構築も含め、半年程度の期間が必要でした。その間、旧ベンダーと新ベンダーが並行で開発を進めるという体制になりました。この間、我々はクライアント側のPMOとして、PoCの進行だけでなく、旧ベンダーと新ベンダー含めた、統合的な推進を行いました。

2019年の年末頃にようやくベンダー切り替えが完了し、スムーズな開発体制が構築できる見通しがついたタイミングで、我々の役割も完了となりました。

結果

タイトなスケジュール、厳しい予算、万全とは言えない体制の中で、要件をまとめ、PoCに向けて動くシステムを作るという目標は達成することができました。品質が悪く、コミュニケーションも難しいという状況下であっても、関係者全員が一丸となって対応したことの成果でした。

プロジェクトマネジメントは、本来、しっかり要求・要件を整理して、スコープを定め、それに基づく現実的な計画を立て、正しく状況を把握し、交通整理をして、課題を解決するということを体系立てて行っていきます。しかし、今回の事例では、走りながらマネジメントする必要がありました。そして多くのトラブルがありました。しかし、この状況でも、クライアント、ベンダーと誠実に、丁寧にコミュニケーションを取って、前向きに、一丸となってプロジェクトに向き合えば、なんとかなるものという学びを得ることができました。

また、苦しい中、一緒に壁を乗り越えたクライアントとはとても強い信頼関係を築くことができました。大変な状況に対してネガティブに対応していたら、このような関係は築けなかったと思います。
私自身もそうですが、現場で奮闘した弊社のメンバーもこのプロジェクトを通じて、やりきる自信がついたと思います。