#june29jp

これは Product Manager Advent Calendar 2015 の参加エントリです。12月12日(土)を担当します。

最初に、ほんの少しだけ自己紹介させてもらいます。ぼくは職能としては「プログラマ (ソフトウェア・エンジニア)」といったところで、ふだんの業務でもプログラミングをして過ごす時間が一定以上あります。とはいえ、創業期の会社に身を置いている期間も長かったので、そういった状況では、コードを書く作業に入る以前の「プロダクトの方針をどうするか？」「ビジネスとしてどうするか？」といった会話も身近なものです。そういった背景もあって、今年はちょうど「プロダクトマネージャ」「プロダクトマネージメント」に興味があって、この Advent Calendar にも参加させてもらっています。

今回は「プロダクトマネージャのロールモデル」、あるいは、ひとりのプログラマである自分から見た「プロダクトマネージャ像」と「プロダクトマネージメント業」について書きたいと思います。

プロダクトマネージャのロールモデルを見つけたい

ぼくが明確に「プロダクトマネージャ」「プロダクトマネージメント」という語彙を得たのは、直近1年以内のことだと思います。それ以前もなんとなく「プロダクトについて、一貫した方針を持つのは大事」「魅力的なコンセプトが大切」といったことは経験的にも理解しているつもりでしたが、これらの語彙を得たことで、プロダクト開発におけるそういった重要な観点をより強く意識するようになりました。

さて、知識というか観点が身についたとしたら、次は当然、自分のプロダクト開発の現場で活かせないだろうかと考えてしまうものです。自分がプロダクトマネージャを担当することになったとしたら、どうふるまおうか。あるいは、自分のチームにおけるプロダクトマネージメント業務が疎かにならないように、ひとりのメンバーとして自分がやるべきことはなんだろうか。だんだんと、具体的に考えるようになっていきました。

ところで、自分には「ロールモデルにしたい」と思えるようなプログラマの人たちというのがいます。「こういうプログラマはかっこいいなあ！」というプログラマ像も、自分の中にあります。一方、プロダクトマネージャという役割を知ったのが最近のこととあっては、プロダクトマネージャのロールモデルを見つけられずにいたのです。「著名なプログラマ」と言われれば、頭に浮かぶ人たちが何人もいるというのに、「著名なプロダクトマネージャ」というと、すぐに思い浮かべられる人が、自分にはいなかったのです。

自分にとって未知の領域も多いプロダクトマネージメント道を歩くにあたって、見本にしたくなるようなプロダクトマネージャのロールモデルが欲しい…！さらに欲を言えば、世界のトッププレイヤーよりは、少しは手の届きそうな、その手のイベントに顔を出せばご挨拶できるのような、日本人プロダクトマネージャが心の中にいてほしいな、と思っていたのです。ちょうど自分がプログラマの駆け出しだったころに、憧れを与えてくれた先輩たちがいたように。

灯台もと暗し

最近ぼくは、気付いてしまいました。尊敬するひとりのプログラマが、同時にまた、素晴らしいプロダクトマネージャでもあるのではないか、と。その人物とは「まつもとゆきひろ」さんです。オブジェクト指向スクリプト言語 Ruby の作者、という紹介が最もわかりやすいでしょうか。

もともとぼくは、言語という意味では日本語の次に Ruby をよく使う Rubyist として、まつもとさんの存在はもちろん知っていましたし、まつもとさんが書かれた文章を読んだり、インタビュー記事に目を通したり、カンファレンスでのまつもとさんの発表を聴いたりもしてきました。そのときはずっと「プログラマとしての、ひとつの究極形だよな」というような印象でまつもとさんの言葉を受け止めてきていたのですが、それらの言葉をあらためて思い出してみて、プロダクトマネージメントの観点から捉えなおしてみると、はっとすることがたくさんあったのです。

「Ruby をプロダクトとして、まつもとゆきひろさんをプロダクトマネージャとして見てみる」この試みから、自分はいろいろなものを得ることになりました。

プロダクトとしてみる Ruby

先ほどもリンクしたプログラミング言語 Ruby の公式ウェブサイトには「A Programmer's Best Friend」とタグラインが記されています。これはとてもわかりやすいプロダクトの「コンセプト」ですね。Ruby の設計に関するいくつもの意思決定を支えてきた、力強いコンセプトだと思います。

よく Ruby は「コンピュータのためではなく、プログラマのために設計されている」といった言われ方をします。いくらでも言及は見つかると思いますが、ここでは2011年のまつもとさんの講演が紹介されている記事をひとつだけ紹介しておきましょう。

「人間様が気分よくプログラミングするための言語」Rubyは何を目指すのか - GIGAZINE

プロダクトマネージャとしてみるまつもとさん

続いて、まつもとさんがよくお話されることをいくつか思い出してみます。

ひとつめは、上記書籍の中で語られている「名前重要」です。Wikipedia にも項目があったのでリンクしておきましょう。ぼくもたまに、日常会話の中で「命名重要」と言うのですが、これはまつもとさんの受け売りです。

プログラマが知るべき97のこと/名前重要 - Wikisource

今、振り返って思うのは、もし私がRubyという名前を選ばなかったらきっと、現在のRubyの普及を見ることはなかっただろうということです。このRubyという名前にパワーがあったからこそ、Rubyの魅力が増加したのではないかと感じるのです。ただ単にRubyがプログラミング言語として優れているだけでなく、この名前の持つパワーによって、愛される存在となっているのではないかと感じるのです。この名前があればこそ、これまでの長い間Rubyを開発し続けるモチベーションが維持できたし、また多くのユーザーがRubyという言語に関心をもってくださったのではないかと感じています。

そんなこともあって、私の設計上の座右の銘は「名前重要」です。あらゆる機能をデザインする時に、私はその名前にもっともこだわります。プログラマとしてのキャリアの中で、適切な名前をつけることができた機能は成功し、そうでない機能については後で後悔することが多かったように思うからです。

実際、Rubyに対する機能追加の要求に対しても、しばしば「要求は分かった。あれば便利なのも理解できる。でも、名前が気に入らない。良い名前が決まったら採用する」として拒否したものも数限りなくあります。しかし、名前が気に入らなかったもので、取り入れなかったことを後で後悔したことはほとんどありません。

プログラマが知るべき97のこと/名前重要 - Wikisource

これなんかは本当にもう、プロダクトマネージメントの文脈で理解しやすいですよね。プロダクト名は、プロダクトの成否に影響する大事な要素だと思います。また、この引用からもわかる通り、まつもとさんは Ruby に対する機能追加の提案の「取り入れる / 取り入れない」を判断しているわけですが、まさにプロダクトマネージャ業そのものです。

最近のものでは、情報処理学会誌に掲載されたインタビュー記事も大変おもしろかったので紹介しましょう。余談ですが、漢字フルネーム表記の「松本行弘さん」だと、誰だかピンとこなくておもしろいですね。

情報処理2015年12月号特集記事「20年目のRubyの真実」インタビュー-情報処理学会

ここでは「言語設計の議論に関しては『驚き最小の原則』は言わないようにしよう。ユースケースが大事」「見かけの重要性」といったトピックについてお話されていて、プログラミングをやらない人にとっては難しいお話が多いかもしれませんが、やっぱりこれもプロダクトデザインについて語られていて、プロダクトマネージメントの範疇のお話なんですよね。そう思って読んでみると、すごくしっくりきます。

最近はそんなことを思っていたものだから、まさにいま会期中の RubyKaigi 2015 においても、まつもとさんの発言やスタンスについては耳を傾けて聴いていました。ひとつ印象的だったのは、TRICK 2015: The second Transcendental Ruby Imbroglio Contest for RubyKaigi - RubyKaigi 2015 の審査員として登壇されていたときに、自己紹介で「島根県松江市で Ruby デザイナーをやっています」と言っていたことですね。「Ruby デザイナー」と、なるほど。

キーノートでは「Ruby 3.0 は Ruby 2.0 の3倍高速にします！(どう実現するかは、まだ分からないけれど)」との発表がありました。それを受けて、Ruby コミッターのみなさんが「よし、やるぞ！」といった反応を見せていたりもしました。会場は大いに沸いていましたね。魅力的なゴールを示して、プロジェクトメンバーやユーザを惹きつけるのも、プロダクトマネージャの役割ですね。

また、最近のバージョンの Ruby 開発の現場には「リリースマネージャ」と呼ばれる役職があるのですが、これもおもしろい役割分担だと思います。2009年のインタビュー記事を見返してみると、こんなことが書いてありました。

Rubyを支えるYuguiの自信 「最後にはわたしがいる」 － ＠IT自分戦略研究所 より。

もともと、Rubyにはあまりマネジメントをする人がいませんでした。まつもとさんはマネジメントをするタイプではないし、笹田さんも細かな作業をこなすタイプではない。「リリースマネジメントは誰かがやらなければならない」という共通認識が、皆の間で強くありました。

「まつもとさんはマネジメントをするタイプではない」と言われていますね。これは「プロジェクトをマネジメントするタイプではない」という意味かと思います。

リリースマネージャは「リリースをきちんと行う」ことが使命です。そのためには、「スケジュール管理」が特に重要です。誰が何を実装しているのか、何をやろうとしているのかという「全体像」を把握しておくようにしています。

「プロダクトマネージャとプロジェクトマネージャ」の役割分担でいうと、まつもとさんが「プロダクト」を見て、当時の Yugui さんが「プロジェクト」を、それぞれ主に見ていたと言えそうです。

ユーザーにとって必要かどうかについては、まずわたし自身がRubyユーザーとして「この仕様は必要であると思えるかどうか」と考えます。わたしはやや古めのユーザーでもあるため、10年前の文化も分かりますし、Ruby on Rails以降のユーザーのニーズも把握しています。言語の一貫性については、それぞれの個所に詳しいコミッタに、取り入れる必要があるかどうかを相談します。

コアメンバーとは、よく話し合いをしますね。「何が必要で何が必要ではないのか」などの議論が活発に行われます。もし、話がなかなか収束しそうにない場合は、わたしが意見を述べて収束させる場合もあります。言語仕様の最終決定は、まつもとさんに委ねます。ユーザーの利便性については、わたしが最終的な判断を行います。

「言語仕様の最終決定は、まつもとさんに委ねます」とのことなので、まさに「プロダクト」のことを決めるのはまつもとさんの役割なんですよね。

他にも枚挙に暇がないくらいに、こんな感じで、実はぼくはもう何年も前から素晴らしいプロダクトマネージャの姿を、そうとは知らずに見てきていたのでした。

まとめ

最近になって語彙を得た「プロダクトマネージャ」あるいは「プロダクトマネージメント」については、ついつい「新しいもの」として捉えてしまいがちですが、プロダクトがあるところには多かれ少なかれプロダクトマネージメントが発生しているのだと思います。今からあらためて「よし、しっかりプロダクトマネージメントをやるぞ！」と歩き出す場合にも、まずは自分が見てきた人たちの中から、そういやあの人はプロダクトマネージメントしていたんだな〜と捉え直してみるのは有益なことだと思います。

ぼくは今一度、Ruby のプロダクトマネージャであるまつもとゆきひろさんの種々のふるまいを思い出してみて、そこから取り入れられそうなものはないだろうかと探してみるつもりです。世界中のプログラマから愛されている Ruby のように、ぼくも魅力的なプロダクトをつくっていきたいです。

というわけで、 Product Manager Advent Calendar 2015 の12日のエントリでした。