プロジェクトマネージャーからプロダクトマネジャーになって、不確実性を捉え直してみる
この記事は"プロダクトマネージャー Advent Calendar 2021"の14日目の記事です。
はじめに
こんにちは、株式会社ツクルバのカウカモプラットフォーム事業部にてプロダクトマネージャーとして働いているonok（小野慶子）と申します。
私はエンジニアやプロダクトマネージャーの経験を経て、プロダクトマネージャーという役割になりました。
プロジェクトマネージャーの仕事も面白かったですが、プロダクトマネージャーとして働いてみると、それ以上に魅力的な仕事だと感じています。
その理由のひとつとして、不確実性に真正面から対処できることにあると感じています。
この記事では、私がプロダクトマネージャーという役割の魅力の一つとして感じている”プロダクトマネージャーが対面する不確実性”について、プロジェクトマネージャーとの比較を起点に考えをまとめてみたいと思います。
プロジェクトマネージャーにとっての不確実性
そもそもプロジェクトマネージャーは、かなり不確実性と戦うことが必要な役割だと思います。要求が途中で変わる。見積りどおり進行しない。期待する品質が得られないなど、プロジェクトが当初計画通りに進行しないことは往々に発生します。私のイメージとしては、プロジェクトマネジメントは、暴れ馬🐴に乗って目的地を目指すイメージです。
プロジェクトとは、不安定であることを前提とすべきで、状況を適切に監視し継続的な対処が必要になると考えています。
プロジェクトマネジメントの目的地とは
プロジェクトマネジメントが目指す目的地は、プロジェクトの成功です。そして、プロジェクトの成功とは、与えられた目的や体制、リソースを元にいかに当初のQCDを順守できたかであり、最終的にリリースしたものが顧客に価値を提供できたのかは、成功の基準にはなりません。
その結果、
苦労してなんとかリリースした。
発注側にも喜んでもらえたが、本質的に喜ばれるシステムを作れたのだろうか？
そんな思いがありました。
プロダクトマネジメントが軸足とするもの
プロジェクトマネジメントは与えられた目的や体制、リソースを元にQCDを中心とした進行リスクを排除することに軸足があると定義しました。
一方、プロダクトマネジメントは、価値の創出に軸足があると感じています。
もし、プロダクトマネジメントの概念なしに、個々のプロジェクトを遂行するだけだとどうなるでしょうか。極端にいうとQCD順守だけが成功基準でプロジェクトそれぞれ実行され、継続的に顧客に価値を提供できているのかどうかは担保されない事態が発生しそうです。
一方、プロダクトいう概念が持ち込まれると、プロダクトで一貫した価値創出に挑むことができそうです。
「できそう」というのは、プロダクトで捉えたからといって、うまくいくわけではないからです。単純に自分たちの頭の中で考えた通りにやって、当たることは稀だと思います。理由としては、様々な不確実性が発生し、見立ての通りに進まないからと考えます。
そう考えると、プロダクトマネジメント上の不確実性とは目的達成に向けて見通しが悪くなることと定義できそうです。
プロダクトマネージャーにとっての不確実性
プロダクトマネジメントの”不確実性とは目的達成に向けて見通しが悪くなること”と定義しましたが、不確実なことは様々あり、対処の仕方も異なるため、まずは不確実性を「価値的」「事業的」「時間軸的」「外部環境的」として以下のように分類してみました。
それぞれの分類の不確実性とそれに対処するにはどのような考え方やアプローチがあるでしょうか。
価値的な不確実性は、試行錯誤しながら確実にしていく
プロダクトマネジメントの軸足となる価値に関する不確実性は、はじめに直面する不確実性であり、当然ながらプロダクトでもっとも重要な不確実性になります。
価値的な不確実性
プロダクトが提供すべき価値がわからない
そもそもターゲットとすべき顧客がわからない
その顧客の本当の課題であるかわからない
そして、考え出した解決策で解決できるかわからない
さらに、どれを優先すればいいか。何をやって何をやらないべきかわからない
ゼロから始めるときは、「わからない」という無知な状態からスタートし、プロダクトのコアとするビジョンやWhy、What、優先順位を考えていく必要があります。課題の発見や仮説検証など試行錯誤しながら見つけ出すしかありません。
パッと思いついたアイデアでいきなりプロダクトを作ることはせず、自分たちは無知であることを前提にもつことが重要そうです。
この不確実性への対峙は、プロジェクトマネジメントではできなかった、プロダクトの根本的な価値を追求するところになり、プロダクトマネジメントでめちゃくちゃ面白いところだと感じています。
事業的な不確実性は、積極的に取り払う
プロダクトだけを対象にせず、事業的な不確実性も考慮する必要があると感じています。
事業的な不確実性
事業・戦略の方向性と同期がとれているか？
どれにどのぐらいの割合でリソースを割り当てるべきかが事業目線であっているか？
このレベルの不確実性になると、経営層や事業オーナーなど事業戦略を担当する役割の人と積極的にコンタクトを取り、プロダクトの方向性と事業の同期を取る必要があります。正直、組織で上位レイヤーでしょうから勇気がいりますよね。
毎日のようにこの不確実性を気にする必要はないと思いますが、定期的に意識して情報収集含めアプローチしたいところです。
時間軸的な不確実性は、継続的に対処する
時間の経過とともに訪れる不確実性もあります。
時間軸的な不確実性
技術負債が溜まり生産性が悪化する
色々作っているうちにサービス運営も歪みが出てくる
プロダクトのブランド観が損なわれている
そして、いつしか価値提供の再現性がなくなる
徐々に到来するため、油断するといつの間にかプロダクトの死を招く危険な不確実性です。見て見ぬふりをせずに注意を払って対峙する必要があります。
技術負債を例にすると、私自身、エンジニアやプロジェクトマネージャー時代は、技術負債への対処が甘かったと反省しています。リファクタリング（ソフトウェアの挙動を変えることなく、その内部構造を整理すること）の必要性はわかっていたものの、いざプロジェクト単体となると、予算は限られるため、プロジェクト上は後回しというより対応しないという選択肢を取っていたこともありました。
技術負債のようにコストがかかるものは、経営層から見ると、なぜ起きるのか理解しづらいところであるので経営層に理解してもらうような働きかけも重要そうです。
ブランド観に対してはKPIばかりを追いつつづけた結果、損なわれることがないようプロダクトマネージャーがプロダクトへの愛と責任を持って守り通す強い意志が必要そうです。
いずれも時間の経過とともに放っておくと劣化することを肝に銘じ、見て見ぬ振りせず真っ正面から対処していきたい不確実性です。
外部環境的な不確実性は、リスク管理する
内部的な不確実性だけではなく、外部環境的にもこれまでの常識がひっくり返されるような予測できないことが発生します。
外部環境的な不確実性
市場が非連続的に変化する。
技術の進化が著しく速い。技術同士が融合し新たな価値が生み出される。
業界の外から新たな競合が出現する。
社会通念が変わる。
大災害や伝染病が発生する。
新たなセキュリティ脅威が発生する。
外部環境の変化は止めようもないです。できることは、プロダクトへの影響がありうるリスクを特定し対策を落ち着いて考えておくこと。情報感度を上げ、リスクを検知したときに、どう行動するかチームで認識合わせしておくことだと思います。
Hotなところだと、先週末に発生したLog4j2の脆弱性の件は考えさせられた方は多いのではないでしょうか。いち早く察知して迅速に土日の休日返上で対処したところもあれば、月曜になってようやく動き始めたところ等など、様々だったと思います。こういった事例は、今回関係なくとも自社にも起き得る教訓として、自分ごととして捉えることが重要かと思います。
まとめ
あらためてプロジェクトマネージャーを起点にプロアダクトマネージャーが対峙する不確実性を比較すると、向き合う不確実性の幅にはこんな違いがありそうです。
この幅の違いがあるからこそ、プロジェクトマネージャーの時に感じていた
苦労してなんとかリリースした。
発注側にも喜んでもらえたが、本質的に喜ばれるシステムを作れたのだろうか？
このジレンマが解消されました。もし、同じように感じている人がいれば、プロダクトマネージャーはすすめたい魅力的なお仕事です。
最後に
ここまで読んでいただき、ありがとうございました！
プロダクトマネージャーアドベントカレンダーへ初の挑戦で緊張しましたが、みなさまの記事を拝見し、働く会社が違えどもプロダクトマネージメントを愛する仲間がいるように勝手に感じ勇気づけられました。皆さんの記事を参考に私も勉強したいと思います。
なお、弊社株式会社ツクルバでは、不動産Techカンパニー化に向けて多くのデジタル人材の募集を行っています。我こそは！という方がもしいらっしゃれば、ぜひ採用サイトを覗いてみてください！
この記事が気に入ったらサポートをしてみませんか？