エンジニアに求められるのは「品質に向き合う力」――ユーザー価値向上のためにフロントエンドができること

ヤフー×メルペイのエンジニアが語る、変化の速い技術領域に向き合うためのマインドセット

若手向け 2021/03/18 12:00

　Webアプリケーションの需要が高まるにつれ、その価値をユーザーに提供する直接のインターフェースとなる「フロントエンド」を構成する技術への関心も高まっています。一方で、フロントエンドは短期間で次々と技術的なトレンドが移り変わっていく領域でもあり、プロダクトの中で、どの技術を、どのように使っていくかが、ビジネスの拡大や、関わるエンジニアのキャリアに少なからず影響を与えます。今回は、ヤフーと、メルペイ／メルカリという、ともに多くのユーザーに支持されているプロダクトに関わる3人のフロントエンドエンジニアに、時流に流されず、ユーザーにより多くの価値を届けられる「フロントエンド」のあり方と、それに向き合う際に必要な考え方について語ってもらいました。

日本最大規模のWebサービスでフロントエンドに関わる3人のエンジニア

橋本：ヤフーの橋本です。本日はよろしくお願いします。私は2011年にデザイナーとしてヤフーに入社しまして、その後いくつかのサービスのデザインを担当した後、PC版トップページの担当になりました。以前、ヤフーではHTML/CSSのコーディングは、伝統的にデザイナーが担当していたのですが、1年ほど前から、最近の業界の傾向に倣って、その領域もエンジニアが担当するようになってきました。私も、そのタイミングでデザイナーからエンジニアに転身した形になります。以降は、フロントエンドだけでなく、これまであまり触れる機会がなかった、JavaやAPIまわりなどのサーバサイドのほうにも、担当領域が広がっています。

橋本龍一（はしもと・りゅういち）氏

　ヤフー株式会社メディア統括本部メディア開発本部所属エンジニアチームリーダー。2011年に入社し、デザイナーとして「Yahoo! toto」「Yahoo!ウォレット」「Yahoo! JAPAN ID」「Yahoo!きっず」といったプロダクトを歴任。その後PC版Webトップページを担当する。2020年よりエンジニアに転身。現在は、Javaを利用したAPI作成など、サーバサイド周辺の技術にも担当領域を広げている。HTML/CSS分野での第7代、第8代黒帯。

神野：ヤフーの神野です。私は2016年3月に中途入社でヤフーに入りました。入社後はPC版トップページの担当となり、そこでしばらく橋本さんと一緒に仕事をしていました。

　2017年3月から1年間、福岡のオフィスに異動になり、災害が起こったときにも確実にサービスを提供できるようなBCPの仕組み作りや、Yahoo! JAPANアプリのバックエンドをモダナイズする取り組みをしてきました。2017年10月から現在までスマートフォン版トップページの担当をしています。どちらかというと、フロントエンド周りを長く経験してきました。よろしくお願いします。

神野真彦（じんの・まさひこ）氏

　ヤフー株式会社メディア統括本部メディア開発本部所属エンジニアチームリーダー。2016年3月入社。ヤフーのPC版トップページを1年間担当した後、北九州センターに異動し、BCP対策やAPIのモダナイズ、スマートフォンWebの担当などを歴任。その後東京に戻り、スマートフォン版トップページを担当し、そこでテックリードを務める。フロントエンド、ユーザーインターフェース周辺での開発経験が豊富。

泉水：メルペイの泉水です。2018年3月にメルペイに入社し、現在は、Manager of Engineering Managersという役割でメルペイとメルカリの両方のフロントエンド組織を担当しています。また、メルカリのWebアプリを刷新するプロジェクトのTech Leadも務めており、このプロジェクトの成果を世に送り出すことにも注力しています。よろしくお願いします。

泉水翔吾（せんすい・しょうご）氏

　株式会社メルカリソフトウェアエンジニア。Webアプリケーション開発を専門としており、HTML・CSS・JavaScript・ブラウザAPIなどのWeb標準技術に関する動向を追っている。企業でソフトウェアエンジニアとして働く傍ら、技術顧問として複数企業のエンジニアリングに関わり、高品質で維持しやすいWebアプリケーションを作るための活動を続けている。

プロフィールサイト

ヤフー、メルペイ／メルカリではフロントエンドにどんな技術や手法を使っている？

――それぞれのプロダクトで使われている技術や手法について教えていただけますか？

神野：ヤフーのスマートフォン版トップページで使われている技術は、TypeScript、Next.js、React、Redux、テストにはJestといった感じでしょうか。わりと手堅い感じです。

　トップページのサーバサイドには大きく2つの役割があって、1つはユーザーからのリクエストベースで、ユーザー固有の情報を返すところ。もうひとつは、災害情報やニュースなどユーザーを問わない情報（マス情報）を返す部分です。トップページは、サービスの性質上マス情報を返すことが多いのですが、マス情報に関してはパフォーマンス／リソース節約／耐障害性の面から、サーバサイドでは多段でデータをキャッシュしています。

　技術的には、Reduxのデータをpropsとしてコンポーネントに渡して表示しているのですが、re-ducksパターンを使いながら、秩序を保った上で仕組みを拡張できるように配慮しています。

橋本：ヤフーのトップページでは、フロントエンドのデザインやコーディングに、UIコンポーネントを小さなパーツの組み合わせとして構成していく「アトミックデザイン」という手法を活用しています。これをベースに、サービス向けにカスタマイズして展開するという流れですね。

　アトミックデザインだと、厳密には構成要素の単位として「原子（Atom）」「分子（molecule）」「有機体（organism）」といった単位を設定するのですが、それをそのまま適用しようとすると、境界のルールが複雑になりがちです。そのあたりについては、なるべくシンプルにカスタマイズしながら使っています。

泉水：メルカリとメルペイでは、それぞれ「お客様向け」「加盟店様向け」「社内メンバー向け」のアプリがあります。フロントエンドは、メルカリはReactベースの技術スタックを使っており、メルペイだとVue.jsやNuxtを使っていますね。

　細かい要素はプロジェクトによってさまざまなのですが、共通して使われているのはTypeScriptでしょうか。背景としては、グループ全体でバックエンドのマイクロサービス化が進んでおり、クライアントサイドとのメッセージングにProtocol Buffersを使っています。そのメッセージフォーマットを、TypeScriptの型定義に変換して、フロントエンドで使っている形ですね。

橋本：メルペイとメルカリで、ReactとVue.jsを使い分けているのですね。

泉水：私が入社した時点で、メルカリではReactを使っていたのですが、その後、メルペイで技術選定が必要になった際に、あえてVue.jsを選びました。もちろん、Reactでも良かったのですが、そうしてしまうと、社内で技術面でのダイバーシティが失われるリスクがあることを危惧しました。私はVue.jsでもReactでも、作れるアプリケーションは基本的に同じだと思っています。新しい技術要素を入れることで、社内に新しい知見を蓄積していくことが重要だと考えました。

神野：「技術のダイバーシティ」とはとてもいい言葉ですね。一般的に、ユーザー数も多く、かつビジネスインパクトの大きなサービスだと、どうしても「ここには、こういう技術を使う」といった暗黙の標準のようなものができあがっていて、新しいものを取り入れにくくなることがありますよね。社内における技術的な意味でのダイバーシティという視点も、たしかに重要だと感じます。

泉水：もちろん、それぞれのプロジェクトであまり好き勝手にいろんなものを入れてしまうと、統制がとれなくなりますし、プロジェクト間での人の流動性も下がってしまいます。そのあたりのバランス感覚は必要ですね。メルカリ、メルペイでそれぞれに知見を蓄えつつも、統制と組織のフレキシビリティの面では不都合が起きないよう、気を配っています。

神野：ヤフーの場合は、サービス領域が近かったり、同じ事業部内だったりすると、ある程度同じ技術を使う傾向がありますね。ただ、バックエンドも含めると、事業領域によって使っている技術はまったく違いますね。

さまざまな側面があるプロダクトの「品質」といかに向き合うか

――非常に多くのユーザーに利用されているプロダクトに関わられていますが、ユーザー価値向上のために、どんな取り組みをしていますか？

神野：ヤフーのトップページに強く求められる要件として「どんなことがあっても落とさない」があります。極端なアクセススパイクがあって、Webサーバが応答を返せなくなってしまったとしても、前段のプロキシから、最低限のコンテンツは返せるような仕組みを作っています。特にトップページについては、マス向けの情報が多いので、キャッシュを多段で入れて、通信コストを削減しつつ、お客様に確実にコンテンツを返せるように工夫しています。

　フロントエンドでユーザー体験を高めるための工夫としては「レイアウトシフト」を極力起こさないような構造にしているというのもありますね。ページを読み込んでいる最中に、広告や画像が後から差し込まれて、コンテンツやUIの見かけが急に変化すると、ユーザーとしては印象が悪いですよね。視覚要素が安定しているというのも、ユーザー体験の向上に寄与するファクターのひとつではないかと思います。

橋本：他に挙げるとすると「アクセシビリティ」ですね。ヤフーは、おかげさまで本当に多くのOSやデバイス、通信環境からアクセスしてもらっています。どんなに通信速度が遅くても、どんなに古くマイナーなOSやブラウザで見たとしても、できる限り対応できるようにしておくというのは意識しています。

泉水：予期していない環境からのアクセスにどこまで対応するかというのは、規模が大きいサービスになるほど、判断が難しい問題ですよね。ユーザー数が膨大なら、たとえ0.1％のユーザーを切り捨てたとしても、それなりにビジネスインパクトが出てきてしまう。でも、そこに対応しようとすると、エンジニアリングコストがかさんでしまう。ヤフーでは、そのあたりのバランスをどう見ているのですか。

橋本：アクセスのあったデバイスやOS、ブラウザの割合を常に集計しており、今使っている技術でサポートできず、極端にユーザーが少ない環境については、まとめて別に対応しているといった感じですね。細かい数値についてはお話しできませんが、環境の切り分けについては、もちろんビジネスインパクトに基づいて判断しています。

神野：目下、非常に悩ましいのは「iOS 9以前」のデバイスですね。この世代だと、Next.jsの一部の機能が動かなかったりします。とはいえ、今のところ公式にサポートしているので、このあたりと今後どう付き合っていくかは課題になりそうです。

　泉水さんの場合、メルペイとメルカリ、それぞれのプロダクトで、求められる要件や対応が異なるということはあるのでしょうか。

泉水：それについては、基本的に区別はないです。例えば、メルペイはプロダクトの性質としてお金のやり取りを扱うので「セキュリティ」や「可用性」といった要件のプライオリティは当然高くなります。しかし、そうした要件が「メルカリ」には求められないかといえば、そんなことはないわけです。

　ですので、どちらかというと「より普遍的に、プロダクトの価値を高い品質でユーザーに届けるために何ができるか」という観点で考えるようしています。

　私はこれまでも組織の中で、パフォーマンス、アクセシビリティ、テストといった、一般に非機能要件に分類される品質を啓蒙してきました。神野さんや橋本さんもおっしゃっていましたが、このような非機能要件が「品質」として、プロダクトに与える影響は大きいのですよね。

　「良い機能を素早く実装する」だけでなく、そこに高い品質が伴うのが「優れたエンジニアリング」であり、それがプロダクトの価値を底上げする要素のひとつだと思います。もちろん、それを実現するためには、エンジニアリング面の努力だけでは駄目で、組織全体としての取り組みが欠かせません。そのために考えるべきことはたくさんあって、難しい課題ではあります。

橋本：本当にそう思いますね。どうすれば、組織にそういう意識が根付いていくかということはいつも考えています。

泉水：フロントエンドのエンジニアリングに関しては、エンジニアにプロダクトの「品質」について、正しい知識を身に付けてもらうことが重要だと思っています。

　例えば、速度が遅くなってしまう実装方法が分かっていれば、それをわざわざやらないですよね。アクセシビリティについても一緒で、正しいやり方を知っていれば、そのやり方でやるわけです。それができるかどうかが、エンジニアとしての「技術力」の一部です。昨今、フロントエンドのトレンドは移り変わりが激しいですが、そうした「品質に向き合える力」というのは、トレンドが変わっても残っていく、普遍的な技術力のひとつだと思います。

神野：ヤフーでは、そうした非機能要件の重要性について、社内にかなり理解が広まっていて、その点はありがたいですね。さまざまな職種が一丸となって対応しようとする体制はできていると思います。

　ただ、そこにも課題は残っていて、ある要件について、どういう状態が「正しい」のかについては、より精緻に残していく必要があると思っており、取り組みを進めています。例えば「テスト環境の拡充」と言った場合には、どういう観点でテストをすべきかについて議論し、ある程度の共通認識を作っておくことが必要ですよね。そうした場合、トップページなどは、ステークホルダーが非常に多いので、ドキュメントベースでやろうとしても、全体での合意に進むまでが大変で、その前の「周知」の段階ですら、かなり時間がかかってしまうという状況があります。

橋本：ヤフーの場合は、そうした内部での品質向上について、経営に理解があるのが助かります。経営の理解があることで、現場の意識も高く維持しやすい点はメリットだと感じています。

泉水：それは素晴らしいですね。メルペイでは、クォーターごとに組織としての目標を設定しているのですが、今、エンジニアリングディビジョンでは、品質向上の取り組みを強化することを目標に掲げています。先ほど神野さんが、ヤフーでは「どういう状況が正しいのか」を定義する取り組みを始めているとおっしゃっていましたが、われわれも、特にエンジニアリングの領域で「品質とは何か」という部分から、整備を始めています。バックエンドなら「可用性」をどう定義するのか、クライアントサイドなら「クラッシュ率」や、どれくらいの「パフォーマンス」が出ているか、それらをどう計測するのかといったところから整備していこうとしています。

橋本：私も「テスト品質」をどう捉えるかについては課題感を持っています。従来であれば、カバレッジができているかどうかが重要で、その内容が品質を判断する上で妥当かということには、あまり目が向けられていなかったように思います。ヤフーのトップページも最近では、テスト品質のルール策定に力を入れ始めていますね。

神野：そうした取り組みの一環としてですが、ペアプログラミングやテスト駆動開発（TDD）なども始めています。私の印象で恐縮ですが、テストコードを先に書いたほうが、テストコードや実装の出来が良いです。実装から先に書いてしまうと、どうしてもテストコードを「無理やり」書いてしまいがちです。はじめにきちんとテストを書いてから（仕様を精緻に明らかにしてから）実装した方が、結果的に早く作ることにもつながります。仕様や設計からテストを書き、それからコードを書くことで、コードの品質が上がると実感しています。最近では、そのように書かなければ、コードの品質というものは確保できないと思うようになりました。

橋本：先ほど、泉水さんが「品質と向き合う力は、普遍的なエンジニアリングスキル」とおっしゃっていました。それに関連して言うと、現在、ヤフーでは「エンジニアスキルの多角化」にもチャレンジしています。

　今、ヤフーのメディア開発本部が掲げている目標に「ユーザーに早く価値を届け、それを維持する」というのがあるのですが、それを特定の人だけでなく、できるだけ多くの人ができるようにしていこうという取り組みです。

　具体的には「HTML/CSS研修」「React研修」「基礎デザイン研修」という3つの研修に加えて、開発本部で実施している「OJT教育プログラム」があり、これまでに100人近いエンジニアが参加してくれています。「いろんな人が、いろんなことをできるようにする」ことが目標ですが、このプログラムをきっかけに第一歩を踏み出してもらって、その後、実際の案件に関わってもらうケースが増えてきています。

「作ってみる」ことがフロントエンドエンジニアの成長を加速する

――これからフロントエンドエンジニアとして成長していきたい方に向けて、どんなアドバイスをしたいですか？

泉水：今日、ここまでお二人と話してきたことでもありますが、「品質」と向き合えるフロントエンドエンジニアが、これからさらに増えていくとうれしいですね。

　その一方で、Web技術そのものは、これからもアップデートされ続けます。情報量も多いので、何から手をつければいいのか迷うこともあると思いますが、その変化を楽しめるとよいのではないかと思います。

　技術に向き合う上で重要なのは「なぜ、その技術が生まれたのか」を捉えることです。新しい技術には、必ず、それが生まれた理由があります。その技術が、どんな課題を解決しようとしているのかを知れば、技術に対する理解もより深まると思います。ReactやVue.jsといったライブラリやフレームワークを学ぶ場合もそうですね。文法やAPIを理解して、何となく使えるようになるよりも、まず、その背景を理解した上で使うことが大切だと思います。

　また仕事の中で、そうした技術は、ビジネスに貢献する手段になります。新たに学んだことを、どう実践できるか、どんな形で現場に持ち込めるかを考えながら触れてみるといいのではないでしょうか。

神野：私としては、エンジニアとしての成長という点では、細かいことは置いておいて「とりあえず何か作ってみる」ことを勧めたいです。

　今は、Firebaseや、AWSのAmplifyなど、BaaSと呼ばれるような、バックエンドのサービスがいろいろあります。これらを使うと、フロントエンドエンジニアが、HTML/CSS、JavaScriptといった自分のスキルセットでサービスを簡単に開発し公開できます。そうしたものも利用しながら、自分でサービスを作って世に出しているうちに、「品質」の大切さであるとか、最近注目されている技術や仕組みが生まれた背景なども、自然と見えてくるはずです。

　正直なところ、自分の学びのために触ってみる技術の選択については、私はわりと適当ですね（笑）。ただ、自分がその立場になったら「その技術は、どこの会社で使われているか」「そこでは、どんな課題を解決するためにその技術を選んだのか」を、最初に知るようにすると、理解が進むと思います。どのライブラリやフレームワークを使ったとしても、ある程度習熟度が上がれば、そこから、より自分たちに適した技術へ移っていくのは難しくないはずです。

　ライブラリやフレームワークの技術的なよしあしや、「品質」も大事なことですけれど、そもそも、そうした課題には、少し大きめな組織の中でないと向き合いにくいということもあります。個人としては、「まず作ってみる」ことが、成長のためには一番いいのではないでしょうか。

　私自身も本を読んで勉強するのが苦手で、作りながら学んできたタイプです。新しいことにチャレンジするときも、自分で動かしながら触っていないと、だんだん何のためにやっているのか分からなくなってきてしまうのですね。

　もちろん、プロとしては、そうやって身につけた知識や技術を、仕事にどう生かしていくかを考えることも大切です。私の場合は、会社の理解もあって、個人的に副業をいくつかやっているのですが、新しく学んだ技術は、まず副業のほうで使ってみて、その中で得た知見を本業のほうにも生かせないか考えてみるようなことをしています。そういう意味で、副業は会社で認められていれば、勉強にもなるし、経験にもなるし、収入にもなるし、メリットが多いですね。

橋本：私もアウトプットを出すことは大事だと思います。やはり、勉強会などで得た知識は、それだけは身にならないですね。

　技術選択について言えば、今の市場の中で、多く使われている技術をどんどん学んでいくといいのではないでしょうか。今、フロントエンド周辺はとても領域が広がっていて、何を勉強すればいいのか、方向性を定めるのも大変だろうと思います。そんな中で、例えばReactやVue.jsが主流になっているのには、市場に求められる理由があるからです。そうした技術については、情報も多くありますから、調べやすく、勉強もしやすいはずです。

神野：例えば今、世界的にどんな技術が注目されているのかを知りたければ「State of JS」のようなサイトも参考になりますね。

　これを見ると、例えばフロントエンドフレームワークの領域では、2020年の時点で「Svelte」という新たなフレームワークが、Vue.jsやReactをしのぐ勢いで注目を集めていることが分かります。このあたりの動向も視野に入れながら、自分がリソースを割いて学ぶ技術を検討してみるのもいいと思います。

橋本：私も、自分が使いたいサービスを、世の中で流行っている技術を使って作ってみるということはやっていましたね。

　働き始めてからは、それをなるべく業務、案件と結びつけて試すことをやっています。とはいえ、いきなり大きなサービスで新しいものを試すのはリスクが大きいので、まずは1枚のランディングページだとか、公開期間が限られているようなところに、少し新しい技術を入れてみるといった感じです。私も、机の前で勉強するより実践したほうが効果があると思っているので、経験上、そのほうが良いフィードバックが多く得られると感じています。

　泉水さんは、Webの標準技術に関して常にアンテナを張っておられる印象がありますが、そこに関心を持つようになったきっかけは何だったのですか。

泉水：実は、何で追いかけ始めたかの具体的なきっかけは、あまり覚えていません。あえて挙げるなら、昔パフォーマンス改善に興味を持ったことがあり、そのためには、そもそもWebブラウザがどう動くのかを理解する必要があって勉強し始めたというのが最初ですね。そこで学んだことが、『超速！ Webページ速度改善ガイド』（技術評論社刊）の執筆や、その後のWeb標準を追うことにつながっていきました。

　私の場合、個人で関心を持って学んだことの主なアウトプット先はOSSです（参考：泉水氏へのインタビュー記事）。作りたいアプリケーションが思い浮かんだら、作って、公開して、触り続けることがモチベーションにもなっています。

橋本：個人で複数のOSSをリリースして、メンテナンスされているというのはすごいですね。恐らく泉水さんもそうだと思うのですが、基本としては「やっていて楽しい」ことが大切ですよね。それがないと続きません。

神野：あと、もうひとつ付け加えるなら「最初から格好いいものを作ろうとしない」ことです。最初のうちから、最新の技術で凝ったことをやろうとしたり、機能を多く盛り込んだりしようとすると、絶対失敗します。そもそも完成しません。まずは、格好悪くてもいいので、自分が作りはじめたものを、最短距離で世に出すことを考えたほうがいいです。

泉水：それは間違いないです。マーク・ザッカーバーグの「Done is better than perfect」という有名な言葉もありますしね。