「Pococha」でのエンジニア経験
城山賢人氏（以下、城山）：本日は「フロントエンドから技術領域を広げてできるようになったこと」という題でお話しいたします。
はじめに、自己紹介します。城山賢人と申します。2019年にDeNAに入社しました。Webフロントエンドとサーバーサイド開発を行う、アプリケーションエンジニアをしています。2021年で3年目のエンジニアです。当時の新規事業部に配属され「Pococha」でエンジニア経験を積んできました。本日はよろしくお願いします。
ご存じの方もいるかと思いますが、Pocochaのアプリについて軽く紹介します。Pocochaは、2017年にリリースされたライブ配信用アプリです。配信をするライバーと、コメントやアイテムで応援するリスナーの双方向コミュニケーションが特徴のアプリです。
本日話す内容です。PocochaでのWebフロントエンドエンジニアの仕事内容について。Webフロントエンドを経験してきたエンジニアが、サーバーサイド開発に取り組むようになった経緯。また、サーバーサイド開発の特徴。そして、技術領域を広げたことで得られたメリットについて話す予定です。今回は、Pocochaの技術的なことについては深く話さない予定です。ご了承ください。
初めてWebフロントエンド技術に触れた大学時代
学生時代の自分の経験や背景について少しお話しします。自分は大学に入学するタイミングで、情報分野への興味を持っていました。学生時代はプログラミングサークルへ所属し、VRゲームの作成などを行っていました。
初めてWebフロントエンドの技術に触れたのが、大学2年生あたりのころです。2017年は、React、Vue.js 2.0といったWebフロントフレームワークが日本で広く認知されるようになった時期です。Node.jsでWebアプリケーションの基礎について学んでいました。Webフロントエンドの技術や知識について、広く浅く学んでいた時期になります。
大学生の時は当時そこまで興味が湧かなかったので、インターンなどにはあまり参加しない学生生活でした。DeNAに入社した決め手は、社内のエンジニアと話が合いそう、一緒に働くイメージが湧く、といった点で入社を決めています。
当時、なぜWebフロントエンドを学んでいたかについて話したいと思います。なんとなく、エンドユーザーに近い感じがする。画面やWebサイトがあり、自分の成果を実感できる。自分のやっていることがイメージしやすい。UI・UXに関してユーザーからいいフィードバックがもらえた時うれしい、などがありました。また、学びやすい環境だったことも要因の1つです。
Webフロントエンドに携わる人で、上記のようなことをWebフロントエンドが好きな理由、または学ぶ理由として挙げる方は多いのではないでしょうか。実際に自分もそうで、画面上に自分の成果が表れて、またユーザーの目に付きやすいことがモチベーションになって、Webフロントエンドを学んでいました。
Pocochaに配属された直後
次に、実際にPocochaに配属されてからのことについて話します。1年目から3年目の業務イメージです。入社後、全体研修・エンジニア研修を受けました。エンジニア研修では、コンピューターサイエンス、Webフロントエンド、サーバーサイドの開発、またプログラミング言語について幅広く学びました。
その半年後、Pocochaに配属され、Webフロントエンドエンジニアとして実務を始めます。配属されて間もなく、リファクタリングなどの小さな改修から、事業部の開発フローについて経験しました。
当時、個人開発と事業部の開発のフローにはギャップがあり、高品質なサービスをリリースするには、ある種の大変さを実感したことを憶えています。2018年卒の先輩Webエンジニアにサポートに入ってもらい、スムーズに改修を進められました。年齢の近さも相まってか、コミュニケーションなどの負担も少なく、開発に集中できました。
半年ほど経ち、開発に慣れてきた頃、小規模な機能開発を任されるようになりました。このタイミングで、必要に応じてサーバーサイド開発にも手を出すようになっていました。
2年目には一転、Webのインフラの移行やPocochaの多言語化対応といった、Webフロントエンド開発の中で比較的大きな改修を、チームの一員として取り組むことになります。
そのような経験を積んだ後、3年目ではインシデント対応、新機能開発や補填対応等の重要な仕事について取り組むことになりました。この頃から、サーバーサイドエンジニアとしての業務も増えてきたように感じています。
PocochaのWebフロントエンド技術
話は変わりますが、PocochaのWebフロントエンドの技術についてここで触れておきます。Pocochaでは、イベントなどの画面のアプリ内Webview、Webで配信視聴ができるWeb版、公式サイトやランディングページなど、幅広い部分でWebフロントエンドの技術が使われています。
ReactとTypeScript、VercelとNext.jsといった、モダンなWebフロントエンドの開発環境を実現しています。PocochaのWebフロントエンドチームは、情報感度が高く、Webフロントエンドの技術を追っていく文化が根強くあります。自分もそれを気に入っています。使用技術に関しては、以上です。
具体的に、PocochaのWebフロントエンドエンジニアがどういった仕事をしているのか、ここで話したいと思います。まず企画段階での話し合いをします。実現可能性やUI・UXの観点についても議論します。
既存機能の改修や新規機能の実装が主な業務になります。また、既存のコードのリファクタリングやチーム内のエンジニアリングに関することも業務内容に含まれます。コーディング規約の整備やCI・テスト環境の整備は、チーム全体の開発のモチベーションを保つために重要で、チーム内で一人ひとりが意識して改善を進めています。
Webフロントエンドエンジニアの業務の特徴として、関わる人が多いという印象があります。だいたい1つの開発単位で、5名から10名ほどの人と関わり、仕事を進めることが多いです。
実際の自分が行った業務
実際に自分がWebフロントエンドエンジニアとして行った業務について具体的に話します。あくまで一例ですが、Webフロントエンドエンジニアの業務について、よりイメージがつきやすいかと思います。
先ほど少し話しましたが、新機能の開発やリファクタリングを行っていました。Pocochaも5周年を迎え、Webフロントエンドを扱うリポジトリで古いコードが出てきます。例を挙げると、クラスで書かれたReactコンポーネントなどです。現在では、React Hooksを用いた実装にほぼすべて置き換わっています。
下の画像は、Web開発されているものの一例です。一番左の画像は、アプリ内のイベントの一覧をカレンダー形式で表示している画面です。新機能開発として、サーバーサイドの実装を含め、開発全体を主導しました。ほかにも、Webリポジトリ全体の多言語化対応を進めたりもしています。
Webフロントエンドの開発にかかわる業務をする中で、ある日、サーバーサイドの開発も任されるようになりました。チームにジョインして2年目の冬頃のことです。ある程度の規模の新機能開発をすることになりました。
具体的に行ったことを話すと、Pocochaの新イベントのための新機能作成を行っています。シニアエンジニアのサポートのもと、既存の実装の影響の範囲の調査から始めることになりましたが、実装の影響範囲が広過ぎてかなり時間がかかったことを憶えています。
この開発経験では、Webフロントエンドの開発だけでは考えられない経験ができました。データベース設計では、複数シャードにまたがったトランザクションの考慮。また実装では、万が一のことがあった時の補填対応を考えて実装することになります。Webフロントエンドの開発だけでは得られなかった開発経験を積めて満足しています。
なぜサーバーサイドの開発を経験することになったか
サーバーサイド開発を任されるようになったという話をしましたが、ここで、自分がなぜサーバーサイドの開発を経験することになったかという経緯について話しておきましょう。
もともと、Webアプリケーションについて学んだり、Webフロントエンドエンジニアとして業務を進める中で、一定、サーバーサイド開発をしてみたいという気持ちがありました。サーバーサイド開発自体については、学生時代に小さなWebアプリケーションを作った程度でした。
また配属1年目から、必要に応じて、Railsのコントローラーの実装など、サーバーサイド開発について少しずつ取り組んできました。その積み重ねの結果、業務でもサーバーサイドエンジニアとしての開発を担当しました。
ここで、サーバーサイドエンジニアの仕事として、特徴的な仕事内容について整理したいと思います。まず、データベース設計があります。RDB全般の知識やデータベースのトランザクションについても詳しい知識が必要です。APIの設計や実装の際に、パフォーマンスについても考慮することになります。これは、Webフロントエンドを触るだけでは普段あまり考えない部分になると思います。
また、プロダクト全体の運用・改善業務を行うこともあります。障害対応も、クライアントの開発だけではあまり経験することのない業務の1つです。
実際に、自分がサーバーサイドエンジニアとして経験したことについてお話しします。新機能の開発や、既存機能の改修、サービスのメンテナンス、問い合わせがあった場合のシステム上の調査、システムの運用や改善業務、またインシデント対応などです。
各種のサービスの機能についてより深い理解や、システム上のロジックの理解が必要になると感じました。このサーバーサイド開発を通して、プロダクトへのより深い理解を得られました。
技術領域を広げたことで得られたこと
技術領域を広げたことで得られたことがいくつかあります。大きく分けて2つあり、それらを紹介したいと思います。
1つ目は、チームを横断した活躍ができます。自分1人のリソースがあれば、Webフロントエンドとサーバーサイド開発の両方が必要な施策を進めることができます。リソースの調整がしやすく、小回りが利いて開発効率がいいので、特に小規模な開発と相性がいいです。Webフロントエンド、サーバーサイド開発をともに行うことで、スピード感のある開発を進められるようになります。
また、事業部内では、複数の施策が並行で進むことは、往々にしてあります。プロジェクト全体の工数が足りない場合、スポットで開発に参加できます。いろいろなプロジェクトに参加し、活躍するチャンスが多くなったと感じています。
また、所属しているチームをまたいでレビューの依頼や相談をされることが多くなりました。チーム内外のエンジニアと広く業務を進められるのは、すごくおもしろいなと思っています。
次に、2つ目です。開発効率が上がります。企画段階での懸念を回避できることが増えます。API設計1つを取っても、Webフロントエンドとサーバーサイド、両方の観点から設計を進められます。
企画段階で、複数の観点での仕様をレビューできるため、手戻りが少なく、実装段階での仕様変更も減っていると感じます。また、サーバーサイドエンジニアとのコミュニケーションの回数も必要最低限になることで、開発全体のスピードが上がります。
最後に、まとめです。Webフロントエンドとサーバーサイド、両方触ることで学びがあります。キャリアの幅が広がったし、4年目以降の選択肢も増えると思います。サーバーサイド開発をやってみて損はしないと思います。
両方の技術領域を学び業務を行うことで、多少の負担は増えますが、それはチームで頼られている証拠だと思います。また、技術領域にも飽きません。いろいろな技術に広く興味を持っている人には、おすすめだと思います。
まとめは以上です。ご清聴ありがとうございました。
両方やってみないと見えない景色
司会者：城山さんありがとうございました。なかなか、たぶん両方やってみないと見えない景色みたいなものがあったと思うので、そのあたりもQ&Aセッションとかで掘っていければなというふうに思います。
最初の質問はこちらです。「フロントエンドからサーバーサイドをやるようになって、逆に苦悩した点はなにかありますか？」という質問ですが、いかがでしょうか。
城山：サーバーサイドエンジニアの特徴的な仕事というスライドでもお話ししたと思うんですが、ふだんWebフロントエンドの開発だけでは経験できないものがあります。
主にデータベースの話なんですが、RDBの設計やパフォーマンスを考慮した実装、トランザクションの考慮などは、Webフロントエンドの開発だけでは得られない経験です。最初、業務でこれらを扱う時に経験が足りない部分に苦労しました。
司会者：なるほど、その上で、どういったところが具体的に苦悩だったんでしょうか。
城山：新しい技術領域を学んでいるということで、Webフロントエンドの開発よりも、自分のスキルというか技術が足りない状態での業務になるんですが、サービスとしては高品質なものが期待されているところで、そこのギャップを自分で実感しているて、そこを埋めにいく学びというのが大変でした。
司会者：なるほど、ギャップを埋めるために、自分で学習しながらそこを進めていくというところが、苦労されたところなんですね。
城山：はい。
司会者：ありがとうございます。では次の質問に移っていきましょう。次の質問はこちらです。ちょっと似たような質問ではあるんですけれども、「両方やれるようになった上でのつらみとかありますか？」という質問ですね。
城山：これは1つは、両方のWebフロントエンドとサーバーサイドの両方の業務をやることで、複数の施策に同時でアサインされて業務をこなすことが増えました。そこで、複数の施策が走っているので、ミーティングなどが単純に増える。あと、開発のまとまった時間は、工夫しないとなかなか取りづらくなってきました。
司会者：会議だったり、いわゆるステークホルダーとのコミュニケーションが増えていくというところですね。会議を寄せるとか、そういった工夫もしているんですか？
城山：できる限りは寄せたりして、あとは、サーバーサイド開発とWebフロントエンドの開発を少しずつやると、けっこう頭の切り替えというかエネルギーを使う部分があるので、できる限りまとまった単位でサーバーの開発をやって、また別の日に、Webフロントエンドの開発を行うみたいな調整を自分でしています。
司会者：コンテキストがバラバラにならないようなかたちで、統一していくような工夫をしているということですね。このへんは、複数のことをやるエンジニアにとっては、朗報なのかなと思いました。それでは、お時間ですので、以上となります。ご視聴ありがとうございました。
城山：ありがとうございました。
