自己紹介
古川陽介氏（以下、古川）：僕の発表では「Frontend Developers Experience」ということで、目的やどうやってやるのか、どうやって上げていくのかなどの話ができればと思っています。
自己紹介から先にすると、@yosuke_furukawaというTwitterアカウントと、@yosuke-furukawaというGitHubでやっています。もしよかったらフォローしてもらえるととありがたいです。
いくつか活動はしていて、例えばChrome Advisory BoardというChromeの諮問委員会の一員だったり、リクルートという会社の中で活動しています。あと、Node.jsの日本ユーザーグループの代表などをやっています。わりとフロントエンドエンジニアリング畑で、このキャリアを築いてきたと思っています。
今回はわりとフロントエンドあるあるというか、どうやって開発者の体験を上げてきたかの話をできるといいかなと思います。
UXとDXはVSでつながないで
フロントエンドとDevelopers Experienceという話です。同じような言葉として“UX”という言葉があります。User Experience、ユーザー体験です。このUXを最大化してあげるというか、作ってあげるのがフロントエンドエンジニアの仕事の一番大きな部分と思っています。
最高のUXを作るために必要なのが開発者体験、DXかなと思っています。“〇〇X”という言葉がキャッチーで、UXとDXをVSでつなぐような記事がたまにあると思います。、よく考えてもらえばわかるかもしれませんが、これは別にVSでつなぐようなものではありません。 ユーザーの体験と開発者の体験、それはどちらもいいに越したことはないし、どちらかを犠牲にどちらかが成り立っているものでもないので。UXとDXをVSでつなぐこと自体間違っていると思っていますが、どちらかというと、両立することを大前提に考えてもらうのが一番いいのかなと思っています。
ただし！ ここがよくVSでつながっている原因かとも思います。開発者の体験を作るといっても、ユーザーの体験を作るとしても、いずれにせよ開発できるリミットの時間は限られています。その限られた時間の中で両方を成立すること自体は、確かに難しいと思います。これは1つの技術かと思います。
どちらもやらなければいけないことですが、両立させようとするとスキルが必要。かと言って、片方だけやったらいいかといったら、そんなことないところではあります。今回は、そのUXとDXの両立をさせるためには、どういう目的をしないといけないかを明らかにして、どうやってそれに対して向かっていくかを話そうかと思っています。
まずそもそもこの冒頭でいいたいことは、UXとDXはよく言う言葉で、VSでつながれるときがありますが、VSではつながないでくださいという話。言うは易しという言葉がありますが、どちらかというと両立してくださいという話です。
開発者体験を向上する目的
何か、なんで、どうやってやるかとか、いわゆる目的について話そうかと思います。開発者体験は何に依存するかというと、生産性です。生産性に直結するものと思っています。それが、ひいてはモチベーションにも直結する、関連してくるかなと思っています。
いわゆる開発者体験が悪いもの。例えば、開発するときにビルドに30分かかるとか、20分かかるとか。テストで実行して走らせて、終わるまで3時間かかりますとか。こういうのは完全に生産性が悪いわけです。
開発者がタイムリーにコードを書いて、タイムリーにリリースしてとやっていきたいのにも関わらず、それができないとなってくると、徐々に「どうなっているんだろう？」となり、自分の中で「こんなことが本当にやりたかったんだっけ？」という気持ちになって、モチベーションが下がっていくようなことがあります。
いわゆる生産性に直結する問題だと思っていて。この生産性がサービスの品質だったり、プロダクトの品質にも直結しますが、ひいてはそれだけではなく開発者のモチベーションに直結する。だから、開発者体験自体を上げる・上げないに関しては、そもそも開発者のモチベーションが一番犠牲になることがあります。そのため、上げていかないといけないし、これがサービスの品質にも関連するところです。
“開発者体験”と一言でまるっと言ってしまっていますが、実はいろいろな要素が絡んできていると思っていて。UXと言われたときに、単にユーザーインターフェイスのことを言っていないのと一緒で、“開発者体験”と言ったとしても、単に「テストを書いていない」とか、「ビルド時間が」とか、それだけの話ではありません。このセクションで“開発者体験の向上”というのは、ニアリーイコールで生産性向上のための施策のことをしゃべろうかなと思っています。
生産性を悪くするブロッカー
生産性を悪くするブロッカーはたくさんあり、「実は」も何もないかなと。例えば、開発終盤で手戻りが発生する。これも生産性が悪くなる一因というか、開発終盤まできて「これをやり直してほしい」となったときに、生産性が悪くなることは想像のとおりだし、開発者の体験も悪くなる1つかなと思います。
あとは、古くなったまま放置されたライブラリ。これも生産性を悪くする1つです。使いたいものがあったとしても使えなかったり、アップデートをしようとしたら「互換性が保たれていないか確認しないといけないよ」と言われたり。そういうのがけっこうあります。
あと形骸化したワークフロー。例えば、テストを書いてとか、コンポーネントのカタログを作ってやろうとしても、あまりちゃんとメンテナンスしていなかったりで形骸化している。そうすると、結局無意味なものだけが残り、ルーチン化されたワークフローになっているけれど、メンテナンスされてないから意味がない状態になっている。これも生産性が悪いです。
あとは……これはノーコメントです。IE対応も悪いですが、それはちょっとジョーク、ジャストジョークです。
開発終盤の手戻りについて
開発終盤の手戻りについて話をすると、よくある話で、けっこう昔のフロントエンドは、いわゆるAPIやデータベースのモデルなどができあがってから始まることが多く。そうじゃないとデータの大元がなかったり、それを操作できる対象がなかったりするので、操作する対象がある程度できあがってから開発に参加してになります。
そうすると、作っていく過程で「動いている画面を見たらなんか違ったな」などが発生しがちかと思います。過去の話でもあるとは思いますが、わりと昔に開発を進めていたときには最後の最後に「なんか違った」「変えていきたい」と言われたりする。
これもよく起こりがちかと思いますが、ユーザーインタフェイスを作っていたときに、ユーザーインタフェイスの部分とAPIの2つをガチャンとやったら動かない、みたいな。「よく見たらAPIの定義が間違っていた」「実はこっちが正しい」、もしくは「データのスキーマがこう変わったから、こうしてほしかったのに言ってなかった」とか、そういうことが発生します。
これも“手戻りが発生する”ということですが、手戻りが発生すること自体は別に、終盤でなければいいと思います。「本当のユーザーはこうやって使ってほしかった」というケースがたぶんあると思うので、その手戻りが発生すること自体は、そこまで悪いことではないと思います。しかし、適切なタイミングでフィードバックをもらい、変更をしてこなかった。そこが一番ネックになっているところかと思います。
他にも、さっき言った古くなったまま放置されたライブラリ。ライブラリの中で、例えばjQueryのライブラリを使っていて、「新しいバージョンで新しいファンクションが使えるらしい」と使おうとしたら、バージョンが3世代も古くて使えなかった。
jQueryのバージョンが3世代古かったところで、あまり気にしない人も多いかもしれませんが、機能が使えなくて、見てみたら古かった。これも1つの生産性を犠牲にする話だし、あとはこれはフロントエンドあるあるですが、フロントエンドはライブラリのバージョンアップ頻度がかなり早いです。
しかも、その上であまり後方互換性を気にしないライブラリもあったりして、破壊的な変更が多く、それによる障害発生が怖くてバージョンアップできない。これもあまり生産性がよくなりません。放置されちゃうケースとしてあるあるだと思いますが、溜まった洗い物みたいなものと一緒で、放置されれば放置されるほど大変になる。最終的になんの料理もできなくなることが発生します。
あとは、形骸化されたワークフロー。これは、かなりエンジニアリングのスキルレベルが高い人が、最初の開発初期段階で、例えば「テストをちゃんと書こう」「コンポーネントのカタログ一覧をちゃんとやろう」と言って、いろいろ作ってきましたと。コンポーネントカタログ一覧を作ったけど、誰も見てなかったから、結局「この前チラッと見たら壊れてた」「テストの追加の仕方がわからなくて誰もテストを書いていなかった」とか。結局あまり意味がないというところです。
ワークフローをちゃんと回すという部分もありますが、開発者ツールである程度解決できる部分も、そもそものスキルのレベルの差がかなり大きな問題を占めていて。開発ワークフローの定着ができていないんじゃないか、というところに起因する部分がある。
「ジョークです」と言いましたが、IE対応。ノーコメントと書きながらも一応コメントをしておくと、最近は基本的にやらなくていいと思っています。「やらない」ときっぱり言ってしまうのもありかなと思っています。覚えて帰ってほしいと思っているのは、IEで起動した場合であっても、Edgeに強制リダイレクトする仕組みがあります。
「IE対応をしてください」と言われたときに、Edgeに強制リダイレクトすることで、「IE対応そのものをやらなくていいですか？」と聞く手段もあると思います。起動したときに動かないことにはならないので、8割、9割のユーザーはこれで救えるんじゃないか、ということで対応するのもありかなと思います。
MS側に申請することで、IEで起動した場合、該当URLを開いたらEdgeになりますが、その仕組み自体は覚えて帰ってもらったほうがいいとは思います。IE対応をするだけで、昨今だといろいろなハックや、動かすためにやらなければいけないことも多いので、「やらない！」と言っちゃってもいいし、裏技でカバーもありだと思います。
まとめると、開発者体験を下げてしまう要因としてはいろいろあります。僕が今まで長く経験してきた中では、手戻り、放置されたライブラリ、形骸化されたワークフロー、このあたりが要因として、わりと多かったかとは思います。これが、結果としてモチベーションの低下やプロダクション品質の低下にもつながる可能性がと思っています。
（次回につづく）
