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

December 13, 2017 misc lang-ja

ちょっと前に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の開発を通して自分はこれまで以下の様な決断をしてきた。

• Kotlin対応… やる。これには2つの話があってまずコード生成用のモジュールをJava→Kotlinにreplaceした話とあとGoogleIO 2017の発表を受けKotlinコードを生成する機能をサポートした。前者にはJava1.6環境での導入をサポートできるという実利があり後者はGoogleIOの発表を受けてからのスピード感を大事にしたかった事とプロジェクトに何か新しい風を吹かせたかったというのがある。
• Xiaomi対応… やる。これは当初やらない、という風に思っていたのだが中国でのユーザーが非常に多い事とXiaomiが中国国外にも影響力を持ち始めた事を考慮してやるに変更した。が、今後これをkeepするかは若干悩み中。
• RxJava対応… やらない。競合にRxPermissionsというプロダクトがあるのでRxLoverはそっちを使えばいい、という意思決定。無理矢理導入する事は勿論可能なのだがそれはやりたくない。

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

メンバーをmotivateする

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

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

• 技術的な挑戦が出来そうな場合は前のめりに倒す…自分はどちらかというとコンサバティブで勝算なしに新技術を選択する、という事はあまりしないのだけど、例えば最近やったKotlin向けのAPIを導入するというのはプロダクトの方向性としてもエンジニアのモチベーション向上としても効果を期待できたので即決した。
• Awesomeだね！と言うことを忘れない…エンジニアにとって、というか仕事をする上で承認欲求が満たされるというのは実はかなり重要な事だと思っている。良い仕事をしても誰からも注目されなければそれは辛いし誰だって自分のした事が誰かの目に止まってほしい。なのでメンバーのコントリビューションに対して「これは良い！」という事を忘れない事が重要だ。チームとしての成果を発表する様な機会にはspecial thanksとしてメンバー一人一人の活動を取り上げ感謝の気持ちを伝える、という事もよくやる。
• 寿司を奢る…というのは冗談だけど自分はメンバーと上手い物を食べながらプロダクトについて話す、というのは結構好きだ。

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