2020年9月23日に開催されたCTOmeetupのイベントレポートです。

今回はフリーランスで活躍する田中さんをモデレータとして、サイボウズの佐藤さん、リクルートの古川さんをお招きし、フロントエンドエンジニアの未来についてディスカッションを行いました。

質疑応答も交えながら、組織と個人、両者の視点でフロントエンドという領域の本質が語られた今回。フロントエンドに関わる技術や考え方に興味がある方、開発組織に興味がある方はぜひご注目ください。

フロントエンドエンジニアの未来戦略　ご登壇者

フロントエンドの開発組織について

フリーランスのエンジニアが組織に入る際にチェックすべきポイント

田中正吾さん（以下、田中）：まずはフロントエンドの開発組織について話していきたいと思います。僕はフリーランスエンジニアとして、技術アドバイザーも兼ねて外部から組織に入ることが多い立場です。その際は、Slackなどを用いたコミュニケーションをどのように進めていくのかという部分が重要なポイントになると思っています。

Slackがきちんと機能していれば情報収集しやすいですし、逆にDMばかり来るような状況の場合は全員に情報が行き渡っていなかったりします。組織に対してまず探りを入れて、コミュニケーションを上手く取ろうとしますね。

古川陽介さん（以下、古川）：フリーランスとしてジョインする際は、コミュニケーションツールを見て自分の動き方を決める感じなんですね。

田中：具体的には#generalなど自分が招待されていないチャンネルを見て、どういう流れで情報がまとめられているのかを見ます。GitHubのドキュメントが流れているチャンネルなんかを見つけるとハッピーですね。早めに情報をキャッチアップして、自分に関係がある事柄かどうかを聞いたりします。

古川：個人戦略的にはすごくいいかもしれないですね。

田中：ガッツリ入るわけではなくオリエンテーションも無い場合は、そういうフィードをきっかけに使うことがあります。

佐藤鉄平さん（以下、佐藤）：規模感としてはどういう組織に入ることが多いんですか？

田中：大体組織としては10～30人程度、フロントエンドエンジニアのみだと5～6名で回すプロジェクトに入ることが多いです。

サイボウズとリクルートの持つ組織横断型のエキスパートチーム

佐藤：サイボウズの開発組織はざっくり200名程度所属しています。エンジニアだけでなくプロダクトマネージャーやデザイナー、テストエンジニアなども全て含めた数字です。古川さんのところはどうでしたっけ。

古川：リクルートの開発者はディレクターやエンジニア、データ系技術者を含め、toCサービスに携わる開発者全体で1000名以上です。僕はその中でもフロントエンドエンジニアリングを主体としているメンバーのみを統括していて、大体20名ですね。

先程の田中さんのお話は個人戦略として組織にどう探りを入れているかという内容でしたが、組織戦略としてはそもそもどのように組織を作るかという視点になりますね。恐らく「フロントエンド」という領域に特化した組織を改めて作る風潮になったのは、ここ5、6年の話だと思っています。特にサイボウズさんはそういう流れにいち早く気付いていた印象です。

佐藤：サイボウズはもともとBtoBのWebアプリケーション開発を20年以上手掛けている会社で、組織構成としてはプロダクトチームがあるだけでした。フロントエンドやバックエンドという明確な区別も無い、クロスファンクショナルなチームでしたね。

一方で古くはAjax、HTML5といった歴史から始まってここ数年に至るまでに、フロントにどんどんリッチなものが期待される世界が広がっていきました。Webのテクノロジー自体も進化して、要求される技術とやるべきことが増えていく中で当社が2017年に新設したのが、クロスファンクショナルなプロダクトチームを支援するエキスパートチームです。

それまでフロントエンドのメンバーが横のつながりを使ってノウハウを共有していた状態から、組織横断でフロントエンドを担うチームを明確に作ったということです。誰がそのチームで活動するのかという話になったときに入社してくれたのが小林徹さん（@koba04）という方で、彼がリードしてフロントエンドエキスパートチームが立ち上がりました。

古川：うちと完全に一緒です（笑）。リクルートはホットペッパーやSUUMOなどサービスごとに会社も分かれています。各社に所属しているエンジニアは横のつながりがどうしても減ってしまうので、僕が入社してから1年後の2017年に「アプリケーションソリューショングループ」という横のチームを新設しました。

ただ、こういった体制移行の難点となるのは、エキスパートチームを率いることができる人材がなかなかいないという点です。

佐藤：いればばっちりということですね。

田中：僕もエキスパートチームの立ち上げの初動で参入するケースがあり、いくつかのチームに対してナレッジをシェアして平均化するという目的で、いわゆる「情報発信者」を一緒に見極めたりします。

縦のチームと横のチームが上手く関わるための動き方

佐藤：横断チームを作るところまではいいのですが、プロダクトチームとの関わり方は難しいですし、多様なやり方があると思います。古川さんのところはどういう形で関わるスタイルですか？

古川：プロダクトラインも含めて評価することが多いですね。APソリューショングループのメンバーは必ず一人一つはプロダクトラインに関わって、何かしらの新しいものを作るようにしています。その目標に対する評価は、エキスパート目線に加えて、プロダクトラインにコミットできているかどうかの2軸で決めています。単純に自分のためだけに技術を尽くせばいいということではないのがポイントです。

また、プロダクトラインと関わって得た知見は広報したりOSSでライブラリを公開するなど、リクルート全体のために発信する部分まで含めてミッションにしています。

田中：シェアは大事ですよね。それぞれのサービスは開発時期も違いますから、セキュリティーの絡め方やトラッキングの仕込み方も変わります。そのときに別の場所で使ったテクノロジーをどう活用するのかという話はカジュアルに出てきます。

古川：鉄平さんのところはどうですか？

佐藤：うちはエキスパートチームのミッションが3つあります。一つはプロダクトチームの支援で、比較的大きな比重を占めています。支援内容はチームによって違いますが、プロダクトチームのメンバーに定期的にヒアリングをして課題を決め、モブプロをしたり直接チームに入ったり、独立したプロジェクトとしてエキスパートチームの担当者が進行するといった対応をします。もう一つは新しい知見の探求です。社外から知見を得たり、新技術を使った研究開発をしています。最後が社外への発信です。ブログを書く、OSSにコントリビュートするといったことですね。

古川：その3軸はメンバー全員が全て行うんですか？

佐藤：グラデーションはあるかもしれませんが、基本的にはチームでバックログを持ち、全員が取り組んでいる感じです。

クロスファンクショナルなチームがモブプロをする理由

古川：鉄平さんの組織が基本的にコードはモブプロで書いてるのが2、3年前なのですが、画期的すぎて当時は衝撃を受けました。でも、最近は僕のチームでも同じようにモブプロをすることが多くなってきていますし、効率が良いとまで感じています。強制的に集中できる環境になりますし、知識が平滑化されるんです。

佐藤：アジャイルやスクラムの文脈でいくと、やはりプロダクトチームは基本的にクロスファンクショナルなチームとして完結し、ユーザーストーリーの実現を目指すのが基本です。技術中心の組織横断型のチームが関わるのは本質的にはフィットしないやり方なのですが、モブプロによってぐっと入り込みやすくなります。

また、クロスファンクショナルチームの在り方を突き詰めると、モブプログラミングやモブワークになっていくんですよね。一つのチームで一つのタスクを最短でこなそうとするなら、全員が一緒に同じ画面を見て解決すれば待ち時間はゼロです。リードタイムの短縮やフロー効率を重視する考え方というわけです。 さらにモブプロには、知識の共有やオンボーディングがやりやすいというメリットもあります。これらの利点から、組織横断型の支援チームとモブプロは相性がいいのだと思います。

古川：おっしゃる通りですね。僕たちのチームも知識を100％理解している人はかなり少なくて、70～80％の人もいれば、10～20％の人もいる。そういう人たちが一緒にモブプロをすると、全員の知識が上の水準に引き上げられていきます。

知識が平滑化されていると、メンバーの誰かが会社を辞めてしまってもほかの人がすぐ代わりを務めることができるといった副次的な効果もあります。トラックナンバーの数が少しずつ増えていくので、組織的にはかなり楽になりますね。

佐藤：エキスパートと言っても、フロントエンドのソリューション知識を持っているだけでは上手く解決策を見つけられない場合もあります。ドメイン知識を持ったプロダクトチームと同じ場所で議論することで問題解決につながるのもモブプロの利点ですね。

一方でマイナス面ももちろんあって、一人で作り上げる達成感はあまりありません。

田中：「みんなの知識」になってしまいますからね。

佐藤：そのあたりはメリットとデメリットを理解して上手くやっていく必要がありますね。

田中：僕も外部から入る際には、ミーティングの時間を決めて解決しようとしますね。それぞれの部署の知識をその場で聞けますし、解決策の選択肢もすぐに選んでもらえます。一人ずつ会ってヒアリングしていると平気で1ヶ月以上かかるような案件も短期間で効率的に進めることができるので、モブプロというやり方にもすごく共感します。

前半質疑応答

オンラインライブにて、ご登壇者の皆さんにリアルタイムで参加者から質問をいただきました。

緩やかにつながっているフロントエンドとデザインの領域

質問者：デザイナーとフロントエンジニアの棲み分けはどうしていますか？

 

古川：リクルートはデザイナーとフロンエンドが明確に分かれています。デザイナーはプロジェクトにあまり常駐していないのですが、本当はプロダクトラインに意志を持ったデザイナーがいたほうがいいと思っていますね。デザイナーのキャリア的にも、PhotoshopやIllustratorを駆使してただUIを作るだけではなく、UXデザイナーやプロダクトマネージャーに進むような道を浸透させたいです。

ただフロントエンドエンジニアもデザインのツールやスタックを学べるようにはしていきたくて、流行をキャッチアップして一度使ってみるといった試みをしています。

田中：僕もデザイナーとフロントエンドがお互いの知識を共有するとコミュニケーションがスムーズだと思いますね。PhotoshopやIllustrator以外に、Adobe XDなどデザインのフレームワークを伝えるツールでカジュアルにやり取りできるだけでも違います。佐藤さんはいかがですか？

佐藤：うちは小さなサービスの場合はデザイナーが兼務で入ることが多いのですが、メインプロダクトの場合はプロダクトチーム自体にデザイナーが所属しています。また、それとは別に「デザインアンドリサーチチーム」というエキスパートチームが存在していて、デザインやUI/UXに関するユーザーテスト及びリサーチを組織横断的に行っています。デザイナーとの協業するためのツールという意味では、Figmaを使うことが多いです。

古川：うちもFigmaは多いかもしれません。

佐藤：その上でコミュニケーションをしつつ、実装段階になると細かい部分は一緒に画面を見てモブプロで進めることがあります。プロダクトチーム内のデザイナーとフロントエンドエンジニアの境界は緩いかもしれません。

アクセシビリティエキスパートも二名います。そのうち一人はご自身も全盲の方です。アクセシビリティの領域で活動する人も出てくると、デザイナーとフロントエンドを横断するような形になりますね。

古川：アクセシビリティやパフォーマンスといったように、いわゆるフロントエンドの技術要素は細かく分かれてきていますし、フロントエンドとデザインの垣根を行き来しないと達成できない事柄も数多くあります。アクセシビリティは特にそうですよね。「色覚異常の人に対してどの色を用いるべきか」というのはデザインの観点ですし、フロントエンドエンジニアリングの観点でいけばセマンティック的にもスクリーンリーダーのマークアップ的にも優しいタグ付けをするといった話があります。

フロントエンドとデザインの垣根を超えた動きができると、組織としては大変ではありつつも楽しいところですね。

モブプロにかけるべき時間と効率的な運用方法

質問者：モブプロの時間や人数はどれくらいでしょうか？また、モブではやらない、向いていないタスクはありますか？

 

佐藤：僕自身はモブプロのエキスパートではないという前提でお話ししますが、まずモブプロというものは疲れるんですよ。

古川：全速力でずっと走っている感じですよね。

佐藤：なので、1日8時間モブプロをするのは無理です。モブプロの欠点は時間を同期しなければいけないということで、働き方の自由度が高い組織とモブプロはあまり相性が良くありません。うちもそうですが、コアタイムがズレる場合は共通している時間でモブプロしようということになります。必然的にフルタイムでモブプロはできないんです。

ディテールはチームによって全く違いますが、あるチームではメンバーが揃う昼間の任意の時間にモブプロを行い、ほかの時間は個人の調べ物をするといった時間の使い方をしています。

田中：古川さんはいかがですか？

古川：うちは30分～120分程度ですね。モブプロ中は3、4名の時間が完全に拘束されるので、2時間以上やるとその人の都合やこなすべきタスクに影響が出てしまうことがありますし、1時間もあれば解決することが大半です。

逆に短時間で無理なら何時間モブプロしても解決しないケースが多いので、そういうときはエスカレしています。

佐藤：うちの場合、プロダクトチームは1日4～5時間はやっています。基本的にチームのバックログを進めている間はずっとモブという状態ですね。

古川：常時接続も短時間も両方やったことがありますが、タスクをどう進めたらいいか手探りすぎてわからない場合は前者のほうがいいと思います。その場で話をして意思決定しながら進められるので。

佐藤：クロスファンクショナルなチームでリードタイムを縮めるという文脈では、基本的にそのほかのタスクは兼務せず、集中してモブプロを行うチームを作るのが前提ですね。エキスパートチームよりも、プロダクトチームに向いた開発スタイルです。

フロントエンドエンジニアの未来戦略

求められるスキルが細分化されている状況でどう勝ち残るか

田中：次のテーマでは、フロントエンドエンジニア一人ひとりのキャリアがどう進化していくのかといったところを話していきたいと思います。

フリーランスのフロントエンドエンジニアとしては、VueやReactなどのフレームワークを学んで仕事を探すといったことも非常に重要です。一方でフロントエンドはIoTや3Dといった分野でも知識を活かせることが多いので、僕自身はどちらかというとそちらへ足場を広げていくのがいいかなと思っていますね。Webにデータがつながればどんなデバイスでもなんとかなる、というのが大事にしているマインドです。

古川：確かにJavaScriptが動くデバイスは本当に増えました。技術的にコモディティ化しているのは喜ばしいところですが、専門性を謳っている人からすれば自分たちのスキルを改善していかなければいけないので厳しい部分もありますね。

少し前ならwebpackで高度な技術を使えるというだけでもはやされていましたが、例えばNext.jsでやってしまおうといった対処もコモディティ化してきています。webpackの知識は今も必要ですが、それだけで食べていけた時代はそろそろ終わるのかなという気がします。

田中：一抹の寂しさを感じますね（笑）。僕もNuxtとかを動かしたときに、昔悩んでいたことがあっさりできると「これは見積もりに含められないな」と思ったりします。

古川：昔はwebpack時間みたいなものが見積もりされてたんですか？（笑）

田中：実際難しいことなので、環境構築のための時間は換算していましたよ。でも今は調べればすぐに出てきて1日で終わる。

古川：そこは今までフロントエンドエンジニアになるための参入障壁だったと思うんですよね。それよりも早くアプリケーションを作りたいという人が増えるのはいいことかなと思います。

それを踏まえて今後フロントエンドエンジニアに何が求められるのかという話だと思うのですが、一つヒントになるのは、必要なスキルが細分化されているという点です。パフォーマンスやアクセシビリティに配慮できる、きちんとしたセマンティックHTMLを書ける、あるいはプロダクトマネージャーのような動き方ができるといったように、専門性が分かれていくのが面白いポイントかなと思います。パフォーマンス一つを取っても奥が深いですし、ブログに書いてあることをそのまま鵜呑みにするのではなく、自分で書いて知見をためていける人たちが伸びそうですね。

プロダクトが持つ問題点を正しく見極めるのも重要なスキルの一つ

佐藤：採用する側からすると、プロダクトの課題を解決するという視点で「あなたは一体何をしてくれるんですか」という話になる時代なのかもしれませんね。

フロントエンドカウボーイのような人たちがReactだAngularだと言ってチュートリアルをしていましたが、それだけではプロダクトチームと「プロダクトがどういう課題を持っていて、何のためにその技術を導入するのか」という会話ができないんですよね。

古川：一時期そういう人は多かったですね。

佐藤：技術に特化して、自分が必要だと言われる場所に行ってやることをやって去っていくという割り切った戦略もなくはないですが、相当な技術力が必要ですね。

田中：僕はIoTを含めJavaScriptなどの技術を用いたいろいろなソリューションを提案することを心がけていますが、じっくり先方にヒアリングすると不思議なことに技術を使わずに解決する方法が結構出てきます。コードを書く前にやることが見えてくるので、コミュニケーションはやはり重要ですね。

古川：「問題がそもそもそこには無い」と気付かせることができるのもまた一つのスキルですね。上層部は何か新しい機能やプロダクトを作ることが解決策になると思いがちですが、そうとは限りません。もっと根深い部分にある問題を技術無しで解決できるなら、そのほうがいいんだろうと思います。

フロントエンドに大きく影響するWeb回帰の流れ

佐藤：別の話題ですが、Web回帰の流れは若干ありますよね。一時期は完全にモバイルアプリ時代で、モバイルエンジニアの求人がかなり増えました。

当社は業務用のプロダクトを開発しているので基本的にずっとWebの重要性は変わりませんでしたが、ここ最近は世の中でもまたWebが盛り上がっている雰囲気を感じています。一つの例がコロナ禍におけるメルカリUSのニュースです。コロナによって在宅が増え、モバイルよりもPCのWebサイトのほうが利用率が上がり、Webサイトを強化したら数値的に大きな成果が出たそうです。AMPの世界観しかり、Webのテクノロジーは進化していますし、やはりWebにはWebの良いところがあります。

当社の文脈で言えば、JavaScriptでAPIを作ったりSDKのファイルにしてカスタマイズしているのですが、ネイティブアプリはこれが非常にやりにくい側面があります。カスタマイザブルにユーザーがプラグインを追加するといったこともWebのほうがやりやすいですし、業務システムとの親和性も高いです。

フロントエンドの領域という意味でも、Webの良いところを増やしたり面白い部分に着目するのはすごくワクワクしますし、お金ももらえる部分なのではと思います。

古川：当社の場合は美容院やレストランを検索するBtoCのアプリが多いわけですが、そうなるとWebはどちらかというと集客のためのものになります。出先で「このへんのレストランを検索したいな」と思ったときにわざわざアプリはインストールしませんから、検索してもらい人を呼び込むという点においては、Webのほうが圧倒的に長けています。

一方「日常的に使う」という意味ではあらかじめアプリをインストールして検索してくれる人のほうが多い。そのため、他社では一度Webに集客して、そこからアプリをインストールさせるという流れが一般的になっています。Web回帰の流れはありつつも、ものによって棲み分けしている部分は大きいです。

佐藤：モバイルのネイティブとWebを両方良いレベル感で語れる人は強い雰囲気がありますよね。

古川：その通りですが、そういう人はほぼいませんね。

田中：アプリやWebに限らず、フロントエンドにJavaScriptを使う流れはIoTをはじめとした多様な領域にあるので、データの流れを上手く可視化するなどフロントエンドエンジニアが技術提供できる場はいろいろあるのだろうなと思います。

例えばIoTなら、プロジェクトにジョインした当初はデバイスのデータをどう流し込むかという部分に関わっていたのですが、最終的にフロンエンドできちんと可視化したい要件が出てきて、僕が嬉々として書く場面がありました。ただ可視化するだけではなく、Webのユーザーインターフェースが求められることが多いので、最終的にフロントエンドが必要になるポイントは増えている気がします。

後半質疑応答

オンラインライブにて、ご登壇者の皆さんにリアルタイムで参加者から質問をいただきました。

自分が学ぶべきUI/UXの領域を見極める方法

質問者：フロントエンドエンジニアとしてUI/UXの学習の優先度についてお聞きしたいです。

 

古川：いわゆるデザインとしてのUI/UXの勉強はもちろんしたほうが良いです。ただ、UI/UXは非常に大きな学問なので、いきなりフロントエンドエンジニアにマストで必要かと言われるとそこまでではないと思います。

一方で、依頼されているUIをいち早く作れることはフロントエンドのスキルの一つです。例えばCSSのボックスモデルをきちんと理解しているか、HTMLのフォームをどうやって書けばきちんとデータのやりとりができるかといったようなベーシックな技術はもちろん、JavaScriptで作るならどうやって作るのかといったことがわかるのは重要です。

田中：僕もUI/UXの理解力を高めるための勉強はすべきだと思います。ズレのないCSSをどう組むのかといったこともそうですし、最近はピクセルパーフェクトが話題になっていたりします。そういったことをどこまでやれるのかやれないのかを考えることが必要です。

佐藤：今は「フロントエンドエンジニアリング」という領域の全てこなすのはだいぶ厳しい状況になっているので、どの部分を突き詰めていくのか次第でUI/UXを学ぶ優先度も変わります。逆に広く薄くやるのであれば、そのために押さえておくべきところもありますし。

一般論としては、得意分野を2つ持つべきという話がありますね。JavaScriptで実装する技術と、それこそ高いユーザビリティのフォームをデザインするスキルを身につければ、一人で画面の実装ができる。何を自分の得意分野に選ぶのかという視点を持つと考えやすいかもしれません。

個人のスキルのバラつきをカバーする組織の取り組み

質問者：スキルのバラつきにどう対処すべきでしょうか？

 

田中：フロントエンドはどうしても領域が広くなってしまうので、自分の好みで得手不得手が出てきてしまいます。僕自身もバラつきは正直あると思うのですが、そのあたりにどう対処するかということですね。

古川：ある開発組織では、プロジェクトごとにスキルのレーダーチャートを書いていますね。内容はプロダクトチームのメンバーが決めていて、特に伸ばしてほしいスキルなどを入れ込んでいます。そのレーダーチャートがどう拡大していくのか、見える化しながら進めています。

田中：仮に個人でスキルのバラつきはあったとしても、組織全体としてはマルチに対応できるようになるということですね。佐藤さんはいかがですか？

佐藤：チームによってはスキルマップを使っていますね。あとはやはり教育や啓蒙が大事で、エキスパートチームの役割の一つとしています。社内でカジュアルに実施しているのは自由参加のフロントエンドウィークリーというミーティングで、毎週フロントエンド関係のニュースに関して雑談しています。あとは月に1回程度フロントエンドバーという勉強会も開催して、社内全体のスキルアップを図っています。

田中：業務の中ではどうしても一つの技術に特化しがちなので、勉強会などを通していろいろな知識を身につけるのは非常に大事ですね。案件に役立つかどうかは別として、僕自身もJavaScriptでやれることに関する情報へのアンテナは広げるようにしています。

企画/編集：FLEXY編集部