LT：ソフトウェアエンジニアはプロダクトの夢を見るか
及川：それでは、私から「ソフトウェアエンジニアはプロダクトの夢を見るか」というタイトルでお話できればと思います。
今日はエンジニアが、プロダクトの価値つまりはビジネスに対して、どの程度自分ゴトとして考えるべきかというお話をします。
セールスサポートエンジニアからエンジニアのキャリアがスタート
私はIT業界に入ったばかりの頃、外資系のコンピューターメーカーに勤めていました。入社当時は学生時代からプログラミングを行っており、情報処理技術者などの資格も取得していたため、非常に自信を持っていました。第二次AIブームもあったので、漠然とAIに携わることを希望していたのですが、配属はなぜかセールスサポートエンジニア。「プログラムは書かないのか」と少しがっかりしましたが、やってみるとこれがなかなか面白い。
ただ、その外資系のソフトウェアは、そのままではなかなか日本市場に受け入れられませんでした。当時はPCがオフィスにも導入されだしたところだったので、もっとPCとの連携を深めたらいいのではと考えて、より連携しやすいものを試しに作りました。それが非常に好評で、お客さん自身から「これそのまま納品してよ」と言っていただきました。そうした声が多かったため、その後製品化。それを機にソフトウェア開発部署の方に移るということがありました。この時は、ビジネス価値のような固いことは考えていませんでしたが、自分の作ったものがお客さんに「これ欲しい」と言われて喜ばれたことが非常にうれしかったのを覚えています。
その後、上司からあるソフトウェア開発しろと言われて、それが隣の部署で作ってると同じだったので、今思うと私の聞き方も悪かったし、それは自分で考えるべきだったと思いますが、若かったこともあって「これ何の意味があるんですか」「ただコード書くだけのことをやれって言うんですか」と言ってしまって。そして「そうだ」って返されて大喧嘩になりました。「お前なんかいらん」といった評価を受けてしまい、研究開発センターの方に移ることとなります。そこで一番最初にやったのが、JIS配列キーボードの開発です。ただ実際に蓋を開けてみると、日本語の処理体系がOSや製品によってバラバラだったため、そのアーキテクチャを全部考える仕事を任されました。
しかし、いろいろな部署から反発に遭ってうまくまとまらず、最後は上司がうまく引き取ってくれてまとめてくれました。この時なぜうまくいかなかったのか。技術的にどうあるべきかを考え各部署と話していたものの、日本語の処理体系をまとめたのちに、どんな方々がどんなケースで使うかをまったくできていなかったんです。簡単に言うと、ビジネスの妥当性を示せなかったわけです。なので、上層部の方に掛け合ったら「今会社も傾いてるのにこんなお金がどこにあるんだ」と言われてしまいました。
誰がどんなふうに使うのかをまったく考えずに作ってしまったのが大きな失敗でしたね。その後、会社が起死回生の一発を狙って開発していた高速のプロセッサーをに、そのとき成長が著しかったMicrosoftのWindowsを移植しようということになり、米国のMicrosoft本社に派遣されました。
Intelのプロセッサよりも大幅に速くて、これをお客さんに示すために展示会に出展しました。インテルのPCサーバーを載せた隣に我々のハードウェアを載せて、思いっきりパフォーマンスの違いを見せつけたんですね。
これもどちらかというと技術主導であまり褒められたものではないかもしれませんが、お客さんにはしっかり理解してもらえて、非常にうまく刺さったと考えています。
MicrosoftからGoogleに転職。ユーザーが求める製品を作る重要性に気づく。
その後いろいろな経緯がありまして、Microsoftに転職しWindowsの国際版の開発を行っていたのですが、イノベーションのレイヤーが変わったと感じてGoogleに転職。Googleでもさまざまな製品を担当しました。そんな折、IMEを作りたいという話がエンジニアから来ました。
Googleにはご存知の通り20%プロジェクトというものがあります。それを使ってプロジェクトをスタートさせた天才エンジニアがコアの部分を作り、そのうちにほかのエンジニアが何人も加わってきたと。
みんな「俺の考える最高のIME」を持ってきてくれて、すごいものが出来上がりました。ただ、果たしてこれはどんな風に使われるのかということが不明瞭だったんです。内輪受けしてはいるものの、外に出せるものではありませんでした。そこで、全員で「我々は一体何を作ってるんだろう」と考え、議論しました。
当時すでにあったTwitterでも、我々がIMEを作っていることが外部に漏れていたわけではないのに、GoogleIME待望論がツイートされていて。しかも一人二人というわけではなく、無視できないくらいの量でした。
このようなTwitterでの投稿を行う人が期待するものを推測して世に出したのが『Google日本語入力』です。
その後スタートアップを経て、起業。現在は中高生向けのプログラミング学習サービス『Jasmine Tea』を一生懸命作り、普及させようと努力しています。ブラウザ完結で、JavaScriptやPythonなどの本格的なプログラミング言語を学ぶ前の入門編のプログラミングを、アニメーションやゲーム制作などを通じて楽しく学べるサービスです。
このプロダクトも当初は、私たちが昔、ファミリーコンピューターにオプション製品としてあったファミリーベーシックを使ってプログラミングを学んだのと同じ環境をモダンに作り替えれば、昔の我々のように今の子どもたちも学ぶだろうと考えていました。ただ、そううまくはいかなかった。やっぱり、今の子どもと昔の子どもは当然違うんですよね。実際のユーザーをもっと知る必要があると感じ、今まさに、ユーザーと直に接してユーザーを深く知っている最中です。
エンジニア、PdMとしてプロダクトとどう向き合うべきか？
ここまで、いくつか私が関わったプロダクトにおける失敗例や成功例を共有してきました。ポイントは、ユーザーを知りユーザーに使ってもらうために、エンジニアやPdMとして、どう関わるべきかというところです。
そしてもっと大事なのが、プロダクトに対して自分ゴトとして向き合うことじゃないかと思います。堅苦しく聞こえるかもしれませんが、実はすごくシンプル。自分が作ったものによってユーザーに喜んでもらう体験をして、その体験をしたらチームメンバーにそれを伝播させていくだけです。
たとえば、先ほど『Google日本語入力』の話をしました。そのとき私は同時に『Chrome』も担当していたのですが、『Chrome』にしても『Google日本語入力』にしても、Windowsに標準として入っていた『MS-IME』や『Internet Explorer』からシェアを奪うことは難しかったんです。でも、少しずつユーザーが増え、展示会で目にするデモ画面で『Chrome』が使われていたり、電車で隣に座った人が仕事し始めた時に、『Chrome』と『Google日本語入力』を使っているのが目に入ったり。こうした瞬間はやはり、とてもうれしいんですね。
こうして、自分ゴトとして関わったものにより、ユーザーが良い体験をしているのを目の当たりにするのは大切だと思います。
昔、Windowsには、特定の画面で特定のキーを打つと、映画のエンドロールのように開発者の名前がすべて出てくる隠し機能がありました。もしこのように、自分が関わったプロダクトに自分の名前が入ると考えたら、みなさんも「このプロダクトを最高のものにしたい」と考えるでしょう。この気持ちこそが一番大事です。
収益とユーザーの満足度を同時に実現すること
プロダクトマネジメント的に硬いことを言うと、当然プロダクトは事業なので、お金を稼がないといけませんし、収益を最大化させることは必要です。そして現在はサブスクリプション的なビジネスモデルが多いので、お客さんに使い続けてもらわないと、継続的な収益は上げられません。収益とユーザーの満足を同時に実現することが求められます。これはトレードオフではなく、両立させるべきものです。
さらにそれと共に、プロダクトが作り上げたい世界観の実現を目指す。これをすべて達成するべく、自分たちのプロダクトでどんな社会を作るかを考えることが、プロダクトの成功につながっていきます。これはPdMがしっかりと形作っていくものですが、ぜひともエンジニアもそのなかに加わっていただきたいです。
私も趣味の域になってはしまいましたが、いまだにコードを書いています。やっぱり動いたら楽しくて。コンピューターというひとつの世界を制覇したかのような、全能感に溢れます。でも、その楽しさを味わうだけではなくて、今日話してきたようなプロダクト作りにも目を向けてもらいたい。自分が作ったものが思い通りに動く楽しさだけでなく、その先にあるお客さんの課題が解決されている姿にも目を向けることで、仕事がよりやりがいのあるものになると思います。
エディターや管理画面のコードひとつひとつの間にユーザーを見て、どんなアーキテクチャにすべきか、どんな設計にすべきか、このコードは意味があるのか、こうした議論をプロダクト担当者と行いつつ、本当にいいものを作っていく。そしてそのプロダクトが使われた時の喜びを皆さんに味わっていただけるとうれしいなと思いながら、今回のLTはお話しいたしました。以上です。
「ビジネス視点はどこまで必要か、またいかにして身につけるか」
大谷：ありがとうございました。改めて意識しなければならないポイントが多く、聞き入ってしまいました。では続いて、ディスカッションに移ります。
早速ひとつ目のテーマです。「ビジネス視点はどこまで必要か。売り上げを一緒に追いかけるべきか」。また「ビジネス視点を持つためには具体的に何が必要か」についてお話していきます。
先ほど「エンジニアもユーザーファーストでプロダクト貢献をしてビジネス価値を生み出すことが必要だ」とお話いただきましたが、そのためにビジネス価値を生み出すためにどこまでビジネス視点が必要になるか、及川さんの考えをお聞かせいただけますか。
及川：まず前提として、私はお金の話が基本的に嫌いでした。そもそも「お金の話をするのは汚い」といった教育をされてきたし、お金を儲ける営業の仕事もすごく難しいし。エンジニアは営業的な仕事が苦手な人が多いこともあって、同じような気持ちの方もいるかもしれませんね。「嫌いでした」と言いましたが、今でもそういうところがあります。
それを踏まえて考えると、「いきなりビジネス視点で考えようとしない」のもひとつの方法だと思います。まず、ユーザーファーストで考えるところからはじめてみるといいですね。プロダクトを成功させるために事業収益と同時に大事なのが、ユーザーが感じる価値を高めることなので、エンジニアはまず後者を考えるところからスタートしましょう。
そしてそのもっと先の、顧客への提供価値をあげることと収益との因果関係を持たせられるかどうかになると、ビジネスモデルの話になってきます。こちらは基本的にはPdMの担当領域ですね。は、これはもう、プロダクト収益事業として見たときのビジネスモデルの話になります。
たとえば、ある機能に対するユーザから評判が良かったとしても、その機能を動かすためのAWSのコストが非常に大きいとします。すると、コストをペイすることだけ考えてもその機能を課金ポイントにするべきと考えられます。こうしたことを考えてみたり、今携わっているプロダクトは顧客が価値を感じている部分をきちんと収益に反映できているのかを聞いてみたりしつつ、理解を深めていくのがいいのではないでしょうか。
最後にもう少しベタなビジネス視点でいうと、会社が儲かるともちろん、みなさんの給料やボーナスに反映されるので、これはこれでもっと追い求めていいと思います。と同時に、実は収益を上げると個人や会社が潤うだけでなく、そこで得た収益もまた、ユーザーに還元されていきます。
プロダクトが進化するためには、デザイナーがデザインをしたり、エンジニアがコードを書いたりしなくてはならないし、インフラリソースへの追加投資が必要になることもあります。そのためのお金、原資を用意するためにも、儲けないといけない。そして儲かったら、プロダクトをよりよくして、お客さんにもハッピーになってもらう。そしてさらにプロダクトを使っていただき、収益を上げる。このサイクルを回すことを考えてもらえるといいのかなと思います。長くなりましたが以上です。
大谷：ありがとうございます。私もそうですが、エンジニアは会社におけるお金のやり取りに触れる時間は少ないので、最初はユーザーに提供する機能から考えていく、そしてそれをビジネスに結びつける考え方を次に取り入れるというのは、非常に共感して聞いていました。ちなみにこうした考え方ができているエンジニアって、今まで周囲にいらっしゃいましたか？
及川：外資系だと多かったですね。これは今日の話にふさわしいかわからないんですが、人間のそのモチベーションって内発的動機づけと外発的動機づけがありますよね。内発的動機づけというのは、心の底からやりたいこと、たとえば「韓国映画が好きで字幕なしで見たいから韓国を勉強します」といったものです。
対する外発的動機づけは、昇進や昇格などのために頑張ることです。「ユーザーの喜ぶ姿を見たい」というのは内発的動機づけですね。内発的動機づけの方が大事ではありますが、外発的動機付けも同じく大事なわけです。
私がいた外資系企業は社員が株を持っていて、企業の収益が社員にダイレクトに還元される仕組みでした。そのため、簡単に言うと株主として「株価を上げるためにはどうすればいいか」と考えながら多くの人が働いていました。
「金に汚い」と思われることを覚悟でわかりやすく言うと、よくわかんない仕事を頼まれた時にも「これやって株価上がるんだろうか」とどこかで考えるようになるわけです。
株価が上がることはつまり儲かること。ひいては、ユーザーに喜んでもらうことです。さっきと逆方向の考え方ですが、考えることは同じですね。なので、自分の生活に直結した欲望から連動させるのも、悪いことではないとわたしも思います。
「株価を上げることを考える」のは、「経営者視点で考えること」とまったく同じです。だからこそ日本の企業の多くも、社員に生株を渡したりストックオプションを出したりしているのではないでしょうか。
大谷：そうですね。たしかに外発的動機づけがあるとビジネスをどう捉えるかの意識も変わってくるし、それが習慣にも落ちるような気がします。ありがとうございます。
「ユーザー体験と売上のどっちを優先させるべき？」
大谷：では2番目のテーマに移っていきます。続いてのテーマは、「ユーザーにとって必要なものと売上に直結するものが異なる場合、どちらを優先するべきだと考えますか」です。
今の及川さんであれば、どのようなスタンスを取って、どちらを優先されますか？
及川：教科書的な回答をすると、これは両立するんですよ。先ほどお話したように、ユーザーにとって必要なものを提供すると売上も上がるのが理想的な状態です。
当然プロダクトやビジネスモデルによりますが、SaaSサブスクリプション的な、かつ適切なビジネスモデルでユーザーが使えば使うほど収益が上がるような形になっていれば、ユーザーの利益と売上は基本的には両立します。
にもかかわらずこうした議論が出る場合はおそらく、ビジネスモデルが適切に設定されていないか、もしくはユーザー体験をよくすることが利益に直結するとのコンセンサスが取れていないかのどちらかではないかなと思います。
会社の中では、UX的な文脈でこうした議論になることが多いですよね。
たとえば開発サイドがユーザーからのフィードバックを受けて、「このデザインをこう変えたいので、3ヶ月かけてそれをさせてください」って言うと、ビジネスサイドは「それやっていくら儲かるんですか？それよりももっとわかりやすいこれをしてください」といった形で対立すると。
これは、UXを良くすると売上が上がるという因果関係が証明できていないので発生してしまう衝突です。こうならないためには、UXと売上に関するデータをしっかりと取得し、そのデータを基にしたデータドリブンな意思決定ができる仕組みを作ればいいのではないかと思います。
大谷：ありがとうございます。売上に対する蓋然性があれば話はスムーズに進むと思います。一方、なかなかそこがつながらなかったり、急遽「これが必要だから作ってくれ」と頼まれたり、こうした開発サイドとビジネスサイドの認識のギャップをどう調整したらいいのかについてもお聞きしたいです。
及川：こうした衝突が起きる場合は、たいていそれぞれにその事情や背景があります。
さきほどの例で言うと、私は教科書的な回答をしましたが、UX改善して売り上げに影響を与えるまでに多少のラグが発生することも当然あります。でもスタートアップなどの場合、待っていられないこともあるでしょう。たとえば銀行残高があと3ヶ月で枯渇してしまうので、次の資金調達をやるために投資家回りをしている。彼らに次の資金調達を理解してもらうためには、今持っている仮説を機能として形にし、かつ顧客が付き始めてるところを見せない限りは投資してくれないわけです。この場合、とりあえずその機能を作って、営業が売れる状態にしない限りは、自分たちが作りたい理想のプロダクトに行く前に会社自身がなくなってしまうかもしれません。
これはすごい極端な例ですが、こういう事情はいくらでもあります。大企業なら大企業で、社内の他の部署からの意見も聞く耳を持ってるとアピールしないといけないかもしれません。一見理不尽に思えるものであっても、そうなる理由は必ずあります。そこはやはり、それを踏まえてプロダクトやプロダクトチームが継続していくためには何が必要かを考えなくてはなりません。
簡単に言うと、売り上げに直結するものが必要だと言われた場合、その背景が何なのかを汲み取って議論していくのがいいのではないかと思います。
大谷：ありがとうございます。
「プロダクトづくりにおける優先順位付け」
大谷：続いてまた次のテーマに移っていければと思います。プロダクトを作る上で、いかに優先順位をつけていくべきなのかについてお聞かせいただけますか。
及川：優先順位に関しては、いくつかスタンダードな考え方があります。たとえば「ライススコア」と呼ばれるRICEのアルファベットから始まるインパクトやコストなどを見積もっていくものですね。こうしたものを調べていただくのも参考になると思います。
もうひとつ私が推奨しているのは、プロダクトや事業の指標をしっかりと持つことです。いわゆるKGIやKPIですね。最近は収益売上をトップKPIとするのではなく北極星指標（ノーススターメトリック）と呼ばれる指標を用いることが多い印象です。これは売上と顧客価値、ビジョンに結びつけるための先行指標として決めるものです。
こうしたトップKPIと、それを支える先行指標が連鎖する形で構成されてKPIツリーと呼ばれるものができます。すると、たとえばある機能要望があったとしても、それはツリーの中のどこを上げるものなのかすぐにわかるようになります。
おそらく期間ごとにテーマを持って開発を進めてるはずだと思うんですね。それに関係するKPIを作って、そのKPを上げるための施策があり、それが一つひとつの機能になっていくわけです。わかりやすいところで言うと、リテンションレートを上げなくてはいけない ときに、新規顧客開拓キャンペーンのための機能実装を依頼されたとしても、それやっても仕方ないじゃないですか。
プロダクト部署としては、今何をテーマに進めていて、今を何やるべきなのかを明確にしていくことが大切です。
もうひとつ、機能のなかには、すぐに効果が現れてこないタイプのものもあると思います。ただ、だからといって機能をリリースしたのちにそれはもう気にかけなくていいかと言うと違います。一定期間モニタリングし、仮説通りにその機能がユーザーに使われてるかを確認したり、必要に応じて改善しなくてはなりません。実装し、モニタリング、改善までがひとつのサイクルです。この点もテーマと紐づけて考えていくとよいですね。
大谷：ありがとうございました。興味深いお話でした。
「品質とスピードのバランスはどう考えるべきか」
大谷：時間も差し迫ってきたので、再び次のテーマに移れればと思います。
指標をもとに優先順位をつけた上で、実際の開発において、スピードと機能の品質のバランスをいかに取っていくべきか。及川さんの考えとかはいかがでしょうか。
及川：ソフトウェアエンジニアとしてのスピードや品質の話に関しては、私も親しくさせていただいてるt_wadaさんの講演が有名ですからぜひそちらを見ていただきたいです。
私から別の観点でお話すると、品質はユーザーの期待のちょっと上をいってれば十分なんです。たとえばスタートアップが3ヶ月間である程度成果を出し、次の資金調達するような時に、 必要な機能も品質も、その後10年間生き残るためのものとは異なるわけです。
もちろん汚いコードを書いていいわけではないものの、そのフェーズで必要十分な機能品質は確実にあると思うので、ユーザーの期待のちょっと上のところを狙っていくことを常に行っていくべきだと考えます。
とはいえ、直せる部分と直せない部分があるので、基本的なデータスキームなど最初からしっかり作るべきものと、後から改修可能なものを判断していくべきですね。
一般的にはスピードと品質は両立しうるもの、もしくは両立させるべきものだと思います。しかし一方で、「品質とは何を指しているか」をビジネスサイドと開発サイドがしっかりと考えていくことが必要です。かつ、当然事業のフェーズによってはスピードが重視されることもあるので、それもビジネスサイドのことを理解した上で、エンジニアとして最善の解を出していっていただきたいです。
大谷：ありがとうございます。
「ビジネスサイドとのコミュニケーションはPdMに任せるべきか否か」
大谷：最後にお伺いできればと思いますが、エンジニアがビジネスサイドと調整する時間や改めてコミュニケーションを取っていく場合、やはり多少時間かかってしまいます。ここはすべてリーダーやPdMに任せるべきなのか、それともエンジニア自身もビジネスサイドとコミュニケーションをするべきなのでしょうか。
及川：私は任せていいと思います。特にPdMはそのための人です。もちろんエンジニア自身が入った方が効率的なこともあるし、入りたいなら入っても構いませんが、基本的にはPdMに任せた方がいいと思います。
私の本にも書いてるんですが、UX、テクノロジー、ビジネスの三つの円を書いたときに、交差領域の部分に対して意思決定をすることがPdMの役割です。そのなかには当然ステークホルダーマネジメントもあります。特にビジネスサイドは開発サイドとは距離が遠いこともあり、別の言語が必要だったり、知るべきナレッジもあったりするので、基本はPdMに任せていいと思います。
大谷：ありがとうございました。以上でディスカッションは終了となります。
