コラム

　このような場合は、まずは60点レベルでよいので、他社事例などを参考にこれが正しいだろうという「できる営業」の仮説をつくる。そして、試行錯誤しながら、成功・失敗体験のフィードバックや共有を行い、仮説を継続的にカイゼンしていくというやり方をとります。

仮説検証～改善

　営業ではありませんが、ITの世界でもとりあえずたたき台をつくり、試行錯誤しながら改善する手法があります。ソフトウェア開発などにおいて使われる“アジャイル開発”と呼ばれるものです。

　その進め方は、最初から必要要件を仕様書にまとめてやるのではなく、とりあえずプロトタイプを作る。そして、顧客と協力しながら改善、修正を加えながらVer.1、Ver.2・・・とよりよいものに変えていく、というものです。

　以前はウォーターフォールという最初に要件をきちんと固めてから開発に入るというやり方が一般的だったのですが、実際には不確定要因が多く、最初に正確に要件定義を行うのが難しい。さらに、開発途中に制約要因や条件が変わることもしばしば発生する。その都度要件定義をやり直し追加費用がかかる。時間もかかり工期が遅れスピード化の時代に合わない。こういった非効率さが指摘され、ウォーターフォールに代わる方法として分析、設計、実装、テストを短期間で行うアジャイル開発が台頭してきたという背景があります。

知識創造プロセスの実践

 アジャイルという英語のIT開発手法ですが、もとは80年代の日本の製造業の新製品開発やイノベーション手法を応用したものであり、その本質は知識創造プロセスそのものといえるものです。

　できる営業の暗黙知(=ノウハウ、勝ちパターン)をとりあえずまとめて形にし、組織のメンバーで共有しながら、さらに高めていく。目指すべき営業のやり方がはっきり確立していない場合は、このような知識創造プロセスを経て、その組織固有の勝ちパターンを磨き上げていくというやり方が有効なのです。

(初稿2018年2月16日  →  リライト2022年1月6日)