どうしてアジャイル会社でデザイン部が必要なのか?

CJ Hostetter
yamaneco
Published in
Jan 7, 2022

この記事は、Regional Scrum Gathering 2022のために私が行ったトークを参考にしています。

どうしてアジャイル会社でデザイン部が必要なのか?

こんにちは、皆さん。トークにお越しいただきありがとうございます。

CJの写真。前職はfrog design, Goodpatch, yamaneco.

まずは自己紹介をさせていただきます。シージェと申します。9年以上UXデザインとして仕事をしています。今は、デザイン部長としてyamanecoと呼ばれるアジャイルスタートアップで働いています。

趣味:吹きガラス、インディーズゲームを開発したり、猫ちゃんと写真を撮る。

趣味は、色々ありますね。(笑)

吹きガラスをして、ビジュアルノベルを開発しています。今年でスチームにリリスしたいと思います。後は、私の可愛い猫と一緒に写真を撮るのは好きです。よろしくお願いします。見た目から分かると思いますが、私はアメリカ出身なので、日本語は母国語ではありません。そして、職業はスクラムマスターでもアジャイルコーチでもなく、デザイナーです。

なぜ、私は外国語を話すことにしたのでしょうか?

アジャイルの世界とデザインの世界を近付かせるために、新しい視点と言語を取り入れてみたいのです。

それは、より多くの人に同じことをやってほしいからです。たとえ難しくても、間違えても、アジャイルの世界とデザインの世界を近付かせるために、新しい視点と言語を取り入れてみたいのです。

「アジャイルとデザインは絶対にうまくいかない。」

私がアジャイルスタートアップに入社する前にそう思っていたこと。その思いから今までどうやってここにたどり着いたかを理解するために、ストーリーを語ります。以前、frogと呼ばれる国際的なデザインエージェンシーで働いていました。私は、グレーのスーツが着ている社長のプロダクトを厳しく批判しました。

「あなたのプロダクトは最悪だ。」
「デザインの力が必要。」

“Your product sucks,” と言いました。 “You need design to fix it.”

スクラムとデザイン:バックログvs.お客さんの声

全ての疑問は、デザインによって解決できると思いました。クライアントは顧客の声やビジョンではなく、バックログを意思決定の北極星として指さしました。顧客の体験を改善しようと思ったら、プロダクトの技術的な制限があり、諦めるので、スクラムもアジャイルも厳しく批判しました。

外から見ると、「スクラムとアジャイルの目的はただ機能のバックログを作ることだけだ」と誤解されていました。

なぜ、スクラムとアジャイルを厳しく批判したのか?

では、なぜスクラムとアジャイルを厳しく批判したのか?

プロダクト開発のチームの写真。プライバシー保護のため、絵文字を追加しました。

2017年、プロダクト開発の外から中へ飛び込んできました。以前冷たい目で見ていた私は開発者の苦労していること、不安を感じていることについて、共感し始めました。スクラムとアジャイルは違うと分かって来て、価値を理解し始めました。frogで学んだデザインプロセスや、開発者が使用しているスクラムを総合したいと思いました。

何がチームで、何が個人の判断なのか、デザインプロセスとスクラムイベントは一致しないのです。

でも、一つの問題がありました。何がチームで、何が個人の判断なのか、デザインプロセスとスクラムイベントは一致しないのです。

デザイナーが主に使っているフレームワークのダブルダイヤモンド。

デザイナーが主に使っているフレームワークのダブルダイヤモンドを紹介したいと思います。ユーザーのニーズを解決するプロダクトを作るための疑問を理解し、疑問を解決するために必要な、発散と収束を表しています。

フレームワークですので、スクラムと同じように考えてみてください。

ダブルダイヤモンドの発散。

発散とは、新しい情報を得て、新しいアイデアを作ることであり、いくつかのオプションを取り、さらに追加していくことです。そうすることで、新しい可能性を思い描くことができるのです。

発散の例: 顧客との対話とペルソナ作成、新機能のためのブレインストーミングセッション、5年後の製品を想像する、等。

例えば、機能を実装する時に、ホワイトボードでいくつかのアプリ画面を書き出します。このような時に、発散はスクラムイベントの外でPOやデザイナーと一緒に考えられていて、スプリントデモやプラニングの結果について話します。スクラムの「開発者」の言葉は、エンジニアだけではなくて、デザインにも含まれてますが、プロダクト開発の世界の中では開発者の役割は「コードを書く」ということ、そしてPOとデザイナーの役割は「案を描き出す」という考え方があります。

例:スクラムチームでは、発散は個人の判断、デザインプロセスではチームの判断。

そういう考え方をチャレンジしたいと思います。デザインはフィードバックに大きく依存しているので、デザイナーが一人しかいない場合、顧客や他のチームメンバーからのインプットがないと行き詰まってしまいます。発散は、異なる分野の人が複数参加することで、革新的なアイデアが生まれる可能性が高まるというメリットがあります。

ダブルダイヤモンドの収束。

収束とは、意思決定と優先付けのことで、得たアイデアや情報など多くのオプションを取り込んで、減らしていくことです。

発散の例: ユーザーストーリーマッピング、バックログの優先付け、新機能のアイデア決定、等。

例えば、バックログを優先付ける時に、ユーザーストーリーを収集し、その中から注目すべきものをピックアップし、スプリントに何か中心すべきなのかを決定する。私が観察したチームでは、全員参加します。なぜでしょうか?収束が必要な事象は、決める前に開発者の見積もりと意見を聞かせていただきたいからと言うことは一つの理由です。

例:スクラムチームでは、収束はチームの判断、デザインプロセスでは個人の判断。

しかし、デザインプロセスでは、デザイナーがチームにヒアリングして、一人か二人で収束することは多いです。なぜなら、デザインでは、チームの合意よりも、プロダクトに対する一致されているビジョンが評価されるからです。収束する時に、意見がぶつかり、難しい会話が必要になります。同意しない、討論する、そしてコンフリクトが行うまでするのは普通です。そうしないと、プロダクトの範囲が広がり、プロダクトビジョンが見えなくなってしまいます。収束に関わる人数が少なければ少ないほど、難しい会話は短くなるので、デザイナーが大部分を担当しています。

ちなみに、強いデザイン、つまり、プロダクトビジョンに一致している、ユーザーニーズに検証していた理解しやすいデザインを作るために、何回も何回も収束と発散をします。そのために、フィードバック、それと批評が必要になります。デザイン批評は、1日1回から2日に1回がベスト。もし1週間に1回、2週間スプリントが1回しかフィードバックを頂かなければ、デザイン的には遅いです。

スクラムでは、2週間スプリントに別れ、レビューに出来上がったものをデモしますが、あまり思いで深く話せる時間がありません。では、どうやって時間を作るのでしょうか?

入っていたプロダクトチームの中でこの問題が何回も出てきました。何回も統合してみても、スクラムとデザインのビジョンが合わせても、誰が何をするのかを一致しないと、困ります。

アジャイルチームでデザインコーチングからの学び。

告白してもいいでしょうか?

以前、私は文句を言うばかりでした。

プロダクト開発チームで、私はまだどうやって解決するのか分かりませんでした。ある日、yamanecoと呼ばれる会社から来たアジャイルコーチが入ってくださりました。そのときに、私は文句を言うばかりでした。そのアジャイルコーチとよく喧嘩をしました。

プロダクトチームをやめた時に、yamanecoから「ジョインしてみないか」ということを提案されました。

「なぜ、私にお願いしているの?以前、アジャイルコーチと喧嘩したこともあるのに、、」

「だからこそ、あなたはデザインとスクラムを統合できると思います。」

「は?」

そして、統合するのは多分無理と思っていた私がyamanecoに入社しました。でも、他のアジャイルチームとデザイナーは私と同じようなことに困っていると理解しました。コーチングから来た学びを次に共有したいと思います。

デザインが協力的な仕事ですが、主にデザイナーは一人で働く。

デザインが協力的な仕事ですが、主にデザイナーは一人で働く。

私は2年半の間、yamanecoの唯一のデザイナーでした。、何でも一人でやっていました。一人で顧客のヒアリング、案出し、決定。私が関わってきたアジャイルチームの大半は、デザイナーが一人しかいません。主なデザイナーはパターンライブラリを作るような長期的な仕事を諦めて、画像をエクスポートするような短期的な仕事が中心でした。そうすると技術的負債のような「デザイン負債」がだんだん増えて行きます。

短期的な仕事と長期的な仕事のバランスを保つため、チームの協力が必要です。ブレインストーミング、案を描き出す、デザイン画面を批評することは、POの責任だけではなくて、皆の責任です。先に言いましたが、デザイン批評は、1日1回から2日に1回がベスト。一人のデザイナーはその頻度で自分の作業を批評するのは無理です。

コンフリクトが安全に行うために、心理的な安全性が必要。

コンフリクトが安全に行うために、心理的な安全性が必要。

収束をうまく行うために、チーム内で心理的安全性があれば安全なコンフリクトが行われます。案がぶつかったり、討論するのは普通ですので、心理的安全性がないチームでは、デザインが生き詰まります。

例えば、あるチームのデザイナーは、いつも勝手に一人で収束しました。彼はもちろん頭がいいのですが、何かを決定する時は、いつもチームが関わっていませんでした。スプリントプラニングで彼のタスクは行き詰まり、収束が必要になりました。ですが、皆さんは馬鹿にしたくないと思いましたので、誰も意見を出せませんでした。タスクはそのままで止まって、チーム内で喧嘩が始まりました。

全てを捨てて、新しいフレームワークを立ち上げられるのは怖い。

全てを捨てて、新しいフレームワークを立ち上げられるのは怖い。

私がデザインとスクラムを総合しようとコーチングを学び始めた頃、あるチームでは「スクラムを捨てる」という話が出ました。チームが、今までで学んできたスクラムプロセスを全部捨てるのは怖いと言いました。

でも、他のフレームワークを試してみるのはいかがでしょうか?

Mobius Loopは、デザイン思考とアジャイル原則を統合したフレームワークです。

Mobius Loopは、デザイン思考とアジャイル原則を統合したフレームワークです。発見、生成、選択、測定、学びというプロセスをわかりやすくまとめています。(日本語の説明はこちら。)このフレームワークはダブルダイヤモンドのように見えますが、ダイヤモンドにはない重要な点、たとえば、学んだことを新しい案に統合することなどが含まれています。yamanecoは、これを不安を感じているスクラムチームに提案し、彼らは元気に会話をし始めました。Mobius Loopを自分のプロセスに比べて、どの部分を追加したい、改善したい、そして捨てたいと話しました。それを見て嬉しくなりました。このフレームワークだけではなくて、自分のチームに合わせたフレームワークを作成できます!

「アジャイルとデザインは絶対にうまくいかない。」

「アジャイルとデザインは絶対にうまくいかない」と思ったことがありました。嬉しいことに、私は間違っていたです。このような貴重(きちょう)な学びを与えてくれたyamanecoの同僚とクライアントにとても感謝しています。

以前に、私はスクラムとアジャイルと開発者の仕事を理解しなかったので、厳しく批判しました。

ですが、今ではスクラムとアジャイルの世界が少しだけ理解でき、好きだからこそ、厳しく批判しています。強いデザインを作るために、批評が必要です。今までで「デザインとスクラムをどうやって統合するのか」という話は、「スクラムを何も変えずデザインに入れてみたい」とか「ダブルダイヤモンドを変えず、スクラムイベントを入れてみたい」と言うことです。

「どうしてアジャイル会社でデザイン部が必要なのか?

しかし、違うと思います。

結婚した方がいらっしゃいますか?

今年が7年の結婚記念になります。「拍手」

ありがとうございます。「笑」

「私の生活、意見は何も変わらずに、いつもパートナーとラブラブしまーす」と以前は思っていました。でも、それは現実的ではないと皆さんご存じだと思います。私とパートナーは別の人です。コンフリクトがあるのは普通でしょう。ですので、心理的安全性を作って、お互いの気持ちを理解し、話が難しくても、怖くても、目をさまして、前へ向かいます。

スクラム、アジャイル、デザインと結婚することはできますが、いつもラブラブしないですよ。コンフリクトが行うのは当然なので、怖くても、やってもいいんじゃないか?

yamanecoのデザイン部は、そのようなコーチングをします。だからこそ、アジャイル会社の中でデザイン部を立ち上げました。

yamanecoのTwitterは、@yamaneco_agile, 自分のTwitterは@chostett.

この話を聞いて、「Mobius Loopを試してみたいな」と思えば、自分のプロセスに対して、デザイン思考に興味を持つかもっと言えば、あるいは全てを捨てて、新しいことを作りたくなったら、ぜひやってみてください!

たとえ失敗しても、一緒に成長すれば、もっと強くなれるはずです。

ありがとうございました。

もしあなたが東京の組織で、バイリンガル(日本語と英語)のデザイン思考とアジャイル統合についてyamanecoと一緒に仕事をしたいと思ったら、メールTwitterで連絡を取ってください。

--

--

CJ Hostetter
yamaneco

Design researcher, artist, indie dev. Co-founder of Studio Terranova in Tokyo, Japan.