「自分事としてそのプロダクトに向き合えているか」が大事　及川卓也氏が考える「エンジニア力」とは

「ソフトウェア開発よりもプロダクト開発のほうが絶対におもしろい」

ーーなるほど。そうすると今言った流動する側のエンジニアとして、例えばやはり自分もエンジニアを極めたい、スペシャリスト職ならスペシャリストになっていきたいという時に、その人がエンジニアとしてやっていけるんじゃないかというポイントって何か、及川さん的にはあったりしますか？

及川卓也氏（以下、及川）：難しい質問だと思います。難しいというか、シンプルな1つの答えがないものだと思います。それを別の質問の言い方に変えるとすると、エンジニアの能力は何をもって定義するかという話だと思うんですよね。エンジニアの能力は、例えばここではソフトウェアエンジニア、実装するようなエンジニアを考えたとしますと、そうするとその人のまずはカバーする領域、カバレッジという部分があると思うんですね。

よく言われるように「フルスタック」というような言葉がありますが、インフラからWebのフロントエンドからバックエンドなどなど、そのプロダクト事業が必要とする領域をひととおりカバーするというようなのがフルスタックという考え方ですし、一方で例えば今の話で言ったのならば、インフラに特化するエンジニアというのもいるわけです。

モノリシックなアーキテクチャだったものをマイクロサービスにして、それぞれをコンテナで管理して、Kubernetesなどを使いオーケストレーションして、さまざまな自動化をしてということをやる。ここの部分に興味があって、インフラに特化したいというエンジニアもいるわけです。なので例えば、今言った領域のカバレッジに関しても、カバレッジが広ければ広いほどいいかというと、必ずしもそんなことはない。

でも狭くて、その狭い領域だけで例えば自分がその領域のトップクラスに行きたいのか、行けるのかというのもあるわけで、このカバレッジ1つを取っても、自分が何をやりたいのか、やれるのかということを含めて。あとはもう1つは、私はあまり好きじゃないんですけれども、そこの人材市場における価値を考える。要は希少性ですよね。それを考えてみるということが重要だと思います。

ですから、今でもその部分は残っていると思うんですけれども、やはりデータサイエンス領域、AI領域に関しては、人材の希少性が非常に高い争奪戦があるということなので、フルスタックではなく、自分はあえてデータサイエンスだけで深めていきたいということを考えるのは、今においては非常に妥当性があるわけですが、今後はそれが続くとは限らないですし、他の領域では、過去においてはそういうことがあったとしても今そうであるかどうかがわからないというところがあると思います。

なので、カバレッジにおいては完全にカバレッジがないというのも問題だと思うので、ひととおりは少なくとも技術の内容は理解しておきつつ、それを全部自分でひととおり実装とか設計とかをできるようにするか、どこかを深めるかというのは、繰り返しになりますけれども、自分の興味関心とそこに向いているかどうか。プラスあとは実際に飯を食っていかないといけないわけですから、それにおいてしっかりと収入が確保できるかというところがあると。

あとは、今はこの広さの話をしましたけれども、同時に今の話の中にあったように深さ。広さと深さというところの掛け合わせが、まずは技術領域ではあると思います。

もう1つは技術者というのは、例えば今言ったソフトウェア開発エンジニアというのは1日中画面に向かってコードを書いているわけじゃないと。たまに業界のことをあまり知らない人が、「私は人付き合いが嫌いだからソフトウェア開発者になろうと思うんですけど」という相談に私のところに来る、学生さんとかなんですけど、もたまにいるんですけど（笑）。

（一同笑）

それは、大昔からそんなことはできませんでしたという話をして、基本的にはソフトウェア開発やプロダクト開発というのはチームプレイなので、しっかりチームとの間のコミュニケーションやコラボレーションが必要だという話をするんですね。ここは少しフワッとした言い方になってしまうんですけれども、いわゆるヒューマンスキル、ソフトスキル的な面が必要になるわけです。

それは今言った繰り返しになりますけれども、コミュニケーション能力であったり、プレゼンテーション能力であったり、ネゴシエーション能力であったり、いろんなものが必要になります。これは例えばコミュニケーションといっても人前で話をしたり、こういった口頭でのコミュニケーションに極めて高いものを求めているというのだけでは考えないでもらって大丈夫で、いわゆるプロダクトを作る、ソフトウェアを開発していくに関してのコミュニケーションというのはさまざまなスタイルがあるんですね。

ですから、今リモートワークなどが出てきたりしている中でいうと、テキストでのコミュニケーションが得意であったり、もしくはそれが求められている場もあると思います。それも含めてのコミュニケーション能力ですし。あとは通常やるようにコードレビューとか、あとは設計書にあたるデザインドキュメントみたいなものがあったならば、それにおいてレビューしてコメントを書くというのも、これも立派なコミュニケーション能力になるわけです。

ここでしっかりと自分の言いたいことを言いつつ、でも相手に対しての尊重の念を忘れないというようなやり方。「アサーティブ」と英語で言うんですけど、そういったアサーティブコミュニケーションみたいなものが当然必要になってくるわけです。こういったところの裏側には、ちょっと順序が逆になってしまいましたけれども、ある自分の考えをしっかりと整理できる能力が必要になるわけですし、それをまとめ上げる能力が必要であり、人にそれを説明する能力が必要であると。

これはいわゆるロジカルシンキングのようなものであったり、クリティカルシンキングになるようなものだと思うんですね。ですから、人に何か自分の考えを伝える。自分の実装方法なり設計方法なりを伝え、理解してもらうためには、そのためには後ろにちゃんとしたファクトであり、ロジックであり、こういったものが必要ですから、それを組み上げていくものが必要であり、その集大成が最終的にはコードに落ちていくというかたちになりますから、その一連の思考というものが、能力の中では極めて重要になってくると思います。

ーーなるほど。

及川：あとはちょっともう1つだけ。これをどこまでエンジニアに求めるかというのがあるんですけれども。事業に対しての貢献力みたいなものなんですね。要は今申し上げたとおり、どこを境界線とするかなんですけど。エンジニアで「私は金儲けにまったく興味がないです。作るものを決めてくれたならば、そこから先はやります」という人がいます。少なくないとは思います。

これはこれで、そういうような仕事の仕方はあるかもしれないんですが、個人的にはそこに明確な境界線を引くよりは、自分が作っているものが自分の会社の事業にいかに貢献するのかを理解したり、何だったならば自分からそういう貢献、事業の先には当然ユーザーがいるわけですから、ユーザーに対して何をすればいいかということを理解、もしくは自分から考える能力というものを持っておいたほうがいいと思います。

よく、かっこいい言葉で私が言っているのが「ソフトウェア開発よりもプロダクト開発のほうが絶対におもしろいです」という話をするんですね。コードの難しい課題に対して、しっかりといろいろな試行錯誤を重ねてコードにして、品質の高いものでバグもなく動いたら、めちゃくちゃエンジニアとしては楽しいんですけれども、でもそれってその段階だけだとユーザーがゼロなわけですよ。

でも自分が苦労したものが本当にユーザーに届いて、ユーザーに使ってもらったらうれしいし、こういったユーザーが何人も何人もいたらもっとうれしいわけですね。なので「コードの向こうのユーザーを見てください」という話をしていて、そうすると自分のやっているものの価値がもっと高まりますと。

だから例えば、もしいわゆる事業サイドから「あるものを作ってほしい」と言われた時に、盲目的にそれを信じて手を動かしだすよりも、わからなかったら質問をして、これだったらコードもこういう書き方をしたほうがいいというのを自分の中で考えたり、必要ならば事業サイドにわかる言葉で「2つのアプローチがあるんだけれども、今のお話からするとこちらのアプローチでいこうと思いますけれども、どうですか？」という話を積極的にかけられるような、そういったほうが私はより価値があると思います。

なので、本来であれば​​ここまでエンジニアの能力として入れたいんですが。ただ、ガッツリそれでビジネスを理解しろとかお金儲けを理解しろというのはちょっと難しいところもあるし、実際問題できないと思います。ただ、そこを常に意識した上でソフトウェア開発をやるというところは、持っていてほしいなとは思います。

「マネージメント」と「マネージャー」

ーーなるほど。そう考えると、いわゆるエンジニアがプロダクトマネージメントみたいな部分は、マネージャーじゃなくても身に付けておいたほうがいいですかね？

及川：そうですね。ここではちょっと言葉の定義として説明をしておいたほうがいいなと思うのが、「マネージメント」と「マネージャー」という言葉があります。

日本でいうとマネージャーというのは多くの場合が管理職で、その管理職の何を管理するかというのは、人と組織の管理なんですね。

でも実は人と組織のマネージメントのことは「ピープルマネージャー」というのが正しいんですよ。先ほどの文脈で私がエンジニアのキャリアの話をしていた時のマネージャーというのは、このピープルマネージャーの話です。エンジニアをマネージメントする、要はエンジニアの部下を持つ上司という意味でのマネージャーです。

それでプロダクトマネージャーというのは、プロダクトをマネージするものなので、必ずしもこの人は下に部下を持っているわけではないんですね。なので今の話でいうとプロダクトマネージャーはプロダクトのマネージメントであり、これは専門職として人が存在していたほうがいいとは思いますけれども、一方で会社によってはプロダクトマネージャーを置かない会社もあったりします。

そうなると、エンジニアがそのプロダクトマネージャーの役割を兼務していると。これはPros/Consあるんですけども、そのPros/Consを理解した上でそうやっている会社はあります。なので誰がやるかは別にして、このプロダクトマネージメントというのはプロダクト開発において絶対に必要な部分なので、これは繰り返しになりますけれども、専門職であるプロダクトマネージャーというのを置くか。置かなかったならば、エンジニアもしくは事業サイドがそれを担う必要があります。

プロダクトマネージャーがいたとしても、プロダクトマネージメントの考え方はプロダクトに関わる人全員がある一定レベルは持つべきだと私は思います。

大事なのは「マインドセット」

ーーなもしかしたら繰り返しの質問になっちゃうかもしれないんですけど、そのプロダクトマネージャーをやるとなった時に、どうやってそこの感覚を鍛えればいいのか。どういう方法で身に付けていけばいいのかというのは、何かあったりしますか？

及川：これは先ほどのフルスタックとある特定領域に深掘りするエンジニアの話と近いところがありまして。先ほどプロダクトマネージメントをエンジニアが身に付けなければいけないかというと、必ずしもそうではないところがあると言いました。なので、さっき言ったのと矛盾しちゃうのでもう一度言い直します。

プロダクトマネージメントは、事業サイドも、あとはエンジニアサイドも理解してほしいという話をしました。これはもってほしいですね。それでこの部分は、正直言うと、何かスキルとしてとか能力として身に付けるという前に、大事なのはプロダクトは誰の・何の課題を解こうとしているのか。これを理解し続けようとするマインドセットだけだと思うんですよ。

ーーなるほど。

及川：だから「あなたのプロダクトのお客さまは誰ですか？」と言った時に、解像度高く答えられるかどうかなんです。どんな人ですか？　どんな時に使っていますか？　それで今あなた方が提供しているプロダクトはそのお客さんの課題に完全に答えられていますか？　答えられていないとしたならば何が足りないと思いますか？　今後それをどう改善すればいいと思いますか？

こういったものをプロダクト関係者は毎日考えているはずなんですね。これを自分事として持つということが、プロダクトマネージメントの本質であり、それをやるために細かいいろんな手法なり考え方というものがあるわけですけれども。これが必要になったなら勉強すればいいし調べればいい。それこそ会社の中でそれを担当している人に教えてもらったり、その人が何をやっているかを知ればいいだけなはずなんですね。

だから一番大事なところは、誰の・何の課題を解こうとしているか。誰にどういう価値を届けようとしているのか。そこさえ理解しておくこと。あとプラスでもう少し言うのならば、それをやることによって、どのように事業収益に結びついているかも重要なんですが、当然継続的な事業として展開していかなければいけないならば、お金がきちっとフローで回ってこないといけないわけですから、どういうビジネスモデルであるかは理解しないといけません。

でも最後の部分はちょっといったん会社のほうに任せておいても、まだ大丈夫なところだと思いますから、一番大事なのは、ユーザーは誰ですか？　ユーザーはどんな時にこれを使いますか？　なぜ使うのですか？　そこをしっかりと理解し続けようとするということができれば、繰り返しになりますけれども十分だと思います。その時の例えばユーザーを理解するための手法は、マーケティングの手法でもUXリサーチの手法でもあります。

今は日本語でも良い書籍がたくさん出ているわけですし、YouTubeを見てもそういったことを簡単に解説しているような動画もありますから、それを見るだけでも理解がぜんぜん高まると思いますので、まずは今言ったプロダクトが誰のためのものなのかということを理解し続けようとする。そういったマインドセットが大事だと思います。

全員が自分事としてそのプロダクトに向き合う

ーーなるほど。及川さんも、それについていろいろなところで話されているかと思うんですけど。そういう時に、そこに参加している人は、けっこうそういうマインドセットを持っている人が多いのか、それともそこはプロダクトマネージャーの重要性が会社としてもあまりわかっていないパターンが多いのか。そこらへんは今はどういう感じが多いんですかね。

及川：そうですね。プロダクトマネージメントの重要性というのは、理解され始めているように思いたいなと思っています。

ーー（笑）。

及川：どういうことかと言うと、『ソフトウェアファースト』の書籍も売れましたし、あとはプロダクトマネージメントもここ5、6年で日本の企業にかなり認知されるようになってきています。それはプロダクトマネージャーカンファレンスという、私も立ち上げメンバーの1人だったんですけど。

ああいったカンファレンスを始め、さまざまな方々が草の根的にやられて広めたところもあれば、私も書籍を1個書きましたけれど、プロダクトマネージメントの書籍も日本語版でいくつも出てくるようになり、そういったことが認知されたりして、日本の従来型の大企業の中でも「プロダクトマネージメント」という言葉は認知されるようになってきています。

それもあって私の会社にも研修の依頼が来たりすることも多く、そこでいうと認知されるようになってきているとなと思うんです。一方でプロダクトマネージャーやプロダクトマネージメントだけではないんですが、言葉が良いように独り歩きだけをしていて。DXも若干そういうところがあると私は思うんですけど。

会社の中で「なんかDXが重要そうだから研修を受けてこい」とか、どこかのコンサルに頼んでDXの施策を展開したりということをやられているんだけれども、本当に重要な部分ということが理解されていないことがあるように思っています。プロダクトマネージメントでいうと、結局そのプロダクト事業を……。ちょっと浪花節的な、精神論的になるんですけど（笑）。

プロダクトを絶対に成功させようと思うような人たちがどれくらいいるか、にほぼかかっているんですね。今の伝統的な従来型の日本企業の方とお話をしていて思うことは、結局これは誰がプロダクトの責任者ですか？　という時に、明確に1人の責任者が出てこなかったり、出てきても極めて上位職の人が出てきて「この方は毎日の現場にはいないですよね？」と。

「現場の中で常に発生するようなプロダクトの意思決定の時はどうしているんですか？」と言った時に、いわゆる悪い意味で無難な判断になってしまっていて、みんなが全員自分事と思っていないんですよ。これは会社が決めた新しい事業企画なので、それで大量の人が入ってくることもあり、それぞれで役割分担が決まっていて、その自分の役割をまっとうするだけで、物事は進んでいくんですよ。

先ほどのエンジニアのほうの話でいうと、どういう流れかはわからないけれども、もう仕様が決まり、それが設計に降りてきて。例えば、自分はコードを書くだけであると。「コードを書いています」と。でもこれが最終的にどこの誰にどう使われるかわからないし、本当にその機能のためには、この書き方でいいのかわからないけれども、誰かが書いてくれた筋書きがあり、それをまっとうすればいいと。他の人もそんな感じなんですね。

そうやっているうちに、一応プロダクトが出来上がっていく。でも、これじゃあ先ほど言ったプロダクトが誰に使われて本当に使われるようにするにはどうすればいいか、全員が自分事として考えることになっていないんですね。

だから私がよく大企業のこういった方々、スタートアップの方々にも言うんですけど、自分のプロダクトだと思って、世の中に出た時にお客さんが、例えば昔ながらのソフトウェアパッケージで量販店に並んでいるようなものだとしたら、後ろを見たら開発者の名前が書いてあって「自分の名前が書かれていると思った時に今のプロダクトに誇りを持てますか？」という話をしている時に、みんな持っていないことが多いんですよね。

だから物事の本質はそこだと思います。全員が自分事としてそのプロダクトに向き合えているかどうかです。

大規模開発でも「ビジョンをしっかりと語り続けること」が大切

ーーちょっと話が少し外れるかもしれないんですけど、私もたまにゲームのプロダクトを開発している人と話をすることがあるんですけど、昔はそれこそやはり1人で作っていたりとか数人でゲームを作っていて、それでゲームが出来上がっていたから、みんなけっこう自分事になっていたんですけど。

だんだん大きい、それこそ大規模なゲームを作り始めると「この部分だけをやってね」「ここの部分だけをやってね」と言われるから、なかなか自分事にしにくい。商品として出来上がるものはなんとなく、例えばこういうゲームだなというのはわかっているんですけど、自分が担当しているのが例えばバトルのところのバーのところだけだったとかというふうになってくると、なんか自分事にしにくくなってきている。

だからプロダクトがどんどん大きくなればなるほど自分事にしにくくなるのかなというところを感じていたりはするんですけど、そういうことってあったりはするんですか？

及川：それはあり得ると思います。それは、本人のプロダクトへの関わり方だけでは解決できないところではあると正直思います。なのでそれは、本人の問題というよりもそのプロダクト開発組織のあり方の問題ではないかと。そのようになってしまうのは、プロダクトが肥大化して、その開発組織も大きくなると、必然的にそれは生まれうるものだとは思うんです。

でもそれでも、やはりトップなり、そのプロダクトの全体の責任者的な人が、いかに全メンバーに自分事として関わってもらうようにするかを、いろんなかたちでその状況を作り出すことは可能なんだと思うんですよ。なので少なくとも私がいた会社ではトップからメッセージが届くんです。例えばWindowsを作っている時にWindowsのトップからのメッセージは、もうしょっちゅう送られてくるんですね。「俺たちは今ここまでいるんだ」と。「こんな状況だ」と。「ここはうまくやった」と。

あともう1つは、Windowsはわかりやすかったんですけど、開発に長いものだと数年かかるし短いものでも1年ちょっとはかかるわけですけど。途中で動くようになったら、自分たちで作っているものを使うんですよね。いわゆるドッグフードという考え方なんですけれども、その中でもOSを作っている場合だと、開発中のOSを開発中のOSの上で作るんですよ。それをセルフホストと呼ぶんですね。

それで、最初はクラッシュばかりするわけですよ。それで開発に影響を与えるぐらい品質が悪いわけですね。でも「手のかかる子ほどかわいい」というのと同じで、最初は目論見とは違って重かったりクラッシュしているのも途中で妥協することもあるんですけれども、妥協せずにやはりその担当チームがしっかりとそれを改良していくとどんどん使いやすくなって「確かにこれはすごいや」と思えたりするんですよ。

今もMicrosoftがやっているかどうかはわからないんですけど、我々は開発中のOSを何台か回して、今だったらおそらく仮想マシンでやっていると思うんですけど、昔は物理的に実際のマシンを何台も机に用意をしていて、それでカーネルデバッガと言ってデバッガをつなげて、空いてるマシンにはストレステストを自動的に流していって、一晩そのまま置いて帰っていくんですね。

それで次の日にクラッシュしていると、リモートでそこに担当者の人たちが入ってデバッグしていってというのをやったり。それがうまくいかない時は、こっちである程度デバッグしてそのダンプファイルとかを社内のどこかに上げて解析を手伝ってあげたりとかをするわけですよ。

そういうことをやっていると、自分の担当のこと以外のところ、例えばカーネルモ―ドでおかしいとか、ネットワークのスタックがなんかおかしいとか、という自分の担当以外のレイヤーも見るし、自分でバグ報告をするようになるんですよね。そうすると、自分の担当のエリア以外のところも、なんか自分が多少は関わって貢献しているということを理解できるんですよね。

たまたまOSの開発だったからこういう機会に恵まれたのかもしれないんですが、なんかこういうことを組織としてしかけるだけでも、細分化されてその部分だけを任せられてる、任せてるという感じじゃないようなプロダクト開発の進め方ができるんじゃないのかなと思います。

ーーなるほど。

及川：あと大事なのはやはりあれですね。ビジョンをしっかりと語り続けることなんですよね。

それでもしある一定の領域しか見なかったとしても、そのビジョン実現のために「あなたの担当しているこの領域はこれだけ大事なんだ」と。ここを作り上げると、こっちの例えば別のコンポーネントと組み合わせることによって、これが可能になるんだというものをやはりしっかりと語っていくことが大事なんだと思います。

ーーそこにエンジニアも着いてくるというか、エンジニアもそこで「自分たちも」ということになるということですね。

及川：そうです。

（次回へつづく）