技術的チャレンジをプロダクトに反映してユーザー体験を高めていく　フロントエンド組織が職能組織として目指すことと乗り越えたい課題

福島英児氏の自己紹介

福島英児氏（以下、福島）：みなさんこんばんは。福島と申します。今日は事業の話やサービスの紹介をするつもりはぜんぜんありません。私たち、フロントエンド組織にフォーカスしてお話ししようと思っています。

あらためて自己紹介です。福島英児と申します。僕は2009年に今の会社に入社しました。当時はLINEではなくネイバージャパンという会社で検索サービスの開発に携わっていました。現在は執行役員としてフロントエンド開発センターのセンター長をやっています。本日はよろしくお願いします。

UIT（User Interface Technology）の歴史

LINEでは、WebフロントエンドのことをUser Interface Technologyの略でUITという名称で呼んでいるので、本日のスライドもUITという名称で進めていきたいと思います。

まず、僕らUITがどういった変遷をたどってきたのかを簡単な歴史として紹介したいと思います。僕が入社した2009年当時のUITは、実は開発組織ではなくデザイン室の配下にあるチームでした。業務も（スライドに）書いてあるとおり、デザイン室の配下で検索や、当時あった「NAVERまとめ」というサービスに携わっていました。

当時はサーバー側でテンプレートを持って、レンダリングしてページ遷移するのが主流だったので、僕らが作っているHTMLをJSPのテンプレートにサーバーサイドエンジニア側で反映してもらって、そこにJSで動的な振る舞いを実装するという業務フローがメインでした。

そんな中、東日本大震災が起こって、LINEアプリが作られるわけです。全社的にもLINEに注力するという流れがあって、そのタイミングでUITチームはデザイン室の配下から開発室の配下に編入されることになりました。このあたりから、LINEの中で立ち上がるWebアプリをシングルページアプリケーションとして開発するというのがメイン業務になり、現在も6割、7割ぐらいがそのような業務となっています。

2015年あたりにその上位組織であった開発室がセンター化して開発センターとなったことで、僕らのUITチームはUIT室に変わりました。室の直下にメンバーがフラットに所属している感じだったので、当時室長だった私と副室長の2人で全体をマネジメントするというのがしばらく続きました。

2018年頃には人数規模的にも30名弱のフロントエンドエンジニアが所属するようになったので、さすがにマネジメント的にもかなり厳しくなってきたこともあり、メンバーの中から何名かマネージャーを選出して、室の下に複数のチームを作りました。

そして2019年頃に、フロントエンド開発センターとしてセンター化します。東京だけではなく、京都開発室やLINE FukuokaそれぞれにUITのメンバーがいる状態だったので、UITメンバーの兼務所属としてセンターに取り込み、1つの大きなリソースプールとしてのフロントエンド組織とすることで、採用面での一貫性やナレッジの共有といった部分で、より強固にすることができたかなと思っています。

直近では室をいくつかに分割して、担当する領域に合わせた室体制というかたちに変わりました。現在では100名弱のフロントエンド開発組織になっています。

UITが組織として抱えていたいくつかの課題

そんなUITは、2009年当初からいくつかの課題を抱えていました。

Webフロントエンド組織として外部にアウトプットする機会や場所がなかったということと、2011年以降はやはりLINEというネイティブアプリケーションのイメージがどうしても強く「LINEに入社してWebで何を開発するんだろう？」など、イメージがあまりないというか、そういった印象を持たれてしまっているという課題がありました。これらの課題はどちらかというと、採用面でかなり苦労するところにつながっていたと思っています。

デザイン室の配下にいた2009年、2010年当時、こういったことを解決する手段として技術ブログ、エンジニアブログをやりたいと思っていたのですが、デザイン室の配下で提案してもそこに開発リソースを割くことになかなか上位の理解を得られず進められませんでした。

2011年以降、開発室の配下に移ってから「こういったことをやりたいんです」と現グローバルCTOの朴イビン、当時の上長に提案したところ、UIT単体ではなく開発組織全体の技術ブログとしてやってほしいというオーダーをもらったので、UITが主体となってエンジニアブログを立ち上げたという経緯があります。2011年9月にエンジニアブログがスタートして記事が投稿されました。

ほかにUIT単体として、四半期ごとにミートアップイベントを行っています。外部からゲストを呼んだり、さまざまなトピックで開催しています。あとはPodcastですね。1、2週間に1回ぐらいのかなり高い頻度でコンテンツを公開しており、実際にLINEでは多くのものがWebで開発されているということを対外的に発信しながらプレゼンスを高めています。

いわゆる技術ブランディングを継続的に続けてきたことで、当初抱えていた課題がちょっとずつ解消されてきていると感じています。ただ現在でも面接をする際にどういう仕事があるのかなかなかイメージを持ってもらえていないというのがあるので、まだまだいろいろ継続してチャレンジしていかなければいけないなと思っています。

UITの長所は「柔軟性の高さ」と「横串の刺しやすさ」

ここからは職能組織のUITの長所・短所をお話できればなと思っています。前提として、これはLINEの組織概念なんですが、このように事業部型組織と職能組織型のハイブリッド型になっており、事業部側はカンパニー制度を取っているのですが、それ以外の開発やデザイン組織は職能組織として存在しています。

そのため、例えばなにか新しいプロダクトサービスが立ち上がる時には、それぞれの組織から人がアサインされてプロジェクトチームが作られるイメージだと思ってください。

職能組織の長所は、やはり柔軟性の高さが挙げられるかなと思っています。先ほどもお話したとおり、アサインベースでプロジェクトに関わることになるので、個人個人のやりたいことや、興味がある領域に合わせてアサインを柔軟に変更できますし、事業やサービスのフェーズによって、こちらのチーム体制を変えなければいけない場合にも体制構築や改編を比較的スピーディーに行うことが可能となっています。

ほかには、横串の刺しやすさも大きな長所かなと思っています。例えばフロントエンド基盤の開発でリソースを投入するという意思決定も、ステークホルダーは自分たちだけなので非常に容易だと思います。

UITでは、実はフロントエンド専門のDevOpsチームをフロントエンド組織センター内に持っているのですが、このチームを作る時も非常に早く意思決定されましたし、その後のこのチームの採用もスピード感を持って進められたと思っています。

実際にボトムアップでのアクションの例として、現在UITではアクセシビリティへの取り組みを非常に積極的に全社に向けて進めています。

私たちUITでアクセシビリティのタスクフォースを作って、ユーザーインタビューを行ったり、ガイドラインやチェックシートの作成などを行ったり、そこから実際にプロダクトに反映する啓蒙活動をしたり、デザイン組織と連携して取り組んでいたりします。これらは、職能組織だからこそリソースをかけて取り組める1つの事例だと思っています。

UITの短所は「事業部との距離」

一方、短所について。（スライドを示して）ここに挙げているように、どうしても事業部側との距離ができてしまうというのはあると思います。もしかしたらみなさんにも経験があるかもしれませんが、仕様、デザイン、スケジュールなどがだいたいすべて決まった状態で「ちょっとこれのフロントエンド開発をお願いします」という依頼のされ方をされてしまったり、どうしても事業部側との温度感に差ができてしまうことがあると思います。

事業の売上がその期にバンッと大きく跳ね上がったとしても、それが自分たちの報酬にダイレクトに反映されるのかといえばそういう構造ではないですし、逆にサービスが振るわなくて縮退していく場合にも、そこに対して大きな危機感を持って携わっていくというのはなかなか難しいという状況があるのかなと思っています。

また、私たちは横断してさまざまな事業に関わっているわけですが、開発のメンバーやリソースは有限なので、例えば複数の事業でなにかフェーズが変わってエンジニアを追加投入する必要があるという場合に、どういう優先度付けで人をアサインしていけばいいのかが僕らだけでは判断できないことがあり、ボトルネックになりがちになることがあります。

こういう場合には、もっと上位レイヤー、つまり取締役や上級執行役員に手札を見せて「今はこういう状況ですが、どういった優先度で対応していけばいいですか」と判断を仰ぐことになるので、どうしてもスピード感が落ちてしまうというのはあるかなと思っています。

このような短所を解決していくには、僕ら自身が事業側に対して、オーナーシップを持って関わっていくという意思や姿勢を継続して伝えていったり、また組織体制で距離を縮めていったりすることも1つの解決方法なのかなと思っています。

例えば「LINE NEWS」など「LINEスキマニ」という事業では、スモールチームやスクワッドといった名称で非常に小さなチームを大きなプロジェクトの中に作って、そこにプロダクトオーナー、各いろいろなエンジニア、QAエンジニア、フロントエンドエンジニア、サーバーサイドエンジニアが所属して、この小さなチームでスプリントを回していくことで大きなプロジェクト規模でも距離感を縮めていくという工夫をしています。

ほかには、toC・toBなど、事業領域に合わせて、UITの中で室を分割して明確に対応領域を決めることで、自分たちがその領域に対して責務を担って事業にコミットしていくんだという意識をより持たせるようにしています。

このようにフロントエンド開発センターの配下では室ごとに担当領域を持っており、さらにその下のチームも担当サービスが決まっています。一人ひとりに自分が担当している領域に対して責任を持って携わっていくという意識を持ってもらうような工夫をしています。

横断して関わる組織だからこその長所を活かして、アクセシビリティなどの取り組みも広く影響を与えていけると思いますし、こういったことは短所として挙げた事業部側との距離を縮めていく1つの要素になると思っています。

組織の長所を最大限に活かしてユーザー体験を高めていく

今後もUITが職能組織として継続していくこと。今ここでお見せしているのはUIT内部で伝えているステートメントです。やはり私たちが一番見るべき・意識するべきものはユーザーなので、常にユーザー中心に物事を考えて、技術的な探求心を怠らずに、ユーザーと自分たちに対して良い体験を与えていきましょうということをUITのステートメントとして伝えています。

そういったことも踏まえて、職能組織の長所を最大限に活かして、開発者体験を高めていきながら技術的なチャレンジングをしっかりとプロダクトに反映して、ユーザー体験を高めていくことが私たち職能組織として継続していくことだと思っています。

LINEではその評価方法の1つとして、同僚による360度評価というものがあります。LINEらしいやり方を11項目にまとめた「LINE STYLE」というガイドラインがあり、これに沿ってその360度評価が行われます。

その11項目の中には、ユーザーニーズやディティールの追求という項目があり、これらをどれぐらい意識して行動しているのかというのは、同僚からの評価にもつながっていくと思っています。

UITとして求められること

まとめです。UITは、適切な技術選択ができることが求められます。これは別に常に新しい技術を使っていればよいということではありません。もちろん事業やプロダクトのフェーズによっては、枯れた技術を選択する場合もありますし、いかに多くの技術選択肢を持っていられるかが大事だと考えています。

また、フロントエンドは企画、デザイナー、サーバーなどの複数の部署とコミュニケーションを取る機会も多いので、コミュニケーションのハブとしてプロジェクト進行できることがやはり理想ですし、フロントエンドエンジニアにはユーザーにとって何が一番大事なのかを優先して考えてもらいたいと思っています。

とはいえ、フロントエンドエンジニアはフロントエンドの開発だけやっていればいいとは考えていないので、いかに自分たちの領域や境界、いわゆるバウンダリーを越えて、ユーザーに対して良い体験を与えられるかをしっかりと意識できる人がUITにフィットすると思っています。

LINEのエンジニアリングカルチャーには「Take Ownership」というのがキーワードの1つとしてありますが、ユーザーが直接触る部分を開発するフロントエンドエンジニアだからこそ、オーナーシップを持って開発に携わっていただきたいと考えています。私からは以上です。ありがとうございました。