私はソウルで働くニュージーランド人の開発者で、作っているのはスキンケアとコスメが大好きな人たちのためのコミュニティです。私自身はそういう人間ではありません。スキンケアといえば、調子のいい日に日焼け止めを塗る程度です。つまり、「ユーザーが何を求めているか」についての私の直感は、信用しないことを学ぶ程度には頻繁に外れる、ということです。

自分とはニーズも背景も好みも違う相手のために作っているなら、自分の勘はずれていると思ったほうがいいです。私がその対策としてやっていることを書きます。

直感よりリサーチ

#

勘が別のユーザー向けにチューニングされてしまっているなら、直す方法は本物のユーザーと接触することしかありません。アンケートとインタビューは素材をくれます。オープンな質問をして、あとは黙っていれば、何に苛立っているか、みんなちゃんと話してくれます。ユーザーがすでに集まっているフォーラムやコミュニティを覗きに行くのは、もっと安上がりです。そこにある日々の不満や熱狂は、どんなワークショップより多くを教えてくれます。既存のレポートや調査研究は補助輪です。自分が見つけたパターンが本物なのか、単に声の大きい3人の意見なのかを確かめるのに役立ちます。

ペルソナの例

#

上で書いたようなコミュニティアプリなら、リサーチの結果をこんな形にまとめます。ミンジはこの記事のために作った架空の人物です。本物のペルソナは、インタビューやフォーラムの観察からそのまま出てくるべきものです。

ペルソナが本当に役立つのは、バックログにつながったときです。目的や不満の一つひとつを、おなじみの「〜として、〜したい。なぜなら〜だから」という形のユーザーストーリーに落とします。たとえば「敏感肌のユーザーとして、肌質でレビューを絞り込みたい。自分と同じような反応をする肌の人の感想だけを読みたいから」。どのペルソナにもたどれないストーリーがあったら、それは誰のための機能なのか、一度問い直してみる価値があります。

頭の中に入り、次は生活の中に入る

#

共感マップというと、コンサルの小芝居っぽく聞こえます。でも、ペルソナが何を考え、感じ、言い、するのかを書き出す作業は、自分の好みをどこで投影してしまっていたかに気づかせてくれます。付箋そのものが大事なのではなく、「思い込んでいた自分」を捕まえることが大事なんです。

さらに強力なのは没入です。ユーザーが使う製品を使い、観るコンテンツを観て、行く場所に行ってみる。うちのユーザーが語り合っているルーティンを実際に試してみたことで、プロダクトが何を説明すべきかについて、どんな仕様書よりも多くを学びました。

プロトタイプ、テスト、傾聴、繰り返し

#

どれだけリサーチしても、プロトタイプとの初対面には耐えられません。だから、テスト可能な最小のバージョンを作って、実際のターゲットユーザーの前に置いて、相手の戸惑いを「使い方が悪い」ではなくデータとして扱います。リリース後も本物のフィードバックチャネルを開けておくこと。理解は一度きりの達成ではなく、ユーザー層は移ろい、トレンドは動き、去年の洞察は静かに賞味期限を迎えます。このループに終わりはありません。それでいいんです。

もっと確かな目を借りる

#

一人では埋められないギャップもあります。ターゲット層に実際に属している同僚は、自分には一生見えないものに気づいてくれます。私は同僚たちに頼りっぱなしです。自分とユーザーの間の溝がヒビ割れではなく渓谷なら、採用で解決しましょう。コンサルタントでもいいですが、できれば「本人がそのままユーザー」というチームメンバーがベストです。

すべての土台にあるのは、たった一つの規律です。目標は相手に響くものを作ることであって、自分が気に入るものを作ることではない、と覚えておくこと。私は今でも、気を抜くと自分のためにデザインしてしまいます。リサーチも、テストも、借り物の目も、それを早めに捕まえるための仕掛けにすぎません。それを続けていれば、実際に使う人たちのために機能するプロダクトができあがります。そもそも、それが目的だったわけですから。

私はその線を、身をもって探ってきました。マネジメントの訓練を受けたわけではなく、開発者として働くうちにプロジェクトチームを率いる立場になったタイプなので、以下に書くことはだいたい、一度少し間違えてから学んだことです。

リーダーシップにおける共感とは

#

リーダーシップにおける共感とは、メンバーが実際にどういう状態にあるかを理解し、意思決定をするとき、フィードバックを伝えるとき、チームの進め方を決めるときに、それをきちんと重みとして扱うことです。全員に同意することでも、会議で感じよく振る舞うことでもありません。相手の事情を十分に理解したうえで「ノー」と言うことは、普通にできます。自分の事情が考慮されていると分かると、人は肩の力が抜けて、早めに声を上げるようになり、仕事も目に見えて良くなります。この部分に関しては、世間の定番アドバイスは正しいと思います。

足りなくても、多すぎてもダメ

#

よく警告されるのは、人をリソースとしか見ない冷たいマネージャーの失敗です。これは実在します。メンバーの生活で起きていることを無視すれば、みんな口を閉ざし、士気は下がり、問題は何か月も経ってから発覚します。

一方、誰も警告してくれないのが、その逆の失敗です。何もかも受け入れていると、境界線が曖昧になります。締め切りはただの目安になります。そして、黙って水準を守っている人たちが、守らなくても許される人たちの分をかぶることに、不満を募らせていきます。私自身、その場では優しさのつもりで譲りすぎたことがあります。チームの他のメンバーにとっては、まったく優しくありませんでした。

共感がうまく働く例、行き過ぎた例

#

並べてみると違いがよくわかります。ルールというより、私が目指している形くらいに読んでください。

行き過ぎた例には共通点があります。その場では優しく感じられて、実はツケを後回しにするか、誰か別の人に回しているのです。

1on1がほとんどの仕事をしてくれる

#

私がバランスを保てているのは、何か哲学があるからではありません。カレンダーの定期予定のおかげです。定期的な1on1があれば、小さな問題は小さいうちに表に出てきます。ある日突然、退職願というかたちでまとめて届くのではなく。

私の1on1は、毎回だいたい同じことを聞きます。何に詰まっているか。最近うまくいったことは何か。チームの連携はどうか。今後どう成長したいか。そして、私が変えるべきことはないか。

いちばん役に立っている質問は、ごく地味なものです。「タスクを進めるうえで、私やチームから必要なものはありますか？」。ありふれた質問に聞こえますが、そうではありません。「私も解決に関わるつもりだ」という意思表示になりますし、返ってくる答えはほぼ毎回、実際に対処できる具体的なことです。誰かへのアクセスだったり、宙に浮いたままの決定だったり、1時間のペアプロだったり。

「ノー」を伝えるときこそ正直に

#

1on1をやれば要望が出てきます。全部には応えられません。応えられない要望をどう扱うかで、信頼は築かれもすれば、失われもします。

私のやり方はこうです。まず要望を真剣に受け止めて、そう伝える。今は実現できない理由を説明する。部分的な代替案があれば出す。いつ再検討するかを言う。そして結論が変わっていなくても、必ずその話に戻ってくる。

これで「ノー」を伝えるのが楽しくなるわけではありません。ただ、理由付きの正直な「ノー」は、二度と話題に上らない曖昧な「検討します」よりも、はるかにまともに受け止めてもらえます。

私がたどり着いた公式は、せいぜいこの程度です。メンバーの状態を本気で気にかける。仕事に必要なことは正直に言う。そして、どちらかに寄りすぎたことに気づけるくらいの頻度で、話す機会を持つ。