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](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チームの7人で参加して、その場で実況しつつ、記事も作っています。

# このセッションについて
## 内容
開発者が開発者向けにツールを提供する場合に陥りがちな課題と解決策についてのお話です。

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

お話されています。発表資料は[こちら](https://speakerdeck.com/line_developers/product-management-tips-for-in-house-tools)

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

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

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

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

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

つまり、PdMも実質兼任。

### なぜ社内ツールのPdM？

Technology Rader[^1] でも、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社のトレンドレポート。どんなアジャイルツールが普及しているか、等がわかる。