「（彼らは）職人なので人と話したり、人に教えたりするのが苦手なんですよ！」は無知ゆえの間違った常識だった！？

関西地方のＩＴベンチャーＭ社のＴ社長。ご自身は、システム会社の営業経験を経て独立。システム会社の社長にして「システムの専門知識なんかわかりません」と笑顔でおっしゃいます。ご謙遜に過ぎませんが、Ｔ社長は持ち前の営業力で、創業10年立たずに、会社を30億規模にまで成長させてきました。

Ｔ社長の理念に共鳴して、優秀な技術者が集まり、いまでは幅広い領域のシステム開発を扱うようになっています。

会社の規模が大きくなるにつれ、受注金額が大きくなってきました。嬉しいことでしたが、負の側面もありました。リスクの増大です。一件当たりのプロジェクトの成否が、会社の経営を揺るがすようなことも時折起こるのだと言うのです。

その理由をどのように考えているかを聞いたところ、Ｔ社長から、「システムの技術者ってのは、職人なんですよね。（彼らは）職人なので人と話したり、人にに教え足りするのが苦手なんですよ」とおっしゃいました。

私はすかさず、「Ｔ社長、ちょっとまってください。技術職だらけの会社で他では全く別のケースもありましたよ」と口を挟むと。

Ｔ社長は、一瞬「は？」という顔をされましたが、「いやいや、それはうちの場合は当てはまりませんよ。」となぜかしたり顔。

---

ならばと、Ｔ社長に詳しく話を聞くと、「プロジェクトの成功には3つの関門がある」と言います。多くのプロジェクトは、第一の関門で躓くというのです。

第1の関門は、迅速な情報共有。職人気質な人が多いＩＴ企業では、人と話したりするのが苦手。ＩＴ企業ならではの、チャット式の情報共有はあるものの、結果的にそれだけでは不十分とのこと。5割方がこの問題。

残る2－3割が、第2の関門。それは、職人気質なので、自分の知識は自分のものとしてため込む傾向があるというもの。最後の関門が、また2－3割で、当事者意識の欠落。ということでした。

そして、Ｔ社長が言ったのは、第3の関門以外は、職人気質の技術者特有のもので、なかなかこれが変わらない、と。

---

Ｍ社だけではなくＩＴ企業の場合は、「職人気質」「職人」という言葉が使われて、マネジメントが機能不全に陥ることの理由として挙げられることが多いです。

一方、営業会社でも、営業だけはできる「職人」と呼ばれる人達がマネジメントに向かない人として形容されます。

これまで支援してきた会社の事例を振り返ると、「職人なのでマネジメントができない」というのが如何に間違った常識であるのかがよく分かります。

同時に、Ｔ社長のように「職人なのでマネジメントはできない」という方々の気持ちもよく分かります。「実際にありえないでしょ、それ」という事例に何度も遭遇すると、「やはり、職人だからなぁ、彼らは、、」と考えてしまうのもうなずけます。

私自身も、かつて技術職の人達と一緒に仕事をした折「職人はマネジメントには向かない」と
標榜していた口です。「職人」社員、職人リーダーにはとても手こずった経験もありました。

しかし、それは、一般的に言われている常識が、うまくいかない理由にもってこいだっただけのこと。自分の失敗原因を、なすりつけていただけなんです。

---

今は違います。断言できます。
「職人気質」「職人」と「マネジメントが不得手」には相関関係はないです。他の人達同様、マネジメントの仕方を知らないだけ、でした。

でも、どうして、多くの「職人気質」「職人」の人が「マネジメントが不得手」言われ続けて、その変な常識が今も改善することなく続いているのか？

これは私の勝手な解釈ですが、固定概念が邪魔しているのです。まことしやかに言われた、世間の常識が、現状の問題を長引かせています。

しなやかな組織を作るためには、常識にとらわれないしなやかな思考から始めるべきなのです。

---

Ｍ社を支援した折、支援するメンバーは、Ｔ社長の他に3人いました。

1人目は、社長の右腕のＣＴＯのＫさん。まさに、Ｔ社長がいう、「職人」そのもので、直下の2名の部長が疲弊してしまっていました。

ＣＴＯのＫさんは、非常に向上心が高い方でしたが、マネジメントには興味が向かなかったのです。必要だという認識はあっても、システムや、新規技術の動向や、自らの技術力アップへの意欲に比べるとマネジメントに関する興味は低かった。

なので、常に他の事にくらべて、マネジメントの優先順位が低くなっていました。

もう一人の新規事業の開発部門の責任者、本部長のＨさん。業界でも知る人ぞ知るなの知れた技術者。この方を招聘し、新規事業を立ち上げたものの、Ｔ社長からすれば、やはり「職人」故のマネジメント音痴に見えました。

Ｈさんの部門では、要求の厳しいＨさんのやり方の結果なのか、離職率が高止まりしているとのことでした。

最後の1人は開発の最前線で若い開発リーダーＦさん。こちらも、向上心も高く、学習能力も高く、成長著しい方。Ｔ社長は、このＦさんのような人を更に増やしていきたいのだけど、チームを率いて、チームを動かせるか否かが課題とのことでした。こちらも、Ｔ社長曰く、職人気質がネックになっているとのことでした。

「この方々に組織運営の力がつかなければ、今後の組織拡大は心許ない」ということで、半年間の支援プログラムが始まりました。

---

結果からいうと、大成功でした。その後、メンバーを入れ替えて、2期目を開始。現在その中盤にさしかかったところです。

Ｆさんは、30代後半でしたので、3ヶ月目にして、効果を実感していました。部下からＦさんへの報告連絡相談が増え、プロジェクトの改善提案も、週に1度の会議の際に、必ず出てくるようになりました。

通常の開発プロジェクトでは、知識不足の1年目は、「使えない」ということで、雑用係がおきまりのパターンでした。ところが、今回は計画通りに、知識の伝播が進み、新人も稼働したのです。テスト係だけではなく、一部は戦力として活躍するまでになりました。

ＣＴＯのＫさんは、ご自身が考える自分の役割と、Ｍ社長が期待する役割の違いにショックを受けたところから始まりました。

6ヶ月目には、計画通り、Ｋさん自身が完全に現場から手を引くところまであと一歩のところまで進みました。

Ｍ社長が驚いていたのは、2名の部下から、Ｋさんに関する不平不満がピタリととまったこと。そして、月初と中旬にある戦略進捗会議での2名の部長の発言内容の違いに驚いていました。

そして、Ｈさん。ＨさんもＫさん同様。自分が考える会社における役割とＭ社長がＨさんに期待していた役割の違いを認識するところから始まりました。

Ｈさんの提案で始まったのは、自分の部門以外だけではなく、全社員と対象とした、技術研修でした。Ｈさんの本を読んで入社してきた若手の社員を中心に大盛況。

テスト的に始めた研修が好評だったため、初級、中級、上級とコースも分けて展開する計画が作られました。

これ自体が新規事業として、外販される予定にまでなっていったのです。

Ｈさんが自らの役割を確認して、整理したことで、直属の2部長、3課長の役割が明確になりました。部門利益も過去最高を記録したのでした

---

なぜこのようにうまくいったのか？

理由は簡単です。
マネジメント知識と技術が無かった人にそれを伝え、技術を体得してもらったからです。

この話を経営者の方にお伝えしても、「いやいや、うちの場合はちがいますよ。」とＴ社長のように皆さんお答えになります。

しかし、技術は、やはり技術なのです。誰がやっても同じ結果になります。

結果の違いはもちろんあります。それは、どこの会社の営業技術、エンジニアリング部門の技術と同じです。結果の差は、反復の量の差で生まれます。

更に言うなら、正しく反復練習をすれば、技術は誰でも身につけることができます。

反復練習の量が足りずに、習得までの間延びしたり。反復しているつもり、間違ったやり方を繰り返して、成果の差が出るのです。

---

さて、あなたの会社の場合は如何でしょうか？

「（彼らは）職人だからダメ。職人だからリーダーには向いてない。」これは凝り固まった考え方です。しなやかな発想とは呼べません。

もし、それが事実だとしても、そのままあきらめて、良い将来はありますでしょうか？それとも、○○職人に、マネジメント技術を身につけてもらって、○○職人であると同時に、マネジメント職人になってまらうことを選択しませんか？

職人だらけの組織でうまくいっている組織と、うまくいかない組織の違いは、ただ、マネジメント技術を獲得したか否かだけです。

 

Warning: Undefined array key 0 in /home/xb528411/jcpo.jp/public_html/wp-content/themes/jcpo_theme2020/inc/inc-under-widg.php on line 4

Warning: Attempt to read property "term_id" on null in /home/xb528411/jcpo.jp/public_html/wp-content/themes/jcpo_theme2020/inc/inc-under-widg.php on line 4