はじめに

仮説検証学習サイクルを可視化するためのツールを 「Experiment Board」 と呼んでいます。2年ほど試行錯誤を重ねましたが、今は納得して運用することができているので、世のプロダクト開発をよりよくするためにも、参考になるかわかりませんが公開したいと思います。

なぜ、この Experiment Board が必要だと思ったのかと言うと、過去にこんな悩みがあったことがきっかけでした：

• ユーザーリサーチの際に、過去の質問や検証内容と重複してしまうことがあって、時間の無駄だと思った
• どこまでが未検証で、どこまでが検証済みだったかわからず、迷走することがあった
• 価値ある学びやインサイトが多くあった場合に、まとめて管理したり記録する方法がわからなかった
• 仮説検証学習のために実験を繰り返す習慣を身につけたかった

これらのモヤモヤを解消してくれたのが、Experiment Board でした。 根底にあるのは、リーンスタートアップの「Build-Measure-Learn」のフィードバックループです。

2019年7月10日に、弊社主催のイベント「Pivotal.IO 2019」が開催されました。「デジタルの力でビジネスに変革を」をテーマに、弊社のクラウドプラットフォームである「Pivotal Cloud Foundry」などの導入や、私が所属している「Pivotal Labs」と一緒にソフトウェアを開発したユーザー企業様の事例が紹介されました。丸1日がかりのイベントで、各セッションが常に満席になるほどの大規模なイベントとなりました。その内の「Pivotal Labs パネルディスカッション〜実践者が語るリーンXPの価値〜」というセッションにて、僭越ながらオブザーバーという立場としてパネリストの方々と共にディスカッションに参加させていただきました。当記事ではその時の様子を振り返ってみたいと思います。

イントロダクション

まずはじめに、東日本旅客鉄道様と日本事務器様よりそれぞれのプロダクトの簡単な紹介と、Pivotal Labs と一緒にソフトウェアを開発した当時のエンゲージメントの振り返りからセッションは始まりました。

東日本旅客鉄道様
Pivotal Labs とのエンゲージメントを開始したのは2017年6月頃で、Pivotal オフィスに来たメンバーはプロダクトマネージャーが1名、デザイナーが1名、エンジニアが2名のバランスチームで参加しました。プロジェクト開始時には D&F（Discovery & Framing の略）を約4週間実施し、正しい課題を発見し、正しい解決案を発見してから実装・実現していきながら2017年11月6日に MVP（最小限で実用可能なプロダクト）となる「GO! by Train」をリリースしました。

Pivotal Labs でのエンゲージメントが終わり、自社に戻ってからも開発を続けているとのこと。そして2019年4月10日に JR 東日本アプリをリニューアルしました。

日本事務器様
Pivotal Labs と一緒にプロダクト開発を開始したのは2018年の3月頃。メンバーはこちらも同じくプロダクトマネージャー1名、デザイナーが1名、エンジニアが2名の計4人でした。開発したのは「fudoloop」という生産者と青果流通業者が出荷数などの情報をいち早く交換でき、食品ロスや価格の暴落を防ぐためのプロダクトで、Lean XP を実践しながらゼロから立ち上げました。

MVP をリリースしたのは2019年5月28日。これもサプライズだったのですが、2019年6月4日に NHKニュース「おはよう日本」の１コーナー「ビジネスに求められる“アート”」で日本事務器様の「fudoloop」が紹介されたそうです！残念ながらオンデマンドしか視聴することはできませんが、プロダクト開発の様子が一部映っています。

パネルディスカッション

さて、ここからは後半のパネルディスカッションの様子を Q&A 形式で振り返ってみたいと思います。話題は「実践チームのつくり方」「実践チームにおけるプロダクトマネージャーの役割」の二つにフォーカスされました。

— 田口様（以下、敬称略）：日本事務器様が Pivotal と一緒に仕事を進めるときにハードルはありましたか？

松島様（以下、敬称略）：今までとは異なるアプローチをやろうということで、いまいる新しい部署を立ち上げたので、アプローチから変えようという想いは既にありました。そのため、ハードルはそんなになかったように思います。

— 田口：これまでのお話にありました Lean XP を実践してみて、実際どうでしたか？

松島：とにかく検証を続けて、価値があるかどうかを調査しながら開発を続けるので、とても腑に落ちました。これまでのウォーターフォール型開発みたく、一気につくるのではなく、検証できたものからつくるという点が新鮮でした。実感を得ながらつくっていけるのはよかったですね。

こんにちは、Pivotal Labs のプロダクトマネージャーの Mario です。

Pivotal Labs を知らない方が多いと思いますので、簡単にご紹介しますと弊社オフィスでクライアントのチームと一緒に開発をすることを通して、アジャイルチームの育成をサポートする米サンフランシスコに本社を置くコンサルティング会社です。2015年に東京オフィスが開設されてから、ラクスルなどのスタートアップから Yahoo! JAPAN やANA といった大企業まで様々な規模、業種の組織へ向けたリーン・アジャイル開発の支援を行なっています。私はそこのプロダクトマネージャーとして、毎日楽しく働いています！

さて、これまでの「アジャイルチームのデザイナー」シリーズでは弊社のプロダクトデザイナーの Erika Ito がデザイナーの立場から、アジャイルなチームにおけるデザイナーの価値を最大限に発揮するためのアプローチや手法をご紹介してきました。シリーズの最後となる本記事では、プロダクトマネージャーの視点からアジャイルチームの在り方、そしてデザイナーの在り方を考えていきたいと思います。

アジャイルなチームはサステナブルであり、フレキシブルでもある

最近ニュースを賑わせているサービスの早期撤退に代表されるように、インターネット業界は非常に流れが早く、変化も早いです。その変化に対応するためには、ソフトウェアのみならずチームにも目を向ける必要があります。なぜなら、ソフトウェアをつくったとしても、その開発を常に続けなければユーザーに価値を提供しつづけることが難しくなるからです。そのため、今、正に求められているのは「確かなものを正しくつくり、ユーザーの反応を見ながら素早く学び、そして変化に対応できるチーム」なのです。

Pivotal Labs が考える、アジャイルなチームとしての在るべき姿は「Deliver Value Fast, and Forever」を体現できることです。直訳すると、「素早くつくり、頻繁にリリースしながら持続可能なペースで続けられる」ということです。つまり、理想的なアジャイルなチームは動くソフトウェアによってビジネス並びにユーザー価値を創出し続けることができます。

ソフトウェア開発のあるべき姿は、マラソンに例えることができます。最初から全力疾走で走るのではなく、負担が少ない一定のペースを保ちながら進むことで上り下り、追い風や向かい風といった急な障害や状況にも焦ることなく対応ができるようになります。だからこそ、マラソンランナーは長距離でも走りきることができるのです。

なぜ今、アジャイルなチームが求められているのか？

従来のソフトウェア開発手法であるウォーターフォール型開発は、要件定義、設計、開発、テスト、リリースという上流工程から下流工程へ順番に完了しながら移行していく開発手法です。この開発手法の特徴は、一度完了した工程に移行したら戻れないことです。開発を進める際に、問題や漏れなどがあった場合は、戻ってやり直す必要があり（場合によっては最初からやり直すことも！）時間とコストがかかってしまいます。

そのため、ウォーターフォール型開発は、変化に弱い開発手法と言えます。今つくっているソフトウェアを素早く検証しなければ、最初に決められた要件を満たすことがゴールとなってしまい、開発が終わって世に出す頃にはユーザーに使われずに失敗に終わってしまうケースがあります。

では、どうすれば成功の確率を上げることができるのでしょうか？それは、失敗するリスクが高い「思い込み」を特定し、検証方法を考え、その「思い込み」は結果として正しかったのか、間違っていたのかを検証して学習し続けることです。そのためのチームが、今求められているのです。

ケーススタディ：Zappos を成功に導いたチームの取り組み

実際にはどのような取り組みをすべきなのか。靴のネット通販会社「Zappos」がビジネスの成功確率を上げるために、実際に行なった取り組みをご紹介します。

リスクの高い思い込み：
人はネットで靴を購入するだろう

検証方法：

• サービスの入り口となる簡単なウェブサイトを用意し、販売を開始
• 在庫は自社で持たず、サイト上で靴が売れたらショッピングモールに出かけて靴を購入
• 発送も物流業者に頼らず、郵便局に出かけるなど、すべてをマニュアル作業で行う

結果：
ユーザーは、実際にお金を払って Zappos 上の靴を購入した

最初から完成されたサービスをつくらず、実際は裏を手作業で進めることで、ソフトウェア開発をせずに投資額を最小限に抑えながら、ユーザーのニーズを早期に確かめることができたのです。

この場合の最も危険な思い込みは「人はネットで靴を購入する」ことです。当時（1999年）はネット通販が普及する前だったため、本当にどれほどの人がネットで靴を購入するかわかりませんでした。この思い込みが違っていた状態のままで開発し、システムを構築していたらどうなっていたでしょう？

最終的にユーザーがネット上で靴を購入したことは変わりませんが、実際に世に出るまで分からないという不確実性が高い、まるでギャンブルのような状態が続くのは持続可能なチームを構築する上ではよくありません。Zappos のような取り組みが実践できるチームこそ、今求められているアジャイルチームなのです。

まとめ：アジャイルなチームにおけるデザイナーの在るべき姿とは？

以上のことから、私が考えるアジャイル・チームにおけるデザイナーの在るべき姿とは、リスクが高い思い込みを検証可能な仮説に落とし込み、最適な方法で検証する方法を見出し、実行と計測を続けられる存在だと思っています。

チームが考えているユーザーはターゲットとすべき人かどうか、という疑問があったとしましょう。そのための検証方法として、伊藤が当シリーズのコラム「ユーザーインタビューでよくある失敗例と成功のコツ」でご紹介したようなユーザーインタビューを通じてユーザーのファクトやニーズを把握する必要があります。

既にあるアイディアまたはソリューションは最適なのだろうか？少ない労力で検証することができるペーパープロトタイプなどを用いてコンセプト案を出してみましょう。別案のユーザーインターフェイスを採用することで、今よりも使い勝手がよくなる、という思い込みを検証するには、オンライン・プロトタイピングツールを利用してユーザーの行動を観察・分析することを推奨します。ユーザーが問題なくタスクを終えることができれば、少しづつビジュアルデザインの確度を上げて実際に動くソフトウェアをエンジニアが主体となってつくっていきます。

しかし、これらをすべてデザイナーが1人で行うことは難しいです。プロダクトマネージャーやエンジニアといった他のチームメンバーをどんどん巻き込んでいきましょう。そして、伊藤が当シリーズのコラム「デザイナーはチームの中でこそ最大限に力を発揮する職種である」で紹介したように、チームにおける意思決定といったアクティビティにも積極的に参加し、ユーザー視点をチームに持たせましょう。そうすることで、ソフトウェアを、チームをより成功へと導くことができるはずです。

これまでの話を振り返って見ると、デザイナーの価値は、デザインをする立場からデザインを導く立場へと変わっていっているように私は思います。それも、ソフトウェアのように持続的に。

関連記事

Originally published at https://www.creativevillage.ne.jp on August 23, 2019. 2019年8月23日に Creative Village に掲載させていただいた記事の転載です。

Product Run をご覧のみなさま、こんにちは！プロダクトマネージャーの Mario です。この記事は、Pivotal Labs が東日本旅客鉄道株式会社（JR東日本）様と共に、2017年6月から半年に及んだ JR 東日本アプリ「GO! by Train」新規開発プロジェクトの当時の様子を、インタビュー形式で振り返ります🚃 前編と後編に別れており、今回はその後編になります。前編をまだ読んでいない方は先ずはそちらから読むことをオススメします😎

Ono さんのプロフィール
JR東日本に入社後、車掌の教育あるいはヒューマンエラーの研究などの業務を経て、マーケティング調査やサービス向上に資する研究業務に従事。現在はデータやICTを活用したビジネス展開を様々な角度から実施する業務を統括。

Ito さんのプロフィール
JR東日本に入社後、指定席予約販売システム（MARS）の運用や売上管理、旅行商品造成・観光開発などの営業部門に従事。現在はICTを活用したビジネス展開を志向した複数のプロジェクトに携わる。

Taka さんのプロフィール
JR東日本に入社後、運輸車両部門を経て、ICTを活用した情報提供やビジネス展開の研究・開発に従事。2014年3月に「JR東日本アプリ」をリリースし、リアルタイムの列車運行状況などをお客さまにスマホで提供するサービスを実現。

ーー今も、Pivotal に来ていたメンバーとほぼ同じメンバーでプロダクト開発を続けていらっしゃると聞きましたが。

Taka さん：Pivotal に常駐していたメンバー4人は今も一緒に仕事を続けています。会社に戻ってからすぐにデベロッパーを2人増やしました。あとは当社内に「デベロッパーになりたい」という若い社員がいて、彼をデベロッパー見習いとしてチームに加えました。まだスキルは十分ではないですが、チームの一員として頑張って貢献してくれようとしています。帰社後1年経ってもなお、皆で Lean XP を愚直に続けている、という感じです。デザイナーとユーザーインタビューを月1～2回ペースで続けてもいます。

ーーPivotal で半年過ごし、卒業されてから1年経ってもプロダクトの開発を続けているとのことですが、その後、大きく変わったポイントを教えていただけますか？

Ito さん：私は正直言ってこのメンバーの中では、一番技術的な知識は乏しいと思っているのですが、それでもアプリとかシステム開発の考え方が変わったと思います。これまでは要件定義をして、「これで頼んだ」といって、あとは「いつまでできるんだ」というスタンスでしたが、途中のプロセスがよく理解できるようになりました。

Product Run をご覧のみなさま、こんにちは！プロダクトマネージャーの Mario です。この記事では、Pivotal Labs が東日本旅客鉄道株式会社（JR東日本）様と共に、2017年6月から半年に及んだ JR 東日本アプリ「GO! by Train」新規開発プロジェクトの当時の様子をマネジメント観点から振り返っていきます🚃 前編と後編に分かれており、今回はその前編になります。それでは、どうぞ！

Ono さんのプロフィール
JR東日本に入社後、車掌の教育あるいはヒューマンエラーの研究などの業務を経て、マーケティング調査やサービス向上に資する研究業務に従事。現在はデータやICTを活用したビジネス展開を様々な角度から実施する業務を統括。

Ito さんのプロフィール
JR東日本に入社後、指定席予約販売システム（MARS）の運用や売上管理、旅行商品造成・観光開発などの営業部門に従事。現在はICTを活用したビジネス展開を志向した複数のプロジェクトに携わる。

Taka さんのプロフィール
JR東日本に入社後、運輸車両部門を経て、ICTを活用した情報提供やビジネス展開の研究・開発に従事。2014年3月に「JR東日本アプリ」をリリースし、リアルタイムの列車運行状況などをお客さまにスマホで提供するサービスを実現。

ーーまず簡単に、OnoさんとItoさんの当時のプロジェクトにおける役割について教えていただけますでしょうか？

Onoさん：私がプロジェクトの責任者で、うまく回るように温かく見守り後押ししながら社内にアピールする、そんな役割です。

Itoさん：私は Ono のサポートをしつつ、グループのリーダーをしています。私のグループの中でも、JR東日本アプリは一番大きな仕事です。他にも山手線の駅にビーコンを付けて案内や広告に活用してみようとか、 Suica を使ったいろいろなサービスを考えたりということもしています。

ーーPivotal Labs では基本、クライアントのプロダククトマネージャーとプロダクトデザイナー、エンジニアに弊社オフィスに来ていただくのですが、お2人も週に2，3回くらいお見えになったことを記憶しています。その当時の印象を教えていただけますか。

Ono さん：私は Pivotal オフィスへ行くと「お客様にダイレクトに届く仕事だけを集中して」やっている現場を見ることができるので楽しかったですね。集中するために仕事の仕方やオフィス環境が整っていることも含めて。どうしても当社の企画部門の仕事は、様々な関係箇所があるため調整業務に偏りがちなので、本当にお客様に役に立つにはどうすればよいかを徹底的に考え実行することに十分な時間とれていないのでは、と思うことがあります。そうはいっても（調整業務も）もちろん必要だとは思っているのですが。

ここではダイレクトにお客様に役に立つ仕事を皆で全力でやっている。そういった環境に身を置いていることが、非常に楽しかったです。勉強になりました。

Ito さん：彼（Taka さん）も含めて私のグループのメンバーは、当時5人いたのですが、極力全員と話す時間を作った方がいいだろうと思っていました。ここに彼が常駐することになったときも、コミュニケーションをメールだけで済ませるのではなくて、来られる限り来ようとは思っていました。

我々は、先ほど Ono が言うとおりで、資料を作って社内でどう説明するかということばかりやっているのですが、ここでは皆で意見を出し合って、共有して、その結果をプロダクトなりデザインにフィードバックさせる。それを更にユーザーを呼んでテストする。これまで我々が開発会社に頼んでいたことを、ここでは間近に見られる。そのプロセスが大変興味深かったと思っています。ここに来ることによって、直に体験することができたことがよかったです。

あと、やはりスピードの速さはもちろん感じましたよね。

ここでは、Pivotal Labs が ANA システムズ株式会社様と共に、2016年9月から2017年6月にかけて ANA アプリを開発した当時の様子をインタビュー形式で振り返り、従来のウォーターフォール型開発からリーン・アジャイル型開発に切り替えるまでのチャレンジについてお伺いしました。Pivotal Labs について興味のある方は以下の記事もおすすめです 😆

• Pivotal Labsの1日
• Pivotal Labsって一体なに？

ーー僕は2016年6月入社のためはじめは知らなかったのですが、Takeshiさんはプロジェクト開始前にトライアル期間として数ヶ月、Pivotal Labs と一緒に仕事をしていたと聞きました。

Takeshiさん：はい。僕はトライアルで、2ヶ月ぐらいここにいました。トラ …

プロダクトやサービスを開発している中で、聞かれるとちょっとドキッとしてしまう質問があります。

（その）プロダクトの価値ってなんですか？

なぜドキッとしてしまうかと言うと、どのような言葉で説明すれば納得がいく回答になるのか、戸惑ってしまうためです。

プロダクトやサービスは何かしらのユーザーないしは社会の課題を解決しています。解決しているからこそ、存続していると思っています。そのため、プロダクトやサービスの価値はなんですか？という問いに対する回答には、どんな人の、どのような課題を解決しているのかが明確に具現化されていなければ、自信を持って答えることができずに、モヤモヤが残ってしまいます。

そもそもなぜ具現化する必要があるのか？

ぼくが好きな言葉のひとつに以下があります。

Customers don’t care about your solution. They care about their problems.（ユーザーはソリューションに興味はない。ユーザーが興味があるのは、自分自身がどのような問題を抱えているかである。）

米サンフランシスコで多くのスタートアップのアクセラレータープログラムを提供している 500 Startups の Dave McClure 氏の言葉です。

ソリューションはなんであれ、ユーザーはプロダクトを利用するきっかけとして、自身が抱える問題が解決されるのか否かを気にしています。そのため、どのようなソリューションでも、どんな問題を解決してくれるのかが具現化されていないと、ユーザーとの距離が遠ざかってしまって、つくることだけに注力してしまいがちです。それはチームにとってもよくありません。

結果としてリスクが膨らみ続け、ユーザーに使われなくなったり、改善に向けて検討を開始する際に、プロダクトやサービスの存在価値を問う場面に直面してしまって、あたふたして逆戻りしまいます。ぼくも以前、その状況下に陥ったことがありました。「解決したいこと」よりも「開発したいこと」が先行してしまい、開発して満足してしまうケースです。

どのように言語化すべきか？

具現化するためには、言語化する必要があります。言葉で表すことができなければ、もちろん伝達することはできませんよね。

そんな居心地の悪さから打破するためには、プロダクトやサービスの提供価値の言語化が効果的です。それも、対象の価値が一目でわかるようにすることです。

そこで今回ご紹介したいのは、Pivotal Labs でプロダクトやサービスの提供価値を言語化する手段の一つとして用いられているバリュー・プロポジション・ステートメントです。以下がそのフォーマットです。

〜は（ペルソナ）
〜のとき（コンテキスト）
〜ができていないだろう。（課題）

この〜は（ソリューションまたは機能）
〜とは違い（競合またはいまの解決策）
〜をすることによって（提供価値）
〜は（ペルソナ）
〜できる。（ユーザーが得られるアウトカム）

イメージしやすいように、例を挙げてみます。

電車の新しい乗り換え案内アプリを開発していると過程して、ペルソナの名前はタカシさんとします。ユーザーリサーチで特定した、ビジネスにとってもユーザーにとっても優先度が高く、解決すべき問題にアプローチするための提供価値を、バリュー・プロポジション・ステートメントにあてはめてみると以下のようになります：

タカシさんは
目的地（駅）に向かうために電車に乗るとき
ちゃんと時刻表通りに電車が動いているかどうかを必要なときに把握できていないだろう。

このプロダクトは
（競合プロダクト名）とは違い
正確かつ最新の運行情報を提供することによって
タカシさんは
どの電車を利用すればよいか自信をもって選ぶことができる。

実際のプロジェクトではコンテキストや課題をもっと具体的に記載していますが、提供価値をステートメントとして言語化することによって、冒頭の質問をされたときに、僕はもちろん、チーム全員が自信をもって回答することができるようになったと思います。

つくった後はどうするべきか？

バリュー・プロポジション・ステートメントのいいところは、以下がひとまとまりで表現されていることです。

• 誰が、どんなときに、どのような問題に直面しているのか
• 他と比較して、なぜこのプロダクトでなければ解決できないのか
• プロダクトの価値を届けることで、ユーザーが得られることはなにか

そして、このプロダクトでなければいけない理由をビジネスとユーザーの双方の観点から捉えることで、北極星を見失わずに済みます。

バリュー・プロポジション・ステートメントはつくっただけで満足するのではなく、常に振り返ることが大切です。時間の経過と共にユーザーもマーケットも変わっていくため、様々な調査を進めながら変化に合わせて柔軟に更新し続けていく必要があります。

そのためには継続的にユーザー調査を実施することをお勧めします。プロダクトマネージャー、プロダクトデザイナー、エンジニアなどメンバー全員で優先度が高いと判断したユーザーの課題を解決するための価値が反映されているか、がポイントになります。

もしお時間がある方はぜひやって見てください😆 そして、やってみた感想などをコメントなどでフィードバックしていただけると嬉しいです。

Pivotal Labs では、定期的にワークショップ型イベントを開いたり、ブログでプロダクト開発やチームビルディングなどについて紹介していきます。

イベントの最新情報：
Meetupグループに参加すると、いち早く案内が届きます😎📩

公式ブログ：
Product Runも是非フォローお願いしますっ🙌🏻🗒

こんにちは😊 Pivotal Labs Tokyo オフィスで PM（プロダクトマネージャー）として働いている Mario です。この Publication ではいまの私の仕事についてだったり、プロダクト開発における日々の考えなどを書いていこうと思っていますので、こちらでもよろしくお願い致します！

突然ですが…

どうしたらいいアイディアは生まれやすくなるのでしょうか？

プロダクト開発に関わっている方であれば一度は深く考えたことがあるのではないでしょうか？私もその中のひとりです。

高度経済成長期を支え、常識となっていた「プロダクトを届ければユーザーは自然とついてくる」といった「製造の時代」が終わり、いまでは「顧客の時代」と言われるようになってきました。情報の取得が地域に関係なく可能になったことで、人は溢れるほど提供されるプロダクトの中から欲しいものだけを選び取る能動的な行動を取るようになってきたことが、その背景にあるのではないでしょうか？

結果として、せっかくつくったプロダクトやサービスがユーザーに届かずに売れなくなってしまうリスクがより高まっていき、イノベーションを起こすためには…といった議論をあちこちで聞くようになりました。

では、どうすればいいプロダクト（アイディア）が生まれやすくなるのだろう？

このような背景から、ユーザー中心デザインやデザイン思考といったユーザーの視点からアイディアを創出する「創造的な活動」が2010年頃から注目されるようになっていくわけですが、同時に組織的な観点から考えを改めなければいけないことが増えてきたと考えています。

第一歩は一人に閉じないこと

3秒くらいで考えていただきたいのですが、ユーザー中心デザインやデザイン思考という言葉を耳にしたときに、みなさんの頭の中ではどのようなイメージが浮かんできますか？

恐らくこのような絵が頭に浮かんだのではないでしょうか？ホワイトボード、ポストイット、色とりどりのペン、複数の人が参加している、といったような発想の支えとなる要素が多いのではないかな、と思っています。

冒頭で述べたとおり、デザイン思考だからと言ってデザイナーだけに閉じるのではなく、組織全体でユーザーを理解し、課題を解決するために取り組む必要性が生じてきました。そのための活動として、組織の壁や職種をも横断してユーザーと向き合うデザイン思考があります。

しかし、

このような創造的な活動を実施することそのものはとても素晴らしいことなのですが、その価値を最大化するためには今回の主題でもある「公正性」を取り入れないと、形だけで反復せずに終わってしまうリスクがあるため、注意が必要です。

多様性だいじ、は本当にだいじ

今回のこの記事を書こうと思ったのは、同僚でプロダクトデザイナーの Erika Ito が書いた「多様性と働きやすさ」にインスパイアされたからです。

その記事で Erika Ito はとてもよい例を出しているのですが、ひとつのアイディアに対して、誰か一人が決めつけてしまうと他のアイディアを持った人が意見や考えを伝えられなくなってしまうことがあります。

属性やバックグラウンドが異なる人が集まる場では、「みんなそれぞれ違う」ことが暗黙の前提になります。そうすると、お互いの意見を聞き入れようとする雰囲気になりやすいです。

属性に加えて出身や国籍のみならず、役職や経歴もあてはまるのではないでしょうか。どうしても企業の体質上、役職付きの方が同じ場に出席する場面が多くなってしまうこともあるかと思いますが、もっとも大切なのは上で言う、お互いの意見を尊重し合う雰囲気をつくることだと考えます。

例えば年齢に多様性があるチームでも、年功序列的に、年上の人の言うことばかりが大切にされるような雰囲気では、多様性の意味がなくなってしまいます。

ではどうすればお互いの意見を尊重し合う雰囲気をつくることができるのでしょうか？ぼくがここで取り上げたいのは、公正性です。

不公平な扱いをなくす公正なデザインプロセス

公平をよくフラットな、とあてはめる人が多いと多いますが、差をなくすことが必ずしも公正というわけではありません。

公正なプロセスは例えば以下のことを指します：

• すべてのアイディアにチャンスを与える
• アイディアが優れているかどうかが重要である

公正なプロセスとは、お互いの意見を尊重し、一人が主張するものであれ、多数が主張するものであれ、最高のアイディアを求めつづけることです。この人が言ったから、この人が言おうとするから、という不公平な扱いがないことが前提です。

そうでなければ、「自分の意見が受け入れられる、または受け入れてもらえる」環境をつくりだすことができないのではないでしょうか。その分だけ、アイディアはスポットライトを浴びることなく去っていってしまいます。

Pivotal Labs が大切にしている公正性を保つための取り組み

Pivotal Labs ではアイディアを創出するためのアクティビティのひとつに「Design Studio」があります。具体的な進め方などの詳細はまた別の機会にとっておければと思いますが、Design Studio のゴールはこれからつくろうと考えているサービスやプロダクトの機能だったり画面の骨子となる優れたアイディアが何かをチーム全員で決めることです。