見出し画像

発信のハードルを下げる

こんにちは、世界中のヒトや組織の可能性を拡げたい、おおもりです。株式会社アトラエにて、組織力向上プラットフォーム Wevoxのプロダクトデザインをしています。

今日は、「発信のハードルを下げることの重要性」という話をさせてください。


本題の前に…軽く自己紹介

本題に入る前に、初投稿なので軽く自己紹介を。

2022年5月にアトラエに第二新卒のデザイナーとして入社しました。Wevoxという組織力向上のためのSaaSプロダクトのUIデザインを中心に、機能開発の企画をしたり、フロントを書いてみたりと色々やっています。

小学生の時に人生での許容量を超えた摂取をしてしまったため、納豆が苦手です。

集中力が低めです

違和感を発信する難しさ 

ここから本題です

「違和感の発信」って、非常に難しくないですか??????

とある日の自分

これはかつて僕が悩んでいたことです。


プロダクトづくりをしていると、「チーム全員がコトに向かうことが大事」「提供する価値にフォーカスすることが重要」のような話をよく耳にします。


その大切さは職種柄もあり非常に痛感していますし、近年ユーザー中心のプロダクトづくりの広がりや、そのためのフレームワークが増えてきたことで、実践しやすくなってきているなと感じます。特にプロジェクトの開始時においては、十分に検証をしたうえで、誰に、何の価値を届けるのかを起点にして走り出すことが非常に多くなったように思います。


しかし、プロジェクトが進行するにつれ、提供価値よりプロジェクトの進行や、チーム内のコンフリクトを発生させないこと優先させてしまっている。
ふと気がつくと、そんな状況に陥っていることがあります。かく言う自分も、この状況に落ち込み、悩んでいる時期がありました。

苦悩していました


そして、この状況の大きなデメリットは、「違和感の発信」へのハードルが格段に上がってしまうことです。例えば僕のケースでは、プロジェクト中に作っているものや途中経過に対して違和感が生じたものの、次のようなことを思って発信を躊躇してしまうことがありました。

・発信するなら、納得できるような説明をする責任がある
・対案ないと、今発信しても文句にしかならない
・この発信で、プロジェクトが止まるかも
・他のメンバーがもう考えたんじゃないかな、あえて蒸し返さなくて良いか

本来、提供価値にコミットするのであれば、どんな違和感でも議論の俎上に上がること自体に価値があると考えるのが自然です。


ところが、サンクコストや、プロジェクト進行に伴った暗黙的なメンバー間の領域区分などの様々な遠心力で、プロジェクト進行に伴い違和感の発信に難しさを感じやすくなり、結果として「なんとなく違和感はあるけど、誰も発さない」「全員なんとなく頑張る」という状況が生まれてしまいます。


では、この状況が生まれることを防ぐにはどうすればよいのでしょうか?


個人的には、完全に防ぐことは不可能だと思っています。というのも、プロジェクトが進行するに連れ、提供価値とは別の論点が入ってしまったり、違和感の発信のハードルが上がったりするのは構造上どうしても起こり得るからです。むしろ、ある種仕方ないものとして受け入れ、自覚的になった上で、

発信者のハードルをさげる
議論のテーブルに乗せることを最優先する、歓迎する

という遠心力と逆の力を、マインドと仕組み双方の面からチームで担保するのが、一番大事なのではないかと考えています。

発信が当たり前になったプロジェクトの話

実は、このように考えるに至った背景には、自分が参画したプロジェクトでの成功体験があります。このプロジェクトの概要をかいつまんでご紹介しようと思います。

プロジェクトの発足

プロジェクトの内容としては、Wevoxの契約周りの改修。発足のきっかけは「契約周りのペインが社内、社外ともに大きい」という課題感を、開発メンバーの1人が発信してくれたところからでした。


当時Wevoxの契約に関してはざっくりと、
■ ユーザーで操作できる部分が極めて限定的
■ 社内システムが整っていない
というペインがあり、この2つを解消するためにプロダクト・社内システム共にまるっと改修しよう、という目標が定められ、プロジェクトが走り始めました。


メンバーはデザイナーの自分に加え、プロダクトオーナー1人、フロントエンド1人、バックエンド1人(PMも兼務)という最小人数での構成になり、この4人でビジネスロジック満載の改修に立ち向かっていくことになりました。

各領域にアサイン1人という、少数精鋭のチームでした
(出典 : 美味しんぼ 38巻より)

プロジェクトでの苦戦とアウトカム

プロジェクトの進行は、当初は順調ではありませんでした。
ビジネスロジックが多い改修にはありがちですが、後から判明したビジネス/リーガル側の制約で要件を見直したり、既存システムの仕様に苦戦したりということが何度も発生しました。

そこで、メンバーからの提案を受け、毎朝1h同期でチームメンバーが集まって、要件/仕様や、それによってもたらされる提供価値に関して見えている課題を列挙し、ひたすらに同期的に解決策を検討する、という時間を取ることにしてみました。


実は、自分はこの時間を最初はやや懐疑的に捉えていました。課題があったらmtgを都度開く、の方が効率的ではないか、と当初は考えていたからです。しかし、この時間を取り入れたことで目に見えてプロジェクトの速度が上がっていったのです。


まず、すぐに現れた効果として、要件漏れや、デザインの考慮不足などの問題を、早いうちに潰せるようになったのです。発端は何気ないメンバーの疑問や、ちょっとした違和感でしかありませんでした。ただ、その解決策を皆で探るうちに、仕様の欠陥に気づけたり、より質の高い方向に修正されたりいったことが何度も発生したのです。また、違和感の発信がどんどん当たり前になっていき、より良くするための声も増えていくという好循環も巡るようになりました。


さらに、長期的な効果もありました。違和感の発信、もっと言えば要件や提供価値へのコミットが日課になったことで、自分が誰のどの価値のために作業をしているのかが明確になったのです。その結果、たとえ苦戦するような状況が訪れても、「ココを乗り越えられれば大きな価値を提供できる」というような、効力感を常に持てるようになったのです。


完璧ではなくても良いからとにかく、違和感があれば全て発信し、議論のテーブルに乗せることを最優先する。発信者のハードルをとにかく下げる。この土壌をチームで作り上げることが、アウトプットの価値に直線的につながるのだと、痛感しました。


なお、このプロジェクトは最終的に、保守性、操作性、どの側面でも質の高いアウトプットを出すことができました。リリース時期こそ当初の想定より遅くなってしまったものの、最終的な成果物からすれば非常に早いスピードでのリリースだったのではないかなと思っています。

念願のリリースを成し遂げ、オフィス中をスキップで駆け巡るメンバーも目撃されました

まとめ

再三になりますが、良いアウトプットをチームで出すには

■発信者のハードルをさげる
議論のテーブルに乗せることを最優先する、歓迎する
をチームで担保することが重要

だと思っています。長々と書いた割には、当たり前な結論かもしれません。でも当たり前だからこそ、忘れられがちだし、意識から抜けがちな部分でもあると思います。

そして上記の実践で成功体験を積めた自分だからこそできること、しなければならないことがあると思っています。次は、今自分が所属しているチームでこの土壌を作り、また良いアウトプットを出せればなと思います。

今の僕のチームです。僕は写っていません(写りそびれました)

おわりに


アトラエメンバーによる #アドカレ2023_アトラエ は以下よりご覧いただけます。

絶賛採用強化中ですので、少しでも興味を持ってくださった方は、アトラエバーでお待ちしております!お気軽にご連絡ください!

この記事が気に入ったらサポートをしてみませんか?