こんにちは、Insight Edge開発チームの綱島です。
今回の記事では、私がここ最近従事しているプロダクト開発についてお話ししたいと思います。
一般的なプロダクト開発に関する有用な知識・ノウハウは世の中にたくさんありますので、少しテーマを絞って、「少数精鋭(≒限られたリソース)」のチームでプロダクト開発を進めるにあたって、重要だなと思うポイントをお話ししていきます。
Insight Edgeにおけるプロダクト開発
本題に入る前に、Insight Edgeにおけるプロダクト開発について触れておきたいと思います。
Insight Edgeは、2019年に住友商事グループのDX内製化組織として設立された会社で、各ビジネス“現場”における課題指向なアプローチを重視しています。そのため、以下のDX推進プロセス図のように、顧客やユーザーと対話しながら現場の業務課題を分析し、各顧客に合わせたアプローチでDXプロジェクトを企画・推進するケースが多いです。
ただ、最近では、さまざまな現場のDX案件を通じて蓄積された経験やノウハウをもとに、汎用的な課題に対応するソリューション/プロダクトを企画・展開する取り組みも生まれています。 その一例として、「カスタマーセンター×AI」をテーマとしたプロダクト『Voiceek』があります。企業のカスタマーセンターやCX部署に寄せられるVoC(顧客の声や問い合わせ)を、生成AIを活用して分類・分析・レポーティングするツールであり、BtoCの事業会社を中心にニーズがあるソリューションです。
本プロダクトに関する詳しい情報はこちらを参照ください。
上記ようなプロダクトの開発・展開においては、まず少人数のチームを組成して取り組みを開始し、徐々にスケールさせることを目指しています。立ち上げ期の小規模チームの活動において重要だと感じるポイントについて、次章からお話ししたいと思います。
「少数精鋭」チームでプロダクト開発を進める際のポイント
ここから本題ですが、少人数でプロダクト開発を進める場合、リソースが限られる分、チームの強みを最大限に活かし、効率的に動くことが求められます。そこで、実際の取り組みを通じて感じた重要ポイントを3つ紹介します。
チーム全体で顧客理解を深める体制
プロダクト開発には、カスタマーサクセス(CS)*1、エンジニア、PM、デザイナーなど、さまざまなロールのメンバーが関わります。少人数チームでは、職種を超えてコミュニケーションを密にし、全員が顧客理解を深める体制を意識することが重要です。
- 実践のポイント
- エンジニアが顧客の声を直接聞く場を作る
通常、エンジニアはPMやCSを介して顧客要望を受け取ることが多いですが、それでは伝言ゲームのようになり、細かいニュアンスが失われる可能性があります。エンジニアが直接、顧客との打合せやイベント(展示会など)に参加することで、ユーザーの実際の課題や使い方を肌で感じることができ、プロダクトに反映しやすくなると思います。
上段でご紹介したVoC分析ツール『Voiceek』においても、当該ポイントを実践することで、エンジニアの顧客理解度が高まり、CSやPM等のフロントメンバーとのコミュニケーションがスムーズになっていると感じています。 - PMとCSを一体化させて顧客課題の共有を円滑化
これは立ち上げ時期ならではの取り組みかもしれませんが、PMロールと、CSロールを一体化することで、迅速な意思決定やフィードバック対応が可能になると思います。
一般的にPMはプロダクト導入におけるプロジェクト推進を担当し、CSは顧客の利活用支援や問い合わせ対応を行いますが、立ち上げ期においては、これらの役割を統合することで、顧客からの問い合わせやフィードバックをリアルタイムで共有し、プロダクトの改善スピードを加速させることができ、メリットがあると感じています。
- エンジニアが顧客の声を直接聞く場を作る
「やらないこと」を明確にする優先順位付け
少人数チームでは、すべての要望に応えることは現実的ではないため、リソースを最適化するために、「やること」だけでなく「やらないこと」を明確にすることが不可欠です。
- 実践のポイント
- 「ないとどうなるか?」を整理し、必須要件を絞り込む
開発機能を選定するにあたっては、「この機能がないとどのような影響があるのか」を具体的に評価することが重要だと思います。「ユーザーが目的を達成するために必須の機能であるか」、「他の手段で代替できるか」といった視点で検討しながら、リソースの状況と機能の価値とのバランスを考慮することがポイントになります。 - ニーズを複数回深掘りして、本当に必要な機能をあぶり出す
ユーザーの要望をそのまま受け入れるのではなく、「なぜその機能が必要なのか」を繰り返し問い直すことが大切です。表面的な要望の背後には、より根本的な課題が隠れていることが多いため、何度も掘り下げていくことで本質的なニーズを特定できます。この問い直しを通じて、実はA機能ではなくB機能のほうが適しているというように、本質的なニーズを基にした機能を開発することができます。そして、提供者とユーザー双方にとってWin-Winな結果につながると思います。
- 「ないとどうなるか?」を整理し、必須要件を絞り込む
「型化」の余地を探り続ける
プロダクト開発に限らず言えることですが、限られたリソースを有効活用するため、個別対応が必要な部分とテンプレート化できる部分を適切に切り分け、継続的に効率化を図る意識が重要です。
- 実践のポイント
- よくある問い合わせのFAQ化
まず、ユーザーからの頻出質問をFAQやガイドラインとして整理し、可能な限りサポートの負担軽減を図りたいところです。仮にユーザー向けに公開しない場合でも、チーム内のメンバーが「誰でも」「迅速に」「同一の品質」でユーザー対応できる仕組みを構築することで、サポート業務の効率化につながります。 - トライアルや事前検証フェーズのテンプレート化
プロダクトのトライアル期間は、顧客が導入を決定する重要なプロセスですが、個別対応が多くなりがちです。そのため、トライアルにおける顧客満足度とリソース配分のバランスを考慮しつつ、共通ステップを定め、ガイドラインなどを整備することが重要と感じます。
- よくある問い合わせのFAQ化
さいごに
少人数チームでのプロダクト開発を通して重要性を感じたポイントとして、3つ(「チーム全体で顧客理解を深める」「やらないことを明確にする」「型化の余地を探り続ける」)の視点を紹介してきました。
今後は、こうしたフェーズを経て、プロダクトをスケールさせていくための戦略についてもまとめていきたいと考えています。
なお、Insight Edgeでは本記事で言及しているようなプロダクト開発から、個別具体のビジネス現場におけるDX案件等、様々なプロジェクトを経験できます。興味がある方は、カジュアル面談から是非お気軽にお問い合わせいただければと思います。
最後までお読みいただきありがとうございました。
*1:カスタマーサクセス(CS):提供する製品やサービスを顧客が最大限に活用し、成功体験を得られるようにサポートする役割。