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

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

プロダクトマネージャーのキャッチアップ術 〜構造の絵を描こう〜

f:id:swnws322:20201004201509p:plain

 

はじめに

以前「プロダクトマネージャーの転職活動記」を書きましたが、その続編となります。実際に転職をして3ヶ月ほど経ち、それなりに良いスタートを切れたと思っています。

 

そんな中で、上司や同僚から「キャッチアップが早いね」とか「3ヶ月でよくそこまで把握してますね」とよく言われることに気づきました。あまり自覚はなかったのですが、実は高速キャッチアップが自分の得意技みたいで、それが良いスタートに繋がりました。

 

これが自然と身についた理由は、リクルート時代にプロジェクトマネジメントに特化した組織に属していて、組織やプロダクトが既に存在している状態から立ち上がったプロジェクトに参画するケース、つまり「新しい環境でゼロからキャッチアップをする」機会が人に比べて多かったためだと思います。その後プロダクトマネージャーとしても1回の出向、2回の転職をしているので、単純に場数が多いんですね。

 

というわけで、新しい環境に入って少しでも早くプロダクトマネージャーとして活躍できるようになるための自己流キャッチアップ術をまとめてみます。転職や異動したばかりでなくても、うまくプロダクト開発が進まないと悩んでるPMの方にも参考になるかもしれません。

 

 

キャッチアップすべき3つの構造

少なくとも以下の3つの構造を理解する必要があると思っています。

  1. 組織構造
  2. 事業構造
  3. システム構造

とにかくこの3つを最優先でキャッチアップしましょう。経費精算ルールとか勤怠ルールなんて理解してなくても、誰かに怒られてから覚えればいいのです。

 

ではそれぞれの内容とキャッチアップのコツを書いていきます。ある程度の歴史があって大きめの組織に新たに参画する場合を想定して書いてますが、歴史が浅く少人数の組織の場合はもっとライトにやってもいいと思います。

 

全てのコツの共通点は「構造を自分で絵に描いてみる」です。

f:id:swnws322:20201004201919j:plain

1.組織構造

プロダクトマネージャーと一言で言っても、組織によって求められる役割は少しずつ異なります。恐らく「前職と全く同じ動きをすればOK」というケースはほとんどないでしょう。もし組織の状況や意思決定ルールを何も把握せずに自分の経験則に従って行動してしまうと、無駄にハレーションが起きてスタートダッシュが失敗してしまうかもしれません。

なのでまずは「直近で求められる動き」を把握するべく、組織の構造や仕組みを理解する必要があります。主なポイントは以下のような情報です。

  • どのように役割分担されているのか
  • どのように情報が流れ、どこで意思決定されているのか
  • 意思決定におけるキーマンは誰か
  • 組織における「顕在課題」と「課題候補」の仕分け

 

2つ目と3つ目は物事を円滑に進めるために重要な情報です。必ずしも役職がついている人がキーマンとは限りませんし、アンオフィシャルな場で意思決定されることもあるため、正確な現状を把握する必要があります。

 

4つ目は少し要注意です。顕在課題は組織全体が既に認識しており、目指すべき姿も擦りあってる課題です。これはすぐに解決に向けたアクションをしても問題ありません。

一方でまだ顕在化しておらず、ジョインしたばかりの客観的な視点だからこそ気づける潜在的な課題も見つかるはずです。例えば「マネージャーが意思決定のボトルネックになっているっぽい(誰も指摘しないけど)」とかですね。ここは要注意で、自分の前職の経験に基づいて安易に課題であると決め付けてはいけません。現時点でそうなっている理由が何かあるはずで、もしかしたら止む無しで放置している可能性もあります。そんな中で新参者に「ダメだ!」とか言われたら、シンプルにイラッとしますよね。なので一旦「課題候補」として自分の心の中に留めておき、時間をかけて事象を紐解き、本当にすぐ解決すべき課題なのか見極めなければなりません。

 

これらを整理するためには、組織図を自分で作ってみるのがオススメです。

もちろん既に公式の組織図はあるはずですが、それとは別にオリジナル組織図を作ります。公式の組織図を参考にしながら、人に聞いたり実際に会議に出たりして得た気づきを少しずつ積み上げて完成させていく方法を推奨します。ポイントは、必ずしも実際の人事情報に則る必要もなく、役割ベースで自分なりに整理することです。

 

非常に簡単ではありますが、イメージはこんな感じです。

f:id:swnws322:20201004193917p:plain

もちろん内容はフィクションです。ちなみにこれは自分のローカルに留めておきましょう。「あまり機能してない」とかいうメモを誰かに見られた日には…w

 

2.事業構造

ここではマーケットや競合の情報ではなく、自社の事業がどのように回っているのか、という意味合いで書いています。もちろん前者の情報も重要ですが、「新しい組織の中で早く活躍するために」という文脈なので後者にフォーカスをあてています。

1つ目の組織構造を理解すれば、ある程度は「どのチームが何をしているのか(What)」は把握できると思います。しかし「各チームがそれをどのような手段で行っているのか(How)」、またチーム間のWhatの繋がりまではなかなか見えません。これらを知らずにプロダクトチームのやりたいことだけを主張しても物事はうまく進みません。

 

キャッチアップすべきポイントとしては以下のようなものが挙げられます。

  • 一連のユーザー体験において、どのチーム/システムがどう関わっているのか
  • 一連の業務プロセスにおいて、どのチーム/システムがどう関わっているのか

 

これらの情報をまとめるにはサービスブループリントが有効です。サービスブループリントとは「あるサービス提供のプロセスにおける、ユーザー体験・サービス提供者双方の動きを時系列で表したツール」です。カスタマージャーニーマップと似てますが、サービスブループリントはサービス提供側も含めたプロセスにフォーカスをあてるところが違います。

 

幸いにも弊社には既にサービスブループリントを作る文化があったので、苦労なくキャッチアップできました。昨年のアドベントカレンダー記事に作成プロセスや成果物のサンプルが書かれているので、詳しく知りたい方はご一読ください。

qiita.com

 

加えて、自分で新たにもう一つサービスブループリントを作りました。それは、これから行う大規模な機能改修後の姿を描いたものです。自分がジョインした時点である程度の構想はできていたのですが、具体化まではされていなかったため、頼まれもしないのにすぐに作り出しました。おかげで事業構造の深い理解にも繋がったし、細かい部分の方針のすり合わせにも活用できています。

f:id:swnws322:20201004171204p:plain

既にドキュメントが存在していても、少し軸をずらして似たものを作ってみるアプローチもオススメです。

 

3.システム構造

シンプルなシステム構造のプロダクトの場合は苦労なく理解できると思いますが、複数システムが関わり合うプロダクトの場合は、それなりに気合を入れてキャッチアップする必要があります。

整理すべき情報は主に以下のようなものです。

  • どこに何のデータが管理され、どう連携されているのか
  • サービス・サーバー・DB・データ・ユーザーの関係
  • 各システムの名称(通称)

 

特に重要だと思ってるのは1つ目のデータの構造です。データの制約条件を知らずにプロダクトバックログアイテムを作ると、リファイメントに凄まじく時間がかかってしまいますし、逆にすぐ活用できるデータがあるのに知らないが故に機会を逃すリスクもあります。要は「やりたいことのハードルの高さ/低さ」の感覚を持つために、データ構造の理解が最も重要なのです。

 

また地味ですが、3つ目の「各システムの名称(通称)」も重要です。システム名ってそれがサーバーを表しているのか、DBを表しているのか、はたまた全部含んだ総称なのか、意外と新参者には理解できないことが多いのです。既存メンバーの間では暗黙知になっているため、ミーティングで出てくるシステム名を間違って解釈すると、話の内容がちんぷんかんぷんになってしまいます。

 

これらをまとめて整理するために「システム構成図+簡易ER図」を作ります。

システム構成図はサービス・サーバー・DB・データ・ユーザーの関係性を1枚の絵に表したものです。世の中にいろんなタイプのシステム構成図はありますが、これはリクルート内でよく使われてたフォーマットです。

 

ここで書くべき情報はこのようなものです。

  • サービス・サーバー・DBの名称
  • 各DBに何のデータがあるのか
  • 各DB間で何がどう連携されているのか
  • 各サービスはどのDBを参照しているのか
  • 各サービスは誰が使っているのか

f:id:swnws322:20201004170219p:plain

※内容はもちろん架空のシステムです。

このように、どのサービスがどのDBを参照しているのか、どのAPIを使っているのかなどを記載し各DBには持っているデータの概要を記しています。もちろん完全に網羅しているわけではなく、重要なポイントさえ抑えられていればOKぐらいの気持ちで作ればいいと思います。

 

これと2.組織構造で作成したサービスブループリントを合わせると、全体の解像度がかなり上がってきます。

 

システム構成図だけでも十分理解は進むのですが、より深くデータ周りを理解するためには簡易ER図を作るがオススメです。「簡易」の意味は、正式なER図のうちエンティティとリレーションだけ表した図です。アトリビュートやカーディナリティはめんどくさいし、クエリを作ってる中で自然と覚えてくるので最初は不要だと思います。

f:id:swnws322:20201004164758p:plain

グレーの箱がテーブル(エンティティ)で、青い四角はざっくりグルーピングを意味してます。黄色い付箋は自分で調べてもわからず、チームメンバーへの質問するためのメモです。

自分は元々エンジニアで、一時期DBサーバの運用やチューニングをしていたので、テーブル構造を見ながらER図を作れました。MySQLWorkbenchとか使えばすぐ作れるのですが、それだとあまり頭に入らないので、手作業で作ることをオススメします。

 

これらの作成はエンジニアバックグラウンドを持っていないプロダクトマネージャーにとっては少し厳しいと思いますので、エンジニアに聞きながらせめて「どこに何のデータがあるか」「そのデータはどう連携されてくるのか」だけでも理解しておくべきだと思います。

 

 

終わりに 

以上、キャッチアップするべき情報と、キャッチアップのコツを書いてきました。この3つの構造を理解できれば、既存メンバーとの情報量の差が埋まり、検討や決断をする際の迷いがかなり減り、パフォーマンスがどんどん上がってくるはずです。

共通するのは、自分で情報を取りに行って構造を絵に描いてみることです。まさに「急がば回れ」ですね。このご時世MiroとかFigmaとか超絶便利なツールがあるので使わない手はありません。自分1人で最後まで作りきるのはそれなりに大変なので、ある程度できたらチームメンバーや詳しい人にレビューしてもらいましょう。意外とチームメンバーも知らなかったことに気付ける良い機会になったりします。

また可能な限り、作り終わったものはチーム内の公式ドキュメントへの昇華を目指してみましょう。どうしても自分のためだけに作ると手抜きになっちゃうしモチベーションが持たないのですが、誰かに使ってもらう前提で作ると最後までやり通せます。例えば、中途メンバーへのオンボーディング資料とかに転用するのも一案です。

 

 

誰かの参考になれば幸いです。

【スポンサーリンク】