M&A直後のプロジェクトマネジメントのリアル - MINAGINE勤怠管理
こんにちは、株式会社kubell(旧Chatwork株式会社)プロダクトマネージャーの坂田です。
連載最後の今回はMINAGINE勤怠管理のUIリニューアルのプロジェクト管理についてご紹介したいと思います。
プロダクトマネージャー(PdM)およびプロジェクトマネージャー(PjM)の視点から、どのようにプロジェクトを推進してきたのかをお伝えします。
<本記事の対象>
株式会社kubellグループの株式会社ミナジンについて知りたい方
株式会社ミナジンのプロダクト開発の内情について知りたい方
業務系プロダクトのUIリニューアルについて知りたい方
M&A直後のプロジェクトマネジメントのリアルについて知りたい方
1.これまでのおさらい
いよいよこの連載も最後の記事となりました。「MINAGINE勤怠管理」のUIリニューアルに関するこれまでの投稿を簡単におさらいします。
【UIリニューアル連載第1弾】
社内に十分な予算やメンバーがいない中スタートしたリニューアル構想初期。過去に一度は断念した経験や、仕様の複雑さはリニューアルに踏み切る上で壁となっていました。
【UIリニューアル連載第2弾】
株式会社ミナジンの株式会社kubellへのジョインを機に、徐々にリニューアルを進める体制も整ってきた中で、デザインPlanBへとシフトチェンジ。PC版のデザインを一通り完成させました。
【UIリニューアル連載第3弾】
新たに専任のデザイナーが参画し、色に関するデザイン管理上の問題や余白のルールの甘さなど、デザインルールが足りないことに気づきます。課題を整理し、Figmaの機能の活用方法も吟味しながら、試行錯誤の末にデザインを完了させました。そこで改善されたプロセスやノウハウは以降の開発に大きく役立っています。
最終章の今回は、M&A直後のグループ間合同メンバーで、どのようにプロジェクトを推進し、どのような課題に直面して解決してきたのか、プロジェクト管理の視点でお伝えします。
2.ミナジンのPdMが抱える業務範囲が広すぎるという課題
デザインプラン変更直後の状態
私がこのプロジェクトにPdMとして参加したのは、2023年の7月。UIリニューアル連載第2弾でご紹介したとおり、デザインのプランを変更し2ヶ月ほど経った時期でした。
プランの見直しはkubellとミナジンの経営層と開発部で合意されていましたが、プロジェクトの内部では以下の課題が生じていました。
プラン見直しによるデザイン修正が追加になったことで、デザイン工程が逼迫
全工程をアジャイルで進めていたため、開発チームの手が開かないように、急いでデザインを仕上げていく状態。主要メンバーの中で、プロダクトの知識を持つのはミナジンのPdM兼PjMの松尾さんのみ
一人で画面要件定義/ワイア作成/デザイン進行管理/デザイン成果物確認/画面設計書/開発進行管理と何役も担っていて、タスクが集中していた。
この頃の状況を松尾さんに伺ってみました。
集中するタスクとプロダクト知識を共有するための方法
本来はデザイナーも含めてプロダクト全体の知識をつけて、UIの提案をしたいと思うのですが、充分なドキュメントはありません。仕様書の更新と体系化にリソースを避けないことは、小規模の開発体制でプロダクトを維持してきた組織ではよくある状況だと思います。
そこで下記のプロセスで情報共有とタスク分配の課題を少しずつ緩和しました。
私がデザイナー出身のPdMであることと、仕様理解が浅くてもできることとして、デザイン進行管理とデザイン成果物の確認から担当した
各画面の要件〜仕様の基本を、毎日30分のMTGを通して、松尾さんに教えていただき、デザインが要件を満たしているか判断できるように知識を共有していただいた
デザインの工程に余裕が出てきた時期から徐々に、デザイナーがワイヤーやフローから提案できるよう、画面要件の詳細と主要な仕様を共有した
こうすることで、松尾さんのPdMとしての進行と確認のタスクを徐々に坂田へ、さらにUIの改善提案のタスクをデザイナーのお二人に移行してきました。
斉昭さんと藤森さんがミナジンの専任デザイナーとしてプロダクトを深く理解したことで、それまでPdMに集中していたタスクを巻き取りながら、専門職の知識を活かしてプロダクト全体のデザインルールや保守性も改善することができました。
一番の忙しい時期に、知識共有の時間と準備をして下さった松尾さんに、とても感謝しています。
3.出向者がチームメンバーとして活躍するために
松尾さんは以降もこのプロジェクトにkubellからの出向者を何人か受け入れながら、メインのPdM兼PjMとして推進していきます。
すでに何役も担いながら、M&A直後という複雑な関係性の出向者を受け入れることは、私から見て、とても難易度の高いことに見えました。
改めてこの時の心境を伺ってみました。
当初からミナジンのメンバーはとてもフレンドリーで、kubellのメンバーを快く受け入れてくれる組織文化があります。もともとは小規模な開発体制だったことや、長期にわたってベンダーと開発してきたご経験からか、別組織との関係性構築が上手な方が多いと感じます。
私もすでに出向者という意識は薄く、ミナジンのプロダクトに、より貢献したいと思っています。
合同メンバーを形成するにあたり、組織同士の関係や、プロジェクトに適したケイパビリティとスキルセットにも気をつけなくてはなりませんが、積極的にコミュニケーションをとる姿勢と、意見を早く受け入れて活かそうとする柔軟性が、信頼関係を構築するのだと教えていただきました。
4.デザインルールの実装をすべきか、リリース時期を守るべきか
デザイナーのお二人の貢献により、デザイン管理上の課題が明らかになりました(第3弾参照)が、そのデザインルールをもとにした修正を開発環境に実装することは、リリースの後ろ倒しを意味しました。
ミナジンの開発部メンバーや、ベンダーのメンバーにも再三相談した結果、実装を決断します。その決定打はなんだったのでしょうか?
短期的にはスケジュールの遅延というリスクを伴いましたが、長期的にはプロダクトの品質向上とユーザー満足度の向上に繋がる重要なステップでした。
またこの経験から、後に続くUIリニューアルプロジェクトでは、対象の画面全てにおいて要件定義とデザインを完了させてから、開発とテストはこれまで通りアジャイル工程にすることで、手戻りが少ないプロジェクト管理ができるようになりました。
5.おわりに
今回の記事では、MINAGINE勤怠管理のUIリニューアルプロジェクトにおけるプロジェクト管理の実際と、その中で直面した課題や解決策についてご紹介しました。M&A直後の複雑な状況下で、異なる組織間のメンバーが協力し合い、プロジェクトを成功に導くための努力と工夫をお伝えできたかと思います。
私たち株式会社kubellと株式会社ミナジンのメンバーは、互いの強みを活かしながら、より良いプロダクトを目指して日々取り組んでいます。今回のリニューアルプロジェクトを通じて得た知見や組織同士の関係性は、続くプロジェクトにも大いに役立っています。
最後に、この記事がプロジェクトマネジメントやUIリニューアルに関心のある方々にとって、少しでも参考になれば幸いです。今後も引き続き、魅力的なプロダクトを提供するために努力してまいりますので、どうぞご期待ください。
ご覧いただき、ありがとうございました。
kubellグループでは、一緒に働く仲間を募集しています。少しでも一緒にチャレンジしたいと感じられた方は、ぜひご応募ください。
この記事が気に入ったらサポートをしてみませんか?