Tably株式会社 代表取締役
及川卓也さん(@takoratta)

早稲田大学理工学部を卒業後、日本DECに就職。営業サポート、ソフトウェア開発、研究開発に従事し、1997年からはMicrosoftでWindows製品の開発に携わる。2006年以降は、GoogleにてWeb検索のプロダクトマネジメントやChromeのエンジニアリングマネジメントなどを行う。2015年11月、技術情報共有サービス『Qiita』などを運営するIncrementsに転職。17年6月より独立し、プロダクト戦略やエンジニアリングマネジメントなどの領域で企業の支援を行う。19年1月Tably株式会社を創業

【PMを希望した理由】独りでコードを書くより「みんなで作る楽しさ」を重視

及川　初めて鵜飼さんとお会いしたのは、ある小学校で行われているプログラミング教育のイベントでしたね。その時にお話した記憶だと、確かマイクロソフトには新卒でご入社したとか。

鵜飼　そうなんです。実は就活当時、マイクロソフトディベロップメントではPMの新卒採用の枠はもうなかったんです。でも、自分がこれまでやってきたことや、これから実現したいことなどを人事の方に直談判したところ、PMとして採用していただきました。

及川　この連載でお会いしてきたPMの方々は、ほとんどが開発職やコンサルタント、プロデューサーとしてある程度の経験を積んでからPMになっている人ばかりで。私自身も、エンジニアをやってからPMの道に進んでいます。なのになぜ、鵜飼さんは社会人になってすぐPMをやりたいと？

鵜飼　もともと、人と一緒に何かを作るのが好きなんです。僕は大学院在籍時にIPAの未踏クリエータに認定してもらい、水泳のコーチ代わりになるロボットの開発をやっていたんですが、これも「人と一緒に何かを成し遂げるモノ」が作りたかったからでして。

もう一つの理由は、学生時代にプログラミングをしているうちに、プログラマーの限界みたいなものを意識するようになったから。1人のプログラマーがその人生を通して書けるコードの量って、そんなに多くないなと。

もちろんそれは人によるわけですが、僕の場合は独りでコードを書くよりも「みんなでプロダクト開発ができるPMの方が向いているんじゃないか」と思ったんです。

及川　最初の職場に日本マイクロソフトを選んだ理由は何だったんですか？

鵜飼　さっきのコーチロボットの開発話にもつながるんですけど、コーチングとか、ヒトの教育に興味がありまして。テクニカルなバックグラウンドを持つ人間が、プロダクト開発だけでなく教育にも携われる場所ってどこだろう？と考えながら就職活動をしていたら、日本マイクロソフトと出会いました。

マイクロソフトのWindows製品は、学校教育の現場でもすごくたくさん使われています。だから、ここならITを活用した教育にも何かしらの形で携われるかもしれないと。

及川　じゃあ今はWindows製品のPMチームに？

鵜飼　あ、いや（笑）。今はOffice製品のPMチームで働いています。皆さん経験豊富な方々で、僕の次に若い先輩まで年も10歳以上離れています。

及川　PMの仕事に慣れるまでは、手厚い教育を受けたんですか？私がマイクロソフトでWindows製品のPMをしていたころは……。

鵜飼　たぶん及川さんがいらっしゃったころと同じで、基本はOJTです。

及川　でしたか（笑）。

鵜飼　誤解のないように説明しておくと、マイクロソフトにはPM用のトレーニングメニューが豊富に用意されています。でも、新卒向けのPM研修があるわけではない。仕事のイロハは、先輩方の背中を見ながら学びました。

後、僕の場合はすぐに『Office Lens』のような新製品開発のPMをやらせてもらえたので、かえってよかったと思っています。世界中のユーザーに使われているWindowsやOffice製品のPMよりは、プレッシャーが少なかっただろうなと思っています。

及川　それにしても、入社間もない若者が新製品開発を任されるのは異例ですね。業務はすぐにこなせました？

鵜飼　いえ、失敗もたくさんしましたよ。でも、入社前にIPAの未踏事業を経験していたことで、何とかやれたというか。

未踏事業では、「なぜそのプロダクトを作るのか？」、「これは人類のためになる取り組みなのか？」みたいな部分を徹底的に議論するんですね。そういう体験が、Office Lensの企画～開発でも活かせたと思っています。

それと、学生時代に慶應義塾大学の村井研究室や東京大学大学院の暦本研究室に在籍して学んだことも役に立っていると感じています。

村井教授（村井純氏。日本における「インターネットの父」と呼ばれている）の研究室には、僕よりはるかに優秀なエンジニアが大勢いて。それぞれ得意分野を持った人同士がコラボレートしながら何かを作り出す際は、チームワークが大切なんだと学びました。

それと暦本先生（暦本純一氏。日本を代表するユーザーインターフェースの研究者の一人）の研究室では、アイデアを出したりまとめたりする方法を学びました。例えばディスカッションの時は、ただ持論を主張するだけでなく自分の意見を資料にまとめて出すようにする。または、僕が描いている構想を「絵」に描いて見せるようにする、といったことを学んで、今でも役立っていますね。

【業務遂行のコツ】できるだけ「目に見えるモノ」を作って思いを伝える

及川　この辺で、読者向けにPMの業務範囲を伝えていきたいと思うのですが、主なミッションは何ですか？

鵜飼　マイクロソフト ディベロップメントにおけるPMの役割は、

■ 担当製品のビジョンや、提供したいユーザー体験を定める
■ そのビジョンやユーザー体験を、開発チームと協力して形にする
■ 製品の現状を分析しながらグロース施策を決める

の3つが挙げられます。

及川　では、Office Lensの開発プロジェクトではどのような役割を？

鵜飼　Office Lensは、写真やドキュメント、ホワイトボードのメモをスマホで撮影することで最適なファイル形式に変換し、OneDriveやOneNoteに保存できるというスキャンアプリです。時間がないシーンで使われることが想定されるアプリなので、使い勝手よく利用されるようなUI/UX面での工夫が必要不可欠でした。

そこで僕は、国内外のOneNote開発チームやUXチームと連携しながら、主にUI/UXまわりの開発をリードする役割を担っていました。

ちなににこのプロジェクトには、僕の他にも画像処理のアルゴリズムを、リサーチチームと組んで進めていたPMもいて、一緒に開発の方向性を決めたりしていましたね。

及川　大変だった点はどこでしょう？

鵜飼　UIを担当するデザイナーが米本社のスタッフだったんですね。なので、日本人と外国人の感性の違いというか、デザインにおける考え方の違いをクリアにしていくのには苦労しました。

及川　実は私も、Googleにいた時、海外拠点にいるデザイナーと遠隔でやりとりするのに苦労していました。ある意味、エンジニアとのやり取りよりも難しい。鵜飼さんはどうやって考え方の違いを埋めたんですか？

鵜飼　実際にモックアップを作ったり、UIの改善点をSketchでプロトタイピングしてみて、それを社員食堂などで人に見せながら「こんな意見が出ているので、こういう風にデザイン変えない？」と説得していました。デザインの良しあしについては、「I think……」で話してもなかなか折り合えないので。

及川　プロトタイピングもPMがやるんですね。

鵜飼　いつもやっているわけではなく、Office Lens開発の時はそうした方がいいと思ったので。守備範囲を広げざるを得ないプロジェクトでしたが、ある時は自分でモックアップを作り、またある時はSQLをいじったり、スペックを書いたりと、毎時間やることが変わっていたので楽しんでやれました。

及川　では、エンジニアリングチームとの連携はどのように？

鵜飼　マイクロソフトには、PMとは別のポジションである「エンジニアリード」がいるので、エンジニアリードを介して連携していました。

製品に求めるスペックをドキュメント化するのが僕の役割。で、そのドキュメントを基に2人でレビューを重ねて具体的な開発メニューを決めるところからは、エンジニアリードにやってもらっていました。

及川　開発のスプリントはどのくらいにしていました？

鵜飼　最初は1カ月単位で、その後は2週間ごとに仕切って進めていました。その間に僕がやっていたのは、次のスプリントで何をやってもらうかを考えたり、できあがったモノとレビュー時に決めた内容との差分を埋めるための施策を考えたり、ですね。

及川　そういえば、鵜飼さんはその後、Minecraft Educationの開発チームでも働かれていたんですよね。

鵜飼　ええ、Office製品以外のPMもやってみたかったのと、あのゲームはプログラミング教育に活用できそうだと思っていたので。社内の「グローバルタレントプログラム」という制度を利用して参画させてもらいました。

及川　Office LensのPMとは違った経験ができたんじゃないですか？

鵜飼　そうですね。僕は教育版マインクラフト『Minecraft: Education Edition』や、Code.orgと共同で開発したプログラミング教育教材『Minecraft Hour of Code』の開発を担当したんですけど、マインクラフトのチームではPMではなく「プロデューサー」と呼ばれていて、勝手も違いました。

でも、製品開発をドライブするという役割自体に変わりはありませんでしたし、そのための引き出しが増えたという意味では貴重な経験を積ませてもらいました。

それと、どんな製品のPMをやるにせよ、「ユーザーがどう使うかをまず考える」という出発点が肝になると分かったことで、PMの仕事をやっていく上での自信にもつながりました。

最近は、これらの経験で得た現場感を経営陣にフィードバックする目的で、役員への「逆メンタリング」もやらせてもらっています。

及川　おぉ、それも、教育に興味がある鵜飼さんならではの社内貢献かもしれませんね。

【よく使うツール】情報共有はマイクロソフトの製品群が便利

及川　では次に、鵜飼さんがPMの立場でプロジェクトを進める際によく活用しているツールを教えてください。

鵜飼　個人のタスク管理ではWunderlistを使っていて、開発チームのプロジェクト管理ではVisual Studio Team Servicesを使っています。

後は、先ほど話したようなモックアップづくりの際にSketchやPowerPointを使ったり。これ、声を大にして言いたいのですが、パワポは使いやすさ抜群のプロトタイピングツールなんですよ（笑）。

及川　やはり、マイクロソフト製品が多いですね（笑）。

鵜飼　マイクロソフトは、チーム開発を円滑に進めるための製品群をたくさん持っていますから。ブレーンストーミングやでデザインスプリントの時も、ホワイトボードに書いたメモをそのままOneNoteに取り込んで共有したり、Microsoft Surface Hub上でOneNoteに直接書きなぐったりしながら進めています。

後、チームのSurface Hubには常にKPIとその進ちょく状況を映し出すようにもしています。

及川　伺っていると、あらゆる手法を使って見える化していくのが鵜飼さんの得意なやり方なんですね。

鵜飼　ええ。プロダクト開発を進めていると、エンジニアやデザイナーが「なぜ？」、「どうして？」と疑問を持つ瞬間があると思うんです。

そんな時こそ、実際にモックアップを見せたり、データ分析の結果をビジュアル化して見せたりしながら、「なぜ今これをやるべきなのか」を理解してもらう必要があると思っています。

自画自賛になってしまいますが、見える化という点ではOffice Lensも非常に役に立つツールです。ディスカッションで出たアウトプットをデータ化して共有することができるますし、かつ、そのデータを活用してさらに内容を補強した資料を作ることもできますから。

及川　なるほど、Office Lensは鵜飼さんにも必要な製品づくりでもあったわけですね（笑）。

鵜飼　はい。

及川　データ分析の業務でよく使うツールは何ですか？先ほど「SQLをいじることもある」とおっしゃっていたので、ご自身で分析をやることもあるわけですよね？

鵜飼　はい、僕はコードを書くことができるので。経験が少ない分、やれることは全部やろうと。SQLのコマンドラインを叩いてデータを取得してそのままExcelで分析したり、Azure Data Lakeを使って分析することもあります。

【PMを目指す人へのアドバイス】客観視点を身に付けるために、いろんな“帽子”をかぶってみる

及川　最後に、これまでの経験を通じて、これからPMを目指すエンジニアに何かアドバイスがあればぜひ教えてください。

鵜飼　PMの仕事で必要なのは、課題解決のアイデアを考え、それをチームに論理的に伝えていくスキルだと思います。でも、こういう表面上のスキルよりも大切なのが、情熱と客観性のバランス。よく言われることですけど、「心は熱く、頭は冷静に」っていうのはやはり真理だと思うんです。

プロダクト開発は、そこに賭ける思いの強い人ほどうまくリードできます。パッションを持っている人の方が考え抜いていますし、発言に力がありますから。でもその一方で、客観視点も持っていないとチームが動いてくれません。この2つのバランスをどう取るか？が大切なんだと感じています。

及川　それは僕も同感です。鵜飼さんは、そのバランスをどうキープしているんですか？

鵜飼　僕の場合、思いの方はけっこう明確で。「教育にも役立つような製品づくり」であったり、「みんなで何かを成し遂げる」ことへの情熱は、今も変わらず持っています。

ですから、今は客観視点の方を意識して身に付けるようにしています。

エンジニアの声に耳を傾ける、きちんとユーザーデータを分析してUI/UX設計をやる、モックアップを作って意見を聞いてみる。どれも、自分だけの思いだけで製品づくりを進めないようにするには何が必要か？を考えながら見つけたやり方です。

及川　なるほど。

鵜飼　後は、この客観視点を身に付ける上で、とにかくいろんな”帽子”をかぶってみるのも大切だと思っています。

及川　“帽子”ですか？

鵜飼　はい、いろんな役回りを実際に経験してみるということです。

僕はコードを書けるPMなので、データ分析の際に手を動かす必要があれば面倒がらずにコードに触りますし、デザインについての話も同じような考えでやってきました。

及川　PMは、エンジニアやデザイナーからリスペクトされていないとできない仕事ですから、そういった姿勢を見せることで「本気でやっていることを伝える」のは案外アリかもしれません。

鵜飼　今の僕の強みは、データ分析をしながらチーム運営をより良くするためのカギを探すことだと思っていますが、だからといって、データだけ分析していれば良いモノができあがるわけではないですしね。

及川　本当にそう。数字は「Why？」まで見せてはくれないというか、なぜこの結果が出たのか？という部分まで考察しなければ有効な打ち手は見いだせませんよね。

鵜飼　ええ。僕はその「Why？」をもっと深く考えられるようにならなければなりませんが、そのためにも、今後もいろんな“帽子”をかぶり続けたいと思っています。

及川　今日は貴重なお話をありがとうございました。これからの活躍を期待しています！

>> マイクロソフトディベロップメントにおけるプログラムマネジャーのジョブディスクリプション（採用ページ）はこちら

>> 及川氏が作成した、Incrementsにおけるプロダクトマネジャーのジョブディスクリプション（GitHubページ）はこちら

取材・文／浦野孝嗣　撮影／佐藤健太（編集部）