「チームで価値を届け続ける」のはけっこう難しい
鈴木健太氏：次に、チームで価値を届け続けるにはどうしたらいいか？ 「共に信頼し、共に創る」にはどうしたらいいか？ そういう話をしていこうと思います。
ここからが本題かなと思っているんですけれども。チームについて考える時に、2つ観点があると思っています。
「いいチームを選ぶ」。そこにあるいいチームを選ぶという観点と、「そこにあるチームをいいチームにする」。自分が入ったチームをいいチームにするという観点があると思っています。いいチームを選ぶという観点もいいですが、みなさんにはいいチームにするという、より難しいところにぜひチャレンジしてほしいなと思って、今日はこの話をしていきます。
その上で、どういうチームで働きたいか。どういうチームだったらエンジニアリングが活きるのかということにちょっと向き合う時間にしてもらえればなと思っています。
この中にもきっと、チーム開発したことがあったり、学校での実験だとか、あるいはハッカソンでチームで作ったことがあるという人もいるんじゃないかなと思います。その上で、じゃあ、どういうチームが価値を届け続けられるのかについて、ぜひ一緒に見ていきましょう。
「チームで価値を届け続けるには」。これにはいろいろな難しさがあります。コンテキストとしては、自社で開発したプロダクトをどう続けていくかという話を念頭に置いていきます。
ざっくり言うと、やはり使ってもらう必要があり、それなりに儲かっている必要があります。その上で開発もいい感じである必要があります。この三拍子が揃わないとやはり続けられないんですよね。
先ほど、スタートアップを作った時のお話をしましたが、やはり使ってもらわないと、そもそも儲けることもできないし、いくら良いソフトウェアを作ったと自分たちが思っていたとしても続けられないんですよね。方針を転換して変えていかなきゃいけない。難しさがあります。
機能追加が遅い・対応が遅い・競合がすばらしい…うまくいかない事業はたくさんある
CARTA HOLDINGSでは、今までもすごくたくさんの事業をやってきました。最初にも挙げましたが、100以上の事業をやっています。サポーターズもそうだし、僕がやっていたfluctもそうです。今はもうない事業もたくさんありますが、そういうものなんですよね。
たくさんトライして、時代に合わせて事業やプロダクトがどんどん変わっていく。そういうことにトライし続けています。
うまくいかない事業はたくさんあります。先ほど言ったとおり、やはりユーザーがつかないという時ですよね。なぜなのかを深堀っていくと、そもそも必要とされていないよねというケースもあります。
あと、機能追加が遅い。これはエンジニアとしては耳が痛いですよね。なぜか追加できなくなっていく。
ほかには、対応が遅い。サービス側に、「こういうのに対応できるようにしてよ」と言ってもなかなか変えてくれない。そうするとユーザーは離れていっちゃう。
あと、競合がすばらしい。もっといいサービスが世の中に出てきて使われなくなる。これもやはりあります。
でも、やってみないとわからない。事業って考えて考えて、これでいこうとみんなで合意する。合っていると思っていてもやらないとわからないから、そういうところまで考えて詰めてやってみた。でもその結果、失敗したことがある。それはいい学びなんじゃないかなと思っています。なので、経験が蓄積されると成功確度が上がるはずだと僕らはずっとそう思ってやっています。
大事な観点の1つは「たくさん使われるコードを書く」こと
このセクションでは、「チームで価値を届け続けるには」という観点で話をしていますが、みなさんがこれからエンジニアとしてソフトウェアを作っていく上で、すごく大事な観点の1つは、やはり「たくさん使われるコードを書く」ということです。
至極当たり前の話かもしれませんが、やはり使われないコードは、メンテナンスする必要性がなくなっていくんですよね。僕がfluctで作っていた時だと、広告が1日に何億回も何十億回も出るので、自分の書いたコードが1日数億回使われるんですよ。
そういうものだと、当然お金も順繰り順繰り回って、「じゃあ、次はこういう機能を追加しよう」とか「こういう機能追加をするための改善を事前にしておこう」とか、ソフトウェアの質やチームの学びに対する投資をする余裕が出てくるんですよね。
逆に、利用されなくなるというのはすごく怖いことで、利用されなくなった瞬間に、機能を追加するメリットがどんどんなくなっていく可能性があるんですよね。もちろん新しくトライして機能を追加して、宣伝をして、どんどん使えるようになるかもしれませんが、基本的には、使われないというのは、非常に危ない傾向です。
だからこそ、これからソフトウェアを書く時にみなさんにぜひ意識してほしいのは、「使われるコードを書く」こと。これはすごく大事なことですね。事業をエンジニアリングしていく中で、いかに使われるものを書くかというのが、ポイントかなと思っています。
“ソフトウェアエンジニアリングの難しさ”がチームで価値を届け続ける難しさを生んでいる
『Googleのソフトウェアエンジニアリング』という本があって、その中に、ソフトウェアエンジニアリングとプログラミングの違いという話が出てきます。
みなさんに今日の最初にツールの話を挙げてもらいましたが、僕が先ほど例に挙げた三角数の話というのは、まさにプログラミングなんですよね。正解があって、答えがあって、課題を提出したら基本的に終わり。その場限りでしか使われないもの。それがプログラミングをするということ。これはすごく基礎として大事です。
ですが、ソフトウェアエンジニアリングはどういうことかというと、この本の表現を借りると、時間、スケール、そして作用しているトレードオフ。このトレードオフがあるということなんです。そしてこれがソフトウェアエンジニアリングをすごく難しくしている要素なんですね。
どういうことかというと、例えば1人で作っていたらそんなに気にしないかもしれませんが、10人、100人でソースコードを書こうとしたら、1個のソースコード、同じ機能を触ろうとした時に、たぶんすごくコンフリクトしますよね。
かつ、1つの機能を使う人がすごくたくさんいる。たくさんのデベロッパーもいるし、たくさんのエンドユーザーもいるという状況になります。
そうすると、「じゃあ、この機能を変更しよう」という時に、いろいろなものを確認しなきゃいけなくなる。でも、この機能を追加しないとサービスが伸びない。そういう状況がソフトウェアの世界にはやってきます。
僕たちソフトウェアエンジニアは、その難しさとユーザー提供の価値、あるいは、将来どう役立つか。3年後、自分の書いたコードがどんな価値を生み出すか。そういうことを天秤にかけながら、すごく複雑な意思決定をしないといけません。これが、ソフトウェアエンジニアリングの難しさだと書かれています。
これがやはり、事業あるいはチームで価値を届け続ける中の難しさを生んでいるということですね。
作り始めるまで“すばらしいアイデア”は“アイデア”にすぎない
とはいえ、事業をやらないと始まらないですよね。1つ質問です。みなさん、チームで価値を生み出し続けようと思った時に、これから当たるプロダクトのアイデアがなにか思いつきますか？
自分たちがソフトウェアを書き続けられるようにするには、やはりある程度ビジネスである必要がある。その上で、何を作ろうかというのはすごく難しい問題ですよね。
いろいろ思いつくかもしれない。けどね、やはりアイデアだけでは価値がない。これは、みなさん作る人たちだから同じ感覚を持っているかもしれませんが、やはりアイデアって単体ではそんなに価値が大きくはないと思っています。「結局そんなに儲からないでしょう」ってこの本の中では書かれているのですが、作り始めるまですばらしいアイデアはアイデアにすぎなくて、やはり作り始めないといけないと。
これは、Railsを基に作った、37signals、今はBasecampという会社が出している本ですが、そういうフレーズが書いてあります。
なので、みんなが持っている「作る」というスキルは非常に大事だし、実際にアイデアを具現化するというのが、やはり僕たちエンジニアの仕事の役割だと思っています。
アイデアがあるとしてどうプロダクトにするか？
じゃあ、実際にどうやってプロダクトにするか。ここに非常に難しさがあります。
思考実験です。アイデアがあるとして、どうプロダクトにしようか？ ちょっと一緒に考えてみましょう。
僕が思いついた、「ラーメン配送アプリ」というすごくいいアイデアがあります。日本初、お店で食べるクオリティのラーメンがアプリで注文できます。これ、「なんとかEATS」みたいな感じですよね。作れそうですか？ というのがまず1つ。あと、きちんと儲けられるかなという観点があります。
これを作ろうとすると、いろいろな疑問が湧いてきますよね。例えば、作って、そもそもどうやって売るんだっけというのもそうだし。というかそもそも、「ラーメンの調達はどうするんだ？」みたいな。「提携するんだっけ？」とか、「そもそもこれ、使われるのかな？」みたいな話です。「いったん知り合いにこのアイデアをインタビューしたほうがいいんじゃないの？」とか。「（ユーザーは）使ってくれる？」とかね。
あと、「ラーメンを選ぶっていっても、みんなが買いたくなるラーメンってどうやって選んだらいいんだろう？」「UIどうする？」とかもあります。
あと、実際の配送ですよね。ラーメンの出前を取ったことがある人はわかると思いますが、こぼれるし、ラーメンのどんぶりを運ぶのってけっこう大変なんですよね。「じゃあ、パックにするか？」とか。でも、お店で食べられるクオリティのラーメンって、ラーメンどんぶりが必要なんじゃないのとか「そもそもコストがかかるからどうしよう」とか。
僕は今渋谷にいるのですが、お店で食べられるクオリティのラーメンを800円で買って、アプリで1000円で売る。
そうすると、200円マージンがあるけれど、そのうちの100円を配送料で払ったら、1杯100円の利益になりますよね。1杯100円の利益といっても、年間1人の人を雇うので1,000万円かかる。年間何回ラーメンを売ればいいんだという話ですよね。人件費だけでとんとんになっちゃうんじゃないかとかね。というふうに、皮算用ができます。
プロダクトとは何か？事業とは何か？
「そもそも、これは儲かるんだっけ？」というのは、やはり作る中ですごく大事な天秤です。
「ラーメンだけじゃなくていいんじゃないの？」となって、結局Uber Eatsが競合だ、みたいな話になりますけど。そういうふうに、やろうと思えば思うほど、考えることがすごくたくさん出てくるんですよ。
プロダクトを作る上で、この中に書いてあるソフトウェアの要素って、実はけっこう少なかったりするんですよね。「プロダクトっていうのは何か？」というのは、あるいは、「事業とは？」という話なんです。狭義のプロダクト、つまりソフトウェアそのものという話だけではなく、やはり広い範囲でプロダクトというものをうまく活かせる必要があります。
なので、ソフトウェアを作る僕らエンジニアチームだけではなく、やはり営業、PR、カスタマーサポート、マーケティングなどのメンバーと一緒に、このプロダクトをどういうふうに成功させるかというのを日々アップデートすることが必要になってきます。
プロダクトというのは、このプロジェクトの繰り返しと言われていて、どんどんどんどん、「いや、これはこうしたから、次はこういうトライをしてみよう」「次は、ラーメン配送アプリをやって。じゃあ、そうめんも配送するか」とか。あるいはもしかしたら、「いや、自前でキッチンを作ってそこで調理しよう」とか。
もしかしたら、「冷凍めんを持ってきて、その時間を計測して、すぐ機械的に配送できるようにしよう」というプロジェクトがあるかもしれない。そういうプロジェクトを繰り返しながらアップデートしていく。それがプロダクトなんですね。
これがすごく難しい。難しいけれど、やはり事業を続けていく中で、使い続けてもらうためには必要なことなんですね。これをプロダクトマネジメントと言ったりします。
環境の変化により市場が生まれチャンスが広がる
「チームで価値を届け続けるために」という話でいくと、ざっと10年ぐらいを振り返ってみても、すごくいろいろな変化がありました。僕自身、fluctのサービスは10年弱やっていたのですが、やはり10年という単位だとデバイスが変わりますよね。
僕のスマートフォン、iPhoneは、今「13 Pro」ですが、10年前だと、当然カメラなんて1個しか付いていなかったし、セルフィーがギリギリあったくらいだと思います。あと、回線速度にもLTEがなかった。開発環境でいうと、DockerもないしVSCodeもないしAWS Lambdaもなかったんですよね。
内的な環境、僕らが使っているツールもそうだし、外のデバイスも、すごく多くのものがどんどん変わっていくんですね。
例えば開発ツールの話だとわかりやすいですね。ほかのサービス、ほかのアプリケーションは、やはり新しいもので開発スピードを上げていくという方向にどんどんどんどんシフトしていきます。これは、市場がそうだからです。ですが、同じやり方をしていると、やはりどんどんどんどん自分たちだけ機能追加が遅れていくというのも起きる可能性がある。
一方、チャンスもあります。回線が太くなったから、「もうちょっと動画広告を使おうよ」とか「動画を使おうよ」とか、そういう新しい表現方法が出てきて、サービスとしてのアピールの仕方が変わってくる。そういうこともパラダイムの変化として起きてきます。
実際に僕自身が経験した事例だと、先ほど動画の話をしましたが、動画はまさにインパクトがあります。YouTubeとかPCで（動画）を観る人は、10年前もそれなりにいましたが、スマホで見始めた人が増えたのは、やはりここ5年や6年だと思います。
僕自身は広告事業をずっとやっていたのですが、それによってこの10年で動画による広告がメチャクチャ広がったんですよね。
もともと画像だけだったのに、広告というものの表現手段が増えていて、それを出したい人も増えている。そうすると、そこに市場が生まれて、チャンスが広がる。
けれど、自分たちが抱えているプロダクトの中には、動画配信の機能はなくて、じゃあ、それをどういうふうに新しく付けていくかみたいな、大きいアップデートが事業を続けていくとやはりあるんですね。チームの中で価値を届け続けるためには、組み込むことが必要になります。
（次回へつづく）
