😵

しくじりPM 俺みたいになるな!!~やり直したい5つのこと~

hrgc

2024/05/07に公開

プロジェクトマネジメント

ふりかえり

idea

はじめに

はじめまして！レバテックでWebマーケティングをしている堀口です！
普段はレバテックキャリア^[1]におけるオウンドメディアの改善やシステムリニューアルPJのPM（プロジェクトマネージャー）に携わっています。

2023年度、レバテックキャリアは会員登録およびユーザーのスキル情報を回収する機能のUI・システムを大幅にリニューアルしました。このブログでは、私がこのプロジェクトのPMを担当する中で経験した数多くのしくじりの中から特に反省している5つのしくじりを厳選して紹介します。

自身への戒めと学びのため、また下記のような方に向けて少しでも参考になればと思い、恥をさらしていきます！笑

これからはじめてPMを担当する方
現在PMをする中でプロジェクトの進め方に悩んでいる方
いずれPMにチャレンジしてみたいと考えている方

TL;DR

しくじり1
- プロジェクトメンバーの責任範囲を明確にしなかったこと
- 体制図をひけていなかったために、多くの問題が発生した
しくじり2
- アウトカム（成果）を明確にせずに機能ベースでの開発を進めたこと
- 機能要望ベースで開発を進めた結果、要求が膨れ上がり不確実性が増した
しくじり3
- 自分でやろうとしすぎて自身がボトルネックになったこと
- 役割と責任を明確にし、協力しあうことが必要だった
しくじり4
- 一部デザイン未確定のまま実装を進めて手戻りが発生したこと
- デッドラインと対応優先度を握れていなかった
しくじり5
- キャッチアップが遅れて意思決定が鈍化したこと
- 早い段階から開発メンバーとのコミュニケーションを増やすことで、問題解決を加速できた

前提：プロジェクトの概要

まず最初に、今回のプロジェクトの概要を簡単に説明します。かなりはしょってますが、ざっくりこんな感じです。

やったこと
- 会員登録フォーム、スキル情報回収フォームのUI・システムのリニューアル
- 約1年に及ぶ大規模プロジェクトでした
なぜやったのか
- 詳細は差し控えさせていただきますが、ざっくり下記2点です
  - ①様々な職種・スキルのユーザーにとってより使いやすいフォームにするため
  - ②会員登録数やスキル情報入力ユーザー数をより増やすため

プロジェクトを最初からやり直すなら？

しくじったことをただ並べてもあまり意味がないので、最初からやり直すなら？という観点でしくじったこと（≒改善したいこと）に触れていきます。

1.体制図をひいてプロジェクトメンバーの責任範囲を明確にする

最初からやり直すなら、まず最初にPJにおける体制図と責任範囲を必ず明確にすると思います（一発目から当たり前のことでお恥ずかしい限りです...）。
一応、PJメンバーと役割が記載された図はあったものの、いわゆるPJにおける体制図と呼べるものではありませんでした。これができていなかったが故にPJが佳境に差し掛かるにつれて下記のような様々な問題が多発しました。

影響する機能や業務の洗い出しに漏れがあり、手戻りや追加タスクが発生
またそれらのタスクの期日間近での発覚によるスケジュールの遅延やメンバーの負荷増大
本来の担当者以外にも問い合わせや質問が飛び、余計なコミュニケーションが発生

本PJにおける影響範囲は関連システム、データマネジメント、現場オペレーションなどかなり幅広いため、それぞれの領域ごとに明確に役割を定義し、責任者を立ててタスクと責任を渡していくべきでした。
※もちろん大部分は各領域の担当者が責任をもって対応してくれていましたが、誰が何を・どこまで責任を持つのかが明確にしきれていない部分があり上記問題が多発していました

2.アウトカムを明確にしてロードマップを引く

これが今回最大のしくじりポイントかもしれません...
最低限どんな成果が必要なのか（＝PJの目的）を定義し、まずはその達成に向けて必要なことを最小単位で進めていくことを合意形成できていませんでした。そのため、下記の問題が起こりました。

機能ベースでの要求が膨れ上がり、PJの規模がどんどん大きくなった
これにより、単純に開発工数が増えたことはもちろん、PJにおける不確実性（デリバリー・成果の双方）が増した
- 事業目標から逆算したリリース期日のデッドラインは決まっていたため、かなりヒリヒリした時期もありましたｗ

今回開発した機能が必要なかったと言いたいわけではありません。ただ、最も重要で優先度の高い成果を明確にできていれば、まずは必要な機能に絞ってより効率的に開発を進めることができたのではないかと反省しています。

3.自分でやろうとしすぎない

前提、PMは落ちてるボールはすべて拾うべきですし、PJにおける問題に向き合い解決するべきです。そのうえで、自分で手を動かしすぎるのも良くないと思いました。
1.体制図の話とも繋がりますが、役割と責任を明確にしたらあとは基本的にはその領域の責任者に任せて、PMはマネジメントに徹する方針で進めるべきだったと思います。

もちろん、一緒に解決すべき問題があれば入り込みますし、リソースを投下することで問題が解決されるなら状況に応じてPMも対応するべき（またはリソースを調達するべき）です。

ただ今回は、本来別の担当者に任せても良いことまで自身で対応しようとしてしまい、タスク過多でPJのスピードが落ちることが多々ありました。

4.デザイン確定のデッドラインと対応優先度を握る

デザインの確定までに長い時間を要してしまい、デザインが確定していない中で実装を進めることがありました。その結果、後から実装の修正が発生し、工数が大きくなってしまいました。
原因は大きく下記3点だと考えています。

①後工程のスケジュールから逆算したうえで、デザインを確定したい日時を関係者間で明確に握れていなかった
②小出しにせずに大量のデザインの確認依頼を行っていた
③デザインの要求について、事前にプロジェクトオーナーと詳細にすり合わできていなかった

じゃあどうするべきだったかというと...

①について

「このスケジュールでこの部分の実装を行うので、●日までにデザインを確定する必要がある」といったように、PJ全体のスケジュールと各デザインのスケジュールを握っておくべきでした。

一応の期限を設けて確認依頼をしていましたが、今回は繰り返し修正が発生したためデザイン確定までに想定以上の時間がかかってしまいました。

②について

今回改修したスキル情報回収フォームは、ユーザーが選択した職種によってフォームの種類が10通り以上に分岐するため、デザインすべき画面数が非常に多く確認そのものに時間が必要でした。
また、初稿の後に大幅なデザイン修正が入ったため、デザイナーの修正工数も大きくなってしまいました。

まずいくつかの画面のデザインを頭出ししてすりあわせができていれば、早い段階で軌道修正できていたと思います。

③について

デザインイメージの詳細な共有・すりあわせができていれば、大幅な軌道修正も必要なかった（あるいは最小で済んでいた）と思います。
またこのすりあわせの際は、口頭やテキストだけではなく、必ずアウトプットべースで視覚的にすりあわせをすべきです。

5.開発メンバーとのコミュニケーション頻度を増やす

私がこのPJに参画したころ、システム開発や対象プロダクトに関するドメイン知識が浅く、本当に何もわからない状態でした（よく任せてもらえたなと思います笑）

とはいえ、そんなことはお構いなしに開発メンバーから日々質問をもらったり、仕様に関して判断を求められたりするわけですｗ
ですが、当時の私は何もわからないので、人に聞いたり相談したりしているうちにレスポンスや意思決定が遅くなってしまうことが日常茶飯事でした（本当にすみませんでした）

時間の経過とともにキャッチアップが進んだ部分もありますが、開発メンバーとのコミュニケーション頻度を上げることでこの問題の解決を加速できたと思います。具体的には、開発メンバーと毎日朝会をするようになってから仕様理解のスピードと意思決定スピードがかなり向上しました。

開発メンバーは進行中のタスクの仕様で気になっていることをその場で私に質問できますし、私もわからないことがあればその場で質問して理解を深めていました。自身で資料を読み込んだり勉強してキャッチアップすることも重要ですが、毎日少しでも開発メンバーとコミュニケーションを取ることで、よりキャッチアップが加速できると思います。

さいごに

改めて振り返ると情けないしくじりばかりですが、その分学びも多かったな～と思います。引き続き担当しているPJもこれから担当するPJもあるので、今後は「これは最初からPJをやり直した場合の世界線」という気持ちで取り組んでいきたいと思います。

ここまで読んでいただきありがとうございました！

脚注

レバテックキャリアは、ITエンジニア・デザイナー向けの転職エージェントサービスです ↩︎

レバテック開発部

レバテック開発部の公式テックブログです！