フロントエンドはライブラリの更新頻度が高い
次に、ライブラリの更新です。特にフロントエンドは、ライブラリの更新頻度が早いです。私が思ってるぐらいだからやはり早いです。「私が思っているぐらいだから」というか、私は常に早いなと思いながら、別に遅くなった試しがないと思っているので、基本的にずっと早いまま来ちゃったな、というところです。
何かしら新しくなって何かしら壊れる。これがフロントエンドだと僕はずっと思っています。ちょっと脇道に逸れますが、昔はそれもひっくるめてFront-end fatigueや、JavaScript fatigue。“JavaScriptやフロントエンドの疲弊”と呼ばれていましたが、その疲弊と言われていたのが3年、4年ぐらい前で、何か解決するのかなと思ったら、疲弊したずっとそのままでいくのがこのやり方で、自分もフロントエンドエンジニアながら「フロントエンドエンジニアはよく着いていっているな」と思うところはあります。
ちょっと脇道に逸れてしまいましたが、ライブラリの更新頻度が基本的には早いです。更新したタイミングで互換性があるか怪しいものもけっこう多いので、けっこう「更新されたね。パッチのリリースだ。パッチだから外側の変更には影響がないはずだ。じゃあマージしてみよう」と言ったら壊れていることとか、けっこうあります。
かといって放置しておくと、どんどん溜まってしまいます。これも洗い物とか洗濯ものなどと同じような存在です。定期的に更新、掃除していかないとひどくなる。一番やばいのは、これをずっと放置しておくと、いつか壊れて、何も取り返しがつかなくなることがあります。フロントエンドのライブラリ群をそのまま放置しておくと、例えばセキュリティのアップデートが必要になることがけっこうあるわけです。
そうしたときに「もうアップデートできません」となると、ノーガードでクロスサイトスクリプティングの脆弱性が備わったままになっているケースがあるので、取り返しがつかなくなることもかなり多いんじゃないかと思います。たぶんですが、昔jQueryで作って放置したままのサービスは、けっこう本当にやばいところは大きいと思います。
クロスサイトスクリプティングの脆弱性が、潜んだままになっているケースも多いんじゃないかと思います。ただそこに対して関心がないと、問題が起きていても気づけないケースもあると思うので、そこが今ちょうど「掃除しないといけないよ」と言われたところで、拒否反応を示す人たちもいるということです。とはいえ、何もしないままだとひどくなるところです。
昨今のフロントエンドの開発は基本的にライブラリを管理していないことはないと思いますが、ちょっと昔に作ったレガシーなサービスとはライブラリを管理していないところもまだまだ多かったりすると思います。そもそも管理していなかったら、そこに対して負債が溜まっていることに気づいていないと思うので、まずはライブラリを管理するところから始めないと話にならないと思います。
ただ、基本はもうこの辺はあまり気にしていなくて。Node.js、npmが入っていないフロントエンドの開発現場はあまり存在しないとは思いますが、まずはそれを入れて、どのバージョンを使っているかを特定するところからやるようにするといいかとは思います。
これはもう標準ツールなので、覚えて帰ってください。ライブラリ更新を自動化するためのツールとして「renovate」があります。もう知っている人も多いと思うし、知らない人はこれを機に覚えて帰ってくださいというだけのものです。Node.jsなどにも限らず、RailsやPythonでも全部起こせるものですが、その特定のサービスのバージョンアップを検知して、バージョンアップが発生したら、それをプルリクエストというかたちで送ってくれるボットになります。ライブラリの更新が発生することに気づけないことを防げるので、ツールとしてもすごく有用だと思います。知らない人はほとんどいないかもしれませんが、覚えて帰ってください。
更新作業を滞らせないことも重要
ただこれだけじゃ足りません。ライブラリ更新を自動化できたとしても、問題ないかを確認するために結局都度見なければいけなくて、見ないで更新すると事故につながります。我々は、基本的にスプリントごとにライブラリ更新担当大臣みたいな方を作って、定期的に更新が滞らないようにしています。
renovateを入れたとしても、自動ですべてを更新するような設定にしていると危険なので、一応それなりに注目しながらやっています。ただ、どうしても確認コストがかかるので、ここを減らしていく作業が次に必要なわけです。
確認工数を減らす、確認作業を減らす。これはあまりいいやり方がありません。基本的にはテストを書くことしかありません。ユニットテストなど、そのロジックのテストでカバーしていくのもあれば、フロントエンドはCSSのライブラリなど、けっこう見た目に関わるライブラリも多いので、それだけだと足りなくて。
そのために使うツールが、コンポーネントカタログというものです。StoryBookなどそうですが、いわゆるその細かい部分のパーツにおいて、どういう見た目でどう見せるかを一覧化したカタログです。これを作っておいて、見た目の変更が特定されやすいようにする。
コンポーネントカタログを作って、そのコンポーネントカタログの単位で見た目上のデグレ（デグレーション）が発生していないことを確認するといいと思います。それが、Visual Regression Testというものです。これでも足りないことがあるので、そのときはE2Eなどを使って自動化する。
Visual Regression Testは、見た目の変更が起きたときにそれを特定して確認を促します。右下の例だと、例えばフォントがちゃんと読み込まれていなくて、文字がぐちゃぐちゃになっているところを、見た目でわかるようにしてくれます。
ピクセル同士の変更点が見えるようになっているので、重ね合わせるとその変更箇所を把握しやすくなります。これをやることによって内容が違うことが把握しやすくなるので、かなり便利なツールだと思っています。
ちなみにどうやってやるかというと、StoryBookと呼ばれているコンポーネントカタログを定義するツールと、reg-suitと呼ばれるコンポーネントカタログの中で変更があるかどうかを確認するツールの2つを使ってやっています。これもほぼデファクトスタンダードだと思っています。知っている人が多いのかもしれませんが、知らない人たちは覚えて帰ってください。
これでも足りないときは、E2Eテストを書いています。Autifyを使って効率化しているチームも多いと思っています。弊社はやはりサービスがたくさんあるので、有償でもツールでカバーできるとすごく便利だと思っています。
Autifyはけっこうテストの記述も楽で更新の確認がやりやすいので、最終的な担保としてAutifyでやっていることが多いです。
もちろんこれでも足りないときはあるので、そのときはツールで特定できないものだと思ってもらっていいです。
逆に言えば、そういったライブラリの更新のときはそこだけは慎重にやる必要があると思いますが、それ以外のライブラリは基本的にこれだけで足りると思っています。そのため、だいぶ更新のコストは下げられます。
ワークフローの形骸化
あとはワークフローの形骸化です。ここまでやってきたようなことをやっていたとしても、意味なく形骸化しちゃうケースがあって。わかりやすくテストを書くワークフローにしたとしても、そもそもテストを書いているかとか書いていないかとかをチェックするのはやはり人で。テストを書かなかったら意味がないし、締め切りが迫る中で機能実装をしながらテストを書くのも一定のスキルが必要なので、そこが形骸化しやすいです。
いわゆる、スキルに依存したところで形骸化しやすい。そもそも知らない人が多いとやれなかったりする。StoryBookやビジュアルリグレッションテスティングも一緒です。同じことが起きます。
フロントエンドのエンジニアが今までずっといるかのように言いますが、これ自体は最近できたカテゴリなので、“フロントエンド”にはたくさんのいろいろな人がいます。CSSのエキスパートの人たちもいれば、サーバーサイドエンジニア、JavaScriptをやる人が移ってきて、「まだ苦手なんです」という人たちもたくさんいます。
あと、最近はwebpackや裏方作業をやる人たちのことをFrontendOpsというらしいです。“フロントエンド”と一口に言っても、実はその中には得意なジャンルが若干違う人たちがいる。
形骸化してしまうことに関しては、結局ツールで一気に解決できるようなものでもありません。エンジニアのスキルを共有して、互いに知識のレベルを上げていく必要があると思います。
我々がどうやってきたかという話ですが、開発者同士でときには教え合い、ときにはペアプロやモブプロを行ってきました。結局あまり華麗な方法はなく、だから結局「教え合いましょう」「ペアプロ、モブプロをやりましょう」みたいな話になってしまいますが、そうやって全体のレベルを上げる活動をしてきました。
どうしても最初は時間がかかりますが、全体で効率化できると思っていて、最終的に速度も改善できるようになると思います。
これもぜんぜんフロントエンドと関係ないですが、『ザ・ゴール』という本があります。『ザ・ゴール』の中には「ある部分にだけ着目して最適化をしても、決して全体の最適化にはつながらない。ボトルネックを見つけて全体の中の一部分を必要に応じて最適化するべきだ」という、制約理論の考え方をしています。
これと一緒で、1人が遅いとそれがプロジェクト全体のスピードになりがちなので、その人を上げてあげるためにも、その人に補助輪をつけながら一緒に走ってあげる。制約理論の中にも出てきます。子どもが遠足に行って、1人だけ遅い子がいると、その子によって列がずっと伸びちゃうというエピソードがあって。みんなでその子の荷物をみんなで持ってあげることで、徐々に早くしてあげるというエピソードが出てきます。
モブプロとかペアプロとかはそれに近いです。苦手な人やわかっていない人をお互いカバーし合うことによって、全体の速度をちょっとずつ上げていきましょうという話です。
開発者体験向上に大切なのは結局モチベーション
ここまでふりかえってですが、開発者体験は生産性に直結し、ひいてはモチベーションにも関連する。今までの話の中で、生産性を下げてしまうブロッカーについてや、それについてのテクニックめいた話をしてきました。ここまで話してきてちょっと真逆のことを言いますが、この中で一番重要なのは何かというと、結局モチベーションだと思います。
開発者体験が必要なのは、結局モチベーションを維持する必要があるからだと思っていて、ここを間違えてはいけないなと思います。だから、ツールを入れたり、テクニックめいたことをやっていればいいかというと、そうではありません。
僕はみんなそうだと思っているんですが、エンジニアはたぶん、他の人の役に立ちたいんですよ。
根底にある想いとしては他の人の役に立ちたいと思っていて、だから、いくらいろいろな開発テクニックをもってとか、テストを書いたとしても、他の人の役に立っている実感がないと、結局モチベーションがあまり上がっていかないのではないかと個人的には思います。
開発者体験だけじゃないかもしれない。UXも一緒かもしれません。こういう話はテクニックめいた話になりがちだとは思いますが、テクニックめいた話だけではなく、その根底にある想いが解決されないと、実はあまり意味がありません。
開発者体験の向上はいわゆる生産性の向上だと言ってきて、その上で開発の生産性の向上につながらないような話をなるべく省いていきましょう、ということを言ってきました。しかし、結局開発者のモチベーションは“誰かの役に立っている”という実感が元になっているので、やはりりここを蔑ろにしてはいけないと思っています。
もっと具体的にいうと、やはり事業に還元できるところまでやらないといけないと個人的には思います。誰かの役に立っている実感が一番得られるのは、たぶんビジネス上のベネフィットが得られているときだと思っていて。事業に還元できると、それによってポジティブなフィードバックも増え、よりよいサイクルが回ってくるのではないか。いわゆる事業貢献というやつです。
事業貢献までできるようになると、また話が変わってくるのではないかと思っています。開発者の体験を向上させるときに、これからもテクニックめいた話は増えてくると思います。ただ、そのときに、最終的に重要視してほしいのは“その人は誰かの役に立ちたいんだ”と思ってほしいと思っています。
エンジニアは“役に立ってる実感”がほしい
ここからはまとめです。フロントエンドエンジニアはUXを最大化するエンジニアで、もちろんUX VS DXではなく、両方やっていかないといけません。DXは“生産性向上のための施策”とこのスライドでは位置づけましたが、生産性を下げるためのものはたくさんあり、それぞれ代表的なものを3つほど挙げて紹介しました。
それぞれ対処するためのツールやナレッジについても紹介しました。こういうツールやナレッジという話はたぶん増えてくると思っていて、それをいろいろなやり方、いろいろな方法論で各社真似することはすごくいいことだと思いますが、エンジニアは役に立っているという実感がほしい人たちだと思っています。
これは事業に還元させていくことが、結局一番DXに効果的なのではないかと個人的に思っています。これは、UXでも同じようなことが言われますよ。どんなにきらびやかなUIを持ったり、どんなに綺麗で異例なものが作られていたり、雰囲気がものすごくよくても、結局やりたいことができないと、UXと謳ったとしても意味がない。
DXも一緒です。だから開発者体験はいろいろなやり方でナレッジが溜まっていたり、ツールで解決できたりはすると思いますが、それが重要ではなく、結局はやはり事業に還元させていったり、役に立っているという実感をもつ。これこそが、たぶん最終的には効果的なのではないかと思っています。
だからと言って、ツールやナレッジを使わなくていいという話ではありません。それも両立させないといけないと思っていますが、ただ、最終的に達成しなきゃいけないのは、ビジネスとして事業を成功させ、ユーザーに還元させていくことだと個人的には思っています。
私の発表は以上になります。ご清聴ありがとうございました。
