DesignManagement
UXデザインやサービス開発の仕事をしていると、数年に一度は「方法論の更新」という話題に直面します。
振り返れば、使いやすさの改善から始まり、売上や成果への接続、コンセプトづくりや期待設計、さらにはサービス全体や事業の捉え直しへと、扱うテーマは少しずつ広がってきました。
今後は、人と機械が協働する前提での設計も、避けて通れなくなるでしょう。
受け入れる人と、構える人
こうした変化に対して、現場ではいつも同じような反応の差が生まれます。
新しい考え方を比較的すんなり受け取れる人がいる一方で、強く構えてしまう人もいる。
例えば自分で方法論を作ったことがある人などは、すんなりと受け入れることが多かった感覚があります。おそらく、その分かれ目は、知識量というよりも、「やり方には限界がある」という感覚を、どこまで体感として持っているかではないでしょうか。
ある方法論が長く成果を出し、組織の強さを支えてきた場合、それは次第に“正解”として共有されていきます。そういった状況での更新は、かなり手ごわい。
「染められる」ことへの防御反応
方法論の更新というテーマが出た瞬間に、議論の前に感情が動くことがあります。
「また新しいやり方か」
「これまで積み上げてきたものを否定されるのではないか」。
これは怠慢でも、変化への拒否でもありません。
むしろ、「ちゃんとやってきた」という誇りがあるからこそ生まれる、防御反応です。
方法論で説明しようとして、遠回りをした
私自身、この状況でずいぶん遠回りをしました。
新しい考え方を、できるだけ体系立てて説明し、理解してもらおうとしたこともあります。
今振り返ると、あまり賢いやり方ではなかったと思っています。
とくに記憶に残っているのは、使いにくさを直すだけでは成果が出ない案件に向き合い始めた頃です。
いかにインターフェースの課題をつぶしこんでも、成果が出る感覚がない。
問題は操作の分かりやすさではなく、「そもそも、どんな切り口でこのサービスを見せているのか」にあるのではないか。サービスを、どんなスライスで切り取って生活者にみせるのかから考えなければいけないんじゃないか。
つまり、目の前の障害物を取り除くのではなく、見せ方そのものを組み替える必要がある。
後から振り返れば「コンセプトを見直す」という話なのですが、当時は、その検討領域をどう説明すればよいのか、かなり苦労しました。
その更新の必要性は感じていたので、決してエレガントなものではありませんでしたが、不器用にも標準的な業務定義の書き換えに挑戦しました。チームに説明し、やってみようという動きを起こそうと働きかけました。
正しい指摘と、タイミングの問題
抗体反応は強くでていましたが、やがて概念としては理解され始めます。
ただそれでも今度は、「それは常にやるべきなのか」「不要なケースもあるのではないか」という声が出てくる。
それ自体は、まったく正しい指摘です。
今振り返れば、問題は「正しさ」ではなく、「タイミング」だったのだと思います。
まだ十分に切実さが共有されていない段階で、次のやり方の話をしてしまった。
ケースが足りず、「このままでは進めない」という実感が揃う前に、方法の話を先にしてしまった難しさがありました。
方法論ではなく、ケースを見せる
今なら、もう少し素直にやればよかったと思うことがあります。
それは、方法論を説明するのではなく、プロジェクトの事例をそのまま見せるというやり方です。
人は、誰しも誠実に学びたいと思っています。
ただし、「新しいやり方が来た」という話には身構える。
一方で、「価値を出した」「難しい問題を乗り越えた」という結果には、自然と関心が向く。
意味あるものは、勝手に真似される
成果を出した事例を前にすると、
「それは、どうやったのか」
という問いが、こちらが促さなくても生まれます。
意味のあるものは、勝手に真似されます。
説明しなくても、説得しなくても、うまくいったやり方は観察され、盗まれていく。
さらに言えば、同じやり方では突破できない状況に直面したとき、人は真似せざるを得なくなります。
その瞬間に初めて、新しいやり方は「押し付けられるもの」ではなく、「使える選択肢」になります。
前進とは、理解させることではない
いま思えば、「ケースで引っ張る」というやり方を、もっと意識的に使えばよかった。
それは変革を急がない、穏健な方法に見えて、実はもっとも消耗が少なく、確実に前進するやり方だったのかもしれません。
方法論は、先に理解されなくてもいい。
先に使われてしまう状況をつくれれば、それで十分なのだと今は思っています。
