PermissionsDispatcherのプロダクトマネジメント

ちょっと前にpmconf 2017があったり最近仕事で若干プロダクトやらプロジェクトマネジメントっぽい事にもクビを突っ込んでいる中で普段OSS開発をしている中で得た気付きや知見が適用できる事が結構あったので整理してみようと思う。

自分が余暇の時間に開発しているのはPermissionsDispatcherというAndroidのRuntime Permissionsの処理をラップするライブラリで、2年程前から開発を始め有り難い事にそれなりのstarとユーザーを獲得する事ができている。

元々1人で始めたプロジェクトだったのだが今では派生プロダクトも含めて4人のメンバーがorganizationに所属しており、自分はなんとなく言い出しっぺ的な立ち位置で開発以外にもissueの対応やらproposalを書いたり色々雑多にやっている、という感じ。

OSS開発というとそこで使われているテクノロジーやコードに話がfocusされる事が多いが、個人的には「何を」「どう」作るかというのも同じくらい重要だと感じている。という事で自分が気を配っているのは以下の様な点。

いたずらに機能やAPIを増やさない

プロジェクトを進めていく中で絶対に出てくるのが「この機能も入れたい、あれも欲しい」という衝動で、それは開発者自身から出てくるものであったりあるいはユーザーから要望という形で届くものだったりする。

こういった要望をうまく処理するのは実に難しく、ちょっとでも気を抜くと新しい機能やAPIがどんどん増えていき最終的に複雑怪奇なソフトウェアが出来上がりこのプロダクトのcoreってなんだっけ?という事になりがちである。誰かが悪意を持ってやっているわけではないのに気づくと誰も得をしない状態が出来ている…というのは実に皮肉というか恐ろしい。

こうした事態を避ける為にPermissionsDispatcherの開発では新機能の要望等に対しては意識的にsensitiveになっており、色々と要望が上がってくる中でシンプルなAPIを保つためにどうしても必要なもの以外は取り込まないようにしている。結果として、最初のverから2年経った今に至るまでほとんど破壊的な変更もなく一貫したAPI設計を保っているのは自分が密かに誇りに思っている事の一つだ。

やる事、やらない事を決める

プロダクトマネジメントとは詰まる所「やる事」と「やらない事」を決断し織りわけていく作業だと思う。プロダクトの方向性がぶれていては例えエンジニアリングチームが如何に優れていたとしてもそのソフトウェアが成功する事は稀だろう。

従って、プロダクトの仕様を決める人間には、やる事とやらない事を取捨選択し、優先度を決定し、メンバーに道筋を示すという事が求められる。いわゆる「芯が通っている」という状態だ。

一例を挙げると、PermissionsDispatcherの開発を通して自分はこれまで以下の様な決断をしてきた。

一つ補足しておくと意思決定というのは何も100%正解でないといけない、という事は無くて間違っていたときには素直に認めて方向転換する事ができる、というのもプロダクトマネージャーの重要な素質の一つだと思う。

メンバーをmotivateする

これはプロダクトマネジメントではなくてどちらかというとチームビルディングの類だと思うが、開発にしろ何にしろ1人の力で実現できるプロジェクトというのには限りがあって、多くの場合はチームとして働く事で1人では実現できない事を達成する。従ってメンバーとの関係性やチームの雰囲気というのは非常に大切だし大切にするべきだ、と考えている。

幸いな事に仕事でもプライベートでも自分のいるチームのメンバーはself drivenかつ細かい気配りができる、という事が多くて特に指示等出さずとも最高の仕事をしてくれるので僕としては「Awesomeだね!」くらいしか言うことがないのだけど、何となく普段心がけているのは以下。

最近仕事でやっている事についてはReact Native Advent Calendar 2017に後日書こうと思う。現場からは以上です。