自分の担当する開発案件を進めるために社内のリソースが必要なのだが、優先順位が低く困ることありますよね。
私は理化学機器を開発するメーカーでプロジェクトリーダーを務めてきました。その経験上、自分の案件の優先度を高めるためにはある条件をクリアする必要があると感じています。
その条件とは一つ。具体的なお客様を見つけて商談に乗せてしまうことです。
目次
お客様を見つければ必然的に最優先となる
会社にとって進めたいプロジェクトはたくさんありますが、社内の実働部隊のリソースは十分ではないどころか、ぜんぜん足りないのが現実ではないでしょうか。
これをどうしたら確保できるのか。また、激しい競争の中、すぐに具体的な成果が求められるのもつらいところです。
ここで有効なのは、具体的にお客様を見つけてきて、商談にしてしまうことです。お客様がついていれば、具体的にビジネスとなることがはっきりしているので、会社としても必然的に優先度が上げて対応することになります。
わたしの勤務する会社で言えば、こういうフレーズがあります。
「出荷優先」
お客さんがついていて出荷が見えているようなプロジェクトは何よりも優先されるのです。
どうやってお客様を見つけるか
ではどうやってお客様を見つけるかですが、ここは、むしろ開発テーマをどう見つけるか、というところで既に工夫が必要です。
お客様を見つけるには、お客様との接点が必要です。営業スタッフと仲良くして、営業に同行してお客様に会いに行きましょう。自分が動きづらければ営業マンが営業する際に必要な資料のネタを提供しましょう。
また、お客さんに会うためには口実が必要です。ただで時間を割いてもらうわけにはいきません。お客様に会ってもらうだけの「手土産」をもっていかなければなりません。
この、口実は既存の装置のちょっとしたバージョンアップとか改善、新機能追加などでよいです。あるいは社内でやってみた実験(もちろん話せる範囲の内容で)でもOKと思います。
だいそれた話題である必要はないですが、こちらから情報をギブしていく姿勢が重要です。それに対してのお客様のレスポンスに金言が含まれているのです。
「そういうことを考えているなら、こういう手法を試してみたら？」
「うちではあまり使わなそうな技術だけど、あの業界では需要があるんじゃあないの？」
など、社内で調査しているだけでは知りえない貴重な情報に触れることができます。
これは営業に聞いてきてもらうのではなく、自分自身が世の中を戦略偵察するために直接出向くことがベストです。自分自身で説明して自分自身で見て、聞いて、感じることが大事です。
これをやるには開発側として常に何か新しい話題を作っておく必要があります。そういう意識でやれば普段の業務でも常にお客様を意識して取り組むようになります。お客様にとってどういう価値を持つかを意識することでアウトプットの質も変わってくるでしょう。
本当に必要な製品は何かを技術者は考えなければならない
そうやって活動していると、5件に1件ぐらいは使えそうなアイデアが出てくると思います。ただし、そのときもお客様の言っていることをそのまま実現させようとするのではなく、お客様の要望の本質をよく考えるようにしましょう。
お客様が自分たちが必要なものを正確に理解しているとは限りません。お客様は自分たちの業務についてはもちろんプロフェッショナルでしょうが、自分たちの業務に必要な道具についてまで熟知していないからです。
たとえば、運送会社の人たちは、トラックを普段から使っており、改善点やアイデアを持っているかもしれません。しかし、そのようなトラックのユーザーは技術者ではありません。機械設計や内燃機関の技術、システム設計の技術などは無いわけで、ユーザーの意見が即採用できるとは限りません。
お客様の要望をそのまま実現するのではなく、ほかの製品との組み合わせで簡易に実現できないか、違う手法でも同じ成果が実現できないか、などの観点はサービスを提供するプロフェッショナルとして自分自身が良く吟味すべきです。
「顧客が本当に必要だったもの」という風刺画が典型的な例です。
これはITビジネスでのプロジェクト受注における例ですが、我々にも参考になります。下記のリンクに説明されていますので読んでみてください。
まだ未確定の部分に技術者はどう責任を取るか
こういったやり方をするとき、未確定の要素が大きい状態で技術者としてお客様に製品の説明をすることになります。技術者としての発言には専門家としての責任が伴うため重さがあります。
できないことをできると言うのは、当然NGです。また懸念点があるのならばお客様にもしっかり説明が必要です。
しかし何かしらチャレンジする場面で100％できることだけを約束しているわけにもいきません。
「やったことが無いのでわかりません。」を繰り返していては何も新しいことができません。やったことが無いなりに、予想される課題やリスクを考え、調査して実現の可能性をはじき出すのが技術者に求められる仕事です。
流れ製品でなく、特注仕様や開発要素が大きい案件では、未来を100%予見することはできないので、想定外のトラブルが避けられません。しかし、そこを恐れていては何も進められません。
現実は基本的にVUCAです。VUCAとは下記の単語の頭文字を取った軍事用語です。
- Volatility（変動性・不安定さ）
- Uncertainty（不確実性・不確定さ）
- Complexity（複雑性）
- Ambiguity（曖昧性・不明確さ）
ここは未来を完全に予測しようと思わず、逐一ベストを尽くして対応するしかないです。現時点で考えうる限りの手をうち、何か事がおきたら逃げずに最後まで誠心誠意対応する覚悟を決めるしかありません。それが技術者として最終的にできうる責任の取り方だと考えます。
そこをチャレンジして、リソースをかき集めプロジェクトを成功させることで次の仕事をおこなうために必要なリソースを集めるための信頼を得ることができます。そしてあなたの仕事はいつも社内での優先度を高く保って進めることができるでしょう。
併せて読みたい：「無知の技法 Not Knowing」
これは別にプロジェクトマネージメントの本ではありません。
誰も正解を持っていないVUCAな現代を生きるとき、自分は無知だと思い知らされますが、それを受け入れ肯定して生きるための技法が書かれています。人生を生きる上での勇気をもらえる一冊です。
技術者としてどういった姿勢で仕事に臨むか、職業倫理あるいは責任について考えさせるところは、プロジェクトマネージャーとしても是非読んでおきたい本です。