この記事はモチベーションクラウドシリーズ Advent Calendar 2022 11日目の投稿です。

これは何？

SaaS Design Conference 2022の一般公募枠で登壇時使用したスライドと、話した内容の書き起こしです。

はじめに（前提情報）

組織のエンゲージメント診断・改善サービス「モチベーションクラウド」のプロダクトデザインをしています。
組織人事のコンサルタントからデザイナーに職種転換しました。
こうした経歴から、デザインの中でも 「組織の行動デザイン」や「ユーザーの課題解決」 に関心があります。

現在、開発やセールスなど合わせて、総勢155名でサービス運営しています。

リリースしたはずの機能が「使ってもらえない」問題

アメリカのSaaS企業が行った調査によると、システムのうち、使われない機能の割合は80%だそうです。悲しいことに、 ほとんどの機能はリリースされても使われない可能性が高いといえます。
使われない機能が増えると、様々なデメリットが生まれます。
開発コストが増えるにも関わらず、顧客価値が高まらない。
それだけでなく、ユーザーが使わない機能がシステムに増えることで、サービスがどんどん複雑化していきます。

どうすれば、この状態を防げるか？
使われるためには、何が必要か？を考えました。

当然のことではありますが、
つくったものが「使われる」ためには、正しいものを正しく「つくる」だけではなく、
つくったものを正しく 「届ける」 ことが必要です。

正しいものを正しく「つくる」
＝ユーザーの価値を捉えてプロダクトに落とし込むことについては、
書籍や記事など、知見がかなり溜まっていると思います。
そのため今回は、つくったものを正しく「届ける」ことにフォーカスしたいと思います。

では、「正しく届ける」とはどういうことか？
「届いていない」とは、どんな状態か？

届いていないときには、こんなやりとりがよくあります。
あるユーザーとカスタマーサポートの会話です。

ここで起きていることは、リリースした機能をユーザーが認識できていない。
つまり、ユーザーに価値が届いていないといえます。

ただし、価値が届いていない相手とは、ユーザーだけなのか？
実は、ユーザーに届く前に、つまづいてしまっている場合もあると思います。

それが、どういう場合かというと、カスタマーサポートやセールスをはじめとした、
ビジネス部門にも届いてない場合があります。

具体的には、こんなやりとりがありました。

私たちがやるべきことは、価値を「届けきる」こと。
そのためには、ユーザーにはもちろん、ビジネス部門にも価値をしっかり届けること が重要です。

「届けきる」開発組織までの3つのステップ

「届けきる」開発組織になるためには、3つのステップがありました。

そもそも 「つくる」 開発組織であることは大前提だと思います。

次のステップが 「伝える」 開発組織になること。
ビジネス部門に、どんな機能がリリースされたか伝えること。
ただし、これだけでは不十分だと思っています。

「伝える」組織であるあるなのは、リリースノート出す、
マニュアルを共有するなど、情報を一方的に「共有して」終わりになってしまうこと。
ただし、それだと理解が浅くなるし、ユーザーにも届いているかどうかはわからない。

本来あるべきは、「届けきる」 開発組織になることだと思います。

特に、BtoB SaaSでは、ユーザーの接地面を最前線で担ってくれているビジネス部門との連携が不可欠です。ビジネス部門と「協働して」、一緒に価値を作り、一緒にユーザーに届けていくことが大事だと思っています。

ユーザーに価値を届けきるために、開発のプロセスを通してビジネス部門との連携を強化すること。それを、「ゼロ距離開発」 と呼んでいます。

「ゼロ距離開発」の最初の落とし穴

ただ、「ゼロ距離開発」を実現する上で、やってしまいがちな落とし穴があります。
それは、全員をいきなり巻き込もうとすることです。

私自身も最初、やってしまって痛い目を見ました。
なぜ、うまくいかないかというと、
人それぞれ、プロダクトの理解度や関心度にばらつきがあるからです。
さらに、理解度や関心度は機能の内容によっても変わります。

では、どうやってそれを乗り越えるか？
「全員」ではなく、「変化しやすい人」に最初に働きかけることで、変化の「分岐点」を作ること が大切です。

では、「変化しやすい人」とは誰か？
前提、人によって物事への受け取り方や反応は違います。

同じ出来事に対する受け取り方は、ポジティブ、中立、ネガティブの3つに大体分かれます。
このポジティブ:中立:ネガティブの人の割合は、組織論で言うと大体2：6：2 と言われています。機能のリリースに対する受け取り方でも、同じことが言えます

ここで、抑えないといけないのは、中立の人が多数派である こと。
この人たちが動いてくれると、風向きが大きく変わります。

この、中立の6割を抑えるための最初のアクションとして、
ポジティブな「2割」を強く深く巻き込むこと で
一緒に過半数をとって、風向きを変えていくことが効果的です。

「ゼロ距離開発」実現のための3つのステップ

先程の前提を踏まえて、
「誰に/どの順番で働きかけるか」 をデザインすることが重要だと考えています。

大きく3つのステップがあります。
まずはポジティブ、次にネガティブ、最後に中立含めた全員という流れです。

ポジティブな層から「仲間をつくる」、その後、ネガティブな層の「不安をなくす」。
この2ステップで前提の流れを作った上で、「みんなで届ける」ことが大切です。

ここからは各ステップに砕いて、やるべきこと、やらない方が良いことについて、
大事なポイントにのみ絞ってお伝えします。

1つめのステップで大事なのは、どれだけ強力なサポーターを味方につけるか です。

対象を見極め、意義や価値を伝えて共感してもらうことで、
「受発注やタスクの受け渡し関係」 ではなく、「仲間・チーム」 になっていることが大切です。

2つめのステップで大事なのは、最もリスクに対する感度が高い人に安心してもらうこと です。

前提、ネガティブなリアクションを伝えてくれる人は、あらゆるケースを踏まえたリスクへの感度が高い人が多いです。リクエストを伝えること自体、本来ストレスがかかるもの。

自分たちでは気づけなかったところに気づいてくれる点に感謝を伝えつつ、
不安や懸念を先回りで聞きに行き、それに対してどう対応するか判断の背景まで伝えること。
それによって、「わかってくれないじゃん」「言っても無駄」 という状態を防ぎ、「早めにリスクに気づいて対処する」 ことができるようになります。

最後のステップ3では、ここまでの流れに乗って、
前提をすり合わせて具体的な行動を起こし、ユーザーに価値を届けていくこと が大事です。

「ムードだけは高まった」 という状態に陥らないように、「みんなで届けきるまでコミットする」 ための仕組みを作ることが大事です。

まとめると、ゼロ距離開発を実現する上では、こちらの3つのステップになります。
アプローチするべき対象と、やった方が良いポイントを抜粋しています。

事例

実際のプロジェクトでこのステップやポイントをどう活用したか、
活用してどんな結果につながったかも最後にお伝えします。

この「ゼロ距離開発の3ステップ」を、メイン画面のリニューアルプロジェクトで活用しました。
メインの導線全てに関わり、要件定義からリリースまで9ヶ月をかけた大規模なプロジェクトでしたが、
結果、ユーザーからのネガティブな声はゼロ。
ページの滞在時間の向上など定量成果、および「わかりやすくなったね！」というお声を多くのユーザーから頂戴するなど、定性成果にもつながりました。

プロダクトの発足からリリース直前まで、
それぞれのステップで実際に行ったアクションは以下の通りです。

「ステップ1. 仲間をつくる」では、巻き込むタイミングは大事。
「まとまってから」ではなく、できる限り最初から巻き込むこと。
また、意義や価値は一度握って終わりではない。
伝えて伝えすぎることはないので、毎回常に確認し続けることが効果的でした。

懸念を示してくれる人って本当にありがたい存在。
伝えてくれることに感謝を伝えるとともに、懸念の意図背景にヒントがあると思って汲み取ること。
その上で、全部一気に対応するのは流石に難しいので、
今回はどこまで対応するか、それはなぜか、背景をすり合わせることを意識しました。
それによって、お互いの大事にしたいことやコンテクストが伝わりやすくなりました。