PjMは事業と開発の両サイドに。複雑化するプロジェクトマネジメントに、ZOZOが出した答え

事業の成長と組織拡大に伴い、開発量や関係者が増え、コミュニケーションエラーや認識の齟齬が頻発して、進捗の遅延や開発現場の疲弊につながるケースは少なくありません。

ファッションEC「ZOZOTOWN」を運営するZOZOでも、約5年前からこのような課題を抱えていました。進行管理を担う人が固定化されていないことで、ボールが落ちたままになってしまうなど、プロジェクトがスムーズに進められないこともあったといいます。

ZOZOではこの問題を解決するために、PM（プロジェクトマネジメント）組織として事業部側のPM「Biz-PM」、開発側のPM「Tech-PM」という2つのチームを組成。開発案件の進行において、事業部側、開発側それぞれにプロジェクトマネージャーがアサインされる体制をつくり、一定の効果が生まれているそうです。

本記事では、多くのステークホルダーが関わるプロジェクトのリードタイムを短縮しながら「誰も疲弊しない体制」をつくってきた方法を、ZOZOTOWNのPM組織全体を率いる加藤さんと、Tech-PMチームの宇佐美さんにお聞きします。開発者の負担を減らしながら、プロジェクトの推進力を高める取り組みの中には、様々な現場に活かせる工夫が詰まっていました。

• keyboard_arrow_down 事業と組織の拡大で、「進行管理」が宙ぶらりんに
• keyboard_arrow_down Biz-PMとTech-PMの連携で、QCDのトレードオフも折れずに調整
• keyboard_arrow_down 独り立ちまで約2年　進行中とふりかえりのナレッジを貯める仕組み
• keyboard_arrow_down 影響範囲の広い体制変更　成功のカギは「愛」

――今日はよろしくお願いします。まず初めに、現在の体制を検討する前に、開発現場にどのような課題があったのか教えてください。

加藤：事業の拡大やマイクロサービス化による組織の再編が進む中、関係者がどんどん増えて、開発案件全体の進行管理が複雑になっていたんです。案件ごとに進行管理を担う人が変わることもあり、誰がボールを持っているのか、今どこまで進んでいるのかが見えにくくなっていました。メンバー同士の連携でカバーしたりして、なんとか進めていたんですが、次第に対応しきれなくなってきて…。

宇佐美：当時、要件定義などの上流工程は事業部側が中心となって進めていたので、ある程度要件が固まってから「これ、実装できそう？」と開発側に確認が飛んでくることも。そこで初めて技術的な課題が見つかって、スコープや仕様の調整に時間がかかることもありました。

――「もっと早く言ってよ」と思ってしまいそうですね。多くの組織がぶつかる課題だと思います。

加藤：この課題の解決するために、2021年に、ZOZOTOWNに関する事業部側との調整と進行管理を担うPM組織「ZOZOTOWNプロダクト戦略部」を立ち上げました。PMが案件の初期段階で、マーケティングやセールスといった事業部側の関係者にヒアリングを行い「案件の目的、ターゲットユーザー、期待する効果（KPI）」を明確にして要求を整理する。要求が固まった段階で開発チームに相談して要件定義、開発へと進めていく。この取り組みにより、手戻りは格段に減りました。

でも、新たな課題も見えてきて。PMには開発の知見が薄く、開発側との認識をうまく合わせられていなかったんです。開発の細かなスケジュールまでをPMが管理することもできず、やむをえずエンジニアのメンバーが進行管理や調整役を担うことも多かった。そのため、エンジニアが開発業務に十分な時間を割けないという状況が起こっていました。

――たしかに開発の知見がないと、技術的な懸念事項を把握するのは難しいですよね。次の一手はどう考えましたか。

加藤：PM組織の上長と、開発側のディレクター（部長職）に声をかけ、いくつかの選択肢を検討しました。

例えば、PMメンバーが開発に関する知識をつけていく方法や、進行管理や調整を担う開発リーダーをある程度固定化してプロジェクトマネジメントの知見を蓄積していく方法などが候補に挙がりました。前者をとると、開発に関する膨大なコンテクストや知識を理解するための努力が、PMの強みである推進力を圧迫してしまう可能性がある。後者をとると、エンジニアが開発に集中できる環境を作りきれない。

最終的に選んだのは、PM組織を拡大して二つのチームに分ける方法です。事業部側を担当する「Biz-PMチーム」と、開発側を担当する「Tech-PMチーム」の2チーム体制を作り、1つの案件に対してBiz-PMとTech-PMを1人ずつアサインし、連携しながら案件を推進していく形にしたんです。

――1人のPMがビジネスと技術の両方を担うのではなく、それぞれの専門性を生かした2チーム体制で連携する道を選んだわけですね。

加藤：はい。こうすることで、プロジェクトの優先度や特性に応じて最適なBiz-PMとTech-PMを、横断的にアサインできるようになりました。

また、Tech-PMの役割を「技術的なバックグラウンドを活かしつつ、プロジェクトマネジメントに専念する」と明確に定義できるため、Tech-PMとなったメンバーがこの役割に明示的に専念できます。さらにスケールを見据えた、スキルセットの言語化、育成やナレッジシェアの仕組みの構築にも取り組みやすくなる。この体制こそが、短期的にも中長期的にも、まさに今必要な機能を果たせる形なのではないかと考えました。

宇佐美：そのタイミングで私はTech-PMチームの取りまとめをやってほしいと声をかけてもらって。それまではWebバックエンドのチームのブロック長として、商品詳細ページやお気に入り機能の改修や新規機能追加などの開発の進行を管理しながら、自分でも手を動かしていました。プロジェクトマネジメントにはもともと興味がありましたし、進行管理の経験もあったから、声をかけてもらったのかなと思います。

Tech-PMチーム発足時のメンバーは、特定の領域に偏らないようWebバックエンド、Webフロントエンド、アプリチームから1人ずつ選出され、計3名でスタートしました。3人とも、開発リーダー的な役割を担っていたり、以前からプロジェクトマネジメントに興味があったりしたので、発足当初から同じ目線を持って進めることができました。

――Tech-PMチームはどんなミッションを持っているのでしょうか。

宇佐美：大きく2つあります。1つは、一部のエンジニアが進行管理も担うことでリソースが分散していた状況を改善し、開発チームの全員が開発に集中できる環境を作ること。

もう1つは、案件全体のリードタイムの短縮です。私たちTech-PMチームが案件の初期段階で開発の方向性や実装の道筋をある程度固めることで進行をスムーズにし、結果的に案件全体のリードタイムを縮めていくことを目指しました。

加藤：Tech-PMチームが本格的に稼働し始めてから、明確な変化がありました。案件の初期段階で技術的な観点での提案や懸念が共有されることで、開発の方向性や実装の道筋が固まり、プロジェクト全体の進行が非常にスムーズになりました。

宇佐美：何より大きかったのは、開発チームからプロジェクトマネジメントの役割を明確に切り出せたことですね。エンジニアから細かな調整や進行管理の負担を取り除くことで、開発に集中できるようになりました。これは開発組織全体の生産性向上にも繋がっていると考えています。リードタイムも短縮でき、より大きく事業に貢献できるようになりました。

――現在の体制や案件の進め方について詳しく教えてください。

加藤：現在はBiz-PMチームが10名、Tech-PMチームが6名の16名体制です。1つの案件にアサインされるのは大抵1人ずつです。

案件の大まかな進行フローとしては、①案件優先度決定→②開始準備/整理→③案件説明会/要求定義→④要件定義→⑤開発キックオフ→⑥開発設計→⑦開発→⑧QA/テスト→⑨リリース→⑩リリース後対応という流れ。このフローはBiz-PMチームもTech-PMチームも共通認識として持っていて、関わる全員が「今どのステップにいるのか」「次は何をすべきか」をPMチーム全体のMTGで報告し合って把握しています。

通常はBiz-PMチームが①～④、Tech-PMチームが⑤～⑩を担当しますが、厳密な線引きはありません。案件の特性によって、お互いの領域を行き来しながら進めていますね。

宇佐美：例えば抽選販売機能の開発など、影響範囲が広く、技術的な難易度が高い案件であれば、③の要求定義や④の要件定義からTech-PMが積極的に関わっていきます。案件の特性に応じて最適なタイミングで連携できるように、案件発生時からPMチーム全体の週次MTGで情報共有をしています。

加藤：開発が始まってからも、事業の状況が変化して要件やUIが変わる場合は、主にBiz-PMが調整に入ります。開発中に新たな課題が見つかったり、ビジネス要件が変わったりすれば、主にTech-PMがそれを拾って対処する。その過程で一度前のフローに戻ることもありますし、臨機応変に進めています。

――プロジェクト自体の優先順位やリソース調整はどのように行っていますか？

宇佐美：どの案件も、基本的には要求定義の段階でQCD（品質・コスト・納期）のどれを優先するかを、事業部側とすり合わせます。QCDはトレードオフの関係なので、例えば品質を重視するならば、ある程度納期は後ろに倒れることを理解してもらう。そういう調整を案件ごとにしています。

――トレードオフの調整って、難しくないですか。

宇佐美：難しいですね。そもそもエンジニアが考えるQCDの関係性やバランスを、事業部側全員が理解しているわけではありませんし。納期が迫っている、進行が遅れているといった案件がいくつも同時進行していると、関係者が皆焦って余裕がなくなっていることもあります。

でも結局は、相手の納得感を大切にしながら説明する姿勢が大事だなと思います。まずは開発チームと課題を整理して、調整可能なポイントを明確にする。そしてスコープを削る、納期を延長するなど複数の選択肢と、ビジネスに対して与える影響をセットで具体的に提示して、最終的に双方が納得できる意思決定へと導いていく、といった動きをとっています。

基本的なことではありますが、技術観点を持って、相手のやりたいことを形にする方法を一緒に考えていくのが、Tech-PMとして発揮できるバリューなのかなと思っています。

――「この日までに絶対に完成させなければならない」という強い納期の制約がある案件には、どう対応していますか。

加藤：納期が決まっていて、事業インパクトが大きく、かつ開発リソースを要するようなプロジェクトは、経営層まで持っていき、全部門が納得感を持って「この案件は優先度が高い」と認識できるようにしています。

こうした際は、要件定義より前の計画段階からBiz-PMとTech-PMが介入して、プロジェクトの準備を始めます。納期に向けたプロセスを練って、事業部側、開発側の両方の上位レイヤーの方に、計画に無理がないかを確認してもらった上で、リソースの確保に移ります。期限が厳しく決まっているわけではない内部施策からメンバーをアサインすることもありますね。

――仮に納期が決まっている案件がいくつか続いたとすると、内部施策がどんどん後ろ倒しになってしまいそうな気もします。

加藤：おっしゃる通り、中断することも0ではありません。ただ、そもそも中断が起きないような全体開発計画の策定に徹底して取り組んでいます。万が一中断する際には、キリのよいところまでは進めたうえで、中断する背景や理由、再開した時にすぐ着手できるタスクリストをドキュメントに残しています。再開予定を開発計画に織り込んでいる場合が多いです。

そして、原則は中断した時と同じPMが再開時も担当するようにしています。もし担当者が変わったとしてもドキュメントがあるので、誰でもすぐに状況をキャッチアップできるようになっています。

宇佐美：内部施策の多くが「技術的負債の解消」なので、Tech-PMとしては「技術的負債を、対処可能なサイズに留めること」と「中断時のチームのケア」に注力しています。通常案件でも必要に応じてスケジュールに余白を持たせるようにしていますし、内部施策を中断する場合は、ビジネスリスクをBiz-PMと共有した上で、開発チームとすぐに再開時期をすり合わせ、再設計なども支援します。

また、内部施策の中断は、施策に関わっていたエンジニアのモチベーション低下に繋がるリスクもあります。中断理由の説明を丁寧に行ったり、「決して内部施策を軽視しているわけではない」と伝えたりと、コミュニケーションをとるだけでなく、Tech-PMが責任をもって速やかに再開へと動きます。ほかにも、特定の人が「火消し役」に固定化されないよう、プロジェクトごとの負荷状況をモニタリングし、偏りが見られればチームリーダーと連携して調整したりもしています。

――ここまでのお話で、PMは案件の成否が決まる、非常に重要なコミュニケーションの要点だと感じています。Tech-PMは元々エンジニアの方ばかりだと思いますが、事業部側の要求を引き出して適切に調整するスキルを得ていくために、チームでどんな工夫をしていますか？

宇佐美：Tech-PMのタスクの1つである「基本設計書の作成」のプロセスが、育成において強力に作用していると感じています。基本設計書とは、案件の要求が決まった後、その内容を技術的に破綻のないようシステムの設計に落とし込んだものです。これをもとに、事業部側と開発方針をすり合わせ、開発を進めています。

作成した基本設計書は、Tech-PMチームの皆に、案件の背景やなぜこのタイミングなのかを共有したうえで、レビューをもらうように決めています。自分が担当する案件を、チーム全員に内容が伝わる説明ができるように理解しなくてはならない、良い意味での強制力が働いているのです。また、他の人の基本設計書を見たりレビューを聞いたりするうちに、別の案件の動きや背景、事業部側の意図も少しずつ理解できるようになります。

この説明プロセスやレビューの中で、参画したばかりのメンバーにも事業部側の視点が徐々に身についていく実感があります。

――ZOZOには新卒ですぐPMに配属された人もいるそうですが、経験の浅いうちはどうフォローしているのでしょうか。

加藤：たしかにPMがうまくワークできないと、案件全体が遅れたり混乱したりといったトラブルにつながります。そのため新卒PMが最初から一人で対応することはなく、必ず先輩のBiz-PMがサポートに入って並走しています。

また、週次で行っているPM全員が集まるミーティングが、案件特性に合わせたノウハウの共有や、各自が直面している課題の相談ができる場として機能しています。

宇佐美：Tech-PMチームには、エンジニア出身の新メンバーが昨年2名加わりました。彼らは開発の知見を持っているものの、プロジェクトマネジメントは初心者。最初はメンターとなったPMと一緒に案件を進めながら学んでもらいました。

重要な学びの場となっているのが、リリース後には必ず行うふりかえりです。見積もり精度の向上のために、「プロジェクトの技術的な目標は達成できたか、リリースされた機能の品質は期待通りだったか」といった成果の検証や、「当初の技術的課題や工数の見積もりは、実績と比べてどうだったか、その差異の主な要因はどこにあったのか」を深掘りしたり、チーム間の連携プロセスの改善点を探したりしています。「Biz-PMとの連携において、ビジネス要件を技術仕様に落とし込む過程で曖昧な点はなかったか」「開発チームに対して、技術的な方向性の提案や課題解決のサポートは的確に行えたか、開発のブロッカーを早期に排除できたか」といった観点から、具体的な改善策を話し合います。

ふりかえりで得られた重要な気づきや具体的な改善アクション、あるいは成功事例などは「ナレッジボード」に集約し、オンボーディングの際に参照できるようにしています。

――PMとして独り立ちするまでにどのくらいかかりますか？

加藤：新卒からだと2年から3年くらいですね。1年くらい経つと、プロジェクトが始まって進んでいく仕組みが理解できるようになります。あとは1～2年かけて、様々なトラブルへの対応力を養っていくイメージ。もちろん、ベテランでも対応が難しいケースもありますが。

宇佐美： Tech-PMの場合は、開発知識がベースにあるので飲み込みが早いですね。1年で独り立ちを迎える人もいます。

技術的な課題の特定や開発チームとの連携に苦労する人は多くありません。みんな苦労しているのは、調整スキルの習得です。技術に詳しくない事業部側のメンバーにも、技術的な制約やリスクを分かりやすく説明し、納得感のある合意形成を図れるようになるのに1年くらい、という印象です。

―― Biz-PMとTech-PM、この2つの役割が連携してプロジェクトを進められる流れをつくるうえで、特に重要だったポイントは何でしたか。

加藤： 案件進行フローを「型」として、Biz-PMとTech-PM、そして案件の関係者全員で意識を統一することだと思っています。

先述の案件進行フローで全体の流れを可視化したうえで、「どういう状態になれば次のフローに進めるのか」を、具体的なチェックポイントとして定めています。例えば、『要求定義』の完了条件として『案件の目標、ターゲットユーザー、現時点での技術的実現性や懸念点が明確であり、関係者間で合意できていること』、『要件定義』では『具体的な機能要件・非機能要件やスコープ範囲などを含めた実装方針、今後の概算のスケジュールなど、Biz-PM、Tech-PM、開発チームの間で合意が取れていること』というように。この型はPMだけでなく、関係するステークホルダーとも対話しながら半年近くかけて作り上げていきました。

骨の折れる作業ではありましたが、この型があるからこそ、案件の現状とネクストアクションをPMが整理しやすくなったし、関係者同士での認識の齟齬が起こりづらくなりました。

――こうしたPM体制をゼロからつくりあげるのは、組織体制や進め方が変わることとなり、影響範囲も広く、簡単なことではないと思います。実現のカギとなったのは、どんな要素でしたか。

加藤：これを言っては元も子もないかもしれませんが、やっぱり「信頼関係」だと思います。

PM組織を立ち上げた当時も、既存の部署がそれぞれ活動し、多くの案件が同時進行していました。そんな状況で「新しい組織を作って、今までと違うやり方で進めます」と言っても、周囲からの信頼を地道に集めていけなかったら、受け入れてもらえなかったでしょう。

今では「PMって必要だよね」という認識が社内に浸透していますが、体制変更に動き出した時からずっと、「この体制にしたいから、よろしくね」ではなく、「今のままだと皆がきついから何とかしたいんです、一緒に考えましょう」という姿勢で協力をお願いしてきました。PM一人でできることは限られていますし、状況によっては何もできませんから。

宇佐美：そうですね。たとえ信頼関係が崩壊しかかっているような状況であっても、まずは自分一人からでも、目の前の人に敬意を持って接することで、少しずつ変わっていくんじゃないかなと思います。

自分が厳しい状況に置かれている時は、大抵プロジェクトに関わる関係者もみんなそう感じているんだと思います。例えば「開発が遅い」などと責められてしまうと、「開発側への理解が乏しい」とか、「事業部側が無理な要求をする」など、相手に原因を見出したくなるときもあるでしょう。でもそうして不満を溜め込んでいても根本的な解決にはならない。プロジェクトで何を実現したいのかというゴールにフォーカスすると、相手への働きかけ方を変えていけるのかなと思います。

加藤：それから、当社の「ZOZOらしさ」という価値観の中の「愛」という要素も、大きく影響していると思います。これは仲間やステークホルダー全員、そして運営しているサービスや販売している商品に対して愛着や思いを持つことを指しています。

「相手にリスペクトを持ち、お互いの立場を理解して対話を重ねる」という意識を、PM組織だけでなく会社全体で大切にしていることが、PMとして価値を発揮しやすい土壌につながっているように感じています。

宇佐美：ここでいう愛は、「視野の広さ」とも言い換えられるのかなと。技術観点だけでなく、事業部、ユーザーまでを含めた全体最適で行動しようとすることが、よいプロダクトを作る原動力になると思います。

加藤：次のステップとしては、PM組織がより広い視野を持ち、プロダクト全体の視点も持てるようになっていくことだと考えています。案件を推進するだけでなく、「何をユーザーに届けるべきか」という本質的な問いに向き合えるチームになっていきたいですね。

取材：古屋江美子、光松瞳
執筆：古屋江美子
編集：光松瞳
撮影：赤松洋太