プロトタイピングが社内に平和をもたらすのはなぜ?

こんにちは!

突然ですが、みなさんの社内は「平和」な環境でしょうか?

話が通じる環境で、アイディアに耳を傾けてもらえますか?
フィードバックを求めるとき、チームメンバーはそれにきちんと答えてくれますか?
すべてのチームメンバーが同じ方向を目指してがんばっていると言えますか?

「うわ、思い当たることがたくさん・・・」という方。あなただけではありません。こうした事態に頭を抱えている方はたくさんいます。

そもそも、立場や専門領域など異なるバックグラウンドを持つ複数のメンバーが、チームとなって一緒にプロダクトを作るということ自体が、大きなチャレンジなのです。ただ、円滑な議論やコミュニケーションができず苦しくなったときに、「仕事ってこんなものだから、仕方ない」と諦めてしまうのはもったいないです。

実はチームメンバーや他部署との間でのコミュニケーションを円滑に改善する秘策があるのです!

飲みニケーション?

いえいえ、ここで活躍するのが「プロトタイピング」。

前にプロトタイピングは「ユーザーに愛されるプロダクトを作るため」、「プロダクト開発におけるリスクや無駄を防ぐため」の方法だとお伝えしましたが、それだけではありません。プロトタイピングが持つもう一つのチカラ、それはチーム内・社内のコミュニケーションを円滑にするチカラです。

そこでこの記事では、「チームのコミュニケーション」にフォーカスた場合のプロトタイピングについてお話したいと思います。

プロトタイプは何の為にあるのか?

それを理解するために、もう一度プロトタイプは何のためにあるかを考えましょう。

Adobe Creative Cloudのプロダクトマネジャーを勤めているデミアン・ボルバー氏はプロトタイピングの役割をこう語っています。

「私たちは、学ぶため、異なるアイディアをまとめるため、議論を始めるため、そして構築プロセスを管理するためにプロトタイプを作ります。テストする、あるいは刺激を得る目的で作られたプロトタイプによって初めてチームに共感や協力が生まれ、新たな可能性やハードルが見えてきます」

プロトタイピングはチームのコミュニケーションを図り、仮説をテストするためのものだということですね。

でも、それが社内に平和をもたらす「コミュニケーション改善の秘策」といえるのは一体なぜでしょうか?プロトタイプの活用がプロセスやメンバーにどのような変化をもたらすのか、
具体的に考えてみましょう。

 

プロトタイピングはチームを一つにまとめる

はじめに、プロダクトができるまでの工程を思い浮かべてみましょう。

アナリストがリサーチを行い、プロダクトマネージャーがコンセプトを作る。デザイナーは画面をデザインし、開発チームがそれを実装する。営業・マーケティングチームができあがったプロダクトを販売する。

一つのフェーズをチームごとに担当し、終わらせてから次の担当チームに引き継ぐという流れです。
ここでの問題点は、専門チームごとに理解や意図にギャップが生まれること。Photoshopやコードなど、専門職向けの複雑なツールを使う場合は、さらにギャップが広がります。また、全てのメンバーが実際のユーザーの声を聞く訳ではないため、チーム全体としてユーザー目線を忘れてしまいがちになってしまいます。

その結果、各チームメンバーの視野が自分の担当範囲にフォーカスされてしまうため、オーナーシップや責任感を持たなくなり、ユーザーのニーズやプロダクト全体について考えることがなくなります。メンバーが全体像を把握していないため、チームで最適な判断をすることもできません。

また、切り離されたフェーズ間でコミュニケーションを取ることも簡単ではありません。うまく伝えようと言葉を重ねるほど、誤解が生じてしまうということも少なくありません。正確に伝えるために大量のドキュメントを作ったところで認識のズレが無くなるわけではないため、相手からの確認のリクエストは頻繁に発生します。プロダクトの品質に悪影響が出るばかりか、時間やコストなど多くのリソースを費やし、チームのモチベーションを低下させてしまいます。

規模の多いプロダクトを作っている事業会社の方にとっては“あるある”ではないでしょうか?

こうした問題を解決するためには、すべての関係者を最初から巻き込んで一つのチームを作ってしまうのが一番です。ただし、先に挙げた通り、専門領域の違う人々が一つにまとまるには共通言語を介した相互理解が欠かせません。


以前私が経験した例をあげましょう。

ウェブサイトに新しいCMS(コンテンツマネジメントシステム)を入れることを検討していました。マーケティング部だけでは解決できない問題だったので、IT部門の協力をお願いしました。私は多少のコーディング経験はあるものの、サーバーの話になると専門用語があまりにも多く、それが何語なのか区別もつかず、話についていけませんでした。ありがたいことに、チーム内の開発メンバーは気配り上手な人ばかりで、話しながら概念を絵にしたり、簡単なシステム図を描いてくれたので、きちんと理解して一緒に問題を解決できました。

ここで、フェーズごとに担当チームが分かれている従来のプロセスにおける問題点を整理してみましょう。

  • スペシャリストたちが互いに理解しないため、プロセスが止まったり、リソースを無駄に費やしたりしてしまう
  • チームが全体像を把握できないため、プロダクトにもっとも効果的な決断ができない
  • ユーザーの声が届かないため、ユーザーに愛されるプロダクトが作れない
  • コミュニケーションやプロダクト作りが上手くいかないため、ストレスやフラストレーションがたまり、チームのモチベーションが下がってしまう

開発メンバーにホワイトボードで描いてもらった絵や図のように、プロトタイプはチームの共通言語としてチームを一つにまとめ、この問題を解決することができます。

だれもがプロセスにスムーズに参加できる

上記の問題を解決するのに、まずは今までバラバラで動いていたメンバーがチームとしてプロセスを貢献できる場(プラットホーム)を用意しないといけません。

プロトタイプは、その役割を果たすことができます。出し合ったアイデアを具体的に表現するため、現在のアウトプットや進捗状況を確実に把握できるようになり、今後の方向や問題点がよりわかりやすくなります。

さらに実際に体験することも可能なので、細やかなテストを重ねて結果を反映させるのにも役立ちます。メンバーの反応を見たり操作感のフィードバックをもらうことが、ユーザーの気持ちに寄り添うことにつながり、メンバー間でも互いに共感や思いやりが湧いてきます。

また、ウェブ上でプロトタイプを管理していれば、直接顔を合わせて会議ができなくても同じような効果が得られます。誰でもフィードバックやコメントを簡単に行えるため、自然とプロダクトの現状を把握できるのです。

異なる職種の人々が互いに理解できる

職種の異なるメンバー同士でプロダクトを作る工程では、現状への共通理解だけでなく、互いの役割やスキルに対し、一定の理解と配慮が必要です。案外ここに課題を抱えている会社が多いのではないでしょうか。
コーディングに詳しくないデザイナーが最新トレンドのかっこいいデザインを考案して気軽に実装を開発者に依頼したが、実現が非常に難しいデザインだったために開発者がそのデザインを差し戻し、プロセスが止まってしまった・・・というような話を聞いたことがありませんか。

この問題の原因は、チームや担当フェーズが職種ごとに分かれていることで、アイディアの実現可能性が読みにくくなることです。せっかくのアイディアも最終的に日の目を見ないのでは考えた甲斐がありませんね。

プロトタイプを活かしたプロセスでは、関係者全員が初期からプロセスに参加するので、開発者がデザインの意図をしっかりと理解し、技術的な実現可能性についてもその時点で議論することができます。むしろ開発者が議論に加わることで、デザイナーやプロタクトマネージャーにはない、実現性を踏まえた新たな発想を得られるかもしれません。

そして全員で議論してビジネス面、技術面での決断を下すことで、共通の意識のもと、その後のプロセスを円滑に進められるようになります。

チームで素早くより良い決断をすることができる

良い決断をするために情報が必要なのは言うまでもありません。ただし情報は事実だけではなく、背景や前後のストーリーも重要視されます。

ひとつ極端な例をあげましょう。

友達から突然「パーカーを買いたいと思って買い物にきてるんだけど、どんなのがいいと思う?」という連絡を受けたら・・・なんと答えますか?

なんという店にいるのか、買う目的や着る人、着こなしのイメージもわからないのでコメントしようがなくて困ってしまうでしょう。アドバイスしようにも必要な背景や前後の情報が抜け落ちているのでなんとも言えません。

プロダクト開発でも似たようなことが言えます。

チームごとに担当領域が分かれていると、そのチームの物差しでさまざまな決定をしがちですが、視野を広げてみるとプロダクト全体にとって最適ではない決断を下していたということが往々にしてあります。

プロダクトの方向性やデザインを検討する際に、その目的や以前のバージョンとの差異、ユーザーの反応や他チームメンバーの意見といった前後のストーリーに気を配らなくては、プロジェクトを円滑に進められるような決断は難しいのです。

この点に関し、フォーチュン500やリテールの大手企業のプロダクトをデザインしたプロダクトデザイナーのポーリー・ティング(Pauly Ting)はプロトタイプの力をこうまとめます:

「プロトタイピングはチームの間の壁を破壊し、プロダクトやプロジェクトの範囲外で決定を生み出す’オフライン’の議論を減らそうとします。」

プロトタイプをもとに議論すれば、すべてのメンバーがプロダクトの現状に共通のイメージを持ちつつ意見交換できるので、決断がスムーズになるはずです。特にデザインレビューの際は効果的でしょう。

また、問題を解決するための手法やデザインは一つとは限りません。いくつかの解決案やアイデアがある時には、口頭でのディスカッションで話がまとまらないことがよくあります。専門スキルや背景の異なる人同士が自分のイメージだけで意見を持ち出しても、議論が噛み合わなかったり勘違いが生じたりしがちです。結局、声の大きい人の意見が通るだけ、という結末がよく起こります。

パーカーの例に戻ると、友達から「青と茶色のどちらにしようか迷ってる」とだけ言われてもコメントは難しいでしょう。しかし、もし二つのパーカーのサンプルが目の前にあって生地や色、着心地などを確かめられたら、着る人に似合うパーカーを選ぶアドバイスもしやすくなります。

プロトタイプは誰もが、見て、触って、体験できるというのが何よりの強みです。仮に各々が抱いていたイメージに違いがあったとしても、その場でそれぞれの案やアイディアを確認し、具体的に議論できるため、プロジェクト関係者全員での良い話し合いや決断を後押ししてくれると言えるでしょう。

ポーリー・ティング氏は自分の経験をこう語ります:

「私はよく議論の途中で ‘あなたが想像しているのはこんな感じであっていますか?’ とその場でデザインを変更することが多いです。そのうえですぐに決めたことをテストしたり、議論したりすることにより、メールでのやり取りで何時間・何日間を無駄にすることから解放されました 。」

さらにティング氏は、プロトタイプの力について、こうまとめています:

「私が理解したもっとも重要なことは、プロトタイピングにはすべての関係者を平等にするという偉大なチカラがあることです。

プロトタイピングは、UI、UX、PM、そしてエンジニアが互いの専門分野を理解する必要性を明かすことによって共同作業をするように導きます。

それは、ラピッドプロトタイピングが単なるツールや方法論にとどまらず、全ての人を巻き込む文化そのものだからです。スペシャリスト一人ずつに線形で責任を渡すことよりも同時に皆にプロセスに参加できる機会と力を与えます。その上、アイディアを誰でもわかるような形として残します。」

ここまで読んでくださったみなさん、誤解を生じないように一点だけ補足させてください。何回も全チームが同じレベルで議論すると言いましたが、それは意見交換の場への参加姿勢についてです。互いに尊重と尊敬の念を持ち、幅広い視野での議論をすべきですが、言うまでもなく「餅は餅屋」です。一つ一つの議題に関する最終的な意思決定は、その分野のスペシャリストと言える専門チームに委ねましょう。

ユーザーもチームの一員にする

プロトタイプのチカラは、社内のチームメンバーをまとめるだけにとどまりません。ユーザーもチームの一員として意識できるという効力もあります。

プロトタイプは、ユーザーテストの実施やユーザーの反応の確認を早い段階から得られるため、最初からユーザーの声をプロセスに取り込むことができます。ただし、それだけではありません。自分がユーザーの立場で体験できるので、ユーザーに対する意識を保ちやすくなるメリットもあります。

ユーザーを意識せず会議室で机上の空論を並べていると、ユーザーのニーズよりも、リソース不足や社内政治など会社都合に決断が引きずられがちです。会社やチームにとっては楽な決断ですが、ユーザーにとって最適な決断とは言えませんね。

プロトタイプを利用すればユーザーと同じ体験ができるので、ユーザー目線で必要性や価値の有無を考えられるようになります。その結果、ユーザーニーズから外れた判断はされなくなり、無駄を防ぎ、必然的にプロダクトの品質は向上します。

 

プロダクト作りが楽しくなる

このように、すべてのチームがアイディア出しからプロダクトの完成まで工程に参加することで、一緒に一つのプロダクトを作っているという意識からオーナーシップや責任感が醸成され、担当領域を超えてユーザーの反応もきちんと見えるようになります。

また、アイディアや進行を理解・把握しやすいカタチにすることによって、勘違いが減り、コミュニケーションにおけるストレスやフラストレーションが減少します。そしてなにより、「チームメンバーにワクワク感が湧いてくる」という、大きな効果をもたらすのではないでしょうか。

プロトタイプが活用されるのは「何をどこに配置して操作させるか」「デザインはどうするか」など、ユーザー目線でよりわかりやすいプロダクトにしていくための議論の場です。多種多様なメンバーが一つの問題を解決しようと議論することで、新たな問題が生まれることもあれば、考えつかなかったようなアイディアに巡り合うこともあります。

そうした開発の過程で、あまり関わったことのなかったメンバーと同じレベルでプロダクト全体について意見を交換する機会に恵まれ、互いのスキルや知識に刺激を受け、理解が深まります。最終的にユーザーにとって価値のある新しいものを作りたいと強く望んでいるプロダクト作りのプロとして、とても生産的で楽しい現場だと言えるのではないでしょうか。

まとめ ー プロトタイピングはチームもユーザーも、みんなをハッピーにする

プロトタイプの存在が常にプロセスの現状把握を可能にし、関係者を同じ方向に向かって一致団結させます。話し合いの過程で誤解を防ぎお互いへの不満を減らすことができるため、余計な衝突はなくなります。ユーザーに徹底的にフォーカスした風通しの良いプロセスは、生産的でワクワクする、楽しいプロジェクトになるでしょう。

プロトタイピングを通じて辿り着く成果に、あなたはきっと驚くはずです。プロトタイピングはチームとユーザーを統一する素晴らしい手段であるとともに、この設計プロセスの一環にいるすべてのメンバーに興奮を与えるのです。プロダクトデベロップメントに喜びと勢いをもたらし、チームがより良い意思決定を下すことができるようになります 。

今のチームにプロトタイピング文化がない場合、是非取り入れてみてはいかがでしょうか?

GoodpatchでもProttBaltoといったプロトタイピング・フィードバックを効率化できるツールを展開しています。事例もありますので、是非ご覧ください!

面倒だったフィードバックが簡単に!Baltoを使ったサービス改善。 LCL

ABOUTこの記事をかいた人

Goodpatch公式アカウントです。