AI時代、フロントエンドに閉じない技術者へ——越境で価値をつくるebookjapanのエンジニア
AI時代が到来し、フロントエンドとバックエンドの境界が曖昧になるのではないかと言われる昨今。LINE Digital Frontier株式会社が運営する国内最大級の電子書籍販売サービス「ebookjapan」のフロントエンドエンジニアは、「フロントエンドに閉じない」幅広い領域でサービスを動かしている。 それを象徴するのが、2023年に展開された「連載プロジェクト」だ。今回は、ebookjapanのフロントエンドエンジニアである山田 拓己（やまだ・たくみ）氏、江口 立樹（えぐち・たつき）氏のお二人に、プロジェクトの内容やその中でフロントエンドエンジニアが担う役割についてお話をうかがった。
AI時代が到来し、フロントエンドとバックエンドの境界が曖昧になるのではないかと言われる昨今。LINE Digital Frontier株式会社が運営する国内最大級の電子書籍販売サービス「ebookjapan」のフロントエンドエンジニアは、「フロントエンドに閉じない」幅広い領域でサービスを動かしている。
それを象徴するのが、2023年に展開された「連載プロジェクト」だ。今回は、ebookjapanのフロントエンドエンジニアである山田 拓己（やまだ・たくみ）氏、江口 立樹（えぐち・たつき）氏のお二人に、プロジェクトの内容やその中でフロントエンドエンジニアが担う役割についてお話をうかがった。
インタビュイープロフィール
開発の全工程に関与しエンジニアと非エンジニアをつなぐ
——はじめに、ebookjapanがどんなサービスか教えてください。
山田：創業25周年を迎えた電子書籍販売サービスです。特徴は、大きく2つあります。ひとつは、電子書籍サービスとしては老舗で、長年にわたって積み重ねてきたデータが強みであるということ。もうひとつはLINEヤフー株式会社（以下、LINEヤフー）と当社が協力して運営しているサービスであるため、「PayPayポイント」が付与されるおトクなキャンペーンが多い点です。
——ebookjapanの現在の事業フェーズについて教えてください。
山田：LINEヤフーと一緒にサービスを展開してきた背景もあり、これまでは主に「PayPay」ユーザーに対する施策に取り組んできました。「PayPay」で本を購入した場合に「PayPayポイント」が付与されるキャンペーンも多く、結果的に「PayPay」ユーザーが何冊もマンガをまとめ買いをするというのが、これまでの特徴だったのです。今後は、ライトユーザーを増やしたり、若年層へのリーチを強化したりするのはもちろんですが、「PayPay」ユーザーに限らず、より多くの人が気軽にマンガを楽しめるサービスにしていくため、ユーザー全体の母数を増やしていきたいと考えています。
——そのなかで、フロントエンドエンジニアはどのような役割を担っているのでしょうか。
山田：フロントエンドエンジニアは、最終的にサイトとして世に出る一番最後の工程を担っています。そのため、企画職やデザイナー、バックエンドエンジニアなど、さまざまな部署と連携しながらスケジュールをすり合わせたり、初期段階から設計に携わったりと、開発全体に幅広くかかわります。僕たちが遅れると全体のスケジュールに影響が出てしまう、責任の大きなポジションですね。
——フロントエンドエンジニアとして、どのような技術領域に携わることが多いですか？
江口：僕は新卒で入社したときから、JavaScriptとTypeScriptを使った実装をしてきました。入社4年目ごろからは、個人的にインフラ周りに興味が湧いて、CI/CDやデプロイの設定など、フロントエンドとは少し離れた領域も担当させてもらっています。
——日々、どういう職種の方と連携してプロジェクトを進めていますか？
山田：一番かかわりが多いのは企画職の皆さんですね。プロジェクトの初期段階から連携します。また、検討しているデザインがアプリ上で実現可能か確認しながら進めなければならないので、デザイナーとも頻繁にやり取りが発生します。 ほかにも、バックエンドがAPIの改修をする際に、フロントエンドとしてどのようにつくってほしいか、設計の段階でかかわることもあります。このように、ほぼ全工程に関与していますね。工程の中間にフロントエンドがあって、エンジニアとエンジニア以外をつないでいるようなイメージです。
他部署とのコミュニケーションを密にし成功させた「連載プロジェクト」
——ここからは、2023年に行われた「連載プロジェクト」についてお聞きしたいと思います。まず、プロジェクトの目的や背景について教えてください。
江口：もともとebookjapanを運営していた株式会社イーブックイニシアティブジャパンがLINE Digital Frontier（以下、LDF）と統合した（※）ことがプロジェクトの背景にあります。この統合で、ウェブトゥーンという、スマートフォンを縦にスクロールして「縦読み」できる作品を、ebookjapanで取り扱えるようになりました。
ただ、ebookjapanはもともと「単行本単位」で購入することを前提としたサービスで、「話単位」で読むためのプラットフォームは存在していませんでした。そこをゼロベースから立ち上げるのが、この「連載プロジェクト」でした。
このプロジェクトではもう1つ、「タイマー無料」というシステムを実装しました。1話を無料で読み、23時間経つとタイマーが回復し、また1話無料で読めるというシステムです。これによって新規ユーザーを獲得し、継続して当社のサービスを利用してもらいたい、という目的がありました。プロジェクトは2023年にスタートし、ひと区切りしたのが2024年末ごろ。フロントエンドからは15名ほどのメンバーがアサインされて、企画やバックエンドと連携して進めてきました。
※「ebookjapan」は、2024年の株式会社イーブックイニシアティブジャパンとLINE Digital Frontier株式会社の合併を経て、現在はLDFが運営するサービスです
——このプロジェクトでフロントエンドエンジニアはどんな役割を期待されていたのでしょう。
山田：1つはバックエンド側との調整です。裏側でバックエンド側が扱っている「話作品」のデータをWeb上でどのように表示するか、擦り合わせる必要がありました。
ほかにも、これまで単行本単位で読んでいたものを、1話単位で読めるようにすると、ユーザー体験が大きく変わります。そこで、従来の体験を損なわないよう調整が必要となりました。実際に動かしてみて、違和感があればまた作り直して。その繰り返しでした。
江口：バックエンドが先、フロントエンドが後に開発を行うため、たまに手戻りが発生することがありました。たとえば、バックエンド側でAPIができあがり、いざフロントエンドで実装しようとすると、データが足りなかったり、フロント側でやりたかったことが実現できない仕様になっていたり。そうしたとき、スケジュールを遅延させることなく、いかにバックエンド側と連携して手戻りを解消するかも重要な要素でした。
——プロジェクトの推進には周囲との丁寧なコミュニケーションが不可欠だったのですね。
山田：そうですね。「連載プロジェクト」はここ数年でもかなり規模の大きなプロジェクトだったので、フロントエンドのチーム内でも密にコミュニケーションを取ることを心がけました。いま、誰が、何を担当しているかの把握をして、フロントエンドチームの体制をしっかり整えたうえで他部署との連携をしていきました。
——プロジェクト中、意思決定が難航した場面はありましたか？
江口：これまで単行本単位で扱っていた分冊版などの「話」を、1話単位の「話作品」としても扱うようになったことで、単行本に収録されている「話」と、連載として独立して存在する「話」が混在するようになりました。その結果、両者の関係性をどう持たせるかが設計上の大きな論点となり、データベース設計の難易度が一気に上がりました。フロントエンド側から見ても、「どの話を、どの条件で取得するのか」を整理しないと実装が進められず、API設計そのものを見直す必要があったのです。
そこはバックエンド側にお願いして、APIのクエリを複数設けてもらうことで対応しました。たとえば、「この単行本の中の第1話を取り出してください」とリクエストすると、バックエンド側でその話を返してもらう仕組みをつくったり。どういうデータが必要で、どんなUIをつくってほしいか、API側への要望を出していきました。
「フロントエンドに閉じないフロントエンドエンジニア」の仕事の幅
——今回のプロジェクトで特に注力された部分について教えてください。
山田：僕はプロダクト開発のなかでも、進捗管理をしたり、要件を整理して実装に落とし込んだりといった役割を担いました。
僕は開発を担当するエンジニアさんと進める中でどうしたら進捗確認がスムーズにいくか、ひたすらヒアリングをして試行錯誤しました。一見するとフロントエンドエンジニアの仕事の範囲からは逸脱していそうですが、僕はこうした役割を担うことにモチベーション高く取り組むことができました。
江口：僕が注力した点は、技術面で大きく2つあります。
1つ目が、APIの負荷を抑えるための設計です。1話単位の「話作品」を読むと、それがユーザーの履歴に残ります。そうすると、必然的にデータベースが肥大化してしまい、APIを呼び出す負荷が高くなってしまいます。さらに、先ほど言った「タイマー回復」機能で、「タイマーが回復しました」と表示するためには、複数の箇所でAPIを呼び出さなくてはなりません。いかにその負荷を下げるかと考えたときに、セッションストレージ（ブラウザ上で一時的にデータを保持する仕組み）にデータを一旦格納し、1セッションごとに1リクエストだけ発生するロジックで動くように設計しました。
2つ目が、モーダルです。「話作品」を購入する際にモーダルが表示されるのですが、その表示パターンがすごく複雑で……。スケジュールを遅延しないように開発を進めるのはもちろん、購入動線にもなるクリティカルなモーダルなので、企画部門の人と一緒に動作確認をしっかりしたうえで実装するように心がけていました。
エンジニアとして実現したいことを追求できる環境がある
——「連載プロジェクト」を通じて、フロントエンドエンジニアとしてどんなことに貢献できたと感じていますか？
山田：フロントエンド組織をどう管理していくか、仕組み化できたことだと思います。
フロントエンドチームは2023年頃からメンバーが急激に増えました。その一方で、組織の管理体制が十分に整っていなかったのです。「連載プロジェクト」をスタートした辺りからそうした課題に向き合い始め、部署内で誰が何をしているかを可視化したり、横のつながりを意識した取り組みを進めたりしています。技術や開発の話とは少しズレますが、こうしたコミュニケーションの取り方を考えるのも、フロントエンドとして重要だと認識しました。
江口：僕はプロジェクトをスケジュール通りに進行させることに尽力してきました。特に、複雑な条件分岐をするモーダルに関しては、自分がそのタスクを遅延させるとほかのページにも影響が出てしまうので、そこは絶対に遅らせないよう細心の注意を払いました。
——プロジェクトを通じて感じた自身の成長ややりがいを教えてください。
山田：フロントエンドエンジニアの組織内で、進捗確認や取りまとめをするポジションの重要性を認識してもらえたことです。自分がそうしたポジションで動いていることがチーム内で周知され、メンバーからの情報が集まりやすくなりました。
江口：個人的に、技術的な知見を得られるタスクや業務に常に携わっていたいという思いがあって、このプロジェクトでもいくつかの新たな挑戦をさせてもらいました。
——江口さんはこのプロジェクトの後に育児休暇を取られたそうですね。
江口：はい。プロジェクトが終わって1年半ほど経過したころに育休を取得しました。
僕が育休に入る半年ほど前に、当時のチームリーダーも3カ月の育休を取得したので、「育休がとりづらい」という空気はまったくありませんでした。育休が終わって復帰してからは何か新しい気持ちが芽生え、Claude Codeを使ったAIによる開発の効率化を試してみたいと思っているところです。
フロントエンドの境界を超え、技術でサービスを動かす仕事
——お二人は今後どのようなキャリアを積んでいきたいと考えていますか？
山田：エンジニアとしてスペシャリストになるよりは、プロジェクト全体をスムーズに進行するマネージャーを目指しています。そのために、技術力を強化したいですね。ebookjapanで用いられている技術以外も積極的にキャッチアップしていきたいと考えています。
江口：僕はフルスタックエンジニアとして、いろいろな技術に触れていきたいと思っています。当社のフロントエンジニアはフロントエンドだけに閉じず、インフラやバックエンドの技術に触れる機会もあります。技術面はもちろん、要件定義や基本設計など、企画職の人たちが担っているような部分の上流工程についても経験していきたいですね。
——AIの進化によって、「UI実装がAIに置き換わる」「フロントエンドとバックエンドの境界が曖昧になる」と言われています。お二人は、フロントエンドエンジニアの価値と役割について、どう考えていますか？
山田：ebookjapanのフロントエンドエンジニアは、色々な部署をつなぐ役割も担っています。そこはAIが進化をしても廃れないでしょう。また、エンジニア以外のメンバーがAIをどう活用していくかという点でも、フロントエンドエンジニアが関わっていくことになると思います。ebookjapanのフロントエンドエンジニアは今後さらにさまざまな場面で活躍できる可能性があるはずです。
江口：UI実装がAIに置き換わるという点は、僕も最近ひしひしと感じています。たとえばFigma MCPでは簡単にマークアップがつくれてしまいますよね。
一方で、最近ではBFF（Backend for Frontend）（※）によるAPIを別途用意することなく、シームレスにSQLを扱ったり、データベース操作ができるようになってきました。実行環境としてはあくまでサーバー側ですが、コード上の役割としては、フロントエンドとバックエンドの境界が以前よりシームレスになってきている感覚はあります。
とはいえ、当社のように歴史の長いサービスだと、その歴史的背景やAPIの仕様などいろいろなコンテキストが大量に蓄積しています。それをすべてAIに置き換えるのはなかなか難しいのではないか……。AIの筋道を立てるために、エンジニアが常に一歩前を歩くという構図は今後も変わらないのではないでしょうか。
※BFF（Backend for Frontend）：フロントエンドとバックエンドの中間に配置され双方の複雑な処理を緩和させる責務を持つアーキテクチャ設計パターン
——最後に、ebookjapan のフロントエンドエンジニアとして働く強みはどこにあると思いますか？
山田：扱う業務の幅が広いので、個人のやりたいことが見つかりやすいのではないかと思います。開発に集中したい、自分のようにマネジメントがしてみたい。そうしたやりたいことにマッチする可能性が高いという点で、よい環境ではないかと思います。
江口：僕は新卒で入社して5年経ちますが、「これがやりたいです」と伝えてNOと言われたことは一度もありません。挑戦したいことに、どんどん挑戦できる環境があります。やりたいことを実現できるという意味で、働きやすい職場だと思っています。
取材・文＝鹿野 恵子（プレーンテキスト）
撮影＝日高 奈々子
※所属組織および取材内容は2025年12月時点の情報です。
