Regional Scrum Gathering Tokyo 2021 Day 2 参加レポート「Tips of Product Management for Internal Tools／社内ツール・サービス・プラットフォームにおけるプロダクトマネジメントの勘所」

Regional Scrum Gathering Tokyo 2021 Day 2 「Tips of Product Management for Internal Tools／社内ツール・サービス・プラットフォームにおけるプロダクトマネジメントの勘所」

202/01/07に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14621/tips-of-product-management-for-internal-tools

チーム参加してきました

aslead Agile のチーム「オキザリス」にて参加してきました。
チームの7人で参加して、その場で実況しつつ、記事も作っています。

このセッションについて

内容

開発者が開発者向けにツールを提供する場合に陥りがちな課題と解決策についてのお話です。

• PMの観点から
• 経験・失敗をもとに

お話されています。発表資料はこちら

スピーカー

発表者の方は、LINEのSETとして社内開発者向けにツールを提案・開発・運用されている方です。
ちなみに具体的には以下のツールを展開されているそう。

• Sebas
  マイクロサービスで問題が起こったときに、どこで問題が起こったか特定するツール。Zipkinという可視化ツールで、問題の早期発見・解決を促す。

• Ayaperf
  Grafanaなどで結果を表示してくれる、パフォーマンステスト用プラットフォーム。

• Testable Infra
  オンデマンドでテスト環境を複製できるサービス。
  いくらでもテストできる安心感をもたらす。

リーダーとしての役割

• 誰の何を解決するのか
• どの順番でいつまでに実現するか
• その結果として全社的にどのような価値を提供するか

つまり、PdMも実質兼任。

なぜ社内ツールのPdM？

Technology Rader¹ でも、PdMの知見・方法論を社内ツール群に適用するトレンドが拡大している一方で、社内ツール群ならではの知見・方法論はまだまだ不足している。
知見を整理し、発信するグローバルなチャンスでは！？と登壇を決めたそう。

プレゼン内での言葉

• ユーザ：開発者などプロダクトを実際に使ってくれる人
• ステークホルダ：役員や上長など、プロダクト開発を支援してくれる人

陥った課題

社内ツールの場合、

• 開発者のみでチーム編成することが多い
• プロダクトマネージャーはまずいない
• プロダクトマネジメントを知らない

というケースが多い。その結果次のような課題に陥ってしまう。

開発！開発！開発！

気が付くと開発に集中してしまう、リファクタリングばかり行ってしまう、既存のツールを再開発してしまう等の問題が起こる。

自分たちがユーザ！

ユーザーニーズはすべて既知という思い込み、ユーザニーズを検証しない。新機能などのデモもしない... 結果として、本来のユーザの望まないものを使ってしまいがち。

Fixの誤謬

意思決定・合意は覆らないという思い込みのもと、作りこみに集中したり、デモや報告を後回しにしたり、ステークホルダーの意思は変わらないと思いがち・・・

→どんどんつらい状況に…

思い込みから一歩離れてみよう

ポイントは以下の3点。

• 技術的に優れている != ユーザ価値
• ユーザとステークホルダにアンテナを貼ることは必須
• プロダクトマネジメントの案が得方は必要かつ有効

そして解決方針は以下の通り。

1. 開発！開発！開発！→社内ツールでもユーザ中心
2. 自分たちがユーザ！→ステークホルダーを疎かにしない
3. Fixの誤謬→プロモーション

知見

1. 社内ツールでもユーザ中心

本当のユーザを知る

自分たちはユーザ代表ではない。自分たちがやりたいことを押し付けない、面倒がらずにユーザの声を聞く。

ユーザニーズを向き合う

結局話をするのが一番。インタビュー、テスト、デモを定型化・仕組み化する。新機能のデモでユーザの関心を高める（デモはばんばんした方が良い）。言われたものだけを作る態度は避ける。

ぞれでも自分が試したいことがある場合は？

なぜ作りたいのか？ユーザの課題を解決したい？それとも自分が試したい？両者を繋げられない？と考えてみる。→WinWinにできるならばつなげよう

2. ステークホルダーを疎かにしない

ポイントは、ステークホルダーからの支持・協力の取り付けの必要性とその方法。
要件や仕様が不変だったことってきっとないはず。一度の合意で満足してはダメ。
興味・関心は常に変わる。業務の優先度と同じ。常に興味・関心を引く仕組みが必要。

定期的なデモ

動くものをみせる、というインパクトを活用してみる。
動くものは、圧倒的に得られる情報が多い。

「地図（＝ロードマップ）」の定期的な共有・更新

現時点でのゴールとその道筋を共有することで、
自分たちのチームは、いつまでにどこまでいけそうかを明確にする。
根拠をもって、それをステークホルダーに説明できることが大事。

全ての要求にこたえてはダメ

No code monkey!
リソースは有限。実現可能なことを説明する。
優先順位は責任をもってつける。あくまでパートナーとしてふるまう。

3. プロモーション

ポイントは「Product Marketing」想定ユーザが社内開発者であっても必要。
ただし工夫は必要。

情報はオープンかつしつこく

定期的なデモ実施や、ロードマップの定期的な共有など、興味・関心を喚起し続ける。
テレビCMくらいしつこく、自然と言葉をついて出るまで徹底的に。

チャンネルを増やす

メールやSlack、LINEなどチャンネルは様々。1つだけでは目につかないのでターゲットが好むチャンネルを狙って活用する。
社外向け発信から社員にコンタクトできた例もあるそう。
そして視界に入り込んで認知までもっていく。「好き」の反対は「無関心」。

まとめ

開発者目線からプロダクトマネジメントへ

• 別の視点を単純に知らないだけかも
• 教えれば、きちんと活用してくれる
• コーチは、いたほうが良い

開発者のメリットを生かす

• 開発者だからこそ、実際に作って試せる
• より実現的なものでデモできる
• メリットに注力して、気持ち良くなりすぎない。開発だけにおぼれない

DevOpsで息吹を吹き込む

仕組みを最初に作ってしまうのがポイント

• ユーザテストをしやすくなるPdM
• 検証を継続的に行いやすくなる
• Pivotを気兼ねなくできる

PdMとDevOpsを掛け合わせることで相乗効果が生まれる。

自己実現は可能

自分がやりたいこととユーザの課題解決をリンクさせる視点と行動はあっても良い。ただ、ワンクッション置いてどちらも考えられるように！

プロダクトマネジメント×エンジニアリング

PdMに対する開発者の疑念として「コードのにおいがしない（信用できない）」という声がよくある。
でも、プロダクトマネジメントとエンジニアリング、どちらも必要。両方を併せて大きな価値を広げていこう。

さいごに

愛されるDevExを目指し続けよう！
社内のユーザをハッピーにしていきましょう。

感想

• どうしても開発者が開発をしていると陥りがちな問題、やりがちな失敗・解決策を事例ベースで語ってくださったので色々と共感しつつ、勉強にもなりました。
• 私も社内ツールに携わっている身として、共感できるポイントが多々ありました。特にエンジニアリングに特化せず、PMなど俯瞰的な視点を持つことの大切さが身に沁みました。

1. ThoughtWorks社のトレンドレポート。どんなアジャイルツールが普及しているか、等がわかる。 ↩