開発組織のモチベーションを上げる３つの特効薬

製品開発組織の疲弊に手が打てない

日程遅れが常態化、仕事の80%が雑用、自分の技術が伸びている気がしない、など、多くの企業の製品開発組織のエンジニアは疲弊しています。問題が複雑化する中、せめて離職率だけは下げたいけど、具体的にどうやって手を打つべきかがわからない。

そんな疑問にお答えします。

開発組織のモチベーションを上げる３つの特効薬

かつて既存事業で右肩上がりの状況が続いていた会社にありがちなのですが、既存事業を効率化することに注力した結果、なかなか新規事業や新たなコンセプトのヒット商品が生まれにくくなった会社をたくさん知っています。

このような会社に共通しているのは、エンジニアたちのモチベーションが低下していることです。

それぞれの会社で事情も違うので、根本の問題には多少異なるところもある（共通の部分も多いとは思う）のでしょうが、多くのエンジニアたちが肉体的にも精神的にも疲れているように見えます。

これまで10社以上で、製品開発組織の改革をお手伝いしてきた経験から、エンジニアのモチベーション低下に注目して、その状態を食い止める３つの特効薬についてご説明させていただきます。

３つの特効薬は以下の通りです。

以下、一つずつ説明していきます。

多くのエンジニアが製品全体の原理を理解するための施策を打つ

技術者のモチベーションが下がる原因の一つは、自分の技術や地位が頑張っても上がらないことです。

日々の忙しさで、なかなか勉強する時間も取れないし、自分一人で好きなことをやる時間もありません。

開発行為の分業化も原因になります。

既存事業の開発効率を上げるために、専門分野ごとの機能組織を作り、一人の専門分野技術者が複数の機種の同じユニットや部品を設計することで、同じような機種のラインナップを並行して開発することができます。

会社全体としての開発のスループットは確かに上がるのですが、要するに工場のラインと同じで、一人の人間は同じ作業（開発）しかせずに、繰り返しのルーチンワークをすることになります。

工場のラインでの実習経験から言うと、自分のやっていることが全体のどの部分で、どんな貢献をしているかは当人にはわかりません。

開発で同じことをやれば、同じように、技術者は全体のどこをやっていて、それがどんな貢献になるかが次第にぼやけていきます。

製品の全体構造、ユニット間の連携による動作原理などが自分とは遠い世界のものになっていきます。

しかもそれを何年も続けると、自分の周りにいる人間は、同じように何かの専門家と言われ、全体を知っている人が見当たらなくなります。

この悪循環によって、品質問題の原因究明に時間がかかったり、隣のユニットとの連携で品質問題が多発したりします。

会社としても品質問題が増加し、一旦問題が起きたときの解決スピードが遅くなっていき、組織の中から全体を把握できるリーダーが育たなくなります。

個人はというと、井の中の蛙状態が長く続き、エンジニアの仕事ってこんなものかと諦め始めて、周りの中に埋もれていくことになります。

「全体を知る必要がないエンジニア」という状態が、モチベーション低下の問題において最大のボトルネックだと私は考えます。

ここに手を打つ基本方策は、以下のようだと考えます。

機能組織による効率化を脱して、少人数で一機種を立ち上げるプロジェクト制に移行する

機能組織が強すぎることが原因であれば、機能組織を止めて機種ごとに専任者を集めたプロジェクト制に移行すべきです。

マトリクス型の縦（機種ごと）と横（機能別）を交互に強弱をつけるなどをやっている企業もありますが、開発する機種数が増えていくと、一旦機能別の運用を強めてしまうと、元に戻すときに人数が足りなくなってしまうという事態に陥ることがあります。

そのような事情を考えると、一度に完全に戻すのは難しいことが予想され、段階的に時間をかけてシフトするということが有力です。

機能組織を維持する場合、機種プロジェクト実行中は機種メンバーが一か所に集合し、機種チームに全面的に帰属させる

どうしても機能組織を維持すると判断する場合には、エンジニア一人ひとりから見たときに、周りに同じ機能担当の人がいつもいる状態から、周りにいるのは別の機能や機種全体をやるメンバーを配置させるようにすることで、機種全体から見た自分の存在意義を自然に理解できるようにすることが挙げられます。

私の経験からは、これだけでも本人の意識はかなりいい方向に変わると思います。

全工数の20%程度を使って、全エンジニアに全体構成、全体の動作原理などを分析させ報告させる

組織体制をまったく変えないという判断をする場合、OJTとして全体を理解することは断念せざるを得ず、その代わりに、ある程度の工数を使って多くのエンジニアが全体を理解するための場と使命を与えます。

単に座学の勉強では効率も上がらないので、ミッションとして全体構造やユニット間の連携を含めた全体の動作原理を分析させます。

分析には、色々なツールを使うことをお勧めします。

弊社が推奨するリーン製品開発で使用しているツールとしては

• 機能構造展開図・・・機能とユニット構成を関連づける
• 動作原理図・・・部品間の関係、影響度、連携、副作用やその対策などを図示する
• 因果関係マップ・・・ユニットごとの顧客価値変数と設計変数の因果関係を図示する

特に、因果関係マップは、設計変数だけで問題解決するエンジニアの癖を修正することになったり、新たに技術課題を発見したり、組織としても知識がない状況を理解することが出来ます。

※因果関係マップについては、別記事「因果関係マップを活用して製品開発革新を加速させる」を参照ください。

基本施策のうち、現実的には組織構造やプロセスをすぐには変えられないことから、3番目のエンジニアに時間とミッションを与えて分析ツールを使って分析させ、それを見える形で残す（報告書等）施策が最も現実的かつ実用的かもしれません。

一人に一つ以上の自慢できるものを与える

エンジニアが、機能別組織に所属していたとしても、各人が本当に強いコア・コンピタンスを持っているとは限りません。

そもそもたまたま配属された部署の専門技術を今やっているだけで、本当に自分がやりたいことなのか、一番得意なことなのかが不明なケースが多々あります。

人材育成プラン、キャリアプランなどの人事制度がある場合もありますが、エンジニア自身がどうやって自分をキャリアアップすればいのかがわからずに、単に社外の教育をいついつに受けたいとか、という程度のキャリアプランが横行しています。

弊社では、他人よりも優れていて、それで将来の社会貢献にもつながり、会社の外へ出てからも通用するようなものを一人ひとりの「コンテンツ」として定義し、コンテンツを自分で見出す方法、コンテンツを育てるためのステップなどを定義して、クライアントの人事システムへの展開をお手伝いしています。

※詳しくは、「7ステップのキャリアアップ人事制度構築支援」を参照ください。

この「コンテンツ」は、簡単に言うと、他人に教えられるもの、教えることで相手に大きなメリットがあるものと言うことです。

会社への貢献と直結し、また本人の社内での認知度を上げることにもなるので、「コンテンツ」に向かって動き出した段階でモチベーションも格段に上がります。

質の高い情報発信に高いインセンティブを払う

多くの会社で開発組織の問題について議論しているときに、情報伝達が悪い、技術伝承が進まない、など、組織内での情報の流れが悪いことが指摘されることがしばしばあります。

日々の仕事が忙しくなると、報告書というのも、上司の指示に応えるための上司のみに宛てたものだけになっていることがあります。

技術の蓄積、技術伝承、知識を会社に残す、というような目的がなおざりにされているケースを時々目にします。

ベテランの暗黙知、つまりベテランにとっては当たり前のことで、でも一般の人には貴重な知識であるものが、一般の人に伝わらず、伝えないままベテランが定年で退職してしまうと、その知識は会社から失われます。

ベテランが技術蓄積や技術伝承のために報告書を残さないから、若い人たちが報告書を書かなくなる。

あるいは、書いたとしても他人に伝わらない質の低いものになってしまう。

報告書よりも、問題対策の方が断然優先度が高いので、報告書を書かなかったり、質が低いことを誰も咎めないようになると、それは負のスパイラルを生み出し、組織の中で流通する情報の質が低下することになります。

報告書を書く文化、報告書で技術伝承を進める文化、報告書で知識資産を会社で守る文化を作っていくことが重要です。

そのためには、良い報告書、あるいは情報伝達に対してインセンティブを払うことです。

義務にすると負担になります。

良いものを出したことにプラスの報酬を与えることが大事だと思います。

人事考課に含めるようなことをする場合もありますが、例えば報告書の件数をノルマにして、達成度を評価するようにすると、質の低い報告書が多数出回ることになります。

報告書を回覧、掲示などをして一般の人から良いものにプラスの点数をつける仕組みを作り、プラスの点数が多ければ、人事考課をプラス側に持っていくようにすると、一般の人も報告書に目を通す癖がつき、また読まれることを強く意識した報告書がたくさん生まれて、全体の質が向上するはずです。

トヨタは、A3用紙にすべてのことを書き切る形での報告書文化を持っていると、様々な書籍に紹介されています。

A3報告書を使った組織改革を進めている企業も多数あり、進めている経過が目で見えるので、成果も出やすい方法だと思います。

インセンティブの支払方法は工夫が必要かと思いますが、プラス思考でのインセンティブによって組織のモチベーションも向上すると思います。

組織改革の具体的な進め方

開発組織の問題を、エンジニアのモチベーション低下という観点を中心に見てきました。

組織のモチベーションを上げる３つの特効薬

• 多くのエンジニアが製品全体の原理を理解するための施策を打つ
• 一人に一つ以上の自慢できるものを与える
• 質の高い情報発信に高いインセンティブを払う

それぞれ、施策を打っていくこと自体はそんなに難しいことではありません。

しかし、目標通りの組織改革を進めるためには、エンジニア、社員の意識改革と組織の体制、プロセス、仕組み改革を同時にバランスよく進める必要があります。

特に意識改革は、しっかりした方針で進めないと時間がかかるだけでなく、途中で頓挫してしまうこともあり得ます。

一つの方法として、社員全員を一つの既知の手法とか考え方に傾倒していくことが有効であると言えます。

1970年、80年代に多くの日本企業がTQCという品質管理手法を宗教のように全社で扱ったことで、高品質の製品で日本が世界を席巻することになったことを思い出すべきだと思います。

手法そのものの良し悪しよりも、全社でトップダウンで、末端まで誰も疑いなく改革を進めたのがTQCです。

QCサークルのような末端から自発的に起こる改善活動は、それぞれの企業の飛躍に大きく貢献したはずです。

弊社としては、例えば

• トヨタ式リーン製品開発手法
• TOC（制約の理論）

の２つのうちどちらかを企業の組織改革の旗印にして、今回のテーマである開発組織のモチベーションを上げるということ、及びその他の組織課題を解決していくための具体的な進め方を熟知しています。

各企業の置かれた状況に応じて、適切な進め方を提案させていただきます。

下記フォームでご連絡いただれば、こちらからコンタクトさせていただきます。組織問題の状況をご相談ください。組織改革の具体的な進め方をご提案させていただきます。

この記事を気に入ってくれたら、下の”いいね”ボタンをお願いします！！