「振り返り」を活かし、スピード感を上げるために組成されたCFチーム

——LINEマンガの開発はどのような組織体制で行われているのでしょうか。

白井：当社の開発組織は、クライアントやサーバー、データサイエンス、データアナリティクスといった領域ごとに分かれています。それぞれの領域にメンバーとマネージャーがいる、規模の大きな組織ですね。

プロダクト開発の起点となるのは、企画側から上がってくるアイデアです。そこから、実現の可能性やそれに必要な調査や準備について各開発領域のマネージャー同士で詰めていき、優先度や方向性が固まった段階で担当者が決まり、案件が発足します。

案件が正式に立ち上がったら仕様をレビューし、概算の工数を見積もり、あらためてスケジュールを引き直したうえで、開発がスタートします。

——2024年にCFチームが立ち上がりました。その背景にはどのような課題があったのでしょうか。

白井：当社はプロジェクトベースで開発チームを組んでおり、プロジェクトが終われば必ず振り返りを行って、課題の洗い出しをしていました。ただ、振り返りで出てきた改善点を、次の開発に活かせる場がほとんどなかった。同じメンバーで次の案件に入るケースが少なく、せっかく得たノウハウや学びが組織に蓄積されにくかったのです。

その結果、いくら個々が頑張っても開発スピードがなかなか上がらない。振り返りはしているのに、「振り返りの振り返り」まで辿り着けない。そんな悩ましい状態が続いていました。

もう1つ、「意思決定の時間」も気になっていました。マネージャー陣のタスクが多く、スケジュールは常にミーティングで埋まっている状態。案件ではスピード感が強く求められているのに、スピードを上げるための意思決定は簡単に前に進まない。そのギャップにもどかしさを感じていました。

——そうした背景からCFチームが立ち上がったのですね。あらためて、CFチームの狙いやミッションはどこにあるのでしょう。

白井：1つ目の狙いは、CFチームが早い段階から案件に関われるようにすることです。従来の開発フローでは、スペックや方針、スケジュール感などがすでに決まっているケースがほとんどでした。そうなると、議論の出発点が「期限に間に合わせるためにどの機能を削るか、どこをスペックアウトできるか」になりがちだったんです。

もう1つは、チームの固定化です。案件が終わるたびにチームが解散する体制では、振り返りで出た改善点を次に活かしきれない。メンバーを固定すればチームとしての学習が積み上がり、結果的にスピードも上がっていくはずだと考えました。

そして3つ目が、マネージャーの負荷軽減です。開発チームを固定メンバー制にすれば、メンバーのアサイン作業自体が不要になります。そこに割いていた時間を、マネージャーが本来注力すべき部分に使えるようにする狙いもありました。

「固定チーム」だからこそ、職能関係なく議論がしやすい

——CFチームが携わっているプロジェクトの流れを教えてください。

本田：まず、チーム内に企画担当者がいるので最初から一緒に企画案をブラッシュアップしていきます。 それをどう実装するかについては、CFチームのエンジニア3名を中心に方針を決めていきます。その後は、実装を一気に進め、最終的には企画チームやデザイナーも含めて、みんなでレビューを行います。スクラムやアジャイルでよくある進め方に近いですね。

白井：レビューでは必ずデモを行っています。例えば、新しい機能を試す際には実際に企画チームのメンバーに触ってもらい、違和感があればその場でフィードバックをもらってすぐに修正するようにしています。リリース前にそうしたやり取りができるのは大きいですね。固定メンバーのチームで取り組むからこそ、こうしたやり取りがしやすく感じます。

——皆さんはプロジェクトの企画・デザイン段階から参画されているわけですが、その際、サーバー・iOS・Androidといった別々の技術軸からどのような観点で議論に入っていくのでしょうか。

白井：技術領域の違いはあまり意識していません。私たちが企画チームと話すのは、「本当に必要な機能は何か」という点です。ユーザーストーリーとして、どんな課題を解決したいのか。そこを丁寧に聞きながら、「この方法ならより工数が減らせそうだ」「ユーザーの反応が得られる別の方法はないか」といった議論を重ねていきます。

本田：議論する段階では職能は関係ありません。デザインについても、素人なりにデザイナーに対して意見を出します。お互いにフラットなやり取りを重ねた上で、実装フェーズに入っていく。そこで初めてそれぞれの専門性が活きてきます。

——CFチームでは、スピード感をもって開発することも大きなミッションの1つかと思います。そのスピードを支える工夫があれば教えてください。

白井：私が意識しているのは、自分のタスクより他の人のタスクを優先することです。自分の作業が順調に進んでいても、他の誰かが詰まっていたら、チーム全体としては前に進んでいかない。なので、自分のタスクに余裕があるときは、誰かのサポートに入ります。逆に、自分がどこかでつまずいたときは、遠慮せずにヘルプを出します。

固定チームで普段からコミュニケーションを重ねているので、何かあったときには手を挙げて、みんなで集まってその場で解決するようにしています。

——従来の開発体制にあった課題から、CFチームでは振り返りを大切にしているとのこと。どういう場で、どんなことを振り返るのでしょう。

白井：1スプリント3週間として、その区切りごとに振り返りをしています。そして、次の振り返りでは、前回の振り返りで出たトライが実際にできたのか、できなかったのかを必ず確認します。もしできていなければ、「なぜできなかったのか」をもう一段深く振り返る。振り返り自体を、継続的に振り返っていくイメージですね。

また、毎日17時にデイリーミーティングを行っているのですが、そこに前回スプリントで出たトライを明示的に書き出して、常に目に入る状態にしています。例えば、企画の方にレビュー時のテスト切り替えをしてもらう今のやり方も、もともとは振り返りで出た改善案でした。

朴：作業以外にも、「休みを取っている人がいたのに気づけなかった」というケースも議題に上りました。それを自動化して気づけるようにするなど、良かった点、改善点があればどんな内容でも振り返り、また次回にレビューしています。

クロスファンクショナル組織で挑んだ「プレビューアー機能」改善プロジェクト

——CFチームが関わった「プレビューアー機能（試し読み機能）」の改善プロジェクトについて聞かせてください。

本田：プレビューアー機能は、チーム発足当初から取り組んでいたテーマの一つです。当時、ユーザーと新しい作品との出会いをいかに増やすかという課題があり、その文脈で浮かび上がってきたのが、プレビューアー機能でした。ユーザーがマンガを読み終えた後、関連する作品をサムネイルで見せるだけでなく、実際に読める形で表示する機能です。

LINEマンガ内プレビューアー機能の画面イメージ 『四度目の夫』より引用　©Chinami Akio/LDF

白井：サムネイルだけだとどんな作品なのかが伝わりづらい。タップして詳細画面を開くというワンアクションも意外とハードルが高い。だったら、強制的に表示して読んでもらったらいいのではないかという発想ですね。

今回はとにかくスピードが求められていたので、工数はできるだけ抑えつつ、ユーザーにとってプラスになる形は何か、みんなで仕様を議論して現在の形に落ち着きました。開発期間は約1カ月。具体的にプレビュー画面をどうするか、仕様に関しては1週間ほどで形が決まりました。

この進め方が成立するのは、チームが固定されていて、企画のメンバーが権限を持っているからです。議論を重ねるなかで「マネージャーに判断を仰ぐ」という流れになると、途端に伝言ゲームが始まり、時間のロスになってしまいます。

——プレビューアー機能プロジェクトで苦労した点や工夫したポイントがあれば教えてください。

本田：LINEマンガはトップセールスのサービスです。機能を一つリリースするだけで、非常に多くのユーザーに影響が及びます。特に、プレビューアー機能は既存の仕様に大きく関わる部分が多く、その理解がまず大変でした。例えば、どの作品を表示できるかといった条件は、コンテンツの許諾による部分が大きく、前提条件を一つひとつ把握していく必要がありました。

QAのテストケースを網羅するのも大変で、調べていくなかで初めて「こんな表示パターンがあったのか」と気づくこともありました。ただ、それもクライアントエンジニアやQA担当と連携し、スピーディーに確認できたため、テスト観点の作成も漏れのない形でできました。

朴：ビューアーは一番重要な画面です。だからこそ、最初の設計段階から、メモリや画像処理、UIレンダリングといった、あらゆる技術的な要素を考慮する必要がありました。テストケースも多く、インタラクションも複雑でしたが、デザイナーとコミュニケーションを取りながらじっくり向き合ったことで良い成果が出たと思っています。

白井：私の担当領域ではSwiftUIで作りたいという話が出ていました。既存機能にプラスアルファする形で手を入れるのはリスクが高いからです。一方で、今回は新規機能として画面を一から作るプロジェクトだったので、普段なかなか挑戦できないことにトライできるいい機会だと考えました。そこで、新しい技術を使ってモダンな画面を作りました。OSのバージョン差による不具合など、想定外の挙動もありましたが、最初からQAチームの方が入ってくれていたので、そうしたリスクも前提として共有できていました。

結果的に1カ月という期間でリリースできたのは、このチーム構成と、早い段階からの連携があったからこそだと感じています。

——リリース後の数値の変化やユーザー、社内の反応など、プロジェクトの成果を教えてください。

白井：強制的に作品が表示されることに対しては、ユーザーの意見が二極化していました。今後は全ユーザーに一律で同じ体験を提供するのではなく、反応が薄い人には極力出さない。一方で、しっかり読んでくれる人には、表示量を多くする。このように出し分けを工夫することを次のアクションとして取り組めたらと思いました。

——このプロジェクトを通じて、それぞれどのような学びや発見がありましたか？

朴：私にとっては、今回が初めてのスクラムチームでした。 最初は正直、スピード感についていけるか不安もありましたが、2人がアドバイスをしてくれて、少しずつ慣れることができました。現在の開発スタイルは、自分から意見を出し、議論に参加しながら、みんなで一緒に作っている感覚がある。結果として、仕事そのものを以前よりも楽しめていると感じています。

コンパクトなチームで開発に挑むからこそ得られる成長と、キャリアの広がり

——皆さんが考えるCFチーム組織で開発する難しさや良さを教えてください。

白井：LINEマンガは組織が大きい分、全体に浸透させたいことがあっても個人の力だけではどうしても限界がある。けれども、チームで取り組めばそのハードルは一気に下がります。自分1人ではできないことも、チームや有志で集まれば前に進められるし、そのほうが説得力もある。CFチームにはそんな良さがあります。

本田：対話をより重要視するアジャイルなやり方は、組成初期にどうしても一人ひとりの負荷が上がってしまう。私は、 “アジャイルネイティブ”なのでこのやり方が自然ですが、他のやり方に慣れている人はこの環境に戸惑うかもしれません。

朴：私は当初、かなり戸惑いました。周囲と衝突したこともありましたね（笑）。

——今後、この組織として挑戦していきたい領域やテーマを教えてください。

本田：大前提として、チームに与えられたKPIを達成すること。加えて、クロスファンクショナルという新しい形のチームで、何ができるかを示していきたいと思っています。従来のチームには従来の良さがある。その上で、CFチームの強みや価値を成果として示していけたらいいなと思っています。

——あらためて、CFチーム組織での開発のどんなところにおもしろさを感じていますか？

白井：他の領域の人たちの動きをリアルタイムで見られることです。企画の人がプロダクトの提案をどうやっているか、サーバー側の人がどこに注意し、どこに苦戦しているか。私自身はiOSエンジニアですが、他のキャリアにいつでも転換できそうなほど、他のメンバーを観察できます（笑）。と同時に自分の足りない部分も丸見えになるので、メンバーに自然と助けてもらえる。この関係性そのものがCFチームで働くやりがいですね。

朴：私は、こういう開発スタイルはほぼゼロからの経験でしたが、皆さん何でも教えてくれるし、隠さずに全部見せてくれる。作業で苦労していることを正直に話せるようになりました。その積み重ねで自分の成長が実感できていますね。

——LDFではどんな人材が活躍できると思いますか？

白井：タスクを振られるのを待つ人よりも、自分から課題を見つけられる人。CFチームは手を挙げれば挙げただけ任せてもらえる環境です。

——LDFやCFチームでの経験は、5年後、10年後の皆さんのキャリアにどのように関わってくると思いますか？

本田：AI全盛の時代、エンジニアとしてこの先ずっと同じ形で働けるかは誰にも分かりません。ただ、そういう時代だからこそ「今、自分に何ができるか」を探し続ける自主性が重要ですし、CFチームではそのような姿勢も培われると思います。

CFチームは、企画やデザインなど、エンジニア以外の職種と日常的に関わります。技術だけでなく、事業やプロダクトの視点も自然と身につくので、キャリアの選択肢も自然と広がるのではないでしょうか。

取材・文＝鹿野 恵子（プレーンテキスト）
撮影＝日高 奈々子

※所属組織および取材内容は2026年1月時点の情報です。

LINE Digital Frontier株式会社
https://ldfcorp.com/ja

LINE Digital Frontier株式会社の採用情報
https://ldfcorp.com/ja/careers/