今回は、Pivotal Labs Tokyoの伊藤さんに、リーン・アジャイル開発に於けるデザイナーの役割や、チームとして「２×２マトリクス」を使った意思決定方法の具体例などについて寄稿いただきました。
こんにちは。Pivotal Labsのプロダクトデザイナーの伊藤えりかです。
Pivotal Labsは、クライアントのチームと一緒に開発をすることを通して、アジャイルチームの育成をサポートするコンサルティング会社です。2015年に東京オフィスが開設されてから、ラクスルなどのスタートアップからYahoo! JapanやANAといった大企業まで様々な規模、業種の組織へ向けたリーン・アジャイル開発の支援を行なっています。
リーン・アジャイル開発は、細かく作って細かく検証することで、プロダクトの価値をより短期間で市場へ届けることができると考えます。仕様書は極力作らず、毎日「なにを検証するべきか？」や「どうやって作るべきか？」を話し合いながら開発を進めます。多いときは一日になんども意思決定を行うため、いかに短時間で「ベストな選択肢」を見つけるかがスピード感のある開発をするための鍵となります。
また、意思決定にはプロダクトマネージャー（以下PM）、エンジニア、デザイナーが関わることで、バランスの良いプロダクトとなるように気をつけています。デザインもデザイナーだけで決めるのではなく、PM、エンジニア、時にはステークホルダーも一緒になってアイディア出しや話し合いをしながら進めます。
今回は、リーン・アジャイル式の開発現場で、デザイナーがどのような役割を担っているか、また、チームでの決断をどのように行なっているかをご紹介したいと思います。リーン・アジャイル開発を行う組織の中でのデザイナーのあり方として、参考になれば嬉しいです。
デザイナーの役割はユーザーに寄り添うこと
一口に「デザイナー」と言っても、業種や組織によって体制や仕事の内容には大きな幅がありますよね。特に最近は、「デザイナーに期待される役割がどんどん広がっている」と感じることもあるのではないでしょうか？これは、経営にもユーザー視点が必要だと言われるようになったことや、プロダクトの機能や振る舞いがそのままビジネスにインパクトを与えるようになったことが関係していると思います。
とは言っても、デザイナーがビジネス知識やコーディングスキルを身につけるべきなのか？というと、それは現実的ではないように感じます。Pivotal Labsでは、デザイナーも、ビジネスゴールの設定から実装まで全ての工程に関わりますが、ビジネス知識やコーディングスキルまでは求められていません。
これは、「PM、エンジニア、デザイナーがお互いを補い合うこと」を前提としたチーム構成と開発プロセスになっているからです。チームにおけるデザイナーの役割は「ユーザーに寄り添うこと」となっています。デザイナーもビジネスゴールの設定や実装にも関わるのは、プロダクトからユーザー視点が抜け落ちないようにする、という目的があります。
PMはビジネス視点、エンジニアは技術視点、デザイナーはユーザー視点からの意見を出した上で意思決定をすることで、バランスの取れたプロダクトが開発できる、という考え方です。
チームでどのように意思決定をしているか
先に「PM、エンジニア、デザイナーで集まって意思決定をする」と書きましたが、口頭のディスカッションでは、どうしても意見が入り乱れて目的を見失ってしまうことがあります。そんな状況を避けるため、みんなで集まって意思決定をする際には、付箋やホワイトボードを使い、意見を可視化しながら進めることに気を配っています。
意思決定に使える手法は複数ありますが、よく使うものの一つに「２×２マトリクス」があります。これは、意見の可視化と優先順位の整理が同時にできる、とても便利な道具です。例えば、縦軸にユーザー視点、横軸にビジネス視点の軸を設定し、それぞれの軸で優先順位をつけます。そうして2つの視点を掛け合わせることで、「何が重要か？」を整理することができます。軸は内容に応じて設定します。
それでは、実際にどのような場面でこのマトリクスを使うのか、具体例を2つご紹介します。
＜ユーザー視点軸×ビジネス視点軸＞
開発を始める前に「どんな施策を打つと効果的か？」という観点で検討することが多いと思います。より多くのユーザーを獲得するべき？価格改定をするべき？レスポンスを早くするべき？CTAを改善するべき？、、など様々な案が出てくると思いますが、期待される施策の効果を整理するときに使えるのが［ユーザーインパクト×ビジネスインパクト］の軸です。
まずは考えられる施策案を付箋に書き出し、ホワイトボード上に縦軸と横軸を作ります。そして、軸ごとに付箋を並び替えながら優先順位をつけていきます。ユーザー軸はデザイナーが中心となって、使い心地への影響や、影響を受けるユーザーの数などを考えながら、「ユーザーインパクト」の高低で順位づけをします。この時に、リサーチの結果や経験を元に、どうしてこの並び順なのか？を説明しながら進めるように意識します。次に、「ビジネスインパクト」の軸は、PMやステークホルダーが主体となって収益性や競合との優位性などを考慮して並び替えを行います。
こうして整理した結果、「ユーザーインパクトが高い&ビジネスインパクトが高い」に当てはまった施策から手をつけると効率的だと言えます。
＜ユーザー軸×技術軸＞
次は、開発が順調に進みリリースが見えてきた、という段階になったプロジェクトを例に挙げます。リリースするには、エラーケースをカバーすることも必須ですよね。プロダクトによってはエラーケースが膨大な数になることもあり、デザイナーだけで全てを把握するのは難しいこともあります。また、どこまでカバーするべきかの判断に悩むこともあると思います。このような場合は、PM、エンジニア、デザイナーで考えられる限りのエラーケースを付箋に書き出した上で、［ユーザーリスク×実装コスト］の軸で整理をすることができます。
この場合もユーザー軸はデザイナーが主体となります。エラーの重要性（危険性）や離脱リスクについて考え、「ユーザーリスク」の高低で並び替えます。次に、エンジニアが主体となってそのケースの複雑さや、他の部分への影響を考慮しながら「実装コスト」で並び替えます。
結果として、「ユーザーリスクが高い＆実装が簡単」に当てはまったエラーケースはカバーするべきですね。そこからさらに議論をする必要があるのは「ユーザリスクが高い＆実装が難しい」に当てはまるエラーケースです。どこまでカバーするか？は具体的なリスクの内容まで踏まえて判断する必要があるかもしれません。例えば、人命に関わるようなエラーはどんなに実装コストが高くてもカバーする、という判断になると思います。
最後に、補足になりますが「２×２マトリクスには２つの軸しか無いから、3つの視点を反映できないのでは？」と思う方もいるかもしれません。それはその通りなのですが、場合によって２×２マトリクスを二段階で用いることで、必要な情報を整理することができます。例えば、まずは［ユーザーインパクト×ビジネスインパクト］で施策案を絞ったあと、具体的な機能案を［デザイン案×実現可能性］でさらに整理する、などが考えられます。
このように、２×２マトリクスを「結論を出すための道具」と捉えるのではなく、様々な視点からの意見や情報を「整理するための道具」と捉えると、あらゆる場面で応用することができます。
まとめ
ご紹介したように、「チームで補い合うこと」を前提とすることで、デザインの力を最大限発揮できるようになるのではないかと思います。
そして、これは私個人の経験ですが、このような意思決定の場に参加するようになってから、「デザインに責任をもつデザイナー」から「プロダクト全体に責任をもつデザイナー」へとステップアップができたように感じています。
PM、エンジニア、デザイナーがお互いの領域を超えて意見交換をすることで、お互いの得意分野を最大限に尊重しあえる関係性も生まれます。デザイナーだけが「ビジネス知識も実装スキルも身につけなければ・・・」と頑張るのではなく、得意分野スキルを活かしたまま、意識を少しズラすだけで、より活躍できるようになるのかもしれません。そう考えると、ちょっとワクワクしませんか？
関連記事
Pivotal (Pivotal Software, Inc.)について
Pivotal は、クラウドネイティブ・プラットフォームと開発ツール、ユニークなメソドロジーを組み合わせ、 世界の大手企業が最も重要なソフトウェアアプリケーションを構築し実行する方法の変革をご支援していま す。 当社のテクノロジーは、グローバル 2000 企業がソフトウェア開発および IT 運用における戦略的優位 性を達成するために使用されています。
企業サイト：
https://pivotal.io/jp/
