Webのトレンドやユーザーのニーズが目まぐるしく移り変わる中で、長年愛されるWebプロダクトをつくり続けてきた開発チームは何が違うのか。そして彼らは「技術的負債」にどう向き合い、課題解決に取り組んでいるのだろう。

2022年6月21日（火）～25日（土）の5日間にわたり、エンジニアtypeが主催したオンラインカンテックファレンス『ENGINEERキャリアデザインウィーク2022』（ECDW2022）の2日目には、2000年前後から業界トップを走り続けるWebプロダクトを展開するヤフー、サイバーエージェント、クックパッドの技術トップ3名が登壇。

各社が今までの経験から学んできた、技術的負債を残さない開発を実現するためのヒントを惜しみなく紹介してもらった。

ヤフー株式会社　取締役 常務執行役員 CTO　小久保 雅彦さん

銀行ネットワークやインターネットプロバイダーでの開発・運用を経験後、2004年にヤフー入社。ポイント、カード、公金決済システムのほか、法人向け課金プラットフォーム、IDプラットフォームなど主に決済・ID系の開発業務に携わる。18年にはコマースCTOに就任、その後執行役員の兼任を経て、22年4月より現職

株式会社サイバーエージェント　 常務執行役員 技術担当　長瀬慶重さん

大学卒業後、通信業界での研究開発を経て、2005年サイバーエージェントへ入社。『アメーバブログ』や『アメーバピグ』、『ABEMA』などのサービス開発を担当し、18年より現職。「技術のサイバーエージェント」を加速すべく、技術政策に注力している

クックパッド株式会社　執行役CTO　成田一生さん

大学院を修了後、2008年にヤフー入社。Yahoo!メールのバックエンド開発に従事する。 10年にクックパッドに入社。サーバサイドのパフォーマンス改善や画像配信を担当後、インフラストラクチャー部部長や技術本部長などを務める。現在は、執行役CTOとしてエンジニア組織全体を率いている

Webサービスが「長年愛され続ける」ことの難しさ

——今回ご登壇いただいた3社は、15年以上続く「長寿のWebサービス」を運営されています。競争の激しいWebの世界で、長年愛されるプロダクトに育てるために必要なことは何でしょうか。

小久保：ヤフーは1996年に提供開始したWebサービスで、 もともとはインターネット検索の黎明期に開発されたディレクトリ方式の検索エンジンです。

その後会社としては、メディア・検索領域から注力領域を少しずつ広げ、ショッピングやオークションなどのコマース領域へ。最近では決済や金融など幅広いサービスを展開しています。

個人的には、この手広さこそがヤフーが長く愛されてきた秘訣かな、と考えます。

一つの有名なサービスに特化するのではなく、手広くやることで「ヤフーにアクセスすれば何かしら見つかるよね」とユーザーの皆さまに立ち寄ってもらい、そうしているうちにどれかのサービスに愛着を抱いていただく。そんなふうに成長してきたのがヤフーなのです。

長瀬：サイバーエージェントは1998年に設立され、僕が入社したのは2005年。そして、この17年間で僕が関わったサービスやプロダクトは、広告、ブログ、ABEMAなどを含めて100個を超えています。

この手広さが当社の強みではあるのですが、一方でクローズしたサービスも多々あります。やはり、ネット業界では長寿サービスを作ることがものすごく難しいんですよね。

そのような身ですので、「いかにして長寿サービスを作るか？」への明確な答えは持ち合わせていないのですが……一つ考えられるとすれば、「作り手が情熱を持ってサービス開発に取り組めるかどうか」でしょうか。

当社では各プロダクトの企画段階からエンジニアにジョインしてもらい、愛着を持てる開発体制を敷いています。この「愛着」や「情熱」はかなり重要なキーワードだと考えています。

成田：クックパッドの場合は、toCの投稿型レシピサービスであるところが「長寿」につながっている大きな理由だと思います。

世の中にレシピサービスは数あれど、多くはメディア型で、企業が用意したレシピをサイトに掲載する形です。つまり、サービスを成立させる主体が企業なんですね。

一方でクックパッドは、主体がユーザーです。レシピやつくれぽを投稿している日本中、世界中のユーザーがクックパッドを作り続けている。

ユーザーの方がクックパッドをよく知っているので、運営が場を仕切ろうとすると、「そういった仕様変更はしないでほしい」とか言われることもあるんです（笑）

あくまでもユーザーが主体であることを認識し「ユーザーがより料理を楽しめるような場づくりをすべし」という思想が社内で引き継がれていること。これが、長年愛されるサービスに成長してくれた秘訣ではと考えています。

技術的負債の解消には「可視化」と「返済する時期を決める」ことが不可欠

——長くWebサービスを運営していると、どうしても「技術的負債」と呼ばれるボトルネックが出てきてしまいます。皆さんは、いつどのような課題に直面したのか、そしてどう向き合ったのか。ぜひ教えてください。

小久保：「負債」が生まれてしまう主な原因は、技術的なブラッシュアップとリリース日のせめぎ合いが起きるためです。つまり、技術的にもっと良いものにしたいという気持ちと、サービスをいつまでにリリースしなければ、という事情の衝突ですね。そこで「リリース優先」を選択してしまうと、後の「負債」を産むことになりやすいです。

成田：どちらを優先するのも正解ですから、難しい判断ですよね。

小久保：ええ。ただこうした負債はいつまでも放置するわけにはいきませんので、ヤフーでは2017年に「大幅にコストを掛けてでも、技術的負債を返済しよう」 という全社プロジェクトを立ち上げました。

負債返済には5年ほどの期間をかけることになりましたし、技術的にはもちろん、返済のためのコスト確保については社内ネゴシエーションの面でもそれなりに苦労しましたね。

長瀬：「技術的負債」という概念を事業サイドやビジネスサイドに理解してもらうことは、かなり苦労しますよね。

小久保：エンジニアならピンとくる話でも、ビジネスサイドには分かりづらい概念ですからね。

僕の場合、技術的負債は「iPhoneのOSバージョンアップ」に例えることが多いです。「皆さんも、定期的にOSをバージョンアップしていくと思います。そんなふうにしていかないと、システムも陳腐化していくんですよ」と。

例え話も交えながら分かりやすい説明を重ね、一定の理解を得ることができました。

最近では、負債の一括返済後もある程度のコストをかけて負債を産まない・負債を抑え込むことの大事さについて、コンセンサスが得られた状態になってきましたね。

長瀬：ビジネスサイドへの説得材料という観点では、「生産性の低下」も強力なエビデンスですよね。

僕自身が技術的負債を一番感じるのは、新規機能やサービスのリリースがどんどん遅くなっていく時です。負債が溜まっていると、もう分かりやすいぐらい開発スピードが遅くなっていったり、不具合が続いたりする。

そしてこの状態を放置していると、他の開発にもどんどん時間がかかるようになっていくんですよね。そういった負債を放置したり見逃したりしないように、一つの機能開発にどのくらい時間がかかっているのか、普段から可視化して注意深くウオッチするようにしています。

ただし、この時に注意したいのが「開発エンジニアの感情」を無視しないことです。

そもそも、エンジニア自身は好き好んで開発スピードを落としているわけではないんですよ。だから、前置きなしに開発スピードが遅いことを可視化されるとすごくプライドが傷つく。

こうしたミスコミュニケーションは本意ではないので、エンジニアには日頃から、「負債は決して悪いことではなくて『解決すべき、面白い課題』とポジティブにとらえていい。そしてその時々で、必要に応じて返済しながら開発に取り組んでいこう」と伝えています。

小久保：面白いですね。エンジニアと「負債」に対するコミュニケーション。

成田：負債は悪いことではない、という考えにも共感できます。

長瀬：これも時と場合によるので、難しいですけれどね。たまには「負債ができてもしょうがない」と割り切り、ビジネスに注力するフェーズだと納得してもらう時期もあるでしょうし。

例えば、『ABEMA』では、今年11月〜12月に「FIFA ワールドカップ カタール 2022」の予選を含む全64試合を無料生中継する予定です。現在はそこに向けて、かなりの開発ボリュームを11月までにやりきらなければいけない状態。

こういったビジネスチャンスがある時は、技術的なことはいったん脇へ置き、「リリース日を守ることに全振り」するのも合理的な判断だと思うんですよ。

ですからエンジニアのメンバーには、「今回はある程度負債を貯め込んでもいいから、スピード勝負でがんばろう！」と声をかけています。

もちろんいずれは、負債の返済期間を設ける予定ですが、そういう仕事の進め方も時には必要だと理解してもらうことは必要かもしれませんね。

成田：僕の経験から話すと「返済する時期」を決めるのは本当に大切です。サービスを維持するためには、時には「機能を消す」のも大事なんですよね。

ずっと存在しているが使われているかどうか分からない機能の積み重ねで開発速度が落ちているので、それを維持するのでなく消していくということを意識してやっています。

消していく速度と生み出していく速度が釣り合わないとサービスが膨らんでいってしまいますから。

例えば、クックパッドのレシピサービスが動き出したのは2008年。そこから10年以上が経って、当時の開発意図が良く分からなかったり、スピード勝負で開発したりした結果、部分的に不完全なプロジェクトが今も残っていたりと、なかなか手強い負債は今でも存在します。

そこで当社では、6年ほど前から負債返済の意味を込めて「徐々にマイクロサービス化を推進していこう」と意思決定をしました。

もちろんこれも万能薬なわけではないのですが、マイクロサービスは各機能がモジュール化されていますから、「思い切って削除する」選択肢が従来よりも取りやすくなったわけです。今振り返ると、6年前にまずは「決めた」ことが大事だったなと感じられますね。

「負債はあっても仕方がない」と割り切るケースもある

——最後のトークテーマは、「技術的負債を残さないための開発・組織の工夫」です。開発の進め方やチームビルディングなどで、気を付けるべきことを教えてください。

小久保：まずは全ての決定において、「エビデンスに基づくこと」ですね。先ほど長瀬さんが挙げられたように、開発におけるいろいろな要素を可視化して、客観的な数値をもとに判断するのが何よりも大切です。

あとは「小さく試す」こと。何かサービスや機能を作るときに、始めから大きなものを作るのではなく、まずは本当に使われるかどうかを小さく試してみる。ユーザの声を聞きながらアップデートしていく。そうすれば、仮に思ったような反応が得られなかった時に思い切って捨てることができます。

サービスの品質面でも、ユーザーのリアクションをこまめに反映させることにつながるため、より望ましい状態に近づくはずです。

長瀬：可視化という観点でいくと、サイバーエージェントでは、Googleが提唱するソフトウェア開発チームのパフォーマンスを示す4つの指標、通称「Four Keys」でモニタリングしています。

ただ、スタートアップでは、組織論うんぬん以前にプロダクトがマーケットフィットしないとビジネスが動き出さないのも事実です。特に立ち上げフェーズにおいては、「負債はあっても仕方がない」と割り切り、スピード重視で進めても良いのかなと。

その前提に立つと、「負債を残さないための工夫」というよりは、「負債をどうマネジメントしていくか」を考えても良いように思います。テクノロジーが進歩する以上、負債を一切残さないことは難しいので、負債はある前提とする視点が必要です。

具体的には、規模が大きい組織であれば、負債を返済するチームを組織して明確にリソースを割いてもいいと思います。

そうでなければ、攻めの開発をしているメンバーに対して「開発工数の20%は負債解消のために動く」といったルールを課すなどして、少しずつ返済を進める方法もありますね。

成田：お二人から開発組織の工夫についてお話しいただいたので、僕はちょっと違う視点でお話しします。

もし、事業サイドから「技術的負債をなるべく作らないように監視してくれ、お金は出すから」と言われたら、僕はおそらくエンジニアの給料を上げると思います。品質はエンジニアの技術力によって大きく変わるものだと思っているからです。

技術力が高いエンジニアが作ったサービスは品質がよく、負債が残りづらい。その上、メンテナンスも容易です。そう考えると、結局は優秀なエンジニアを集められるかどうかがプロダクトマーケットフィットの速さや負債の規模に直結すると思うんですよね。

そのような視点で見ると、年収500万円のエンジニアを2人採用するよりも、年収1000万円のエンジニアを1人採用する方が生産性が高い場合もありますし、特に立ち上げ期のように急激な変化が求められるフェーズではその傾向が顕著です。

「人数を増やせば生産性が上がるだろう」という想定は、サービス開発には当てはまらないんですよ。

ですから僕は、エンジニアの給料を上げて優秀な人材を確保し、少人数でスピード感を持って進めるのが最も効果的だと考えています。

僕自身もお二人が仰るように「技術的負債」はどんなサービスを作る上でも避けて通れないものだと考えています。

なのでそこにネガティブな文脈はなく、サービスの品質をさらに向上させるための仕事の一つだと思うので、今後もチームとして真摯に向き合っていきたいですね。

アーカイブ動画はこちら

イベントの後半では、視聴者からのQ&Aコーナーも。詳しい内容は下記アーカイブ動画よりご確認ください！

文／小澤志穂