![見出し画像](https://assets.st-note.com/production/uploads/images/50297941/rectangle_large_type_2_477e10c94df3a99eb3cca4d56e22d0e2.png?width=1200)
ちょっとずつ、組織の「視点を揃える」
振り返りnoteです。
このnoteで言っていること
■ ユーザー視点でモノづくりをすることは大切、それは間違いなさそう
■ でも、その視点って妄想?独りよがりじゃない?
■ そもそも組織としてあらゆる視点を揃えるところからじゃない?
■ ということで、視点を揃えるために小さく積み上げています
ユーザー視点でモノをつくる
今さらだけど、ユーザー視点でモノづくりをすることは重要。なぜそうかはこのnoteであまり重要じゃないので割愛する。
例えば、起業家養成スクールである「Y Combinator」創設者のポール・グレアムも「How to Get Startup Ideas」でその重要性を説かれている。
※翻訳記事:スタートアップのアイデア(翻訳)
その視点って本当に正しいの?
■ そもそも一人で考えているユーザー視点はどの程度のもんなのか
■ 仮にそれが筋の良いものでも、共に価値創造・提供していくチームや組織にうまく伝え、視点を揃えることができているのか
視点は簡単にズレる
組織に多様な職種・役割を持つメンバーがいる場合、メンバーはそれぞれの目的・目標を持って行動している。故に、お互いの行動や考えがスッとハマらないことがある。
例えば、以下のような架空のデザイナーとマーケターがいたとする。
デザイナー:「ユーザーが触れるデザインの品質向上」を目的として、「デザインシステムの構築」を目標とする
マーケター:「ユーザーへの提供価値総量の最大化」を目的として、「LPのCVR改善」を目標とする
---
ある日、マーケターは、他社LPの改善事例から「ボタンに動きをつけること」がよいという情報を得て、デザイナーに改善案を持ちかけた。
しかし、デザイナーはその改善案に対してデザインの一貫性が損なわれるという理由を述べるだけで一方的に拒絶し、マーケターは他社事例を引き合いとして食い下がった。
この場合どちらが正しいかは重要ではない。それぞれにどんな視点が抜けているかということに注意したい。
つまり、上記のデザイナーは「提供価値の量」に対する視点、マーケターは「提供価値の品質」に対する視点が抜けているように見える。
仮にそれぞれが互いの視点を認識できれば、マーケターはデザインの質に関する懸念事項を合わせてデザイナーに伝えられるかもしれない。
デザイナーは「ボタンを動かす」アイデアに固執せず、CVRを高める方針から「ボタンを目立たせる」という目的を考慮して、デザイン品質を保てる形でのUIを練り直すことができるかもしれない。
組織の視点を揃えていくきっかけ
僕個人としても、ここ1年「視点を揃える」が1つのテーマとなっていた。
新卒から4年関わっていた1つのプロダクトを離れ、3つのサービス・開発チームに関わる機会をいただいた。
■ 人材紹介事業のWebサイト(半年)
■ 社内セールスシステム(半年)
■ B向けのHR Techプロダクト(今)
このように新たなサービス・チームに関わるようになって苦労したのは、情報のキャッチアップだった。
例えば、事業ドメインや用語の理解、事業ビジョン/ミッションの理解、関係者の業務理解、DB設計理解など。
サービスを良くするためには上に挙げたような情報を取り入れていくことで縦にも横にも視点を広げていく準備をしておきたい。
しかし、そうした情報が分散していたり、誰がどんな情報を持っているのかを知る術がないケースが少なくなかった。
小さく積み上げる
そこで、新たに入ってくるメンバーがスピーディーに視点を揃えられるようにするため、以下のような取り組みを行った。
例えば:
■ ドキュメント集を作る
→ サービス/プロダクトに関わる主要なドキュメントやリンクがわかるようにする。
■ 事業関係者を可視化する
→ ドキュメント化されていない情報を、誰に何を聞けばよいかわかるようにする。
■ ドキュメント更新自画自賛botの開発
→ ドキュメント更新を認知・称賛する機会を増やし、ドキュメント文化を作る。
※ドキュメント更新自画自賛botイメージ
(つよつよエンジニアがササッと開発してくれた)
-
また、現メンバーの視点を揃えていくために、意識的に自分の頭の中を公開するようにした。
例えば:
■ 新たに得た情報や疑問を、Slackで日常的に適度につぶやく
→ 自分の脳みそを公開することで、メンバーの視点や知恵が入る余地を作る
具体的には、事業ドメインや営業業務フロー、現状のプロダクトのUIに関する疑問、ユーザーヒアリング/ユーザビリティテストから得た学びなどをつぶやいていた。
つぶやきを起点として、施策化の検討がなされたり、事業ドメインに対する共通の疑問を持っていたメンバーがいたことがわかるなど、共有知が増えていく感覚を得られて良い。
また、そうしたつぶやきを(おそらく)良しと受け取ってくれたメンバーも自分の頭の中を公開してくれるケースが増えたと感じる。
おわりに
改めて、こういった「チーム・組織づくり」がプロダクト・サービスづくりの土台として重要であると理解し始めたのは、約3年前に参加した勉強会で聞いた金子さんの「ユーザー中心組織論」がきっかけだったように思う。
先日、その金子さんが最近出版された『ユーザー中心組織論』という本を読ませていただき、この一年の自分と重なる部分があり、振り返りを兼ねてnoteを書かせていただきました。
この記事が気に入ったらサポートをしてみませんか?