ユーザー企業で働くプロダクトマネージャーの呟き

日本のユーザー企業でプロダクタトマネージャーは活躍できないのか#pmconfjp　という記事を読んで、かれこれ5年ぐらいユーザー企業にいる私が思ったことを書いてみます。

上記の記事には、1文ごとに「わかる！！！」と頷くレベルで共感しています。

一方で、私が今プロダクトマネージャーとして幸せに働いているのも事実なので、ユーザー企業のプロダクトマネージャーとして思うことを共有したいと思いこの記事を書くに至りました。

実際の世界はもっとひどい

さて、冒頭で紹介した記事の下記の部分はWeb系企業の方々からすれば「うわぁ・・・」という感じだと思うのですが、私から見ればむしろ実態より少し美化されているような気がしてならない描写です。

例えば、スーツにネクタイの人たちが黙々と働くオフィスの一画に「アジャイルプロジェクトルーム」を設け、モダンな開発を頑張ることまではできます。

しかし、プロジェクトルームの外には、従来の世界が広がっています。

スーツにネクタイの人たちが働くようなオフィスでアジャイルプロジェクトルームを設けられるなんて、それだけで奇跡です。実際は、そんな人達に囲まれながら生活をしています。常に周囲の光景から突きつけられる現実。プロジェクトルームの外ではなく、まさに視界の中に常にある日常。

しかし、スーツにネクタイなスタイルの企業だから起こる問題なのかというと、そうではないのです。

オシャレな服を着てMacを持った顔面偏差値の高い若者たちがオフィスを闊歩している、そんなユーザー企業もあります。内製エンジニアを持つユーザー企業もあります。

そんな環境であっても、プロダクトマネージャーとして働くことの難しさは同様にあるのです。旧態依然とした体質かどうか、保守的な社風かどうか、開発を外注しているか内製しているか、ITに投資しているかどうか、そういうものとは時に無関係に、ユーザー企業が持つ特性が原因でプロダクトマネージャーが生きづらさを感じる瞬間があります。

ユーザー企業が持つ特性については元記事に紹介されていますが、この記事でも一番下のあたりに怨念を込めていくつか紹介しています。

責任が権限を増やす

じゃあ何で私は今プロダクトマネージャーとしての日々を楽しんでいるのか、という話ですが、それは権限によるところが大きいです。私は現在担当しているプロダクトに関して、ユーザー企業としては通常ありえないような大きな権限をもらっています。

と、風呂敷を広げてみましたが、通常のプロダクトマネージャーであれば当然のプロダクトバックログ＆プロダクトロードマップ、あとは関係する各部署のメンバーを含めたプロジェクト全体をリードする権限です（これを自慢したくなる時点でユーザー企業の辛さがおわかりいただけるかと）。

もちろん偉い人をはじめいろいろなところからいろいろな要望が来ますし、店舗にまつわる諸手続きや法規制に影響を受けたりと、思うようなロードマップの形が描けないことはあります。

ですが基本的には何をどの順番でというのは私が決めて、必要に応じて偉い人の承認をもらう形になっています。

ここまでできる理由は単純で、私はこのプロダクトに関して、売上などのビジネスに直結するKPIに責任を持っているからです。

「私はこれらのKPIに責任を持ちます。だから、そのKPIを最大化できるようにロードマップを策定します。」

こう宣言して、そうなりました。

それを受け入れてくれた偉い人達には感謝しかありません。

ユーザー企業が抱える問題

プロダクトそのものが利益の源泉となるようなWeb企業のプロダクトマネージャーからしたら驚きだと思いますが、ユーザー企業のITはそもそもビジネスKPIを持ちたがらない人が多いです。

彼らが持ちたがるKPIはシステムのダウンタイムやインシデント数だったり、場合によっては「リリースすること」そのものにしか責任を負わなかったり。

持ちたがらない理由もよくわかります。自分の権限でコントロールできないからです。

でも実際ある程度コントロールできるはずの立場の同僚から「そういうのはビジネス部門が責任を持てばいい」と、今週だけでも5回ぐらい言われました。

だから、ユーザー企業で苦しんでいるプロダクトマネージャーの方は、実際に会社の状況が許すかどうかは別として、

プロダクトに関する権限が増えると同時に売上増やコスト減などのビジネス・インパクトのある指標に責任を持つ覚悟があるか

を今一度考えてみてほしいです。もしNoならそもそもプロダクトマネージャーじゃないんだと思います。（ちなみに上述の同僚も、プロダクトマネージャーではない。）

ためにならないアドバイス

もしYesで、それでも状況がそれを許さないなら。

ためにならないアドバイスかもしれませんが、私が前の会社での楽しい日々・辛い日々を思い出してひとつ言えるのは、もしかして、ビジネス部門に所属したほうがプロダクトマネジメントしやすいんじゃない？です。

私はITとビジネス両方に所属した経験がありますが、どう考えてもやっぱり、KPIへの責任と予算を握っている人が、必要な権限に一番近いところにいる気がします。

もし所属部署を気にしないなら、そして異動ができるなら、ITではなくビジネス部門でプロダクトマネジメントをするという選択肢もあるのではないか、と真面目に思います。そしてあわよくばITにカウンターパートを立て、その人を道連れにするのです。

おまけ

さて、私が言いたかったことはここまでですが、ここからはユーザー企業における怨念のようなものを書き綴りますので興味のある方は引き続きどうぞ。

リアルなヒト・モノ・カネが動く世界

ユーザー企業特有の難しさは、リアルなヒト・モノ・カネが動くケースが多いことだと私は思います。

例えば私が過去に担当したECのプロジェクトでは、ローンチ日の変更を経験しました。そして、変更が確定した時点で私は倉庫会社に謝罪に行きました。

Web系企業もキャンペーン絡みなどで日程にコミットしなければならないケースはもちろんあると思いますが、ユーザー企業におけるITのプロジェクトはときに建物を建設するところから始まるなどリードタイムも投資額も開発以外の要素との相互依存性も桁が違うことが多々あります。

先のECの例で言うと、ローンチ延期により在庫が入らない空の倉庫にも月々の倉庫料はかかるのです。

そしてそれによるスケジュール関連プレッシャーも、やはり桁が違うのです。

予算の出処が複雑

ユーザー企業におけるプロダクト開発は、IT部門が主導しながらもコストはビジネス部門負担であるケース、IT負担だがビジネス部門にチャージされるケースなど、開発部署以外との合意形成が必要なケースがあります。

大体そういうケースにおいては、「俺が金を出してるんだから俺の言うことを聞け」的な展開が待っています。適当に受け流せば大体どうにかなるのですが。

それよりも、金の折り合いをつけるのに時間がかかってバグの修正に着手できない時などは実際にお客様に影響が出るので何ともフラストレーションがたまる展開になります。

社内調整の難易度

過去にWeb（厳密にはWebではなくソフトウェア系ですが）企業にいた経験から、ユーザー企業の難しさのもうひとつの要素は社内調整だと思います。

まず、プロダクト自身が会社の利益の源泉ではなく、あくまで本業をサポートするためのツールに過ぎないという位置づけであるため、そのプロダクトや関連するプロジェクトの運営に社内組織やプロセスが最適化されていないというのがひとつめのハードルです。

永遠に続く承認プロセス、サイロ化した組織、本業優先の人員配置、などなど。

例えばアプリを出してもマーケティングの人がダウンロード促進のための適切なデジタルマーケティング施策を持っていない。
なぜなら、本業に効くのはマスマーケティングであり、結果としてマーケティング部はマスマーケティングに強い人で固められているからです。

ふたつめのハードルは、会社全体のITリテラシーがWeb企業と比較して全体的に低い傾向にある点です。

ここは具体的な話をし始めるとそれだけで記事が10本ぐらい書ける気がします。ひとつだけ例を挙げると、コミュニケーションツールは基本的に電話なのでログが残らず言った言わないでもめる・・・

付け足すと、小売や飲食など実店舗を抱える企業においては、「今日入ったバイトの子ができるオペレーションなのか」という点が重要だったりします。
お客様に直接見られないような画面でもかなり注意を払う必要があるという意味で、プロダクトマネジメント観点で非常におもしろい制約で、私はこれを楽しんでいます。ですが、コストやスケジュールへのインパクトがあるケースもあり、たまに私の笑顔がひきつります。