どうやって開発者体験を上げていくか？
古川陽介氏（以下、古川）：ここまではいいとして、じゃあどうやって（開発者体験を）上げていくかという話です。ここからが本題だと思いますが、この手のブロッカーを排除する方法は、実はたくさんあって。どうやって紹介しようかと思いましたが、一応我々がどう取り組んできたかを紹介した上で、心構え的な話というか、考え方的な話を1つ追加できるといいかと思っています。
まず手戻りに関してです。実は、フロントエンドエンジニアはいろいろな人と関わります。開発しているときの役割の中で、中核的な部分にいるときが多いです。例えば、プランナーとフロントエンド。これも思いっきり関わります。なぜなら、一番ユーザーにやってほしい体験の根幹部分を考えるのがプランナーなので、そのプランナーがやりたいと言っていることはフロントエンドとも関わるし、もちろんデザイナーとも関わります。
見た目の部分でどう見せたいかも含め、全体のトーン＆マナーや雰囲気を作るところなので、フロントエンドの動きの部分などと密接に関わります。もちろん、バックエンドとも関わります。APIサーバーを叩いて、こちら側に要求したものがほしい。ほしいデータをこちら側に送ってもらわらないといけないので、そういうかたちで、わりとハブみたいになる傾向があります。
デザイナーやプランナー、バックエンドやフロントエンドが、彼らのハブみたいな感じになるときがあると思います。この他にもインフラエンジニアと絡むことももちろんあると思うし、最近はフロントエンドと言っても普通にサーバーを運用することもあるので、そのサーバーを運用する際には、インフラエンジニアとも絡むことがあります。そういったかたちで、組織的にはわりといろいろなところと絡む要素が多いと思います。
手戻りに関しては、関わる人が多くなればなるほど、仕事が進むにつれて、けっこう変更箇所が発生しがちです。やはりみんな並列に仕事が動いているので、それに対して思ったとおりや想像どおりのままで進むことは、基本的にはないわけです。
だから、プランナーやデザイナーがら「動いている画面を見たらなんか違った」「変えたいな」とか、バックエンドの人から「最後にAPIつないだらなんか動かないんだけど」というような話が始まってしまうのは、やはり関わる人が多いから、というのが1つの問題のポイントだったりすると思います。
2つの問題ポイントへの取り組み
ここで、今さっき挙げた2つの例。「動いているページを見たらなんか違った」という手戻り発生要因その1と、「バックエンドに最後につないだらなんか動かなかったんだけど」という、最後にがっしゃんこの2つについて、「我々はこうやって取り組んできました」という話をしていこうかと思います。
動いているものを見たらなんか違った問題は、最初に頭の中でイメージしたものが、ある程度進んで具体化されていくにつれて、徐々に乖離していってしまうんです。これもしょうがない話かと思いますが、やはり徐々に乖離していってしまいます。
ギャップ自体が小さいうちなら、実は変更修正が利きやすいです。開発途中でもいいからばんばんフィードバックを送ってもらわないといけませんが、たぶん企画の方やデザイナーの方がいろいろ忙しかったりで、あまりフィードバックをもらえていなかったりすると、最後に動いているのを見たら「なんか違ったな」ということで変えたくなる、というのがあります。
これも、放置しておくとどんどんギャップが大きくなりがちなので、適宜フィードバックをもらえる仕組みを作っておかないといけません。だから、ページを最初に作ってある程度動くところが出てきたら、そのタイミングで見せに行くなどをする。フィードバックをもらって都度更新、とやっていけるようにすると、ギャップが大きくなってからの更新がそんなに発生しなくなるので、タイミングをショートに守ってやっていく必要があります。
これはフロントエンドエンジニアとぜんぜん関係のない本などにも、いろいろやり方が書いてあります。我々のやり方としては、デモで見せられる単位で開発を進めておいて、都度フィードバックを得られるようにするのをやっています。
ぜんぜんフロントエンドとは関係ありませんが、『OKR』という本があります。「シリコンバレー式で大胆な目標を達成する方法」というので、OKRのやり方について書いてある本です。
OKR（Objectives and Key Results）という「いわゆる目標達成に向けてどうやって目標を積み重ねて達成するか」という本なので、フロントエンドは関係ありませんが、この中におもしろいやり方が書いてあって。デモデイを設けたほうがいいと書いてあります。
ケーススタディベースが書いてあって、けっこうおもしろいです。毎週金曜日にデモデイというかたちで、成果を見せて祝うというのをやる。いわゆるTGIF的な、欧米でよくありそうなやつ。最後の金曜日の昼過ぎぐらいから「みんな飲みに行くぜ」みたいな感じのノリでデモデイみたいなことをやり、「動いているね！ フー！」みたいな感じで開発していくと言っていました。
個人的に一番「それおもしろいな」と思ったのは、デモをするところです。金曜日に、必ず自分の作ったところや進めたところをデモして、それに対してフィードバックをもらう。ポジティブフィードバックを得た状態で金曜日を終えて、週末を迎られる。気持ち良く次の週に入れるという話だと思いますが、いわゆるこのデモデイをやっていました。デモで見られる単位で必ず進めておいて、都度フィードバックを得られるようにするところです。
具体的な方法
具体的にはですが、これはたぶんみなさんもやっていると思うし、そんなに目新しい方法ではありません。普通に開発のサーバーを常にプルリクエストが更新される度に最新化して、いつでもプランナーやデザイナーが触れて見られるようにした状態、かつ毎週決められたタイミングでイメージのすり合わせできるようにすることです。
実際、正直言ってしまえば何てことありません。普通のことをやっているだけです。
自分たちがやっていることは、見える化するのも1つです。しデザイナーやプランナーが見たときに、「今ここまでできているんだ」と見せてることで、「ここまでもうできているんですね」ともらった上で、「ちょっとここって……」とフィードバックを得やすくなるので、かなりおすすめの方法かとは思います。
もしかしたらみなさんすでにやっているかもしれませんが、こういった当たり前のことを積み重ねてやっていくのも、開発者体験を上げるための活動の1つだと思います。
最後に、つないだら動かなかった問題。これも基本的には適切なタイミングでフィードバックをもらえていないからですが、APIのスキーマの変更はUIの変更に直結しちゃうので、開発終盤で言われても、やはり厳しいところはあるかと思います。
最初期のほうでAPI定義や、「こういうデータをやり取りしましょうね」みたいなものを参考に、フロントエンドとバックエンドが何の進行もしないまま分離してサービスを作ってしまうと、それらを最後につないでも基本は動きません。ビッグバン開発みたいになると思います。
僕のイメージで、これが伝わりやすいイメージかわかりませんが、『バック・トゥ・ザ・フューチャー』という映画があると思います。『バック・トゥ・ザ・フューチャー』の映画の中で、雷を流して、その電力によってタイムマシンを動かして未来に帰るのがやりたいことですが、それをやる直前に電源のコンセントがバンッと切れてしまいます。
なんとか主人公たちが最後にそのコンセントをガンッとつないで、その瞬間に雷がドンッと落ちて電源がつながっていきます。あれは映画なのでそれでいいですが、基本的に普通はフロントエンドとバックエンドをガンッとつないでもつながりません。基本は映画みたい綺麗にいくことはなくて。フロントエンドとバックエンドをずっと分離して、最後に「つなぐぞ！」となってガンッとつないでも、あまり動かないと思います。
どうして動かないかというと、基本的に想定していないリクエストがどこかに必ずあります。すべてが想定のままいかないケースのほうが多いです。例えば、エラーの例外ケースがエッジなケースとしてあったこともあるし、文字列と数字で違ったとかのケースもあると思います。
我々のやり方としては、API定義を両者、主にフロントエンド主導で決めた上で、お互いに定期的に同期を取りながら開発することをやっています。
これはAgreedと呼ばれているツールを社内の内製で作っていて、それでカバーしています。このツール自体は、こちら側が送るデータとAPIが返してほしいデータをそのままJavaScriptやTypeScriptみたいなかたちで書くと、それがそのままフロントエンドのモックサーバーになります。
そのフロントエンドのモックサーバーに要求、いわゆるリクエストとレスポンスが書いてあるわけです。リクエストとレスポンスが書いてあり、そのリクエストとレスポンスを使って、今度はバックエンド側に要求はリクエストを投げてくれるテストになります。
そのため、こちら側が期待する要求と結果を書いたものに関しては、モックサーバーになってそれで開発が進むし、僕らが書いた要求と期待する結果はそのままサーバーにテストとして投げられるので、もしどこかの時点で想定と違うものが返ってきたら、その時点でテストをfailさせたり警告できる。何かしら要求と違うものが出てきた場合は知れるわけです。
これがいわゆるAgreedと呼んでいるものです。これはもともと名前が付いていて、Consumer-Driven Contract、日本語に訳すと「消費者主導契約」と呼ばれたりします。普通は逆で、プロバイダ、つまりサーバー側からAPIを定義して、それをクライアントであるフロントエンドのエンジニアが使って、というケースが多いと思います。
しかし、今回のケースに関しては、Consumer-Driven、フロントエンド側から要求を定義するやり方でやっています。
基本的にリクルートの開発ではAgreedを使って開発しているものの、認識齟齬を適切なタイミングで修正できるなら、個人的には別に何でもいいと思っています。例えば最近はgrpcなど、スキーマを共有してクライアントとサーバーでどういうものを期待として送るか、という仕組みもけっこう増えてきていると思うので、この辺の仕組みをうまく使っていくのもありかなと思っています。
お互いの認識に齟齬が生じないように開発していけば、最終段階でビッグバンみたいな開発になること自体は防げるとは思っています。これも手戻りを防ぐための施策です。
（次回につづく）
