主体性は持つものじゃなく生まれるものだと思う
この記事は、 Kyash Advent Calendar 2023の20日目の記事です。
こんにちは。masaです。
現在、Kyashでプロダクトデザイナーをしています。Kyashに入社したのは2023年8月頃で、それまではクライアントワークで、特にスタートアップのアプリやWebサービス開発のデザイン支援をしていました。
さて、突然話は変わりますが、皆さんは歩く時にどんなことを考えていますか。「歩こう」という明確な意志を持って全身の筋肉を一つ一つ意識しながら歩き続けている....、そんな方はほぼ居ないのではないでしょうか。かといって、誰かに指示されて受動的に歩かされているなんてことも、日常生活ではほぼ無いかと思います。要するに、私達は普段「歩く」という動作を能動的でも受動的でもなく自然と行っています。実は、これは「中動態の世界」という本の冒頭に出てくる話で、こういった能動的とも受動的とも言えないあり方を「中動態」と表現するそうです。
この「中動態」という概念が、プロダクト開発やチームメンバーがそれぞれ主体的に仕事を進める上で極めて大事な意味を持っていると私は考えています。
この記事では、仕事のフィードバックでよく使われがちな「主体性を持て」という言葉の問題点を探った上で、デザイナー以外のメンバーも含めチーム全体で主体的にプロダクトデザインに関われるように工夫してきたことを記します。
「主体性を持て」という言葉の問題点
新卒時代、私自身がマネージャーの方から「もっと主体性をもって仕事をしてほしい」と言われたことが何回かありました。また以前、あるチームのリーダーをしていた時、頼んだ仕事はこなせるものの、自らやるべきことややりたいことを考えたり提案したりするのが苦手なメンバーがいました。
実際、仕事をしていく上で受動的なメンバーがいると困るというのは当然起こることだと思います。しかし、だからといって「主体性を持て」という言葉を相手に投げかけることは果たして意味があるのでしょうか。自ら考え、発言し、行動することを主体性とした場合、誰かから強いられて行った時点でそれは受動的な行為です。
また、メンバーに主体性を持たせるために本人の目指す姿や目標、やりたいことを聞いていくアプローチを取る方もよく見ますが、個人的にはあまり意味がないと思います。なぜなら、その質問を上司や同僚から投げかけられた場合、業務上価値があり相手の期待に沿った「やりたいこと」を話さなければならないという重圧がかかるからです。そこで話された「やりたいこと」や「目標」は、誰かの期待や意図という圧力がかかった受動的なものがほとんどだと思います。
そもそも、主体性というのは個人の意志だけでコントロールできるものではありません。
例えば、その人にとって最も大切な人が苦しんでいて助けを求められたら、できる限り助けようと行動する人がほとんどではないでしょうか。しかし、その行動は主体性を持っている人間だからできるのではなく、相手との関係性によって自然と生まれるのです。
つまり、主体性とは個人が自分の意志で持つかどうかを選択できるものではなく、自分の心身の状況や周囲の環境、関係性によって自然と生まれてくるものです。
したがって、仮に主体性のないメンバーが居た時、主体性を持つよう説得したり持てるように誘導しても意味はありません。
まず周囲の人間がすべきことは、その人が主体性を持てない要因を把握することだと思います。もちろん、その中にはその人の思考の癖や習慣などの個人的な要因もあるでしょう。ただ、周りの人間との関係性や環境など、その人以外に帰属する要因も必ずあるはずです。
受動的な態度は構造によって生まれる
誤解のないようにお伝えしますと、これまでKyashで私が一緒に働いてきた方々は私が言うのもおこがましいぐらい、主体性が高い方々ばかりです。しかし、仕事の中では、意図せず誰かを受動的にしてしまうことがしばしば起こります。
Kyash以外も含めて私がこれまで経験したプロジェクトの中では、要件や仕様、デザインをPdMやデザイナーだけが決め、それをエンジニアに実装してもらうよう依頼するという開発フローに出会うことが何度かありました。このようなフローだと、どうしてもエンジニアが要件や仕様を受動的に待つタイミングができてしまいます。
すると、仕様やデザインを提案する側とレビューする側という関係性が生まれ、相互に主体性を持ってプロダクトをつくっていくという関係性を取りづらくなります。また、デザインが仕上がってからエンジニアにレビューを受けると手戻りが増えるという実際的な問題もあります。
前職はクライアントワークだったこともあり、上記の関係性がより生まれやすい構造にあったので、問題意識がずっとありました。
主体性が生まれるお手軽ワークショップ
そこで私がKyashに入って実践したのは、1時間で行うお手軽ワークショップです。
私のアサインされたプロジェクトが既存フローの改善をスコープとしていたため、既存フローの改善アイディアをみんなで発散することをゴールに行いました。当日のコンテンツは下記です。
ワークとツール（FigJam）の説明
アイスブレイク
ワーク1：既存フローを理想的な順番に組み替えてみよう
発表タイム（ワーク1）
ワーク2：ユーザーがサクサク進められる体験を生むTipsを生み出そう
発表タイム（ワーク2）
投票タイム
まとめ
ワークショップを行う上で、特に工夫した点は下記です。
1. 参加するメンバーの情報の非対称性をなくす
一般的に、エンジニアの方々はPdMやUXデザイナーに比べてユーザー情報や他社サービスに触れる機会は少ないです。また、現行フローの体験上の課題についてもUXデザイナーの方が解像度が高いケースが多いと思います。
そのため、ワークショップの前に既存フローのヒューリスティック評価や他社サービスの類似フローのリサーチ、ユーザーペルソナの作成を行い、エンジニアの方が現行の体験課題や他社サービスの特徴や自社との差分がすぐにキャッチアップできる表を作成しました。
こういった参考資料を事前に用意しておくことで、目線を揃えて議論をしやすくなるように心がけました。
2.アイデア発散のワークをレイヤーごとに分ける
アイデア発散のワークショップでよく起こりがちなのが、アイデアが対象としている課題の抽象度がバラバラになってしまうということです。また、何も手がかりがない状態で「改善のアイデアを自由に発散しよう」と言われると、逆に考えづらかったり、表層の細かいアイデアばかりが生まれてしまったりしがちです。
上記のような事態を避けるため、今回のワークショップではワークを2つに分けました。最初は全体の構造を組み替えたり省略したりすることをテーマにし、次に骨格や表層レベルの細かいTipsをできる限り挙げることをテーマにしました。こういった制限を設けることで、考えるべき課題をわかりやすくする効果を狙いました。
3.ワークショップ内で結論を出さない
ワークショップが盛り上がり、筋が良さそうなアイデアが生まれたとしても、それを採用するかどうかの最終判断はワーク後にPdMが行うべきだと私は考えます。盛り上がること自体はとてもいいことなのですが、そういう時ほどノリや勢いで物事が決まりやすく、大事な観点を見落とす危険性があるからです。
今回のワークショップも、真の目的はアイデアを発散することよりもチームメンバー全員で一緒に考える雰囲気をより高めることにありました。チーム全員で一つのことを一緒に考える時間をとるのはとても大事ですが、意思決定を毎回みんなでするのはスピードが落ちたり業務負荷が増えるだけです。なので、あくまで最終的な意思決定者は1人に絞るべきだと思います。
今回のワークショップは、「1時間だと短かった」という声もあったものの、チームが目指すユーザー体験の認識を揃えられたという点でメンバーの方々からとても好評でした。PdMにも「今後もできるだけやっていきましょう」という言葉をもらうことができました。
おわりに
上記で挙げたワークショップは、あくまで一例でしかありません。それぞれが主体性を持ちやすいチームづくりの方法は他にもたくさんあると思います。私が一番この記事で書きたかったのは、主体性というものは個人の意志だけで作られるものではなく、チーム全体の関係性の中で中動態的に自然と育まれていくものだということです。
これからも、自分が関わる人たちがいきいきとできるような環境作りをしていきたいと私は思っています。
この記事が気に入ったらサポートをしてみませんか？