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

更新日

投稿日

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

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

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

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

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

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

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

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

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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
自社の存在意義とは 普通の組織をイノベーティブにする処方箋 (その111)

   前回は企業でイノベーションを起こすには、「自社の存在意義」を徹底して問い直すこが重要であるという解説をしました。しかし、「自社の存在...

   前回は企業でイノベーションを起こすには、「自社の存在意義」を徹底して問い直すこが重要であるという解説をしました。しかし、「自社の存在...


リーン製品開発が開発チームの行動様式を変える

   今回は、リーン生産方式とリーン製品開発について解説します。リーンとは何でしょうか。リーンとは、英語のleanのことで「やせた」、「細...

   今回は、リーン生産方式とリーン製品開発について解説します。リーンとは何でしょうか。リーンとは、英語のleanのことで「やせた」、「細...


製品設計におけるトレードオフのコントロール(その2)

 製品設計におけるトレードオフのコントロールを、前回に続いて解説します。   1.トレードオフ対応フロー  図1はトレードオフへの対応フローの一...

 製品設計におけるトレードオフのコントロールを、前回に続いて解説します。   1.トレードオフ対応フロー  図1はトレードオフへの対応フローの一...


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

もっと見る
金型メーカー設計部門の業務診断事例

 今回は、金型メーカーの設計部門を業務診断した事例を箇条書きで紹介しますので、診断項目とそのポイントを参考にご覧下さい。 1. 複数設計者で強度や品...

 今回は、金型メーカーの設計部門を業務診断した事例を箇条書きで紹介しますので、診断項目とそのポイントを参考にご覧下さい。 1. 複数設計者で強度や品...


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

 前回はシステム設計を、開発工程上はシステムエンジニアリングと、ハードやソフトなどのサブシステムのエンジニアリングの両方と定義しました。ここで、システムエ...

 前回はシステム設計を、開発工程上はシステムエンジニアリングと、ハードやソフトなどのサブシステムのエンジニアリングの両方と定義しました。ここで、システムエ...


製品開発部へのカンバン導入記(その1)

        最近ビジネスの世界では、カンバンを使ってプロジェクトを管理しようとする動きがとても強いようで...

        最近ビジネスの世界では、カンバンを使ってプロジェクトを管理しようとする動きがとても強いようで...