こんにちは、delyでクラシルのiOSエンジニア兼PdMをしているtakao（takaoh717）です。
この記事は「dely #1 Advent Calendar 2020」の19日目の記事です。
昨日はデザイナーredさんの「Material DesignでUIデザインをブーストしよう」という記事でした。
はじめに
delyに入社して3年が経過し、僕は今iOSエンジニア兼PdMとしてプロダクトに関わっていますが、今の役割になるまでにこれまでいろいろな立ち回りをしてきました。 最近弊社で開催したPdMに関するイベントで「コードを書くことを主としているエンジニアがどうやってPdMとしての能力を磨くべきか」という質問をいただきましたが、イベント内では具体的な話をあまりできなかったので本記事で僕自身の事例を交えながら紹介したいと思います。 この記事がPdMとしてのキャリアを検討しているエンジニアの方やそういった動きを今後していきたい方の参考になる話ができればと思います。
プロダクトマネジメントのスタートは社内のボール拾いから
プロダクトマネジメントの最初の一歩としては社内で転がっているボール拾いをすることから始めるのが良いかなと思っています。 ボール拾いというのは、誰もディレクションする人がいなかったり宙に浮いてしまっている状態のプロジェクトや課題がある場合にそれらを自分から巻き取りに行くようなことを指しています。
自分からボールを拾って物事を進めることができれば、PdMに必要なスキルが徐々に身につけられると思います。
ボールを拾うためにはプロダクトに関するあらゆる物事を自分ごとに捉える必要がある
普段コードに向かっているとなかなか他のことに目を向けられないなんてことはエンジニアであればよくあることだと思います。 もちろん集中してコードを書かないといけないときはありますし、それはそれでとても良いことだと思います。 しかし、社内でボールを拾っていくためには受け身の状態でいるのではなく主体的に動いていく必要があります。 どこに課題があるか、どこが改善できそうか、なにかおかしいところがないかなど常にアンテナを張って、情報収集を続けることで気付けることがあると思います。 そうしていると、自分が介入することでうまく回る部分を見つけられ、次のアクションに繋げられるようになります。
部署間のステークホルダーを繋ぐハブになる
誰かが舵取りをしたほうが良さそうだけれど、誰も舵取りをしなくてなんとなく現場メンバーでふわっと進めてしまったり、全体を把握できている人がいないことで無駄なコミュニケーションが大量に発生する、なんてことはないでしょうか。 関わっているプロジェクトがもしそういった状況に陥っている場合は率先して舵取りをしていけると良さそうです。
delyでは今でこそスクワッド体制になって各プロジェクトの舵取りをするPdMがいるのであまりそういった問題は起こりにくくなっていますが、PdMをそもそも明確に立てていなかったときやPdM1人体制だった頃などはプロジェクトの振り返りをしたときに責任者不在による問題の発生についてよく話が上がっていました。
PdMになるまで
僕は2017年11月にdelyにiOSエンジニアとして入社し、今も（頻度はかなり減りましたが）iOSのコードを書いていますが、どちらかというとPdMとしての役割をメインで担っています。明確にPdMという役割になったのは今からちょうど一年前くらいだったと思いますが、それまでもPdMっぽい動きを度々することがありました。 今考えると、僕の場合はボール拾いを何度も繰り返すことで少しずつエンジニアリング以外のスキルの幅を広げられたのかなと思っているので、その際にやっていたことや意識していたことなどを紹介します。
CSチームとの連携の改善
入社して1ヶ月くらいが経過したころ、ユーザーからの問い合わせの対応に課題を感じました。 当時感じた課題としては以下のようなものがありました
- CS対応が属人化していた
- 開発部のサーバーサイドエンジニア１人 ⇔ CS担当だけでクローズドにコミュニケーションしていた
- 伝言による無駄なコミュニケーションが発生していた
- 問い合わせ内容はアプリに関することがほとんどだけどサーバーサイドエンジニアが対応していたので、都度アプリエンジニアに質問や確認をするコミュニケーションが発生
- 無駄なコミュニケーションが発生することにより返答に時間がかかってしまうことがあった
- 開発チームが不具合を認識するまでに時間がかかっていた
- 開発チームがユーザーの声を拾えていなかった
- CS担当者が対応するためのドキュメントやテンプレートなどが整備されていなかった
改善に向けて起こしたアクション
こういった課題を解決するためにまずはドキュメントの作成と周知を行い、改善に向けて以下のようなアクションをしました。
- CS担当の人にプロダクトの基本的なことに関しては内部の仕組みも理解してもらえるようにする
- 一次回答はなるべくCSチームで対応できるような対応集を用意する
- 開発チームで他のメンバーも対応できる仕組みを作る
- 問い合わせの状況、開発の状況をお互いに見やすい環境を作る
- 問い合わせの一次回答で必要な情報はできるだけユーザーに聞いておく
- アプリ内によくある質問を掲載する
当時はまだステークホルダーもCS担当の方と当時数名のエンジニアだけだったのでそんなに難しいことはしていませんでしたが、こういったことをやり始めた結果その後も1年くらいはCSチームとの連携を続けることができ、ゆくゆくはプロダクトに変更を加えるような施策やCSチーム全体の運用の改善につながるような施策も色々と進められました。 （今は別のメンバーが担当しています）
上記のようなアクションを通して、例えば以下のようなスキルを身に着けていくことができました。
- ドキュメントを使った言語化力
- 部署を跨いだステークホルダーとのコミュニケーション力
- ユーザの行動を知るためのデータ分析力（+SQL）
これらのスキルはPdMとして課題を解決していくためにどれも必要なものだと思いますが、職種に閉じたエンジニアリングをやっているだけではなかなか身につけるのは難しいと思います。 しかし、少し視野を広げて自分から動いていけば自然と身についていくことが多いと思います。
まとめ
今回この記事で特にお伝えしたかった内容は以下の2点です。
- プロダクトマネジメントはボール拾いから始める
- プロダクトに関わるあらゆる出来事を自分ごととして捉えることが重要
今現在エンジニアとしてガリガリコードを書いていて、キャリアとしてPdMとしての道を考えている人の参考になれば幸いです。
おわりに
明日のアドベントカレンダーの記事はジョンさんの「Xcodeプロジェクト管理ツール「Tuist」を試している」です。ぜひ御覧ください！
また、dely ではエンジニア/デザイナーを絶賛募集中です。 ご興味ある方はこちらのリンクからお気軽にエントリーください！
delyではエンジニアを絶賛募集中です。ご興味のある方はぜひこちらのリンクを覗いてみてください。 カルチャーについて説明しているスライドや、過去のブログもこちらから見ることができます。
delyの開発部では定期的にTechTalkというイベントを開催し、クラシル開発における技術や組織に関する内容を発信しています。
クラシルで使われている技術や、エンジニアがどのような働き方をしているのか少しでも気になった方はぜひお気軽にご参加ください！
