Forkwell Press

エンジニアの生き様をウォッチするメディア

トークセッション:Front Line of Frontend @Forkwell Meetup #2

2016年11月に開催した Forkwell イベント「Front Line of Frontend(フロントエンド最前線)」にて、今まさに第一線で活躍しているフロントエンドエンジニア2名を招いてのトークセッション。日進月歩の IT業界において、特に変化の激しいフロントエンドエンジニアリングの現状や、将来の展望・行く先の予想などを、パネルディスカッション形式でお話しいただきました。

パネラー・モデレーター紹介

freee株式会社 山本伶(やまある)氏 @ymrl

企業や個人事業主の会計業務を圧倒的に効率化するクラウド会計ソフト「freee」を担当するエンジニア(フロントエンドヤンキー)。Forkwell Press の連載記事・リレーインタビューの第1回目に登場。

株式会社グッドパッチ 吉田真麻(よしこ)氏 @yoshiko_pg

UIデザインプロセスをより早く、よりシンプルにするプロトタイピングツール「Prott」のフロントエンド開発にテックリードとして携わる。著書に『HTML5/CSS3 モダンコーディング』(参照)。

後藤大輔 氏 @idesaku(モデレーター)

SI企業にて組み込みソフトウェアや Webアプリケーション開発に従事したのち、フリーランスとして独立。以降は Forkwell 運営会社を含む複数企業の開発に参加しつつ、若者たちの仕事を見守り、時にアドバイスする、技術顧問もしくはメンター的な仕事を引き受ける。

「フロントエンド開発」の業務範囲って?

後藤
「フロントエンド」と一言で言ってもその領域は幅広く、担当分野がどこまでかも人によって様々です。そこで、パネラーのお2人はどのようなフロントエンド業をしているのか、自己紹介を兼ねて聞いてみたいと思います。
では、やまあるさんからお願いします。

やまある
僕は多分、名刺に「フロントエンドエンジニア」という肩書きを付けている社内で唯一のエンジニアです。他のエンジニアはデフォルトで「ソフトウェアエンジニア」なのですが、僕だけ自称しています。

先ほど野口(やまある氏と同様に freee社のエンジニア。同日「フロントエンドのパラダイムシフトの耐え方」のテーマで登壇)の話にも出てきましたが、freee のエンジニアはフロントエンドだけを専任でやっているということはなくて、僕もフロントエンドエンジニアを名乗りつつサーバー側のコードもかなり書いています。

サーバー側との境界としては、「API からこっち側」みたいな……ちょっと言い方が変なんですけど。欲しい JSON を作るところから始まって、UI も作って、たまに CSS も書き、みたいな感じです。

後藤
デザインやモックだけを担当するのではないと。

やまある
はい。ちなみに最近は、国税庁の Webサイトをずっと読んでいます。

後藤
(笑)何人くらいのチームですか?

やまある
エンジニアは全部で60人くらいで、私のチームは5人1チームで1サービスを担当する、という体制です。少人数チームで各個の責任も大きいですし、それこそフロントエンドだけを担当するという人はいません。

よしこ
私は「Prott」というプロトタイピングツールの Webフロントエンドを担当しています。
Prott、ご存じの方どのくらいいらっしゃいます?(※ 観覧席からたくさんの挙手)……あ、いらっしゃいますね、ありがとうございます!
Prott のフロントエンドは、私を含め3人体制で開発しています。

後藤
完全にドッグフーディングできるサービスですよね。

よしこ
そうなんですよ。グッドパッチに入社する前は、自分の関わるものにより近いサービス開発ができる会社がいいなと思っていたので、クリエイター向けのプロトタイピングツールを作れるというのも入社の理由のひとつでした。

後藤
基本的には、プログラミングをやっていらっしゃるのですか?

よしこ
はい。去年 HTML/CSS の本を出したこともあり、CSS を書いているというイメージを強く持たれますが(笑)、業務では CSS だけでなくロジック周りも書いています。

後藤
そうなのですね。チームは何人くらいですか?

よしこ
Prott チームはエンジニアが10人くらいで、プロダクトマネージャーやデザイナー、カスタマーサクセス、セールスまで入れると30人規模になりますね。私は先月(2016年10月)からテックリードを務めています。
「テックリード」って言葉はあまり馴染みがないと言われるのですが、役割としては自分の関わるプロダクトに関する技術的な選択・決定やクオリティーに責任を持っています。

後藤
テックリードとフロントエンドヤンキー……どちらが強いのか気になりますね(笑)。
フロントエンド開発と言っても JavaScript だけ書いていれば OK というわけでなく、幅広く色んな所に関わることが多そうですね。

JavaScript だけの時代が終わった今、言語やフレームワークの選定基準はどうする?

後藤
お聴きの皆さんの事前アンケートから、あらかじめいただいた質問をいくつか抜き出してお2人にお答えいただきます。まず、フロントエンド技術の選定基準や方法について。

やまある
選定基準は……あまりはっきりしていないですね。一度 Vue.js を採用してうまくいかなかった経験をしており、おそらく社内でも「導入して1年後につらくなりそうだったらやめよう」という共通認識はあるのですが、明確な基準はないです。
「前の人が入れたからこのまま使うか」ということも多いし、「ついカッとなって Flow を入れました」とか突然のこともありました。

後藤
突然ですか。やまあるさんが実際に freee で導入した技術はありますか?

やまある
この間、Immutable.js をやりたくなったので突然入れました。
みんなには一応相談するんですけど、「覚えることが増える」とか「それ何が嬉しいの?」とかネガティブな反応が返ってくることも多いので、しれっと入れてしまった方がやりやすいなと(笑)。よっぽど危なそうでなければ突然やってしまいます。

後藤
何か問題が起きたら、解決に向けて……

やまある
やっていく気持ちですね。入れたのは自分だから、外すのも自分、みたいな。

後藤
Prott チームでの技術選定基準はいかがでしょうか?

よしこ
今、とても悩んでいるところです。最近はどのフレームワークでも「コンポーネントを作っていく」というベースの考え方は割と共通しているので、その技術の枯れ具合や情報量、エコシステムの大きさ、人材の採用しやすさとか、そのあたりも考慮しながら検討中です。

やまある
世界で使っている人が少ないとなると、やめておいた方が良いですよね。社内相談の前に、自分の中で「これはないな」と決める材料になっていたり。

よしこ
それから Web標準に沿ってるか、というのは最近大きな指標にしています。
Prott のフロントはもともと CoffeeScript で全部書かれていたんですけど、2015年末から今年(2016年)の頭くらいにかけて ES2015 のビルド環境を構築して、新しい機能は ES2015 で書けるようにしました。これも Web の仕様に沿っていきたいという方針のもと進めていました。

後藤
これからは Web標準でみんなやっていくぞ、という流れが世の中にあると社内でも進めやすいですね。ビジネス視点込みでお話しいただき、ありがとうございます。

レガシー環境からイマドキな環境への移行は、どのように進めている?

よしこ
先ほど CoffeeScript から ES2015 への移行についてお話ししたので、その流れで。
Prott のフロントエンドフレームワークは AngularJS をずっと使っていて、私が2015年6月に入社したときバージョンはだいぶ古い1.2だったんです。設計が乱雑だったこともあって、レガシーなものをどう引き上げるかという問題は大きかったです。

実際どうしたかというと、まず AngularJS のバージョンを1.3に上げました。具体的には、まず差し替えてから、触ってみて動かないところを見つけては直す、というやり方でした。自動テストもなかったですし。そんな感じで、その後のパフォーマンスチューニングも含めて1ヶ月ちょっとで完了させました。1.2のころはパフォーマンス上の問題を抱えていたんですけど、1.3の新機能を使えるようになったおかげで大きく改善されました。

それから言語も ES2015 を導入して、ESLint も一緒に入れました。ES Modules が使えるし、ESLint は CI 環境に入れているのでコードレビューも楽だし、とずっと快適になりました。

後藤
CoffeeScript はお嫌いですか?

よしこ
Coffee は Web標準に沿ってないんですよね……。あと、うちはフロントエンドとサーバーサイドで分業しているのですが、それでもアクションを1つ足すぐらいであればフロントエンド側でも Ruby を書くことがあって、そのとき文法が似ている Coffee に引きずられて、例えば end を忘れてしまうことがあったり。

個人的な話ではありますが、私は普段プライベートでものを作るときに JS を使うので、オンとオフのスイッチングコストがきつかったというのもあります。

後藤
Coffee の良いところは ES2015 が全部拾ってしまいましたねぇ。

よしこ
そうなんですよ! class と Arrow Function が拾われたので、ES2015 の中で CoffeeScript は永遠に生き続ける、みたいな。
そういえばすごくびっくりしたのですが、先日 CoffeeScript がメジャーバージョンアップしましたね。なので、「バージョンアップしない」とか「サポートが足りていない」とかは Coffee を捨てる言い訳にはならないなと(笑)。

後藤
(笑)やまあるさんはどうでしょうか?

やまある
レガシーコードについて、「自分が数ヶ月前に書いたコード=他人のクソコード」みたいな話がありますよね。単純にレガシーというのもあれば、「なんでこんな実装にしちゃったんだっけ」的なものもあったり色々ですが、大抵の場合メンテナンスが行き届いてないことが原因なので、ちょっとずつ直していくしかないんですよね。

特に僕らが扱っているサービスは、何年も維持していかなきゃいけないという性質があるので、いきなり全体的に手を入れないようにして、なるべく小さい範囲でできることをコツコツやっています。
そして機能をすべて触りきった段階で最初にやった部分を見ると、おそらく「古いな」という気持ちになるので、それをずっと繰り返す形になっていくのだろうと思います。

後藤
横断的に入っている技術や環境を変えることもありますか? フレームワークとか。

やまある
もちろんあります。そのときは「お祭り」をやるしかないですね。

後藤
お祭りとは?

やまある
「バージョンを上げるぞ!」と宣言して、そのための基本的な作業はやっておいたから、あとはみんなで分担してレビューしてくれ、とお願いするんです。Pull Request に大きいチェックリストを作って、「これは◯◯さんお願いします」と人を巻き込んでどんどん割り振ってやっていく手法です。

テストについてはまだ課題があって、ブラウザが自動で回って色んな画面をチェックする、という体制はあるもののすべて拾いきれていないですね。自動テスト環境は確実にあった方が良いものの、大きい変更の際はどうしても人の手が必要だな、と思います。初めから「テストをがっつりやるぞ!」という気持ちで作っていれば良かったんですけど……。

後藤
フロントエンドのテストは人海戦術が必要なところがやや残りますねぇ。
よしこさんの方はいかがでしょうか。やはり人を集めて「よしやるぞー」みたいな流れですか?

よしこ
AngularJS のバージョンアップの際は、私がほぼ1人で対応して、一通りできたところでテスト環境にあげて社内の人に触ってもらいました。
これはうちの強いところなんですけど、Prott などを開発している自社プロダクト事業と受託事業とでメンバーが半々で、受託事業の方も Prott を使っているので、そちらのチームに一定期間だけ「テスト環境の方を使ってください」とお願いして、実務を通してテストしてもらったりしています。

後藤
はかどりますね〜。

新技術の導入時、周りのメンバーをどう説得する?

後藤
導入したい技術やイケてると思う環境を社内の人に話しても、必ずしも賛同されるわけではないという話がありましたが、どのように説得すれば良いのでしょうね?

よしこ
うちはあんまりないですね。エンジニアの意見が通りやすいですし、社長も理解があるので……「IE対応つらいよね」という会話をしたり(笑)。ES2015 導入のときも、フロントエンドチームのマネージャーが「いいね」といってあっさり入れちゃったり。

私がテックリードという肩書きをもらう前は、技術の採用などに際して上の人の合意を取って進めていたのですが、おうかがいを立てる時間も承認する時間もコストだから自分で決めていいよ、と権限を委譲されたことがテックリードという肩書きの実体です。

後藤
良いですね、組織としてより早い決定ができるようになったのですね。
フロントエンドヤンキーの方はいかがでしょうか?

やまある
フロントエンドの技術選定は僕や野口といった一部の人間が中心となって行うのですが、新しく提案したときは、明確な反対意見が返ってくることよりも「なんかよくわからない」という反応のほうが多いです。でも、フロントエンドに強い人たちが「こういうの必要です」「やらないとヤバイ」と強く主張し続けると、この人たちがそう言うならと尊重してくれるし、周りも触発されて「じゃあ今度その画面触るときに提案どおりにやってみようかな」という空気になります。このやり方がヤンキーと言われている背景かもしれないですけど……(笑)。

逆に、フロントエンド側としても、サーバーサイドやデータベースに強い人からそういう提案があれば従うし、「新しい技術入れました」と言われればそれを尊重しています。戦いをするのではなくお互いを信頼するという雰囲気で、今のところうまくいっています。

後藤
お2人の話を聞くと、理屈を大事にしつつ、ちゃんと自分の仕事をして実績重ねて信頼を勝ち取る、というパターンがありますね。

やまある
信頼関係がなければそもそも導入の許可を取れないとか、ハードルが増えるのかなと思います。

今後導入してみたい、注目している技術は?

後藤
ES2015 に移行したり、新しいフレームワーク入れたり、という技術導入の話があった流れで。お2人が次に注目する技術はありますか?

やまある
難しいですねー。この先は Web標準に沿って進んでいくと思うし、Web Components とか Shadow DOM とか夢だと思っていた技術がもっと現実に近づいてきてくれるだろう、と楽観的に思っています。

それよりも、HTTP/2 とかフロントエンドの枠で見られていなかったものこそ、フロントエンドを変えてくるんじゃないかと。ブラウザ側が Web Components をちゃんと実装してくれたら、コンポーネント化をフレームワークが頑張らなくてよくなるとかと同じだと思うんですけど、そうした新しい技術によって、例えばこれまで Webpack で頑張ってファイルくっつけて、という作業が必要だったのが、不要になったり形を変えたりするのだろうなと思います。その潮流に飲まれないようにしておきたいな、という気持ちです。

後藤
やはり Web標準を追いかけるのが重要だという考えですか?

やまある
追いかけるまで行かなくて、つまみ食いしつつ……という感じですね。様々なお客様がいらっしゃることもあり、どうしても IE の一部バージョンは切れないとか、ビジネス上の障壁があるんですよね。 ただ Windows10 があれだけアップデートされましたし、今後はどんどん自動的にブラウザアップデートされる時代が来るはずなので、Web標準に従うだけで開発しやすくなるんじゃないかなーと希望的に思っています。

後藤
よしこさんはどうでしょう、注目されている技術はありますか?

よしこ
Prott というツールの目線で、Service Worker を通してオフラインでも使えるのはすごく良いなというのがあります。特に SPA でデスクトップアプリケーションのように動くページ、例えば Google スプレッドシートとか、そういったもののアプリ感を高めていけるのはいいなと。モバイルだと Progressive Web Apps という技術がありますが、 iOS では使えないので自社的には導入はまだ厳しいですね。PC だったら Prott のユースケースにもすごくマッチしそうという意味では入れたいです。

後藤
Electoron とはまた違う手法でのネイティブアプリ化なんですね。

よしこ
でも、やっぱりハードルは高いですね。デバッグが難しいという話も聞きます。Service Worker は、1回ユーザーさんにインストールされちゃうとこちらで手が出せない状況になっちゃう可能性があるとか。

後藤
先ほど楽屋で話していて、最近よしこさんは静的型付け言語に興味をお持ちだとうかがいましたが。

よしこ
今の開発環境には静的な型はないですが、大規模で型がないと結構つらいなというのは聞きますね。経験のバックグラウンドがないので、その恩恵をよく知っているわけじゃないのですけど。
以前個人的に TypeScript で触れたりして、型の不一致があったときに事前に教えてくれるのは良いと思いました。特に複数人でやるときには重宝すると思います。関数のコメントとして引数の型をメモ書きしておくぐらいなら、それをコードとして書いて型チェックできるようにしたほうがいいですよね。

後藤
やまあるさんはどうです?

やまある
型が必要か、というのは悩みどころですが、あるに越したことはないと思っています。他の人が書いたコードを読みやすくして、作業しやすくするという利点はあるんだなと。
以前 Flow を入れましたが全体に入れてはいないので、本当にその恩恵にあずかれているわけではないです。ちゃんと恩恵受けるためには、型付けしているファイルをもっと増やしていかないといけないですね。

うちは小さくやっていくという基本方針を掲げていることもあり、まず自分で書くコードに必ず型のアノテーションを入れるようにしています。「同じメソッドなのに全然違う型を返しやがる……!」みたいなことがよくありますが、そういうのも防ぐことができます。自分はやってしまわないよう気をつけていますが、他の人にもある意味強制できる、という点が便利ですね。

ただ、「みんなもうちょっと頑張ろうよ」という気持ちもあって。型定義してあるファイルをこっちで頑張って増やしてあげる、までやる必要があるのか。かといって、みんなにも書いてもらおうとしても、「型定義書いてね!」とものすごくうるさく言わないとやってくれないだろうな、とも思っていて、どうしたらいいかと悩んでいます。

後藤
型定義警察ですね。

やまある
そう、警察になっちゃう。とは言え、他の人がプルリク投げてきて型定義なかったら怒る、まではしていなくて(笑)書いてくれたらいいな〜とは思っています。

10年後のフロントエンドを予想してみる

後藤
皆さん、10年前はどんな時代だったと思います? IT業界的には、IE6 のシェアが83%を占めていて、ちょうど IE7 がリリースされましたね。それから jQuery がリリースされたのも10年前です。この時期はちょうど、Webアプリケーションからフロントエンドエンジニアリングが分離して、土台ができあがった時代と言えます。そこからさらに10年経ち、フロントエンドイベントにエンジニアがこんなにたくさん集まるジャンルになったのですけれども。
ここから10年後も何か大きな変化があるのだろうと思うのですが、どうなっていくか予想をしてもらえますか?

やまある
10年前の Web がどうだったんだろうというのを考えると……変わったところ/変わっていないところ両方あって、この先どうなるかを予想するの難しいですね〜。

Web って、今すごく生活に馴染んでいますよね。ここにいる人たちには当たり前のことでしょうけど、そこら辺を歩いてる人が Google Maps 見ていたり、実家に帰ると両親がインターネット関連の話に詳しかったり……そういう時代ですよね。そんな中で、Webフロントエンドはもっと生活に馴染んでくるんだろうなと。

「フロントエンドエンジニア」って、Web だけのフロントエンドエンジニアじゃなくなってるんじゃないかなと思っています。やってることは Web だけど、今で言うスマホアプリみたいな感じのものを作っていたりとか。
例えば、最近の若者は Web上で見たニュースを共有するときにスクリーンショットを撮る、みたいなことがあるようですが、それは Web ということを認識していないからだと思うんです。技術がどうなるかはよくわかりませんが、Web の受け取られ方は多分今とは全然違うものになってるでしょうね。

後藤
若者はもうスマホしか見てない、なんて話も聞こえてきますよね。最近固まってきた HTML 5.1 とか追いかけても、10年後には使いものにならない可能性もあるんですかねぇ。

やまある
ありえますねー。とはいえ、それも「スマホを使って Web を見ている」ということだと思うので、生き続けるものも絶対にあるはずですけど。
さっきの話の延長ですが、Webフロントエンドは技術的にスマホアプリと融合した得体の知れないものになってるんじゃないか……という気がしていて、色んなデバイスの色んな見方を知っておいたほうが良さそうと思っています。

よしこ
私、10年前はガラケーでポチポチタグを打ってたなーと考えていました(笑)。
これから5年後だと、端末の多様化がさらに進むだろうと思っています。iPhone 6 が出たときに @3x とか増え、それだけでもギャーって感じになったじゃないですか。でも、それどころじゃなくなるだろうなと。

タッチパネル1つ取っても、さらに新しい操作が追加されたりしてますし、むしろフロントエンドがスクリーンでない・スクリーンという形を保っていないということもあり得ると思っています。そうして多様化・複雑化するUIにも対応していかなきゃいけないですよね。

まだ知識を蓄えていないこともあり Web とつながるイメージがあまりないんですけど、 最近 VR も気になっています。最近仕事でなくユーザーとして HTC Vive を使ったのですが、空中にお絵かきができたり、すごいんですよ。この辺も Web につながっていくのかな、と思いました。

後藤
人間の接するところすべてがフロントエンド。守備範囲が非常に広くなりそうですね。

よしこ
HTML と CSS が、どこまで広がっていくのかは気になりますね。今はカーナビやテレビに入っていたりとブラウザだけじゃなくなっているので、今後どこまで行くのかな、と注目しています。

View を作るときには HTML/CSS は作りやすいはずなので、さらに広がっていきそうですが、逆に10年後までいくとなくなっている可能性もあるとは思います。


関連リンク


Forkwell Meetup #3 を1月28日 (土) に開催します!

第一線で活躍するエンジニアの話を聞きながら、一日を通じて開発者同士で Meetup する Forkwell イベント・第3弾。 今回のテーマは Productivity Engineering − チームで生産性アップです。

ゲストスピーカーに 株式会社ドリコムの大仲さん や クックパッド株式会社の勝間さん らを招聘。
マネジメントから日々の細かい改善まで、様々な粒度の”実例”を”生産性アップ”という視点から見つめ直してみませんか?

ご参加はこちらから↓↓↓
https://forkwell.connpass.com/event/48147/



Forkwell イベント運営事務局



Forkwell イベントページ(connpass)はこちら
エンジニア目線で会社を選べるサイト Forkwell Jobs はこちら
エンジニアのキャリア相談・キャリアチェンジ支援は Forkwell Agent