プロダクトにまつわる様々な要因について

せぇべぇ
せぇべぇ

こんにちは、せぇべぇでございます。

今回は過去に携わったプロダクトのことについて書いていこうと思います。
このプロダクトというのは単に作って終わりというものではなく、クラウドで動くパッケージシステムで、『完成』することはなく改修・改修を繰り返し、バージョンアップを続けてサービスを提供しているものとなります。BtoBです。
このプロダクトを担当している部門の中に複数チームがあるのですが、改修(標準機能として追加)にあたりチームごとにプロダクトに対する「思い」(内部要因)や、どのような外部要因があってどのようにこのプロダクトを作っていくのか、良くしていくのかということに迫っていきたいと思います。
※業界や製品名などは伏せております。パッケージを製品を扱う際に参考になればと思います。

マーケティングチーム

このプロダクトを広告やイベントなどで宣伝し、リードを獲得するチームです。
リードを集めるためにこのプロダクトを検討をし始めたり、検討している企業にどのようにみせていこうかということを考えています。当然ながら新しい機能があればそれを目玉としてイベント時に大きく宣伝したいと思っているけど、なければ無いなりにやりますよというスタンスです。

インサイドセールスチーム

マーケティングチームからのリードに対してホットな見込み客を探し出すチームです。
このチームでは基本的な機能を説明し、簡単な質疑などについては現状ベースで回答をしながらより具体的にプロダクトを見たい・聞きたいという要望があればフィールドセールスにパスするという流れになります。
お客様との会話からどのような機能を求めているのか、今のトレンドを感じとりフィードバックすることが多いため、新機能や現機能の改善についてはあまり興味がなかったりします。

フィールドセールスチーム

見込み客に対して客先に出向いて受注を獲得するチームです。
デモを行ったり、金額交渉をしています。
検討・選定している企業から提案依頼書(RFP)が出た場合は、提案書を作らなければならないのでこのチームで対応します。また別製品を使っていたり、独特な運用している場合はFit&Gapを行い、このプロダクトで間に合っているのかという分析もこのチームで対応します。
RFPやFit&Gapにて、今プロダクトに存在しない機能があった場合、基本的にはカスタマイズはしないため受注チャンスを逃すことになってしまいます。ただし顧客からその機能があれば(作ってくれれば)発注する、もしくは開発費を出すから作ってくれと言われると営業マンとしては稼ぐチャンスとなります。リプレースの場合、このケースが多くなります。
営業活動の上では”売るために”新しい機能が欲しいと思っています。

インプリチーム

受注した顧客に対して稼働するまでシステムの導入を支援をするチームです。
顧客と一緒に導入プロジェクトが始まり、利用開始までにプロダクトの詳細な説明などを行うため数多くの打ち合わせをしていきます。このフェーズで詳細な運用などをヒアリングすると、できないことが判明したり思ってた使い方と違うということがあります。その場合、別の方法にて検討したり運用にてカバーする形でまずは提案していきます。また他社でも同じようなケースでこういった機能があったらいいなと思われるものについてはバックログに追加され、以降のバージョンアップで反映される形となります。
このチームでは、新機能より現機能の強化・改修を望んでいます。

ヘルプデスクチーム

利用している企業からの問い合わせの受け答えをするチームです。
問い合わせのほとんどが現状機能や使い方に対する問い合わせです。例えばある項目の区分を増やせないのかなど。この現状の機能に関連する要望などはインプリチーム同様にバックログに追加されていきます。
また当然ながらひとつの問い合わせは別企業からもある可能性が高いため、こういった問い合わせを減らすために新機能より現機能の強化・改修を望んでいます。

という各チームそれぞれ思いがある中、どのように改修していくのか。受注を増やすために新機能か、顧客満足(CS)を上げるために現状機能の強化か。
他の要因からどのようにマネジメントしていくのか見ていきましょう。

その他の外部要因

・機能規模
 ちょっとした期間でできる機能なのか、数か月かかる機能なのか。予定されている機能ごとに期間を見積り、後は予定しているバージョンアップの時期に合わせてパズルのように実施する機能を決めていく。これが一番ベーシックな方法です。大きい機能をドンとリリースするもしくは、細かい機能群をまとめてリリースするかのパターンが多いのですが。また中途半端な機能にならないように関連機能をよせてバージョンアップすることもあります。注)このプロダクト開発はアジャイルではありませんでした。

・顧客
 (注文前・稼働後ともに)大企業、中小企業それぞれで言ってくることが異なります。なかには温度感も高く、理不尽なことも。また役員クラスが出てくると、どうしても「やります」となってしまいます。利用中の企業の場合、要望を上げていてもなかなかその機能がリリースできていないと、他でいいシステム見つけたので解約します。ということになってしまいかねます。そうなると売上が減ってしまうのでこれも「やります」となってしまいます。システム障害の時と同じで解約も発生すると続いてしまう傾向があります。顧客の声というのもプロダクト開発に大いに影響はあります。

・競合他社
 同じことをしていては勝てません。「他社でこの機能が追加されたぞ、俺たちもやらなきゃ!」ではダメです。そんな機能はあって当然なのです。ここを突き詰めていくと似たような機能になっていくのですが・・・うまく差別化していくことが大事で、考えていかないと売れるものも売れません。

・世の中
 今の時代にあったプロダクト、また今後を予測してこの機能が必要だという知見というのか予見というのか、世の中の動向にもアンテナを張って情報収集していく必要もあります。実はここがまだ見ぬ未来の話しなので楽しかったりもします。ただ未来の話しに理解者は一部のメンバーであるということも悩ましいところ。

他にも要因はありますが、メインどころはこんな感じかと。

まとめ

この手のプロダクトは内部にも外部にも要因が多すぎるので、超端的に言うと調整しかないのです。この調整結果にどれだけの人が理解してくれるか。プロダクト(モノ)ありきだけれど、最後はヒトなんです。
また家電量販店で販売されているパッケージシステムとは違って、最初にも書きましたが『完成』しないプロダクトというところに難しさや面白さがありました。内部の関係者はみんな良くしたいという思いは同じです。ただどうやって良くしていきたいか、その『感性』を養っていくとさらに良くなっていくなぁと思っていました。

0
いいね!
この記事を書いたPM
せぇべぇ
せぇべぇ
@sebesa

都内在住システム会社所属。

もっとエンジニアとしてスキルアップをしたいと思い2015年に今の会社(3社目)に転職したものの、マネジメントする人材が少なかったこともあり、また周りからも進められ転職後すぐに方向転換。それからは開発することがなくなり上流工程業務に携わる。今はコンサルよりのPMといった感じ。

また社内では若手向けのPM勉強会を立ち上げ教育も行っているが、自分自身のPMとしてのスキルアップも忘れずに外部研修やイベントに参加している。
エンジニア時代は全くマネジメントに興味がなかったことをたまに思い出す。そのあたりうまく伝えていければなぁとも思っている。