もくもくプロダクトマネジメント( @Nunerm )

プロダクトマネジメント・エンジニアリングマネジメントなどについて黙々と

プロダクトマネジメントに活きるウォーターフォールプロジェクトマネジメントの経験

こちらはプロダクトマネージャー Advent Calendar 2021 の21日目の記事です。

なんと10ヶ月ぶりのブログ投稿となってしまいました…!

f:id:swnws322:20211218162207p:plain

久津(ひさつ)と申します。現在はGLOBISで法人向けプロダクトのPMをやっており、これまでのキャリアでエンジニア→プロジェクトマネージャー→プロダクトマネージャーという順で経験を積んできております。


この記事では、プロダクトマネジメントに活きるウォーターフォールプロジェクトマネジメントの経験について書きます。現在プロジェクトマネージャーで今後プロダクトマネージャーへのジョブチェンジを考えられている方、既にプロダクトマネージャーだがプロジェクト推進で悩まれている方の参考になればいいなと思っております。

 

 

プロダクトマネジメントとプロジェクトマネジメントの違い

これについては説明されている記事や書籍が腐るほどあるので割愛します。こちらの記事が最もわかりやすいかなと思います。

aboutproduct.jp

 

ネット記事やブログでは「プロジェクトマネジメント≠プロダクトマネジメントという説明が多いですが、「プロジェクトマネジメントプロダクトマネジメントつまりプロダクトマネジメントに必要な要素にプロジェクトマネジメントがあるという解釈が個人的には好きです。

プロダクトマネジメントトライアングルやエンジャパン岡田さんが作られた「PM SkillChart HEX」でも、プロジェクトマネジメントはいち領域として定義されています。

画像1

ゴリゴリのウォーターフォールのプロジェクトマネジメント時代

私はリクルートテクノロジーズのプロジェクト推進部という部署で4年ほどプロジェクトマネジメントを担っていました。リクルートといえばデジタルプロダクト開発の最先端でアジャイル開発をしているだろうみたいなイメージをお持ちかもしれませんが、当時はウォーターフォール開発がかなり多く、かつ事業規模が大きいためプロジェクト自体も大規模なものになりやすい環境でした。

プロジェクト推進部は、プロジェクトマネジメントに対して本気で向き合っていた部署で、以下のような取り組みをしていました。

 

  • PMBOKなどのナレッジをベースに独自にオリジナルスキームを作る(大規模プロジェクトガイドと呼ばれていた)
  • プロジェクトの変数(人数/予算/期間/言語/業界など)やその結果を全てデータ化し、成功・失敗要因を科学する
  • 独立したPMO組織を作り、プロジェクトマネージャーが気づかない潜在リスクを検知するために、プロジェクトの状況を客観的に評価をする仕組みを作る(リスクが見つかった場合は合理的な回避・軽減策を提示しないと次に進めなかった)

 

ただ漫然とタスク管理をしてWBSを引いて定例会議を開いてたわけではありません。プロジェクトマネジメントに真摯に向き合い、数々の大規模プロジェクトを推進して成功に導いてきました(もちろん失敗もありました)。

 

アジャイルウォーターフォール論争

最近「世界の不確実性が増してきたから、計画主義のウォーターフォールでは対応できない」「だからまず小さくリリースしてフィードバックを得ながら進む経験主義のアジャイル開発をすべきだ」という言われ方を多く見かけますが、私はそんなに極端に分けるのではなく「状況に応じてうまくハイブリッドするべきだ」と思っています。

もちろんシステムや組織の依存関係の少ないシンプルなプロダクトであれば、大掛かりな計画などせずに早く前に進めた方がいいとは思いますが、ある程度依存関係や複雑性を持っているのであれば、事前に必要最低限の計画を立てた上でしっかりプロジェクトマネジメントをしないと、プロダクト開発が前に進まないこともあると思っています。たまに見かけるのが、アジャイルに傾倒するがあまり計画が杜撰で、フィードバックサイクルを回して進んでるつもりが同じところをぐるぐる回っているようなプロジェクトです。

「大規模で複雑なプロダクトだが、多くの小さいチームでアジャイルを回せている」という組織ももちろんあります。それは依存関係を軽減させる仕組みやアーキテクチャ、または依存関係をコントロールする役割の人がいることで実現できているのだと思います。

もしまだその仕組みや人が存在せず、依存関係や複雑性と共にプロダクト開発、プロダクトマネジメントに挑んでいるのあれば、個人的にはハイブリッドのプロジェクトマネジメントをお勧めします。チームがアジャイル開発をしていたとしても、ウォーターフォールのプロジェクトマネジメントの勘所を知っておいて損はありません。

 

プロダクトマネジメントに活きていること

少し話が逸れましたが、本題に入ります。私はリクルート内での異動や転職の中でプロダクトマネージャーにキャリアチェンジしましたが、あの頃のゴリゴリのウォーターフォールプロジェクトマネジメント経験は、現在のプロダクトマネジメントの中でも存分に活きています。プロダクトマネジメントの責務とタスクが増えたので、相対的にプロジェクトマネジメントに割くパワーは減り、重厚長大な計画書やWBSを作ったりはしませんが、あの頃に得たスキルや考え方が役立っています。

 

ここからはその中でも特に日々役立ってることを書いていきます。

 

リスク感度が高くなる

ウォーターフォールのプロジェクトマネジメントの場合、最初にプロジェクト計画を行い、その中でリスク定義をします。ここでいうリスクとは、品質やスケジュール、コストや人に関わる問題の発生リスクのことを言います。例えば開発が予定通り進まないリスク、開発途中で要件が変わるリスク、リリース後に大障害が起こるリスクなどです。

このプロジェクトではどのようなリスクが起こりうるか、それが起こったらどのような影響が起こるのかなど、可能な限りリストアップしておきます。また、現時点でリスク評価が難しいものは、どのタイミングになったら改めてリスク評価をするのかを定義しておきます。

 

この考え方が頭にあると、プロダクトマネジメントの中で不意に発生する問題に対して強くなります。何か新しいこと始めるときに、一旦のゴールまでの流れをイメージしてリスクの存在をサーチし、影響の大きいリスクがあれば先に打ち手を決めておく、あるいは早い段階でリスク軽減の打ち手を打っておく癖がつきます。逆にリスク評価の結果、起こってもその場で対処できるし影響が少ないと判断すれば、今後そのリスクは特に気にせずプロダクト開発に集中する意思決定もできます。つまり起こってから慌てて考える場当たり的な対応を減らせます。

もちろん今考えてもわからないことを頑張って考える必要はありません。時間の無駄なので。ただ、少しの労力で調べて考えれば検知できるリスクは、早めに検知しておくに越したことはないという考え方です。

当たり前っちゃ当たり前の話なのですが、意外とリスク評価は難しいし大変なのです。評価のための情報を適切に集めないといけないし、どのような軸で評価すればいいのかもわからないことが多いです。プロダクトやプロジェクトの特性によって評価方法や基準は変わるので唯一の解はなく、自分なりのリスク評価軸を持って育てていくことが求められます。

 

勘違い防止力が上がる

ウォーターフォールのプロジェクトにとって恐ろしいのは「勘違い」です。ステークホルダーの勘違いによって要件が変わったりスケジュールが遅れたりします。アジャイルに比べるとウォーターフォールでは勘違いの発覚が遅れ影響が大きくなってしまうので、いかに勘違いを起こさないか、共通理解を作れるかが勝負となります。

リクルート時代、この勘違いを防ぐ取り組みとして「ビジネスルール」の作成を行なっていました。ビジネスルールとは以下のようなものを定義したリストです。

  • プロダクト、サービスに関わるもの(人/役割/機能/業務など)の名前と意味
  • 機能や業務の範囲・境界(例:「決済機能」は会計システムへのデータ連携処理まで含む範囲)

最近はドキュメントは少ない方がいいと言われている時代です。口頭やテキストなどフロー情報でのコミュニケーションが相対的に増えた中で、言葉の意味や定義をいちいち補足するのは難しくなっています。であれば、最初からズレが起こらないように共通理解を作っておくことが勘違いの防止につながります。

またプロダクトマネージャーは様々な職種や部門のステークホルダーとやり取りをする機会が多いと思います。大きい組織になればなるほど、職種や部門によって言葉の使い方が異なるケースが多く、勘違いが生まれやすい環境になります。

DDDのユビキタス言語など、最初から共通言語を使うようなプロダクト開発手法もありますが、そのような仕組みのないプロダクト開発の現場では、ステークホルダーとのコミュニケーションの中で「あれ?何か人によって解釈が違うな」と感じたら、すぐにズレを解消する動きを取ることをお勧めします。

 

クリティカルパスを見つけやすい

ウォーターフォールのプロジェクトマネジメントのキモはやはりスケジュール管理です。各タスクの依存関係や前後関係を意識しながらWBSと日々睨めっこしてました。

WBSのタスクには遅れてもそこまで問題にならないものと、遅れると全体のスケジュールを遅らせるものがあります。後者が俗にいう「クリティカルパス」です。プロジェクトマネジメントにおいてクリティカルパスの発見と遅延防止は本当に重要な仕事です。クリティカルパスは以下の画像のように表されることが多いですが、実際はこんなにシンプルな図で表せるものではありません。もっと関連タスクが多いし変数も多いし、そもそもタスクの洗い出し自体が難しかったりします。


https://www.jooto.com/contents/critical-path/

 

プロダクトマネージャーになった今は、WBSは作らないしこのようなクリティカルパスの定義も丁寧にしないですが、頭の中で常に「どれがクリティカルパスになりうるか?」は考えています。例えば大きめのリリースをなるべく早く行いたいときに、発生するタスク(社内ステークホルダーへの説明、ヘルプページの更新、メンテナンス準備など)をどのように進めるのが最も確実に早く進められるのかを考えます。思いついた順にやるだけでは、どれかがボトルネックになって待ちが発生してしまいます。

 

 

おわりに

ウォーターフォールのプロジェクトマネジメントを経験されてる方にとっては当たり前の内容かと思いますが、最近はアジャイルネイティブのプロダクトマネージャーも増えてきているかなと思うので、誰かの役に立ったら幸いです。もし役に立ちそう、取り組んでみたいと思っていただけたら、プロジェクトマネジメントを学ぶことをお勧めします。

もし内容についてご意見やご質問がありましたら、TwitterでDMいただくかMeetyでお話しできればと思いますので、お気軽にご連絡ください。

 

おすすめの本はこちら

先制型プロジェクト・マネジメント―なぜ、あなたのプロジェクトは失敗するのか | 長尾 清一 |本 | 通販 | Amazon

ザ・ゴール | エリヤフ ゴールドラット, 三本木 亮, 稲垣 公夫 | 英米の小説・文芸 | Kindleストア | Amazon

PMBOK®ガイド第7版日本語版 販売および出荷開始のお知らせ|お知らせ|一般社団法人 PMI日本支部

【スポンサーリンク】