アジャイルとデザイナー：生成AIによる役割の変化とマインドセット、より速くなるディスカバリーのフィードバックサイクル〔ユーザベース平野さん×テックタッチ大輪さん対談〕

アジャイル開発に関わるデザイナー──平野さん大輪さん対談

アジャイルな開発チームで仕事をするデザイナーには、どういったマインドセットが求められるのでしょうか。アウトプットへのこだわりを抑えて、チームのメンバーとして果たすべき役割があります。またAIによるUIの生成が可能になってきた現在、その役割も大きく変化し始めています。

同じ美術大学に1学年違いで学んだ平野友視（@hiranotomoki）さんと大輪俊行（@ohwatoshiyuki）さんは、現在それぞれ法人向けSaaSを展開する事業会社でアジャイルな開発組織に所属しています。アジャイルな現場におけるデザイナーに必要な姿勢や考え方、そしてこれからの在り方について語り合いました。

アジャイルでは完成品ではなく価値を届ける

── お二人がデザイナーとして、最初にアジャイルな開発組織で仕事したときのことを教えてください。

平野　アジャイルと出会ったのは2010年ごろです。あるメーカーで全天球カメラの開発プロジェクトがあり、リリース前の初期段階から数年、外部のUI/UXデザイナーとしてお手伝いしました。そのエンジニア組織でアジャイルを教えてもらって、スプリントで区切って細かくリリースすることや、MVP（Minimum Viable Product）、エレベーターピッチといったアジャイルな開発に登場する要素を学びながら仕事しました。

それまでに関わったアプリ開発のプロジェクトでは、いわゆるビッグバンリリースでウォーターフォール的な開発ばかり経験してきて、リリース時期がどんどん先延ばしになって最終的にリリースしないプロジェクトもありました。そんななかでアジャイルというものがあると知ることができたきっかけです。

大輪　私のキャリアも最初はいわゆるウォーターフォール型でした。まず要件定義があって、そこから仕様が落ちてくるスタイルですね。それからエンタメ企業に移ってゲームアプリなどでスピード感が求められると、プロセスはウォーターフォールであるものの、今から考えるとアジャイル的に開発していたように思います。言葉自体を知ったのはその後の2015年ごろで、Webでアジャイルの記事をよく見かけるようになりました。

本当にアジャイルな開発を実践するようになったのは、現職のテックタッチ株式会社に入社した2022年からです。現在では、2週間スプリントで、スクラムマスターがいて、というしっかりした形のスクラムで開発をしています。ただし、弊社のプロダクトはかなり品質を重視するので、リリースは年に4回と限定されています。そのため細かくイテレーションを回すというより、もっと大局的に動いているのは特別な形かなと思います。

平野　私は2019年からユーザベースで働いていますが、現職のスピーダ事業が実践しているアジャイルの手法はXP（エクストリームプログラミング）と呼ばれるものなので、現在では私のなかでアジャイルといったらXPになります。スピーダ事業ではXPを愚直に実践していて、ここで「アジャイルにもいろいろな種類があるんだ」ということを知りました。

── 最近は入社してすぐアジャイルに取り組む方も増えているなかで、2000年代後半に新卒だったお二人は旧来型の開発から移行した形ですね。とくに違和感などはなかったでしょうか。

平野　私は性格的にも適応性が高くて状況に合わせた生き方をしてきたこともあって、最初からあまり違和感はなかったですね。ただしアジャイルな開発においては、完成されたものではなく、ある期間で切った最新版を顧客に提出することになります。新卒の頃を振り返ると、自分が関わるデザインを良くも悪くも中途半端な状態で届けることがすごく嫌だった時期はあります。

しかし、社会人4年目に自分のデザイン会社を作ってからは、お客様と伴走しながら一緒に作る方がデザインの価値が高くなることに気づいて、仕事のスタイルも変わりました。中間成果物や進行中のデザインでも顧客とできるだけ共有するようになり、それからはアジャイルへの違和感も全くなくなりました。

大輪　私も平野さんと同じです。やはり自分のアウトプットの品質は高くありたいので、スキル面を鍛えてきたところはあります。とくにそれまで日本になかったようなプロダクトでは、最初のリリースが基準になるのでそれこそピクセルパーフェクト¹を目指して仕事したこともありました。

しかし現職のように、既存プロダクトに途中でジョインすると、まずゼロイチではないのでそれまでのデザインルールを踏襲しつつ、その先でどういった価値を届けるのか。UIだけをきれいにするのではなく、チームが成し遂げたいアウトカムをお客様に実感してもらうことを意識するようになりました。

届ける先の人が何を求めているかに立ち戻ると、細かいデザインの優先順位は高くないんですね。アジャイルであるかどうかにかかわらず、早くリリースして使ってもらい、そのフィードバックサイクルを高速に回すためにどうするかが大切になります。

平野　まさにポイントはそこですね。顧客に提供する価値を検証するため、最新版は届けるけれど、完成版を届けるわけではない。そういう考え方なんです。

大輪　目的が「価値を届けること」だとすると「完成版」そのものが存在しないという見方もできますね。

アジャイルに馴染めるデザイナーとそうでないデザイナー

── デザインの中間成果物を提出することやピクセルパーフェクトを目指さないことを二人とも語られていましたが、それはアジャイルな現場で仕事をするデザイナーに必要なことになるのでしょうか。

平野　アジャイルにうまく馴染めないパターンのひとつに、制作会社でクリエイティブを作ってきたデザイナーが、現在の私たちのような事業会社に転職したときに感じるギャップがあります。例えば「完成していない製作物を売ってはいけない」とか「制作途中のものを見せたくない」という気持ちは、とくに芸術を学んできたような方に強く感じます。

それは業界によっては今でも正しくて、例えばゲームクリエイターならアイコンひとつしっかり作り込まないと買ってもらえないという話になるかもしれませんが、「ここでは途中のものを売っていいんだ」と気付けるかどうか、そして自分が合わせられるかどうかが大事だと思います。完成品を作って届けるスタンスが強く残っていると、アジャイルな事業会社には合わないことがありますね。

大輪　完成品に強くこだわる方はおそらくアウトプット志向が強いんだと思いますが、そのアウトプットの矢印が顧客にではなく、自分に向いてしまっていることがありますね。そういう気質のデザイナーは、どこかで価値観を変えないとアジャイルな組織で仕事をしていくのは難しいかもしれません。

本当は「ここまでやり切った方がいい」とか「ここまでいかないと納得できない」みたいな思いがあったとしても「まず試してみようよ」と考えられるかどうか。顧客に提供する価値やアウトカムにフォーカスしたときに、どう立ち振る舞えばいいのかを考えて行動できるデザイナーがフィットしますね。

平野　柔らかい思考や柔軟な姿勢があればアジャイルに合いやすく、そうでないと難しいということは言えると思います。ただし、別にアジャイルに合わないからといってデザイナーとしてダメなわけではない。そこが難しいんですが、生きる場所を間違えると不幸が起きるということはありますね。

── とはいえデザインにおける「こだわり」もあるかと思いますが、どう折り合いを付けるのでしょうか。

大輪　例えばUIのデザインなら、チーム開発なのでいろいろな意見に対応した方向性で案を作って「これがおそらく一番だろう」というものを提示しますが、そこでちゃんと言語化して伝えられればチームは納得感をもって進められます。そういったこだわりはありますが、言語化もできない「なんか絶対にこうしたい」みたいな我を貫くことは、チームプレイとしてないですね。

視覚的に認識できる「なんか美しいな」「色がきれいだな」「この形かわいいな」といったシンプルで美的ユーザビリティ効果²がありそうで、説明しても伝わらなさそうなこだわりは一人でしれっとやります。こっそりとアイコンを整えて、他のメンバーがふと見たときに「あれ、すごくかわいくなってる」とか。

平野　そう。こっそりやるんです。私も美的ユーザビリティ効果は信じているので、UIやソフトウェアのデザインが美しいに越したことはないと考えています。ただし、開発作業を止めて、話し合いをしてまで通したいかというと、そこは違う。そこはしれっとやるとか練り込ませるのが正しいと思います。

自分のこだわりを「まだリリースしたくありません」とか「もうちょっとやりたいです」と主張するのはアジャイルと合わなくなる。角のアールをきれいにしたり「この色だとくすんで見える」というクラフトマンシップ的な作り込みは、主張しないでこっそりやります。

影響の少ないところから始めて4年で8割をリプレイス

── お二人が現職でアジャイルにデザインを改善した事例を教えてもらえますか。

平野　はい。私が携わっている事例として、経済情報プラットフォーム「スピーダ（Speeda）」のリニューアルについてお話しします。スピーダは、企業のデータベースや業界レポート、市場データ、ニュース、統計などを収集・分析・活用できる企業向け（2B）のSaaSです。

🔗 「スピーダ (Speeda)」

このリニューアルは、私がユーザベースに入社した当初から実現したいと考えていたプロジェクトで、2020年から4年以上かけて、まだ終わっていないんですが、少しずつ進めてきました。アジャイル的な観点でいうと、スプリントが数カ月から半年という単位でリリースを重ねながら、ユーザーの反応や技術的なフィードバックを確認しつつ、少しずつできるところから修正してゆっくりと範囲を広げるという進め方をしています。

最初に取り掛かったのは、ユーザーリサーチしてアクセスが一番少なく、影響度も低かった画面です。UIのパーツでは、まずテーブルだけ変えました。テーブルのスタイリングが変わったところでユーザー体験はそれほど変わらないので。そして次にページャ、表示項目のパネル、ローカルナビの見直し、カテゴリーカラーの廃止、というようにリリースごとにパーツ単位で順にリニューアルを進めました。

▲ 財務諸表画面（リニューアル前）

▲ 財務諸表画面（リニューアル後）

▲ ツール画面（リニューアル前）

▲ ツール画面（リニューアル後）

4年間かけて細かくアップデートしてきた結果、今では8割くらいが置き換わっています。アジャイルにおけるスプリントごとの変化は小さいんですが、積み重ねることでウォーターフォール的に設計した大規模なリニューアルと同じ大きな変化になっていたんです。これはかなり大きな気付きでした。

大輪　前後を比べるとずいぶん見た目が変わりますね。コードもリファクタリングしていますか？

平野　完全にモダン化しているわけではないですけど、HTMLやCSSは使いまわしができるようにリファクタリングはしています。

── リニューアルしたいというモチベーションはどこにあったんでしょうか。

平野　リニューアル前のWebサイトは情報設計の構造的には整っていたんですが、私自身は「見づらくて使いづらい」と感じていました。しかし、経営会議でリニューアルの提案をしたところ「シーン」としてしまった。つまり誰も課題と認識していなかったんですね。そこでハッとして、この課題はデザイナーでなければ気付かないのかもしれない。それなら私しか解決できないので、強いオーナーシップを持って進めることにしました。

ただし「スタイリングを変える」というアウトプットではビジネスインパクトも薄いので、「ユーザー体験を改善する」というアウトカムを課題に立てて、機能開発チームとは別に「刷新プロジェクト」チームをスタートさせました。すると、いろいろな要件が出てくるんです。ソースコードの負債だとか、画面のレイアウトを変更したときにCS（カスタマーサクセス）のガイドラインをどうするかとか。

そこでリニューアルで実現したいUIのスタイリングには固執せず、要件のスコープを絞っていきました。最初はレイアウトを固定で進めたり、できるだけソースコードに手を入れないで変更できるところを探したり。

大輪　もし4年前にこのリニューアルを始めなかったら、今の状況はどうなっていたでしょう。

平野　リニューアルで大きく変わったこととしては、CSやセールスのモチベーションがぜんぜん違うんです。以前の見た目は「Windows 2000みたい」と揶揄されることもあったので、自分たちが売っているプロダクトがモダン化されたことを社内メンバーが本当に喜んでくれました。スタイリングの刷新が働く喜びにつながり、結果的に日々の仕事につながることがある。これは一番の学びでした。

デザイナーとAIだけで実現するプロトタイプやデモシステム

大輪　ところで最近はAIによって開発環境がかなり変化していますが、アジャイルな開発を進める上でもかなり影響が大きいと実感しているところです。平野さんはどうですか？

平野　まさに感じています。生成AIで開発をサポートしてくれるエディタもいろいろと出てきましたし、それによって実際に触ってフィードバックを得られるレベルのプロトタイプが簡単に作れるようになっています。弊社でも、デザイナーが生成AIツールでプロトタイプを作り、先にユーザーからフィードバックをもらってから本番で検証する。そんなサイクルを作ろうとしているところです。

要はテスト環境においても、本番とほぼ同じ体験を得られるモデルにシフトし始めているところです。開発で一番悲しいのは、せっかくアジャイルに進めたのに、フタを開けるとユーザーニーズがそこにありませんでしたということなので、疑似的にでもあらかじめテストできることは大きいです。

リリースタイミングもこれまでは早くて2週間スプリントだったとすると、とんでもないスピードで圧縮できるようになっています。スピード感が変わったなかで、最近は価値検証のスピードや精度をいかに上げていくかにリソースを振るべきではないかと考えています。

大輪　それはデザイナー主導で動いてるんですか。

平野　そうですね。実質的には私が進めています。今まではディスカバリーならディスカバリーだけで区切っていたのを、最近はさらに実際に動くプロトタイプを作って試してみるところまでやっています。

大輪　弊社も同じですね。まさにデザインチーム主体で、実際に動くデモシステムに取り組んでいます。実例として、デジタルアダプションプラットフォーム「テックタッチ」の顧客向けデモを紹介します。

🔗 「テックタッチ」

「テックタッチ」を既存のWebサイトに導入すると、入力が必要な箇所をハイライト表示したり、ボタンを追加して注意喚起したり、そのページでユーザーができることを分かりやすくガイドしてくれます。それだけにお客様のWebサイトに応じたさまざまなユースケースが考えられ、CSチームには「営業資料だけでは、初見のお客様にサービスの効果が伝わりづらい」という課題がありました。

これまでお客様の環境で実際に動くデモを用意することは難しかったのですが、Vercelが提供する生成AIサービスv0を使うことで解決しました。v0がフロントエンドのUIとコードを生成してくれるので、デザインチームだけでデモシステムを作成し、営業やテストに使ってもらうことができます。

実際に動いているところを紹介します。まず、これはv0で作成したデモシステムです。

左上にあるトグルスイッチをオンにすることで「テックタッチ」が有効になり、ユースケースを体験できるようになります。

資料ベースの紹介で伝わらなくても、このデモを実際に操作してもらうことで「必要な情報が入力されていないとこんなアラートを表示する」といった効果を試してもらうことができます。

先ほど話したように「テックタッチ」はリリース頻度を抑えているので、プロダクトだけをアジャイルに回していてもUI/UXの改善に限界があります。プロダクト外の取り組みが必要だと考え、開発リソースを使わずに顧客体験を高めるアプローチとして、お客様に対面するCSやセールスといったビジネス領域との連携を始めました。

まず、CSやセールスのメンバーにデモを触ってもらい、プロダクトの使い方や見せ方をブラッシュアップできます。このトグルスイッチ自体が、最初にデモをお客様に見せたときに「テックタッチ」の効果が分かりやすいようにオン・オフしたい、というフィードバックに対応したものです。

さらにボタンジェネレーターなども追加していて、デモシステムだけで再利用可能な部品を簡単に適用できるようにしました。お客様がデモを使ってみた感触や課題感・ユースケースなどから、申込み画面に「テックタッチ」を載せるとこのように分かりやすくなります。というイメージしやすいデモを、CSやセールスの担当者自身が作成できます。これでビジネス提案もアジャイルに改善サイクルを回せるようになりました。

この先生き残る開発チームの形とメンバーの役割

平野　こういったデモシステムはこれまでアジャイルに開発して、本番環境で一部のテストユーザーに向けて提供してきました。これをデザイナーだけで構築して、デモ環境として提供できるようになっている。スピード感の変化もすごいですし、デザイナーにとっても時代の変わり目という感じがします。

大輪　アジャイルの本質は、小さなイテレーションをできるだけ速く回して効果的に価値を届けることにあると思います。それがAIにより、フィードバックサイクルがさらに速くなっています。これまではPdMやエンジニアも含めたさまざまな観点で検証しながら、細かく質を高めていくというサイクルでした。AIツールを導入することによって、仮説ベースでより速くフィードバックを得ることができるようになっています。

一方で、ツールが進化することでインターフェース自体もコモディティ化していて、あまり差別化できなくなっている面もあります。そうすると「プロダクト自体が何の価値を届けているのか」によりフォーカスするようになりますから、関わるメンバー全員が職種に関係なく、自分たちが達成すべきことを探索し、そこに向かって進むことが重要になってきます。

平野　たしかにデザイナーやPdM、エンジニアといったメンバーの役割については、境界がどんどん溶けている印象があります。だからこそ、1人よりチームの方が価値を生むことができるのは確かですから、いろいろな人がそれぞれの視点をもっと生かすことも必要です。

ますます、メンバーみんなの知恵を集めて、価値を最大化できるディスカッションやプロトタイプづくりを進めていくことが重要になりますね。むしろ、そういった取り組みができる「アジャイル」なチームでなければ生き残っていけない。そう感じています。