たった一つ抜けただけで、プロジェクトを失敗させるコトを知っていますか?

タグ:


こんにちわ、ハマケンです。先月2回もCTの検査を受けましたが、あれって一ヶ月に2度も受けて大丈夫なのでしょうか?
部位が違うから良いのかな。ま、良いか。

皆さんは会社でのプロジェクトを牽引したことや、関係したことはありますか?
私は会社員ブロガーなので、よく関わることがあります。
そして何年もそういう事をしていると、上手く行くPJと失敗するPJが当然ありまして、何が違うんだろう?と思ったりします。

今日はその中でも、敢えて言うならこれなんじゃないかな?
と言うものを書かせていただきます。


Advertisement



そもそも失敗とはなんなのか?


プロジェクトの失敗とは何を意味するのでしょうか?
単純に考えれば、設定したKPIを達成することができなかった事を意味するのかも知れません。もしくは求められていたニーズの解決を目的にしたけど、上手く機能が伝わらず解決できなかったコトかもしれません。

でも僕はそこら辺も勿論、失敗だとは思いますが、根本的な失敗では無いと思っています。
プロジェクトの失敗とは「使われることも無く、知られることも無いモノになること」だと思っています。

KPIの数値を達成できなかったり、機能が伝わらなかったり、もしくはスケールしなかったり
と言うのは機能面が直接的な問題だと思えません。

よくよく使わないユーザーの声を聞いたら、「既に出来る機能を見落としていたり、理解していなかったり」と言うことが少なくありません。

なので、使われない機能やサービスを作ると言うのは、とてもじゃ無いけど開発コストを回収できるとも思えないので、そういうモノを作ってしまったら、やはりそれは失敗なんじゃないかなと思う訳です。

当然ジャッジメントミスやニーズ分析を間違って、全然ユーザーが望むモノと違うものがあがってくるコトもありますが、そうであったとしても戦う手段は残されている筈で、戦う前から「失敗」とはならないはずです。

失敗しないためにやる事とは?


これはたった一つだと思っています。

「どうやって機能やサービスを知ってもらって、使わせていくのか?を考え抜く」

だけです。

プロジェクトの発生は主に2つのパターンです。
能動と受動ですね。
受動はどちらかと言うと、「手間、クレーム」と言ったユーザーからの改善要望。
能動は「KPI改善」と言った攻めの施策プロジェクト。

どちらの方でもこの「どうやって機能やサービスを知ってもらって、使わせていくのか?」は重要です。例えば、ユーザーからの改善要望を解決した場合は、機能実装のお知らせをするだけでは不十分です。

  1. こう言ったクレーム、要望がありました。
  2. それをこう解決しました。

と見せていくだけでも、潜在的にその問題に気づいてなかったユーザーも機能を認識しやすくなるし、クレームを挙げたユーザーも満足が行く傾向にあると思います。

攻めの施策プロジェクトも同じです。
「誰の、何を、どうするのか?」をシンプルに表現し、ユーザーのニーズを上手く伝えつつ、解決策や便利さを理解させ、使ってもらわなくてはなりません。

プロジェクトを失敗する人にありがちなのは、この最後のプロモーション(どこに、どんな表現で、どのタイミングで伝えるのか)をかなり甘く見ていて、そこを全くやっていなくて、サービス・機能が使われないから「失敗だよね」とか言っちゃうのは、イケてないなと思う訳です。

ニーズを理解する。解決する手法の要件定義をする。開発する。リリースする。告知する。
これにプラスして「プロモーションをする」を足して欲しい所だし、最後それをやらない人(創造しない人)は、手段が目的となったりするケースが多いかも知れません。

なので、プロジェクトを本当の意味で失敗したくなければ、どうやって機能やサービスを知ってもらって、使わせていくのか?を是非考え抜いて、その部分に対してPDCAを回していってもらえれば、成功に近づくのではないのかな?と思います。

最後に

個人的に「売れないモノ、使われないモノ」はそう簡単に無いと思っています。
昔、家電量販で働いていた頃、機能面などで売るのが非常に難しい商品であったとしても、「伝え方、見せ方」で必ず売ることができました。(でもね、売る労力は倍以上かかりますよ?)

なので考えてビジネスモデルや要件を組んだモノであれば、プロモーション次第でもっと使われたり、売れたりする筈です。

決して要件追加や機能強化なんて言うのは、ある程度スケールした後から言えば良いんじゃないかな。スケールしていないって事は「使ってくれている人の方がマイノリティー」な訳でしょ。
その時点の人の声信じて開発しちゃったら「機能、サービス自体がマイノリティー」かもよ。

そもそもニーズが違う(今更言うんじゃねーよ、無いなら創れと言いたい)とか、ゲンナリすることもあるだろうけど、中身を変えずに伝え方次第で改善できることも非常に多いということを再度認識して欲しいし、ニーズ分析や要件定義のタイミングで、どうプロモーションしていくのかも絶対に考えるべきだと思う訳です。

という訳で、プロジェクトやサービスを創ろうとしている方への参考になればと思います。
それでは。




[ あわせて読みたい ]

この記事はいかがでしたか?

ハマケン Hamamoto Kensaku

会社員ブロガーです。スタートアップやマーケティング、個人的に面白いなと思った動画をアップしていきます。最近は薄毛をどうにかリポジショニングできないか考えています。お気軽にフォローをお待ちしておりますー。



Advertisement