仕組みの見直しに成功する組織1 プロジェクト管理の仕組み (その25)

更新日

投稿日

 この連載では、仕組みの見直しをテーマに様々な考え方や事例を紹介しているわけですが、実際にコンサルタントして仕組みの見直しに取り組んだ組織の中には成功して効果を上げているところもあれば、そうでないところもあります。今回は、仕組みの見直しに成功する組織はどういう特徴があるのかについて解説します。また、組織といっても、業種、業態、企業文化、専門知識・技術など様々ですから、どのような組織にも当てはまる特徴とは言えないと思いますが、図60にこれまでにコンサルティングで関わってきた業界を示していますが、少なくともこれらの業界では多くの組織に共通する特徴といって良いと思います。
 
R&D
図60. コンサルティングを実施した業界
 

1. 新しいものを受け入れる柔軟性

 
 新しいものを受け入れる柔軟性をもたらしているものは、技術者の素直さだったり、開発の中心人物のリーダーシップだったり、マネジャーの問題意識の高さだったりと、いくつかの要因がありますが、ここでいっている柔軟性は、新しい仕事のやり方に対して、組織の振る舞いとして、まずは受け入れることができるかどうかということです。
 
 仕組みを見直すというのは新しいことを受け入れることになるわけですから、本能的に今までと違うことに対する拒否反応は誰もが持っている感情です。この感情が大きくならないように、仕組み見直しの推進者は反対意見を持つ人を説得しなくてはいけないのですが、推進者の努力や工夫が足りないということもあります。
 
 いろいろな要因があるので単純な判断は難しい面はありますが、それでも、説得作業などにかなりがんばっても、どうしても「やってみよう」という空気にならない組織があります。問題なのは、このような組織の状態であるにもかかわらず、トップの指示などで仕組みの見直しや改革を行わざるを得ない場合です。反対者の説得のために多くの時間を使い、賛同者をひとりずつ増やしていくこと自体を独立したプロジェクトとして立ち上げるくらいの考えでないと、本来やりたい仕組み見直しを進めるのは難しいでしょう。
 
 つまり、組織としてこの柔軟性をすでに持っているかどうかは、時間軸で見たときに非常に大きな差になります。事業環境の変化などにより組織に求められるものはどんどん変わるのは避けることができないことであり、そのために見直すべき仕組みは次から次へと出てくるのです。新しいものを受け入れる柔軟性がなければ、次々と仕組みを見直して結果を出す組織との差は広がるばかりです。したがって、組織文化として新しいものを受け入れる柔軟性を持つことは大切です。
 

2. 柔軟性に欠ける組織が変わるためには

 
 柔軟性に欠ける組織が変わるためには何が必要なのでしょうか。柔軟性に欠ける組織もそれは結果であり、そうなってしまった原因があると思っています。最初は柔軟性を持っていたわけです。原因には、マネジャーと現場の意見や考えを無視し続けた、営業や企画の力が強く現場のキャパシティを無視した開発要求が続いた、トップ方針がころころ変わり現場は右往左往させられた、などの様々なことが考えられます。そして、新しいことを受け入れることが自分の損になるという経験を繰り返した結果、柔軟性を失った組織になってしまうのです。
 
 まずは、絡み合っていると思われるこれらの原因をひ...
 この連載では、仕組みの見直しをテーマに様々な考え方や事例を紹介しているわけですが、実際にコンサルタントして仕組みの見直しに取り組んだ組織の中には成功して効果を上げているところもあれば、そうでないところもあります。今回は、仕組みの見直しに成功する組織はどういう特徴があるのかについて解説します。また、組織といっても、業種、業態、企業文化、専門知識・技術など様々ですから、どのような組織にも当てはまる特徴とは言えないと思いますが、図60にこれまでにコンサルティングで関わってきた業界を示していますが、少なくともこれらの業界では多くの組織に共通する特徴といって良いと思います。
 
R&D
図60. コンサルティングを実施した業界
 

1. 新しいものを受け入れる柔軟性

 
 新しいものを受け入れる柔軟性をもたらしているものは、技術者の素直さだったり、開発の中心人物のリーダーシップだったり、マネジャーの問題意識の高さだったりと、いくつかの要因がありますが、ここでいっている柔軟性は、新しい仕事のやり方に対して、組織の振る舞いとして、まずは受け入れることができるかどうかということです。
 
 仕組みを見直すというのは新しいことを受け入れることになるわけですから、本能的に今までと違うことに対する拒否反応は誰もが持っている感情です。この感情が大きくならないように、仕組み見直しの推進者は反対意見を持つ人を説得しなくてはいけないのですが、推進者の努力や工夫が足りないということもあります。
 
 いろいろな要因があるので単純な判断は難しい面はありますが、それでも、説得作業などにかなりがんばっても、どうしても「やってみよう」という空気にならない組織があります。問題なのは、このような組織の状態であるにもかかわらず、トップの指示などで仕組みの見直しや改革を行わざるを得ない場合です。反対者の説得のために多くの時間を使い、賛同者をひとりずつ増やしていくこと自体を独立したプロジェクトとして立ち上げるくらいの考えでないと、本来やりたい仕組み見直しを進めるのは難しいでしょう。
 
 つまり、組織としてこの柔軟性をすでに持っているかどうかは、時間軸で見たときに非常に大きな差になります。事業環境の変化などにより組織に求められるものはどんどん変わるのは避けることができないことであり、そのために見直すべき仕組みは次から次へと出てくるのです。新しいものを受け入れる柔軟性がなければ、次々と仕組みを見直して結果を出す組織との差は広がるばかりです。したがって、組織文化として新しいものを受け入れる柔軟性を持つことは大切です。
 

2. 柔軟性に欠ける組織が変わるためには

 
 柔軟性に欠ける組織が変わるためには何が必要なのでしょうか。柔軟性に欠ける組織もそれは結果であり、そうなってしまった原因があると思っています。最初は柔軟性を持っていたわけです。原因には、マネジャーと現場の意見や考えを無視し続けた、営業や企画の力が強く現場のキャパシティを無視した開発要求が続いた、トップ方針がころころ変わり現場は右往左往させられた、などの様々なことが考えられます。そして、新しいことを受け入れることが自分の損になるという経験を繰り返した結果、柔軟性を失った組織になってしまうのです。
 
 まずは、絡み合っていると思われるこれらの原因をひもといて、関連部署、マネジャー、現場などの各々の立場でどういう思いをしてきたのか、何が悪かったのか、どうしたいのかなどを共有することが必要です。当事者である自分たちだけでは難しいことも多いので、外部の力を使うことも効果的だと思います。そして、まずは、ひとつで良いので仕組みを見直して良かったという成功体験を作ることが大切です。ひとつの成功体験が組織に柔軟性を取り戻すことになるはずです。これ以上差が開いてしまう前に、柔軟性を手に入れなくてはいけません。
 
 次回、仕組みの見直しに成功する組織2では、マネジメントのコミットメントを解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
自社の行く末を徹底して考えるとは 普通の組織をイノベーティブにする処方箋 (その27)

 KETICモデルの中の知識(Knowledge)の内、ここまで3回にわたりコア技術について解説していましたが、肝心のコア技術とは何か?それをどう設定する...

 KETICモデルの中の知識(Knowledge)の内、ここまで3回にわたりコア技術について解説していましたが、肝心のコア技術とは何か?それをどう設定する...


思考の頻度 普通の組織をイノベーティブにする処方箋 (その150)

  現在、イノベーション実現に向けての「思考の頻度を高める方法」を解説していますが、そのための1つ目の要素「行動を増やすことで思考を促進す...

  現在、イノベーション実現に向けての「思考の頻度を高める方法」を解説していますが、そのための1つ目の要素「行動を増やすことで思考を促進す...


どんな時もすぐ動く 新規事業・新商品を生み出す技術戦略(その52)

        新規事業・新商品を開発するにあたって、その組織や個人には「すぐ動く」ことが求められます。 ...

        新規事業・新商品を開発するにあたって、その組織や個人には「すぐ動く」ことが求められます。 ...


「技術マネジメント総合」の活用事例

もっと見る
精密鍛造金型メーカーが自社技術を起点に新商品開発に取り組んだ事例

※イメージ画像 1. 自社技術起点に新商品開発  今回は、精密鍛造金型メーカーとして創業し、現在は研究開発から部品製造まで精密鍛造に関するトータル...

※イメージ画像 1. 自社技術起点に新商品開発  今回は、精密鍛造金型メーカーとして創業し、現在は研究開発から部品製造まで精密鍛造に関するトータル...


システム設計6 プロジェクト管理の仕組み (その38)

◆システム設計は仮説と検証の繰り返し     前回は、システム(ここでは製品も含めてシステムと呼ぶことにします)に必要とされる要件を漏れなく...

◆システム設計は仮説と検証の繰り返し     前回は、システム(ここでは製品も含めてシステムと呼ぶことにします)に必要とされる要件を漏れなく...


トレーサビリティの保証 プロジェクト管理の仕組み (その44)

 前回のその43に続いて解説します。    ハードウェア設計も、ソフトウェア設計ほど明確ではありませんが、同じように開発工程ごとに関連する設...

 前回のその43に続いて解説します。    ハードウェア設計も、ソフトウェア設計ほど明確ではありませんが、同じように開発工程ごとに関連する設...