- ※組織の話は詳しくないので自信はないけれど、こう思ったという話を書きます
- ※現在の所属組織の社内ブログに書いた内容を一部修正して転載しています
プラットフォームのプロダクトマネジメント
メルカリのSREであるdeeeetさん (eは4つ) のこの記事が良かった: 社内PlatformチームのProduct Management | SOTA
直接エンドユーザーに面しないプラットフォームであってもプロダクトマネジメントの基本的な考えや方法論を適用し「ちゃんと」やっていく話と、エンドユーザー向けのプロダクトマネジメントと異なるビジネスとのバランスの話が挙げられている。 参考となる書籍やページがたくさん挙げられているので、おすすめ。
特にどのような優先度がやるかについて紹介されていた方法が自分にとっては初見で有益だったので紹介:
大きなタスクの分類としては左から「User asks」「Platform quality」「Long term key initiatives 」が挙げられる．それぞれの意味は以下．
- User asks: 開発者の問題を解決するタスク
- Platform quality: Securityや技術的負債などPlatformの質を担保するタスク
- Long term key initiative: 長期的な投資のためのタスク
Will Larsonはこれらを40:30:30でバランスをとるのが良いとしている．自分たちは完全にこの比率に沿っているわけではないが分類を含めて参考にしている．
40:30:30の根拠は原文を読んでいないのでよくわかっていない。あとで読む。
他の指標としてBusiness, ROI, SLOが挙げられている。これはまあ普通なかんじ。
組織をプロダクトとして捉えてみる
Developer Experienceがバズワードしていった流れは、作るものが複雑になってきて成果の精度や価値を左右する要素として過程の改善が占める割合が小さくない・投資効率がそれなりに高いと認知されてきたからだと思う。
古くはアジャイル開発を始めとして、最近ではソフトウェアエンジニアリングと組織開発の両方に立脚して意義や効果を説いたという点では広木さんの『エンジニアリング組織論への招待』も挙げられる: エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング
これらの背景から組織をプロダクトとして捉えると、改善の進め方やうまい機能のさせかたは実は身近なところから応用できるのかもしれないと考えた。
たとえばプロダクトを開発する部署の顧客は誰だろうと考えると:
- 経営者:競争力のあるプロダクトを速く正しく作る実行力を提供する
- 主要な結果の例: 設定した稼動率目標の達成、競争力の獲得
- プロダクトを開発する部署の各メンバー: 知的好奇心を満たすに足る場や業界で生き残る知識・スキル獲得の機会を提供する
- 主要な結果の例: 昇給
……など。
同様にプロダクト開発の考え方を適用すると、自分の所属の開発部署をどう変えていくかというロードマップを敷くのは未だできていないことで効果が見込めることかもしれない。
Roadmapを作る意義は大きく2つある．まず開発チームからするとどのような機能がいつ頃利用可能になるのかが明確になる．(略) 次にPlatformチームのメンバーからすると今後何を作るかが分かるため，実装時の意思決定の助けになる．「3カ月後にこういうことをやります」と分かって書くコードと、知らないで書くのとでは全然違う．「次にこうするから今はこういう実装をしておけばOK」といった意思決定ができるになる．
以下の優先度の話にもつながることだがRoadmapを作るといかに「やれることが少ないか」が分かる．(略)
https://deeeet.com/writing/2020/10/07/internal-platform-product-management/ より。
組織とプラットフォーム (基盤) は、提供者と受益者の関係性が二面的であったり曖昧であったりする点に共通点を見出すことができる。
上記例では各メンバーを顧客としたが、同時に開発部署を作るのも各メンバーであって、どちらかのペルソナだけを持つわけではない。 これは社内プラットフォームにも言えて、開発者と利用者が完全に分断されているケースのほうが珍しいだろう。
個人のキャリア形成という文脈では受益者という立場が強く出るだろうし、マネージャーに近い役割を負う人は提供者という立場の割合が大きくなることが想像できる。
ロードマップがあれば、近い内に解決が難しい問題に直面した時に実は3ヶ月後なら変わる芽がありそうだとか、しばらく解決は難しそうだが積み上がっている課題を見れば納得感はあるのでバックログを片付けることに協力しようとう気持ちになるなど、そういったコミュニケーションをとれる人が増えないだろうか。
また人事評価 (MBO) とは独立して、かつ人事評価の単位より長い時点までのロードマップを立てられると、人事評価のようなモノリシックなシステムを変えることなくメンバーにより遠い未来について思いを馳せる機会が与えられるかもしれない。 それは視座の上昇の機会となり、自己組織化を促すきっかけにならないだろうか。 リーダーであるための視野・視座・視点 - Tech Inside Drecom
正しく作る
という話に還元されそうなので未読の以下を読みたいと思います:
正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先についてn
まとめ
- 冒頭に挙げたdeeeetさんのエントリは良いことが書いてある
- 組織運営も同様にプロダクトマネジメントの手法やベストプラクティスが応用できないだろうかと考えた
- その考えに則ると、ロードマップの策定は効果が見込めるのではないか
