“職能組織”の利点を活かして開発体験を高めていく　フロントエンド開発センターの組織と取り組み

清水氏の自己紹介

清水大輔氏（以下、清水）：では始めていきたいと思います。私からは、LINEのフロントエンド開発センターの組織の紹介をしたいと思います。

まず簡単に私の自己紹介ですが、名前は清水大輔といいます。現在LINEのフロントエンド開発センターの副センター長をやっています。

社歴としてはけっこう長くて、もともとネイバージャパンに入社していて、そこから約13年経っていますが、チームのエンジニアリングマネージャーをしたり、あとは「LIFF」というプロダクトのプロダクトマネージャーをやったりしました。現在は副センター長をやっています。

UITとその対外的な活動について

最初に“UIT”という言葉の説明をさせてください。User Interface Technologyの略ですが、社内ではUITイコール、フロントエンド開発やフロントエンドエンジニアやその組織のことを指しています。

社内もそうですが、私たちはこの“UIT”という言葉を使って、対外的な活動も非常に多くやっています。

1つは「UIT Meetup」という、フロントエンド技術に関するミートアップイベントです。現在は四半期に1回ぐらいのペースですが、行っています。

ここでLINEのUITのメンバーが登壇するのはもちろんですが、ゲストを呼んで外部の方にも知ってもらったり、毎回テーマを変えながらイベントを開催しています。

またPodcastですね。「UIT INSIDE」という名前で、Podcastの運営なども行っています。だいたい2週間に1度ぐらいの更新頻度で行っていますが、サイトの企画・運営だったりも含めて、トータルでUITが担当しています。

メインとなるプロダクトの紹介の前に組織の活動の話をしてしまいましたが、私たちの組織ではこういう対外的な情報発信も非常に大事にしています。

もちろんブランディングという面でもそうですが、個々のメンバーの成長する場。やはりインプットだけではなく学んだことをアウトプットしていくことも成長には必要なことだと考えていて、こういった活動も組織として支援しています。

UITが関わっているプロダクト開発

実際にLINEの中でどういったプロダクトの開発に関わっているのかというと、Webのフロントエンド開発全般に関わっています。

一番の量というかメインとなるものとしては、LINEの“ファミリーサービス”と呼ばれるものの開発が非常に多くあります。（スライドを示して）ここにあるのはまだ一部ですが、「LINE NEWS」だったり「LINEスキマニ」というサービスだったりとか、非常に多くのLINEファミリーサービスをLINEのアプリケーションの中のWebviewを使って提供しています。

今紹介していたものはコンシューマー向けサービスが主なものでしたが、それ以外にも、ビジネス向けのプラットフォームである、LINE公式アカウントの管理画面の開発だったり。

あとは開発者向けですね。LINEのプラットフォームとインテグレーションされたWebアプリケーションを開発するための「LIFF」と呼ばれるフレームワークがあるのですが、そういったところの開発にも関わっています。

なのでコンシューマー向け、ビジネス向け、デベロッパー向けと、領域としては非常に多岐にわたっているところが、LINEのフロントエンド開発、UITの特徴かなと思っています。

職能組織の利点

次にLINEの組織全体、フロントエンドに限らない組織の概念です。事業部に関してはカンパニー制度を取っていますが、開発組織、エンジニアリング組織だったりデザイン組織などは、それぞれ職能組織として分かれています。

なので事業部側で、あるプロダクト、プロジェクトが始まった時に、各職能組織からそれぞれメンバーがアサインされて、プロジェクトの開発が進行していくようなかたちを取っています。

職能組織として分かれていることでの利点・欠点があると思っていて、そのあたりの話をしたいと思います。

まず利点ですが、非常に柔軟性があるのかなと思っています。先ほど言ったように、プロジェクトごとにメンバーをアサインする形をとっています。そのため、個々がやりたいことに合わせて、タイミングだったりとかの調整がもちろん必要ですが、わりと柔軟性を持ってアサインを変えていくことができるのかなと思っています。

あとは組織側の都合とかもいろいろ出てくるわけですが、それに合わせてアサインを変えていくみたいなところも、わりとスピード感を持ってやりやすいのかなというところが、1つ利点かなと思っています。

あとは組織側、UIT側の事情ではなくて、もちろん事業側の状況に合わせてさらに人員が必要となった時に、UITの中で調整して意思決定していくところも非常にスピード感を持ってできるのかなというところです。

あとは、職能組織としてフロントエンドという領域に対して責任を持っている組織なので、なにかフロントエンドに関してボトムアップでの取り組みみたいなことが出てきた時に、先ほどとも一緒ですが、意思決定がすごくやりやすい。ステークホルダーとしてはフロントエンド開発組織だけになるので、非常にやりやすいところがあります。

私たちの組織は、実はフロントエンドに特化したDevOpsのチーム、開発基盤を整備するチームも実は持っていますが、このチームを発足する時にもフロントエンド開発の中で、UITの中で「こういった組織が必要だよね」という話をして、そこである程度合意形成をしてすぐに組織を作って。

さらには、けっこうピンポイントな採用になりますが、そこに対してどういった採用戦略を練ってやっていこうかみたいなところも、組織の中で非常にスムーズにできたのかなと思います。

これが逆に外部で別の組織を立ち上げるとなると、けっこういろいろなところと話をして調整して合意を取った上で進める必要があるので、こういったところは非常に柔軟性を持ってやりやすいのかなと思っています。

あと、その話のつながりで1つ。直近で行っている、注力している領域として、アクセシビリティの改善に非常に注力して今行っています。

こういった取り組みも特定のプロダクトではなくて、やはりすべてのプロダクトを横断的に見る必要があります。こういったところも職能組織として分かれていることで、共通のガイドラインを作ったり、共通のメッセージを事業側に対して発信していくようなところも非常にやりやすいところかなと思っています。

職能組織の欠点

逆に欠点に関してですが、事業側との距離感というか、視点がずれる場合があるのは、ちょっとあるのかなと思っています。

例えば事業側でなにか企画が立ち上がって、それを実際開発していくとなった時に、ある程度もう企画もできあがって、できあがった段階からフロントエンド、UITにも相談が来るみたいな時は、受け取る側の捉え方としては受託のような扱いになってしまっていて。

「フロントエンド開発側からも、早いタイミングで企画やデザインにフィードバックできていたらもっと効率よく進められたのに」みたいなことは、過去のケースとしてあったりしました。

あとは事業側のコミットメントというか、先ほど視点がずれるみたいな話をしましたが、事業がうまくいってなにか成功した時にも、その成功を分かち合うようなところもちょっと距離感があったり、逆になにかうまくいかない時も、そこに対する危機感、温度感が違ったりとかは起こり得るところはあるのかなと思っています。

あとはいろいろなサービスに横断してリソース、アサインというところがすごく関わっているので、いろいろな事業、優先度が常に変わってくる状況であるとは思いますが、例えば「Aという事業もBという事業もそれぞれ優先度が高いです」となった時、「じゃあAとBでのリソースのアロケートをどうしようか」といった時、事業同士で話をしても解決するような問題ではないので。

そうすると、より上位のレイヤーの人と相談をする。取締役だったり、より経営に近い人と話をして調整をしていくような場面が必要になったりします。そうすると、どうしてもスピード感が出ないようなことは職能組織の場合起こり得ることとしてあったのかなと思っています。

こういった欠点はありますが、そこに対して私たちもいろいろな工夫はしています。

職能組織として関わっていますが、そこにアサインされたメンバーがしっかりと事業、プロダクトに対してオーナーシップを持って、ちゃんとフィードバックを出して、「一緒に開発をしていくんだ」という意識を持つためのメッセージを継続して発信するといったところで、意識をだんだんと事業寄りに変えていくみたいなことであったりとか、あとは組織の体制として、LINE NEWSやLINEスキマニといったところで、スモールチームやスクワッドという仮想チームの体制を取っています。

これはLINE NEWSの例ですが、LINE NEWSはLINEの中でも非常に大きなプロダクトになります。ワンチームで開発していくとどうしてもスピード感が出ないし、先ほど言ったような職能組織で分かれているところで、ちょっと温度感のズレみたいなものが出ます。

スモールチームという仮想チームを作ることで、そこのチームに各職能のメンバー、企画だったりUITのメンバー、サーバーサイド、QAが一緒に入ることで、共通の問題意識だったり課題を共有しながら、スピード感を持って進められるような体制を取っています。

ほかにもいろいろ工夫はしていて、1つはUITの中での組織体系も、各領域に合わせてセンターの下に室があって、その室の下に各チームがぶら下がっているような組織体系ですが、まずはその室の単位でも各領域を分けて役割などを明確にすることをやっていたり、またさらにその下のチーム単位でも、各プロダクトとかを細分化して役割を明確化することをやっていたりします。

今話したところですが、例えばUIT1室はLINEのファミリーサービスを担当していて、UIT3室はLINEのファミリーサービスの中でもエンタメ寄りの領域を担当していたり。UIT4室に関しては、LINE公式アカウントだったり、先ほど話したLIFFと呼ばれるデベロッパー向けのプロダクトの開発を担当していたりとか。こういった組織での役割の明確化も工夫しています。

そのほかにもアクセシビリティとか、先ほどの話と繰り返しになりますが、横断的に全社として取り組むべき課題があった時に、UITがリードして、事業側に啓蒙活動というかプロモーションというか、理解してもらうためにいろいろな啓蒙活動をしていくわけですが、こういうところで事業との距離、「同じ、アクセシビリティを改善するんだ」という価値をそろえていくようなボトムアップというか、職能組織から事業に対して行うアクションみたいなところも非常に重要かなと思ってやっています。

こういった職能組織としてUITがありますが、UITの中でのステートメントとして、内部向けに「こういう価値観というか、こういう意識を持ってやっていこうね」というもので発信しているものです。

私たちは常にLINEのユーザー視点、ユーザーファーストで考えて、かつテクノロジーに対して、技術に対して常に興味を持って探求して、それをユーザーのみなさんにも、私たち自身にとっても常に良い体験を追求していく。こういったところを共通の価値観として、メッセージとして出しています。

先ほど紹介したような職能組織だからこその利点は最大限に活かして、UITで働く人たちの開発者体験を高めていくというところは非常に重要だと思っていて、それは継続してやっていきたいところではあります。

あとは技術的なチャレンジ。技術的なチャレンジをしても結局、最終的にはユーザーにとってどういう体験ができるのかを考えられる。プロダクトにどう反映していくのか。ただ技術を「やりました」だけではなくて、ちゃんとプロダクトへの反映を意識してやっていくようなところも継続して取り組みたいところだと考えています。

UITにマッチする人材

最後に、UITとして求めることというか、マッチする人材として考えていることです。フロントエンドって、近年でいうと新しい技術が年々出てくるような領域だと思うんですけれども、そういう新しい技術へのキャッチアップだったり、学習みたいなのももちろん必要になります。

しかし、場合によっては事業のフェーズだったり、プロダクト、サービスの特性によっては新しい技術ではなくて、よりレガシーで枯れている技術を使うようなケースもあると思いますが、そういった場面に幅広く対応していくためには、やはり幅広い技術のナレッジ、知識を持っていくところが非常に大事なのかなと思っています。

あとは、フロントエンドエンジニアって、けっこういろいろな部署とのコミュニケーション、つなぐような役割になることが多くあります。例えば企画・デザインの間だと、企画がワイヤーを書き、それを元にデザインが出来上がり、UITが、フロントエンドエンジニアがUIに起こすわけですが、そこでインタラクションだったりが企画の意図に合っているのか、デザインの意図と合っているのかみたいなところを、間に入ってコミュニケーションしていくような場合もあります。

もちろん、サーバーサイドのエンジニアともAPIの設計だったり、QAともコミュニケーションを取る必要があります。そういった、いろいろなところとコミュニケーションを取るところのハブとして動けるような人は、非常にUITとしてマッチしているのかなと考えています。

最後にです。もちろんフロントエンドの職能組織なので、フロントエンド技術を持っていろいろな開発に取り組んでいきますが、だからといってフロントエンド開発だけをやっていればいいのかというと違うと思っていて。

最終的にはユーザーファースト、ユーザーにとってなにが一番大事なのかというのを考えられる。あくまでフロントエンドという技術は手段なので、手段が目的にならないように。

目的としては、ユーザーのみなさんにどういう価値を提供できるのかを常に意識してフロントエンド開発に取り組んで、変な境界を作らずに、いろいろなところとフロントエンドの境界を越えて、日々起きる課題に対してしっかりとフィードバックを行い、組織横断的に動けるような人は"、非常にUITとしてマッチしているのかなと考えています。

では、私のほうからは、全体の組織紹介としては以上となります。