入社エントリ
2021年11月にROUTE06に入社し、1年たったため、振り返りも含め入社エントリを書こうと思います。
入社のきっかけ
ROUTE06に入社した理由は、こちらのnoteにも書かれているとおり、プロダクトマネージャーとして成長するための機会が多そうだったからですが、ROUTE06を知るきっかけは代表の遠藤さんが書かれた「システムインテグレーション」の世界に夜明けをでした。
好きな話に「世界は落下している」というものがあります。
「まあ、色々あると思うんだけどさ、最近気づいたことがあるんだよ」
「なんですか？」
「世界は、落下してるんだ」
「？？」
「本来あるべき方向に向かって、世界は凄い勢いで落下してるんだ」
「はあ」
「色んな既得権益持った人たちが抵抗勢力になって邪魔するんだけど、それは重力に逆らうようなもので、あんまり意味ないんだよ だって世界が落っこちていくスピードの方が圧倒的に早いから」
「なるほど」
「だからさ、その落下する方向を俺たちは見定めて先に落下してくべきなんだよ」
「ほう」
「だってどうせ落下してくんだからさ 先に向かった方が絶対いいんだよ」
「なるほどなるほど」
「俺たちがやらなくたって誰かがやるぜ？だって、そもそも落下してるんだから」
世界はどっちに落下しているのか？
遠藤さんのnoteを読んだときに、「こっちに落下していくな…」と思ったのを覚えていますし、入社した今、落下しているのを感じています。
ROUTE06の事業領域
そもそもROUTE06がどんなことしているかというと、お客さまのデジタルプラットフォーム事業の立ち上げを支援しています。
何をしてきたか
複数領域でサービス設計〜リリースと怒涛の1年でした。お客様の新規サービス立ち上げに向き合う１年間でした。
サービス設計
シンプルに誰に何の価値をどう届けるのかをお客様と一緒に突き詰めて考えていきます。お客様はその領域のプロなので、自分は「何が課題なのか？」「そのサービスを使う理由は何か？」「どの数字にヒットするのか？」をフラットに整理しつつディスカッションしてサービスのコアについて明らかにしていきます。
設計においては、ユーザーの行動動線等をmiroなどで図で書いて論点を整理し、明らかにすべきポイントを決めて行動していくというケースが多かったです。
お客様と対等に会話するために、短期間でその領域にディープダイブして自分なりの仮説を立てていくのはタフな作業ですが、個人的には未知の領域のビジネスを深く知っていくという行為が単純に面白く、好きなステップです。
また異なる領域でも抽象化して捉えると共通項が発見できるケースも多く、知らずとも自分の中に知識としての積み上がりを感じられました。
業務フロー整理
ユーザーヒアリングを通じて、現状の業務フローを整理していきます。フローには様々な分岐が発生しますが、その例外パターンも含めて細かく可視化していくことが大事なポイントだと学びました。
コミュニケーションのパターン（電話、メール、FAX）やタイミング等もステークホルダーの皆さんと一緒に認識を合わせていきます。この業務フロー整理作業はプロダクト設計の拠り所になるだけでなく、関係者との認識ギャップを埋める作業にもなるので自然と一緒の方向を向いて議論できるステップだと思っています。
miro等のツールを使って業務フローの整理を進めていますが、大量の情報を整理して可視化していく力が求められるので、情報の構造化スキルは手を動かした分ついたと感じています。
サービスブループリント作成
現状フローを整理した後は、プロダクトが介在することによってそれぞれのフローがどのように変化するのかを可視化します。システムと人とのタッチポイントを明確にし、フローが問題なく回るのか、またどのような課題を解消しようとしているのか、を整理していきます。
ここでは色々な要求が発散しがちになるため、「本質的な課題はなにか？」を問う力が求められます。
絵に書いた餅にせず、リアルなオペレーションに落とし込んでイメージできるかどうかを突き詰めるステップのため、デザイナーと連携しながらワイヤーフレームやデザインモックをベースに具体的な運用イメージの認識を合わせていきます。
ただ、Podcastで話しましたが、現状デザイナーに頼りまくっているのでデザインへの落とし込み部分は試行錯誤しつつ踏み込んでやっていきたいと思っています。（求、Figma力）
PRD作成
背景、スコープ、ユースケース、機能要求、UX要求についてはこれまでPdMとして整理する機会が多かったのですが、新規プロダクト開発のため、非機能要件についても当然考える必要があります。
非機能要件やセキュリティ要件の考え方、方針についての議論をエンジニアと密にしながら決定していく経験は非常に学びがありました。特にアーキテクチャへの理解が以前より深まった気がしています。（と同時に果てしないなとも思いました…）
アーキテクチャには正解も不正解もない。あるのはトレードオフだけだ。
要件定義（仕様書作成）
機能要求から要件として整理してドキュメントを作成します。作業の中で、抜け落ちていた考慮事項等が様々出てくるので、お客様と一緒に議論して詰めていきます。仕様書として整理していく際には文字数制限やバリデーションの条件等含め定義します。（仕様書メンテナンス方法、みなさんどうしていますか…）
この要件定義の中の作業として学びが多かったのはエンジニアとドメインモデルをベースとした認識合わせの実施です。ドメイン知識がPdMに集中してエンジニアとの認識齟齬が起きやすくなる中で、モデルとして可視化することで認識ギャップを埋めるのに役立ちました。
まだまだモデリング力が足りないので、ここは今後も手を動かして鍛えていきたいです。
要件定義作業は、特にお客さまと一緒にプロダクトを作っていく過程においては頻繁に更新されることを前提として進めていく必要があり、変更に強いドキュメンテーションが必要になります。
ステークホルダー全員が認識しやすい、かつ、変更に強い要件定義方法としてRDRAに注目しており、この辺り同じ課題感を持っており興味ある方、ぜひ色々お話したいです。
開発、そしてリリースまでの諸々
開発におけるチケットの管理はGitHubで行なっているため、必要なIssuesの作成を行います。ただ、ROUTE06の場合、PdMの他にPOMというロールが存在しており、リリースまでの段取りや対応が必要なIssuesの洗い出し等はPOMと一緒に行っていきます。
実装のIssuesについてもテックリードやエンジニアリングマネージャーがIssuesを起票してアサインをしていくため、PdMがメインでみる粒度としてはEpicとしてまとめられたマイルストーンをみることが多いです。
それぞれの機能開発の順番やその進捗等はエンジニアを連携しつつ、依存するタスクについての対応方針などを決めていきます。実装していく中でやはり考慮漏れが発生したり、より良い方針等が見つかったりするため、都度方針を決めて仕様書に反映していきます。
大きめの論点が発生した場合は論点整理をした上で、エンジニア、デザイナーと議論して方針を決めます。そして、大枠整理した状態にてお客様とコミュニケーションを取りつつ方針の合意形成をしていきます。
システムを開発し、リリースするというプロセスには本当にいろんな要素が詰まっており、この経験を経るだけでも強くなれた気がします…（毎回色んなアンチパターンを踏んでしまうのですが…）。
その他
開発、という領域以外においても色々やって学びが多かったな〜というものは以下のようなものです
契約書作成、締結
関連する法律調査
関連するサービスの規定調査
地味PMっぽい作業が与える影響はとても大きく、法令等のリスク管理とその対応方針について整理する重要性を感じる場面も多かったです。
プロダクトには正解がありません。終わりもありません。派手な仕事も、地味な仕事もありません。究極、ひとりひとりが「本当にすべきこと」を「やりやすい」環境作りをしていければ、どんどんプロダクトはよくなっていくだろう、そう信じています。
期待どおりの１年間だったか
PdMとしてより成長したいとROUTE06の門を叩きましたが、1年前の自分と比べ、PdM基礎力は上がったように感じます。やはり、エンジニア/デザイナーとの密なやりとり、大小さまざまな意思決定経験は強くなるための栄養剤だなと思います。
また、ROUTE06には複数名PdMがいて毎週PdM勉強会が開催されるので、PdMとしての悩みなどはみんなで考えられる場もあるのが助かっています。
ただ、まだまだ課題も多く、引き続きエンジニアリングへの理解や、データ分析スキルなどは伸ばさないとな〜と思っています。（会社のプログラミング研修への補助や、社内勉強会などうまく活用したいところ）
ユーザーや事業知識だけでなく、リアルなOpsとデータ構造に詳しくないと、良き仕様が作れない。あらゆるデジタルプロダクトがより複雑化していく世の中では特に。
次の1年は周りにTAKEよりGIVEを多くできるように、とは言いつつうまく周りを頼りつつ歩を進めていきたいです。
この記事が気に入ったらサポートをしてみませんか？