ニセモノ現場主義の横行
本日はこちら。
そもそも現場主義とは何か？
意外と定義が合わないかもしれません。というより、立場ごとで現場は変わり得ると思います。製造業で言うと職能ごとで変わり得ます。
生産管理の場合、「製造ライン」は、一つの現場でしょう。開発の場合は、研究所やラボの「実験室」が現場かもしれない。営業にとっては、担当する顧客との「商談打合せ」が、現場かもしれない。
人事だと？人事の現場はどこでしょうか？例えば「採用面接」が現場でしょうか。法務の現場は？契約書を起案している瞬間はまさに現場かもしれない。
しかし、例えば営業からすれば、正直に言って、人事の「採用面接」を現場とは呼ばないでしょう。現場を戦場に例えるなら、採用面接はまさに兵力・兵站を供給するためのものであり、つまりは後方支援に過ぎない、という感覚な訳です。
別に間接部門をバカにしたくて、このようなことを書いているわけではなく、「現場主義」とは全くもって曖昧なものであると言うことを示したくて書いています。同じ会社であっても相当な相互理解がないと、その仕事場は、周りから「現場」と呼んでもらえないのかもしれないのです。
いやいや、営業の打合せは誰がどう見ても100％現場でしょう、と営業経験者は言うかもしれない。しかし、そうとも言い切れないのです。
もうほとんど受注することがお互いに決まっている段階で、最後に営業が出てきて、フィニッシュするような商談打合せが「現場」か？と言えば、そのお膳立てをした私たちの部署の活動の方がよほど「現場」だゾ、と胸を張る部署があるかもしれない。
製造現場の現場主義は、いよいよ危険です。徹底的なコスト低減や部品在庫の削減、且つ柔軟な納期体制の確保。これも一つの現場主義の結果です。生産ライン上で物事を見つめれば、必然的に目の向くKPIであり、そこを徹底的に磨く、一見すれば素晴らしい現場主義です。しかし、この課題設定、KPI設定そのものが正しいかどうか、チェックが効かないと言う重大な欠陥もあります。
かつての大量生産、大量消費時代には、KPIは誰の目にも明らかでした。しかし、低成長時代の適者生存がより色濃い現代においては、KPI設定そのものに経営センスや試行錯誤が求められているように思います。
センスの良い課題設定ができる、これが現場主義
さて、以上を踏まえて私の経験のお話をしたいと思います。私の知っている現場主義は、100％顧客視点で現場を見つめると言う習慣が前提で、成立していました。つまりKPIなり、目標が、ちゃんと顧客に貢献する数値になっていると言うことです。
私が某社の営業だった頃、同僚の開発チームはどこにいたか？
自社の研究所でもなく、自社の生産ラインでもありませんでした。彼ら彼女らは、お客様の研究所、お客様の生産ラインに居ました。私もまた、お客様の研究所に出向き、お客様の生産ラインを訪問したのです。そこで、アイデアを顧客と議論し、何が必要なのかを理解し、それを具体的な数値や仕様に落とし込む、それに必要な製品構造、製品コンセプトを決める。
それで初めて、開発陣は自社のラボにアイデアを持ち帰って、製品を開発するのです。そのプロトタイプをもう一度、顧客のラボに持ち込んで評価してもらうことを繰り返して、製品を磨き上げていく。
今時の言葉で言えば、デザイン思考に近い仕事の仕方でした。
これは一見簡単そうですが、大変難しいことです。例えば、たくさんいる顧客の中から、開発チームを呼び込むには、その顧客が自社にとっても組むべき魅力ある会社であることを、営業は、正しく伝えないといけません。なぜその会社と組むべきなのか？説明が必要なわけです。
現場主義をやろうとすればするほど、経営的観点で人を動かす方法を考えたり、どうやって顧客とコネクトさせるのかも作戦をたて、プロジェクトが始まれば計画を管理して、皆が（顧客も自社も）、成功の果実を得られるようにコントロールしないとなりません。
現場主義ほど、しっかりとした論理説明や経営論がないと成り立たないのです。
ですので、当たり前ですが両輪なのです。現場と理論。現場と組織。こうした二項対立的なものを、清濁合わせ込んで同時に成立させる必要がある。
そこまで合わせ込んだものを「現場主義」と呼ぶべきであり、そういう現場主義は言わずもがな、どこでどんな仕事に就こうとも、かけがえのない自分の能力、と言うより仕事のポリシーとして、「現場主義」を掲げることができるのだと思います。これを「本質的現場主義」と呼びたいと思います。
DXと現場主義
では、昨今話題のDXの兼ね合いで言えば、どうでしょうか？やはり「本質的現場主義」に精通した人間がDXの全体図を設計できる権限にあるかは、非常に重要になります。理論だけ知ってる人でも、ただ現場に居たと言う人でも、DXの成功は極めて困難だと思います。
本質的現場主義は、言うなれば本当の経営課題、適切な経営課題を設定できることに他なりません。この課題設定をしたときに、その施策としてITツールはあり得るし、結果が出た時、それを人はDXと呼ぶ、と言うだけのことだと思います。
DXを顧客起点で取り入れようと息巻いて始めても、様々な問題にぶち当たります。
例えば、開発者が営業の情報をもとに物を開発する、これは是か？是ではありません、営業の欲しいものを作るのと、顧客が欲しいものを作るのが本当にぴったりと合う保証はありません。「やはり顧客が欲しいもの作りたい」と強く開発チームそのものが意思をもつ必要があります。
ここで初めて、「では顧客の生の情報を集められる情報基盤が欲しいよね」と言う議論に至るわけです。
あるいは営業の場合。営業の発言は、顧客視点だと盲目的に捉えがちですが、そうとも言えません。売りやすい製品、決めてきやすい製品について、より改善を進める開発の方が営業はより好むかもしれない、しかしそれが顧客の望むものかどうか、より市場を切り開くかどうかは保証がありません。
となれば、営業自身が、「より顧客が本質的に抱えている課題をヒアリングするにはどうすれば良いか？」と言う問題意識を持たないとなりません。
そう言う問題意識があれば、ようやく商談管理や顧客管理のシステムに血が通う訳であり、勝ち筋のシナリオが見えてくる。
簡単に言えば、「DXやってみよう」からでは成功しないわけです。適切な課題に対して、今時の最も優れた適切な解なり施策を愚直に実行したら、それを人が後からDXと名付けた・・・みたいな姿が良いのだと思います。
と言うことで、また。
現在サポートは受け付けておりません。