開発しかできていないことに気づいていますか?

#1「したい仕事」と「言われた仕事」

「PM9時からが自分のしたい仕事が出来る時間だったよ」

もう10年以上前の話ですが、私の上司がこんなことを言っていたことを思い出しました。どういうことかと言えば、PM9時までは会社から言われた仕事をしなければならない時間であって、自分が本当にしたい仕事はPM9時を回らなければ出来ないという意味でその方は言っていました。

その当時の自分の状況はと言えば、ベンチャー企業を設立して以後しばらく「したい仕事」ばかりをしていました。「したい仕事」で結果が出るようになって顧客がつくと、今度は顧客から依頼が入ります。その仕事はかならずしも「したい仕事」ばかりとは限らず、顧客に「言われた仕事」の部分もありました。「言われた仕事」は「したい仕事」よりも楽しくないもの。そう感じていた時に上のようなことを言われて、「言われた仕事も大事だし、したい仕事も大事だよ」と励まされたような気分になったのを記憶しています。

件の上司はPM9時以降にしていた仕事が評価されたのか、企業派遣で海外留学を果たされたということも聞いていました。きっと、自分のしたい仕事でも成果を出されたんだろうと思います。「PM9時から」というのは、働き方改革真っ盛りの今からすると、隔世の感があります。現在、多くの会社ではPM8時以降に働くこと自体が否定されるようになっているからです。

しかし、働く時間が減っても「したい仕事」が減るわけではありませんし、時間が限られているからと「言われた仕事」だけしかしていなければ、生産性を上げることはできないことは言うまでもありません。そのため、会社には、「したい仕事」ができる仕組みが必要です。

#2 なぜしたい仕事ができないのか?

前々回のコラムで、「顧客要望対応で減益になる」という話を書いたのですが、顧客要望対応のような仕事は間違いなく「言われた仕事」です。

誰に言われるかと言えば、顧客や事業部でしょう。「期待通りの精度が出ていない」「ちょっと寸法が違う」「もっと安くしてほしい」などなど、顧客要望や事業部要望を挙げればきりはないでしょうが、多くの場合、このような「言われた仕事」というのは対応がしやすく、結果も出やすいのです。

一方で、顧客要望は誰でも気づいていることだけに、大して独自性の高いものではないし、ましてや知財が取れるわけではないことが多いのです。そのため、顧客要望対応では「増収」にはなっても「減益」になることを前々回のコラムでは指摘しました。

このように「言われた仕事」は売り上げにはなるものの利益にはなりませんので、あまり力を入れたくはないものです。分かってはいるのですが、「前年比○○%増」の目標を常に課される事業部や顧客要望がはそれを許してくれる訳ではありません。

仕事柄、多くの会社の研究開発部門(研究より)に関わることが多いのですが、多くの技術者が「顧客要望対応で減益になる」という基本的なことに気づいていません。「言われた仕事」をするのに慣れており、意図せずして「したい仕事」をしないようになっていることがよくあります(そういう研究所からの仕事の依頼が多いと言った方が正確かも知れません 笑)。

このことに気づいていただくために、私は言われた仕事には「D」、したい仕事には「R」というラベルを貼り、両者は明確に違うものであるということを説明しています。なお、DはDevelopment、つまり開発のDです。RはResearch、つまり研究のRを取って言っています。

D・・・顧客要望対応テーマ

R・・・価値の独自性・技術の独自性があるテーマ

すでに書いたとおり、どんな会社でもD(言われた仕事)はほどほどにしておき、R(したい仕事)に注力する必要がありますが、研究所と言われる組織でもDばかりやっているケース少なくないのです。

なぜDばかりになるのか?コンサルタントの経験から非常に端的にまとめれば、ふたつに集約されます。一つは「技術者がDしか評価されないと思っているから」です。もう一つは「技術者の能力を育成していないから」です。そして、これらの原因を引き起こすのは、仕組みの欠如です。

#3 仕組みとは?

しかし、Rはそもそも独自性が高いために難しいと思われ、多くの人にスルーされるようなテーマなのです。そのため技術者の視点では、「Rをやっても評価されるとは限らない、リスクが高い」と思っているわけです。そのため、Rが高く評価される仕組みが必要です。私は以下のような評価の仕組みを提案しています。

図に示すとおり、Rの評価軸は、技術の独自性(横軸)、価値提案の独自性(縦軸です)。これらの視点で評価の高いテーマ(テーマB)が高く評価される仕組みを持つべきです。

なお、図にはDの評価軸(横軸に技術的実現可能性をとり、縦軸に市場性)を示しています。Dの評価軸では高く評価されるテーマAと、この評価軸では低く評価されてしまうテーマBを比較のために示しています。Rの評価軸ではAとBの評価は逆転することを示しています。

このような評価の仕組みを持てば、テーマBを推進しようとする技術者も高く評価されることになるでしょう。結果が出ずに失敗することが許容される組織風土が合わせて必要なのも言うまでもありませんが、きちんと評価される仕組み(人事評価を含めて認められる制度)は重要です。

言うまでもないことですが、経営者は、このような仕組みを構築するだけでなく、技術者がこの仕組みをどのように認識するかに気を配らなければなりません。独自性が高く評価される仕組みを用意したと言っても、技術者の行動がRに向かないことは多々あります。

例えば、経営幹部が「Dが大事、Rは二の次」だと思っていれば、それは言動に出るのです。どんなに元気な技術者でも、上司の顔色は気になるもの。上司がDに向いていれば、部下の行動Rには向かないのです。

あなたの会社ではRの出来る仕組みが運用されているでしょうか?

なお、原因のもう一つであるRが推進できない理由である「技術者の能力形成をしていないから」については次回のコラムに譲りたいと思います。

この記事は日経テクノロジーで連載しているものです。