2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
リンクをコピー
記事をブックマーク
古川陽介氏(以下、古川):ここまではいいとして、じゃあどうやって(開発者体験を)上げていくかという話です。ここからが本題だと思いますが、この手のブロッカーを排除する方法は、実はたくさんあって。どうやって紹介しようかと思いましたが、一応我々がどう取り組んできたかを紹介した上で、心構え的な話というか、考え方的な話を1つ追加できるといいかと思っています。
まず手戻りに関してです。実は、フロントエンドエンジニアはいろいろな人と関わります。開発しているときの役割の中で、中核的な部分にいるときが多いです。例えば、プランナーとフロントエンド。これも思いっきり関わります。なぜなら、一番ユーザーにやってほしい体験の根幹部分を考えるのがプランナーなので、そのプランナーがやりたいと言っていることはフロントエンドとも関わるし、もちろんデザイナーとも関わります。
見た目の部分でどう見せたいかも含め、全体のトーン&マナーや雰囲気を作るところなので、フロントエンドの動きの部分などと密接に関わります。もちろん、バックエンドとも関わります。APIサーバーを叩いて、こちら側に要求したものがほしい。ほしいデータをこちら側に送ってもらわらないといけないので、そういうかたちで、わりとハブみたいになる傾向があります。
デザイナーやプランナー、バックエンドやフロントエンドが、彼らのハブみたいな感じになるときがあると思います。この他にもインフラエンジニアと絡むことももちろんあると思うし、最近はフロントエンドと言っても普通にサーバーを運用することもあるので、そのサーバーを運用する際には、インフラエンジニアとも絡むことがあります。そういったかたちで、組織的にはわりといろいろなところと絡む要素が多いと思います。
手戻りに関しては、関わる人が多くなればなるほど、仕事が進むにつれて、けっこう変更箇所が発生しがちです。やはりみんな並列に仕事が動いているので、それに対して思ったとおりや想像どおりのままで進むことは、基本的にはないわけです。
だから、プランナーやデザイナーがら「動いている画面を見たらなんか違った」「変えたいな」とか、バックエンドの人から「最後にAPIつないだらなんか動かないんだけど」というような話が始まってしまうのは、やはり関わる人が多いから、というのが1つの問題のポイントだったりすると思います。
ここで、今さっき挙げた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など、スキーマを共有してクライアントとサーバーでどういうものを期待として送るか、という仕組みもけっこう増えてきていると思うので、この辺の仕組みをうまく使っていくのもありかなと思っています。
お互いの認識に齟齬が生じないように開発していけば、最終段階でビッグバンみたいな開発になること自体は防げるとは思っています。これも手戻りを防ぐための施策です。
(次回につづく)
関連タグ:
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略