製品開発組織で、問題を抱えていらっしゃる製造業の経営者、マネージャー、あるいはエンジニアの方々の悩みごとについて、何かヒントのようなものを提供できないかと考えて「製品開発組織の正しい組織改革の進め方」というテーマで、バーチャルな討論をしてみたいと思います。
第一回の今日は、問題に対する現状認識の実情についての議論、第二回は製品開発組織が目指すべき姿について、そして第三回の最終回では、組織改革の正しい実践方法についての議論という形で進めていきます。
製品開発組織の責任者として、そして製品開発コンサルタントという双方の経験をもとに、二人の登場人物の間で製品開発組織に関する討論をしてもらいます。
登場人物
- お名前： 鴨志田卓さん（仮名）
- 役職 ： 精密機器製造業の製品開発部長
- 年齢 ： 55才
- お名前： 芳賀康司さん（仮名）
- 役職 ： 製品開発コンサルタント
- 年齢 ： 62才
2人による様々な角度からの議論を通して、読者の皆様にも、どんな製品開発組織を目指すべきか、どのように組織改革を進めるかということを深く考える機会にしていただけたらと思います。
それではさっそく始めていきます。
オープニング －製品開発組織の問題とは？
鴨志田さん、今日はよろしくお願いします。
さっそくですが、御社の製品開発組織における問題点、課題って何でしょうか？
でも、まず挙げたいのは、品質問題にいつも追われていて、しかも日程が遅れて、とにかく追い立てられて忙しすぎるということでしょうか。
そして、そういう状況だからということもあるかもしれませんが職場に活気がなく、この環境で若いエンジニアが技術者として、あるいはビジネスマンとして伸びてくれるかが心配です。
今のお話しは御社だけでなく、多くの製造業で共通する悩みなのかもしれませんね。
他には何かありますか？
そうですね。部内で取り組むべき課題について議論することがあるのですが、色んなレベルで問題点が挙げられます。思いつく限りで挙げてみると、
- 仕様変更などによる手戻りが多い
- ベテランが辞めていくと、いつの間にか特定の技術を知っている人がいなくなる
- 技術開発の仕事よりも雑用に多くの時間が取られている
- 自分としても会社としても技術が伸びているように感じない
- 同じような失敗を何度も繰り返している
- 昔に比べて品質問題の解決に時間がかかっている
- 機能別組織構成が複雑で、誰が責任者なのかわかりにくいことがある
- 製品全体のことを深く理解している人が減っている
- 製品としての進歩があまりないように感じる
などでしょうか？
まだ、他にもあったかもしれませんが、すぐに思いつくのはこれくらいですね。
こうやって挙げていただくと、それなりに多くの課題を抱えていると言えそうですね。
ただお聞きしてると、私も開発現場にいたときのことを考えると、どの課題もすんなりと理解が出来ます。
挙げていただいた中で、例えば仕様変更による手戻りというのがありましたが、仕様変更はなぜ起こるのでしょうか？
理由は一つではありません。
競合製品の状況によって変わる場合もあるし、製品企画の誤りというようなこともあるし、企画要求に対して技術的に達成困難と判断して変わる場合もあります。
さらに言うと、決裁者が変わることで変更されることもありえることです。
製品企画の誤りとは具体的にどういうことですか？
顧客ニーズがしっかりと掴めていないということだと思います。
開発が進んである程度製品の全体像が見えてきたときに、営業から「この仕様では売れない」とか「もう少しスペックを上げてくれ」というような話が挙がってやり直しになることがあります。
スペックのやり取りも、そんなに大層な変更ではないのですが、本当に顧客が求めているというよりは、他社との比較、時代の変化などに対して営業がトークしやすいかどうかという話なのかもしれません。
製品としての進歩が感じられないという問題にも通じるのでしょうね。
コンサルとしての経験から言わせていただくと、既存事業を長く続けているといわゆる持続的イノベーションというか、既存顧客のダイレクトボイスに応えることが中心の製品企画になって、独創的な製品が生まれにくくなる傾向があります。
言い換えると、何か新しいコンセプト、顧客自身も気づいていない潜在ニーズを掘り起こすようなチャレンジが出来にくくなるということですね。
かといって、顧客の声に応えて少しずつ製品を進歩させることも止めるわけにはいかず、そんなやり方の中で新製品の構想段階での、顧客価値に関する考察、検証が疎かになって仕様が生煮えで走ってしまい、結果的に途中での変更を余儀なくされるというわけですね。
お話しを聞いていて思いついたのですが、そういう意味で開発行為そのものがこじんまりしてきているようにも思います。
つまり、手の届く範囲で開発をしている。もちろん企画から多少難しいスペック要求があることもありますが、スペックの根拠も曖昧なので、技術サイドで絶対に無理だと言えば、そのスペックが取り消される。
顧客が求めるものという信念が持てないから、チャレンジもしない、ということになっているのかもしれません。
そうすると、個人も組織も技術力も伸びないし、やっていて楽しくない。だから組織にも活気が出ないということが起きているのかもしれません。
製品開発にマーケティング思考をもっと取り入れるべきというのは私の持論でもあるのですが、そもそもなぜこういう状況になっているかということを考えましょう。
しかし、こうやって見ていくと、たくさん起きている問題も、お互いが因果関係のよう繋がっているようですね。
TOC（制約の理論）の世界では、組織問題はほとんどすべてが因果関係で繋がっていて、その元を辿っていくと根本問題、つまり組織活動におけるボトルネックが見つかると言われています。
興味深い話ですね。
組織問題が連鎖で繋がっているという発想はこれまであまりしてなかったように思います。
問題の一つ一つを考えて、その解決策を一つ一つ立てて、それを一歩ずつ解決していこうというのがこれまでのアプローチでした。
問題点についてもう一つ伺いたいのですが、製品全体を理解している人が減っているというのは何故だとお考えですか？
また、それはいつごろからそのような状況が始まったのでしょうか？
いわゆるアーキテクトと言えるエンジニアが減ってきているのはトップも理解しています。
専門分野を細かく分けて、機能組織化によって分業体制を強めたことが一つの原因であることは認識していますが、複数の製品群を効率的に開発していくためには、分業化はやむを得ないことでした。
おそらく機能組織化での分業化を進めてから、ジワジワと全体を理解できるエンジニアが減少していったのだと思います。
ただし、問題を認識してからは、専門領域に特化するエンジニアと全体を見渡せるエンジニアを育てようという試みがなかったわけではありません。
結果的にはうまく行ってないということかもしれません。
そうですね。この問題で悩んでいる企業も多数あると思います。
景気の上昇で製品の販売量が右肩上がりで伸び、それに合わせて採用も進め企業規模も大きくなるものの、それでも製品開発のサイクルを大幅に早める必要に迫られて、開発の効率化を優先的に進めてきた結果、分業化が進み過ぎたということなのでしょうか？
そういうことだと思います。
分業化によって開発効率が上がったことは間違いありません。
しかし、実は分業化による副作用は、アーキテクトの減少だけではなく、エンジニアの雑用を増やすことになったのかもしれません。
以前は、一つの機種開発に関連するエンジニア、スタッフが一堂に集まって開発をしていたので、機種開発におけるコミュニケーションは非常にスムーズだったのですが、機能組織に分かれることで、一つの機種開発内のコミュニケーションが悪化してしまったのだと思います。
分業化するということは、ユニット間の調整にインターフェイスが生じて、必要なコミュニケーションが増えます。
機種間の共通性を保つための機能組織内のコミュニケーションや調整と、一つの機種を仕上げるための機種プロジェクト内のコミュニケーションと調整という仕事が雑用を増やしています。
分業化の弊害は、カリスマリーダーの育成も阻むのではないかと私は思っています。
機能組織と機種開発プロジェクトが縦と横のような関係で開発を進める体制を取る企業が多いのですが、このときに機能組織のマネージャ―と機種プロジェクトリーダーとの間で力関係が発生します。
多くのエンジニアが自分のホームポジションとして考えるのが機能組織だとすると、機能組織のマネージャ―の方の力が勝ってしまい、そうするとエンジニアから見たときに、誰が機種開発の責任者なのかがわかりにくくなります。
機種プロジェクトリーダーの力が弱いということは、機種開発そのものが弱っていくことに繋がります。
アーキテクトが育たないこととプロジェクトリーダーが育たないことを明確に分けて考えたことがなかったですが、確かにどちらも重要だし、それぞれの役割や育成方法は微妙に違うかもしれません。
ただ、芳賀さんと話をしていると、どちらも分業化によって開発効率を追求した副作用のように思えてきます。
まさにTOC（制約の理論）の組織問題が因果関係で繋がっているということに帰結していきますね。
組織問題へのこれまでの取り組み
さて、ここで議論のポイントを変えて、このような問題があることを認識されたうえで、今までどのようなことを組織としてやってこられたのでしょうか？
そこが問題ですね。
先に挙げたような問題があることは、すでに何年も前から認識はしていましたし、年度初めには毎年問題を精査して優先順位をつけ、いくつかの問題を一つ一つ取り上げて対応策、施策を検討して、年度の活動計画を立てて実践しています。
施策計画の結果は毎年刈り取りをして、計画に対してはそれなりの成果を挙げたつもりになっていますが、こうやって改めて全体を見直してみると、あまり状況は変っていないということがわかりました。
一体、何が悪かったのでしょうか？芳賀さん、何かヒントをいただけないですか？
組織問題の解決がうまく行かない場合、多くのケースで対症療法になっていたのではないかと私は考えています。
症状、つまり状況だけに注目して、症状を抑えることを考えて、実は根本の課題にまで到達していないケースが多くあるのです。
鴨志田さんのご経験でやってきたことから、何かわかるかもしれませんよ。
そうですね。やってきたことは、例えば、品質問題の発生を抑えるという課題は、
- 設計レビューの質向上
- 過去の本質問題の再発防止のためのチェックリスト
- 部門ごとの品質トラブルに関する勉強会
- 品質問題抑制に関する部門ごとの取り組みの発表会
などが、これまでにやってきたことです。
それぞれ、やったことによって品質問題の抑制にある程度は役立っていると私も思っているし、現場も思っていると思います。
ただし、それでもまだ品質問題に追われている感はなくなってはいません。
ちなみに、品質問題の抑制というテーマに対して、その状況を数値で評価する方法は持っていますか？
そして、施策を打つときに、その結果、状況がどう変化すべきかを数値目標として掲げていましたか？
うっ。そう言われると面目ないですが、具体的な数値目標は曖昧だったように思います。
施策の結果を評価する目標は、例えば設計レビュー回数XX回以上とか、チェックリストが過去問題を80%以上網羅して、そのチェックリストがどのプロジェクトで実際に使われたかなどが、成果目標だったと記憶しています。
私の経験からも、とても重要な課題に立ち向かっているのに、肝心の課題解決の結果に目標を置かずに、施策の達成度を目標にして失敗するケースがあることがわかっています。
理由の一つは、課題解決に関する評価方法が難しい、などが挙げられるのですが、代理目標によって達成した気になってしまうという危険がありますね。
他にはどんな例がありますか？
施策を打ってうまく行った気になるという例ではなく、施策そのものが的外れになるケースなのですが、組織能力向上やエンジニアのスキルアップを行うための前段階として、各組織、各個人のスキルの棚卸しのようなことを経営企画室の指示でやらされることがあります。
何度も繰り返しやらされて、結構、労力もかかるのですが、結局やりっぱなしでそこから何も生まれない、というようなこともあります。
笑えない話ですが、これも良くあることですね。
スタッフ部門の悪口を言うつもりはないのですが、狙っていることはわからないこともないのですが、何かセンスが悪いですよね。
ロジックは成り立っているように思えますが、そもそも各個人のスキルをエクセルシートなどで表せるはずがないということに、誰も気づかないということかもしれません。やっては見たものの、データとしては集まったものの、そこから生み出せるものが空虚であることを後になってわかるということです。
何か仕事をやった感だけは残るので、また次の人が同じことをするということですね。
対症療法の悪さというより、対症療法のやり方そのものを間違ってしまっている例ですね。
日々の活動が、一旦立てた施策計画を中心に一喜一憂しているということかもしれません。
本来は、そもそも達成しなければならない大きな課題について見ていかなければならないのに、課題達成のための施策そのものを評価することで、大事なことを見失っている。
いつの間にか対症療法の計画に振り回されて、仕事をしている気になってしまうということなのですね。
大事なことは、組織内で起こっている症状を見ることではなくて、常に根本原因を見つけてそこに手を打つという考え方だと思うのです。
すでに議論したように、組織で起こっている諸問題は因果関係で繋がっています。
その繋がりの状況をロジカルに把握することで、根本の問題に到達できるということなのです。
多くの企業で、その活動が軽視されています。というか、対症療法を脱する考え方を知らないのだと思います。
私は、製品開発革新を専門にするコンサルですが、クライアントの状況分析にTOC（制約の理論）を活用することで、対症療法的な考え方を改めてもらうようにしています。
ぜひ我が社でもTOC（制約の理論）の考え方を学んでみたいと思います。
また、対症療法から脱するには、どうすべきか自分たちなりにも考えてみたいと思います。
ちなみにですが、製品開発組織の根本問題は実際にどんなものなのですか？
他社の事例でもいいので教えていただけないでしょうか？
私も20社くらいで組織改革のお手伝いをしてきたので、ある程度、多くの企業が陥りがちな根本問題は理解しているつもりです。
しかし、組織改革のアプローチは、自分たちで自分たちの本当の問題を把握するところから始めないと、本当の解決にはならないと思っています。
なので、ここで鴨志田さんの質問に答えることは控えますが、ヒントは今日の議論の中にもあると思いますよ。
何かを達成しようとしてやったことが、何かをダメにしてしまう。つまり二兎を追うことが出来ないこと、すなわち組織のジレンマが問題を引き起こしていると考えると答えが見つかるかもしれません。
犯人捜しの考え方でなく、因果関係を深めていくことが大切なんです。
さて、今日はまず、製品開発組織で起こりがちな組織問題や、問題に対する対応法の間違いなどについて討議してみました。
次回は、実際の組織問題を踏まえて、では本来目指すべき組織の姿はどんなものかについて議論してみたいと思います。
第一回バーチャル討論のまとめ
鴨志田さんと芳賀さんの第一回目の議論はいかがでしたか？
実は鴨志田さんと芳賀さんは、筆者の著書「製品開発組織の常識をぶち壊せ！」の登場人物でもあるのです。
著書の中でも二人は、組織改革の糸口を見つけるために議論を重ねています。
本の紹介記事もありますので、こちらからご覧ください。
さて今回は、製品開発組織で起きがちな問題例、そして、問題に取り組みながら長い間解決できずにいる背景などについて議論してみました。
何か皆様のヒントになっていればうれしいです。
何かご意見、ご質問、ご指摘などがあれば、遠慮なく下記のコメント欄、又は問い合わせフォームよりお知らせください。
＞＞製品開発組織の正しい組織改革の進め方をバーチャル討論（第二回：目指す姿）
＞＞製品開発組織の正しい組織改革の進め方をバーチャル討論（第三回：実践方法）
