※このストーリーは、2024年3月13日に Assured note で公開した記事を転載したものです。

こんにちは、Assuredの大森です。当事業では創業以来、ビジネス⇔プロダクト組織二人三脚での事業づくりに取り組んでいますが、半年ほど前からは、更なる強化をすべく「プロジェクトチーム」を組成するなど試行錯誤を続けてきました。

少しずつ形になってきましたので、今回は本施策の全容を紹介すると共に、後半では実際に「プロジェクトチーム」として挑戦している仲間からの実際の声を紹介させてください。

前提：Assuredでは、製販一体の組織づくりを志向

Assuredでは、商品をつくるプロダクト組織と、作ったものをお客様・世の中へ届けるビジネス組織が非常に密接に連携しながら活動しています。

実際にビジネス組織においては、プロダクトと密に連携した事業づくりをしたいと参画してくれています。

齊藤(皓)：ビジネス側は、組織名が「事業開発グループ」となっている通り、事業開発をしている感覚が強いです。既にあるものを売るのではなくて、お客様の課題を拾い、プロダクトや各種チームと連携しソリューションに落とし込む一連のプロセスを、手触り感をもち行えているので、非常に充実感があります。
また、事業成長のために柔軟に役割を変えるスタンスの人が集まっているので、気持ちよく、みんなで事業づくりに向き合えている感覚があります。

一方のプロダクト組織も、ビジネス組織と共に課題を探し、一緒に解決手段を考えながらモノづくりしたいというスタンスの人が集まっており、ビジネスのメンバーと一緒にお客様のヒアリングなどにも参加しながら、日々プロダクトを改善しています。

プロダクトチームの日々の取り組みはぜひAssured Tech Blogを御覧ください

また、事業だけでなく、Visionalグループ全体のプロダクト文化づくりも推進してくれている、とても志高い仲間たちです。

そのため、創業初期（全体で数名〜10名未満の頃）は双方が流動的に交わりながら、阿吽の呼吸で連携してきました。ただ、それぞれの組織が少しずつ大きくなる過程で、課題の種が生まれ始めました。

「作り続ける」ことの弊害

スタートアップはスピードが重要です。そこで1日も早く事業を前に進めようと、お客様とお会いするほど様々なニーズがわかり、推進力の高いプロダクト組織であるほど、顧客課題を解決するための機能が次々に誕生します。

そのため、新しい機能が誕生してはチームが奮い立ち、また新しいニーズの課題解決に向け進めていく…。という循環が回り続けます。

顧客課題を解決する機能が次々生まれること自体は大変素晴らしいことです。

一方、そのサイクルが急速に回るなかでは、「リリース後の機能に対するマインドシェア（注目度）が落ちる」という問題が起こり始めていました。

お客様からの課題が湧き上がり続けるなかで、つい「次なる課題」に目が向いてしまい、また「次の機能を作らねば」という気持ちが働いてしまう。

本来、プロダクトアウト・探索的な要素が強く立ち上がった機能や、ビジネスサイクルのコアに関連するような機能については、「出してから」が本番であることや、リソースが限られるスタートアップにおいては「作るべきもの」を研ぎ澄ませていく必要があり、そのためにも「何を作ることが事業においての本質的な価値になるのか」を問い続け・PDCAを回していくことが求められます。

そこで、注力機能を対象に、「改善サイクルを回し続けるためのプロジェクトチーム」を立ち上げることにしました。

職種横断の改善チームを組成

対象とする機能は「Assuredが目指すプロダクト世界観に対し強く関連づく×プロダクトアウト要素が強いもの」とし、機能ごとにチームを組成しました。
チーム構成は、挙手によりビジネス（新規顧客担当/既顧客担当）・プロダクト（エンジニア/デザイナー）・セキュリティ組織から各1名、計5名を選出し、リーダーを立て進めて行きました。

プロジェクトゴールは、「機能開発前の仮説とのFit&Gapを出したうえで、最適な改善策を講じて市場（お客様）に届けていくこと」とし、大きく以下のような流れで取り組みました。

①当該機能が当初仮説通りのハマり方をしているか
・想定ターゲットに対して、想定した形で価値実感をいただけそうか
・この機能を深掘ることでの「伸びしろ」はどの程度ありそうか

②何があると更にご利用が加速しそうか
（手段はプロダクト開発に閉じない）
・とりうる手段のうち優先順位はどうなるか

③優先事項に取り組むにあたり、プロダクト開発は必要か
・必要である場合、どのタイミングでどのスコープの開発を行うか

④改善後、動き方をどう変化する（させる）か
・「伸びしろ」に近づけるためにどう動くか

詳細について、実際に「サービス検知機能」の改善プロジェクトに参画した方々に話を聞きましたので雰囲気を感じていただけたらと想います。

プロジェクトメンバーからの声

プロジェクトメンバーについて

左列奥から、戸谷さん（デザイナー）、小市さん（ビジネス）、早崎さん(セキュリティ※)。
右列奥から、齊藤さん（ビジネス）、内山さん（エンジニア）

※本プロジェクトはビジネス・プロダクト組織に加え、セキュリティ組織も「ドメインエキスパート」として深く関わっているのですが、本記事内では割愛いたします。興味のある方はぜひこちらの記事をご覧ください。

そもそも、サービス検知機能はどんな目的で作られたのですか？

齊藤：サービス検知機能は、世の中的に言えば「シャドーIT検出」という領域にあたり、従業員が会社の許可なく利用しているクラウドサービスを可視化する機能です。

一方で、シャドーITを可視化すると数百以上の未許可サービスが見つかることも多く、セキュリティ担当者からみれば「パンドラの箱」のようなもので、開いたは良いが、その後の対応がわからず持て余す（運用に繋がらない）という声を聞いていました。

そこで、Assuredの独自性・強みである、クラウドサービスのセキュリティ評価情報と組み合わせることで、滑らかな対策が可能になるのではと考え、2022年12月にリリースをしました。その後、半年ほど経過したタイミングで今回のプロジェクト発起に至っています。

具体的にどんなスケジュール感で動いていましたか？

斎藤：大きくは3ヶ月かけて取り組んでいました。
前述の通り、私達が提供したいUXは非常に独自性の強いものだったので、お客様にとっては初めての体験であり、それ故に、想像いただきにくい点や、コンセプトの異なる他社の機能と比較いただいた時に、見劣りすると感じられる部分がありました。

プロジェクト結成当時は機能リリースからちょうど半年が経っていたため、改めてリリース前の仮説と半年間の学びを照らし合わせ、提供したいUXに対するFit&Gapを可視化し、埋め方の方向性の仮説出しをしていきました。

それらと並行し、既存のお客様にもヒアリングを行うことで、仮説検証のサイクルを回していきました。

2ヶ月目に入ると、意思決定のための材料は揃い始めていたので、機能開発や打ち出し方の方針を決め、その上で自分たちが取り組むべきところ、捨てるべきところを明確にしていきました。今回の場合は有償機能でもあったため、打ち出し方と合わせて商品・価格設計も再検討し、3ヶ月目に大森さんらを交え議論した上で方針を合意しました。

3ヶ月目以降は、その合意した方針に基づき、ビジネス・プロダクト各チームの他メンバーと接続しながら、実際のサービス提供・改善に反映をしています。

プロジェクトのなかで、転換点はありましたか？

小市：実際にモノを作った上で行うお客様との会話を通じて様々な学びがありました。特定のセグメント・条件に該当する企業様とは相性が良い・悪いなど。

戸谷：通常のお客様からの声はもちろんのこと、Visionalグループでセキュリティ統括をしている若井さんと会話したことは大きな転換点でした。グループでもAssuredを利用しているため、一番近い距離で会話できるお客様の一人としてプロジェクトチームみんなで相談に行ったのですが、当時の方針を一蹴いただき（笑）。「Assuredにそれは求めてない、むしろ期待しているのはXXXだ」と。

プロダクトを作っていると、つい自分たちの製品に没頭してしまうのですが、悪い形で没頭し色々やろうとしてかえって、市場やお客様から見た時の価値を薄めてしまうのだと気付かされました。

また、当時はチーム全員静まり返るくらいストレートなフィードバックだったのですが（笑）、忖度や遠慮なくお客様として声をぶつけてもらえるのは、グループの良さだなとも想いました。

プロジェクトの前後で機能にどんな変化が生まれましたか？

内山：何がAssuredにとっての価値なのかが研ぎ澄まされました。「シャドーIT検出」という機能は様々な会社が提供しているなかで、なぜAssuredがやるのか、どんな価値を提供すべきなのかの解像度が組織として数段上がった感覚があります。

今回のプロジェクトを通じパッケージングや訴求などを整えたあとで最近お客様と改めて会話すると「なぜ以前、そういう形で案内してくれなかったんですか！（笑）」と有り難いフィードバックをいただく機会も増えてきました。

戸谷：プロダクトとして「地続きになった感覚・なめらかになった」になったように感じています。機能開発時から他機能との連携を意識していたものの、実際運用まで踏み込んで会話をしていくと、単体機能同士で独立していたなと。機能としてはこれまでも「やればできた」んだけどやろうとすると難しいとか。

小市：シンプルに「このプロダクトをもっとお客様に届けたい」という気持ちが強くなりました。沢山のお客様にお時間をいただいたこと、そしてチーム内であらゆる職能が知恵を絞り合い議論したことで、機能・提供価値に対する自信がより一層強くなりました。

齊藤：多職能でプロジェクトを推進したからこそ強く思った部分もあります。日頃からプロダクトは全力でお客様に提案しようと取り組んでいますが、今回のプロジェクトを通じ、改善のプロセスも含め一丸となり行ったことで、より気持ちが強くなりました。

やってみて個人としてどんな学びがありましたか？

小市：本質的にプロダクト投資すべきものはなにか？を考えるきっかけになりました。身近に頼もしいプロダクトチームがいると、つい相談をしてしまいがちなのですが、プロジェクトを通じて「やりたいこと・やるべきこと」を机の上に並べた時に様々な可能性があるなと。だからこそ、やるべきことを削ぎ落とした上で、人でできるものはまずやってみて、可能性があればプロダクト化していくことで、プロダクトチームの力を「ここ」という場面に投下できるんだなという気付きを得ました。

また、お客様の事実を観察することの重要性、可能性を感じました。特にお客様が体験したことのないUXを提供したいと考えたときには、「聞く」以上に、事実情報を観察した上で考え抜くことが大事であり、そこに仮説やあるべき姿を立てることの面白さを感じました。

内山：ビジネス観点でプロダクト開発を考える機会になりました。技術的に伸ばせるところは多々ありますが、リソースが限られるなかでどこに「張る」べきなのか。これを考える上では、お客様のニーズは勿論、自分たちの強み（ビジネスモデル・中長期戦略）や外部環境を知らずして描くことができず、そこまでを踏まえて思考する機会になりました。

齊藤：職能毎で気づく観点が違うことの面白さを感じました。例えばプロダクトは「機能の使われ方」など運用側面から質問をするし、ビジネスは「意思決定者からどう見えますか」など、ステークホルダーを意識した質問が出てくる。複数のバックボーンを持つチームで動いたからこそ、ものの見方などの多様性が広がったように思います。

小市：機能改善に本気で向き合うと何が起こるのか？を体感できたことは学びでした。
お客様に対する新規提案の側面においては、製販一体で探索する、フィードバックを得に行くことを通じて、プロダクトの伝え方等の深みが増しました。これまではそこまで描いて・考えて提案しきれていたかというとそうではなかったなと気付かされました。

戸谷：逆にプロダクトチームとしても、プロダクトマーケティング（プロダクトの思想や魅力を伝えていくこと）の重要性を実感しました。今まで出来ていなかった訳ではないですが、これだけ密度濃く話せると組織全体での解像度の高まりが全然違うんだなということを実感しました。

最後に

以上、今回はビジネス・プロダクトが二人三脚で取り組む機能改善についてご紹介しました。

別のnote記事にも書いておりますが、我々は創業事業としてセキュリティ製品「Assured」を立ち上げ・磨きつつ、その先に新しい価値を次々と生み出せるような組織づくりを目指しています。

そのためには個々人が高い事業開発志向と能力を持つことが必要不可欠と考えていて、こうした取り組みにどんどんチャレンジしていきますので、面白いなと思っていただけましたらぜひ、お話をさせてください！