リエンジニアリング革命
著者： マイケル ハマー, ジェイムズ チャンピー, Michael Hammer, James Champy, 野中 郁次郎
タイトル： リエンジニアリング革命―企業を根本から変える業務革新
---
我々は、よく次のようなシナリオに直面する。シニア・マネジャーが、問題のあるプロセスを画期的に改善するためにリエンジニアリング・チームを任命する。しばらくしてそのチームは答えを出し、画期的なコンセプトについて説明し、どのようにしてサイクル・タイムの９０パーセント、コストの９５パーセント、欠陥品の９９パーセントを取り除くかを示す。それを聞きこのマネジャーは喜びながらも困惑する。チームは続けて、再設計されたプロセスがなぜ、新しい職務賃金システム、多数の部門の集合、マネジメントに関する権限の再定義、労働関係の新しいスタイルを必要とするのかを説明する。シニア・マネジャーは再び困惑する。しかし今度は喜んでいるのではなく、「君たちにコストと欠陥品の削減を頼んだだけで、会社のことについて意見を求めたのではない」と言う。このチームは通常、解散し、その画期的なコンセプトは二度と聞かれなくなる。しかし、会社について意見を述べることこそが、まさにリエンジニアリングなのである。
---
ソフトウェア開発において、部分的なプロセス改善によって、ソフトウェアの納期の短縮や、作業の省力化を図ろうとするが、ほとんどの場合上手くいかない。上手くいかない理由はいろいろあって、いろいろ改善した部分については少し効果が出るのだが、劇的な効果はないし、がんばらなくなるとすぐに元に戻ってしまう。
がんばっても給料増えないし、残業はするけど早く終わったからといって早く帰れるわけではないし、何時に帰っても朝は定時出社だし、スタッフ辞めても代わりの人材がなかなか入ってこないし、という組織に絡む話が、どうしてもソフトウェア開発とセットでついてくるからである。
本質的な問題として、まさに引用のように会社の雇用や賃金体系や就業規則や経営陣の考え方は、ボトムアップではなかなか変えづらいのである。これをどうやったら話を聞いてもらうようにするか、と組織の下部スタッフが云々唸っても変わるものでは無い。
なぜか、結局行き着くところは会社の売上と利益をどうするのかという、経営論になるからである。ただそのためには経営者を論破する必要がある。技術論だけでは、売上の担保にならない。
今会社が存続している時点で、なんらかの利益獲得ルールに則って会社は動いているのだ。あなたの意見がその利益獲得ルールを無視した理想論を述べても、会社にとっては動きのとりようがない。どうやって利益をあげているのか、自社の仕組みをよく観察してみたほうがよい。
自社の強みがソフトウェアの品質にあるのであれば、よりソフトウェアの品質を保つ方向で提案すればすぐに認められるだろう。逆に短納期を売りにしている会社で、「品質が1．5倍になるからペアプログラミングですよ！」と言っても、当然話を聞いてくれない。
もっとも、上記のようなわかりやすい例はほとんどない。顧客ありきの受託開発会社の場合は、顧客担当者によって優先順位がころころ変わることもよくある。この場合、顧客情報を持つ営業が偉いはずなので、営業の発言力が増す。
何が言いたかったかというと、自社のソフトウェア開発体制がまずいと思うのであれば、今自社はどうやって仕事を取ってきて、どうやって売上をあげているのか、ということを再確認して、それから提案内容を考えるのである。己を知り敵を知れば～、というのはいつの時代も当てはまる。
タイトル： リエンジニアリング革命―企業を根本から変える業務革新
---
我々は、よく次のようなシナリオに直面する。シニア・マネジャーが、問題のあるプロセスを画期的に改善するためにリエンジニアリング・チームを任命する。しばらくしてそのチームは答えを出し、画期的なコンセプトについて説明し、どのようにしてサイクル・タイムの９０パーセント、コストの９５パーセント、欠陥品の９９パーセントを取り除くかを示す。それを聞きこのマネジャーは喜びながらも困惑する。チームは続けて、再設計されたプロセスがなぜ、新しい職務賃金システム、多数の部門の集合、マネジメントに関する権限の再定義、労働関係の新しいスタイルを必要とするのかを説明する。シニア・マネジャーは再び困惑する。しかし今度は喜んでいるのではなく、「君たちにコストと欠陥品の削減を頼んだだけで、会社のことについて意見を求めたのではない」と言う。このチームは通常、解散し、その画期的なコンセプトは二度と聞かれなくなる。しかし、会社について意見を述べることこそが、まさにリエンジニアリングなのである。
---
ソフトウェア開発において、部分的なプロセス改善によって、ソフトウェアの納期の短縮や、作業の省力化を図ろうとするが、ほとんどの場合上手くいかない。上手くいかない理由はいろいろあって、いろいろ改善した部分については少し効果が出るのだが、劇的な効果はないし、がんばらなくなるとすぐに元に戻ってしまう。
がんばっても給料増えないし、残業はするけど早く終わったからといって早く帰れるわけではないし、何時に帰っても朝は定時出社だし、スタッフ辞めても代わりの人材がなかなか入ってこないし、という組織に絡む話が、どうしてもソフトウェア開発とセットでついてくるからである。
本質的な問題として、まさに引用のように会社の雇用や賃金体系や就業規則や経営陣の考え方は、ボトムアップではなかなか変えづらいのである。これをどうやったら話を聞いてもらうようにするか、と組織の下部スタッフが云々唸っても変わるものでは無い。
なぜか、結局行き着くところは会社の売上と利益をどうするのかという、経営論になるからである。ただそのためには経営者を論破する必要がある。技術論だけでは、売上の担保にならない。
今会社が存続している時点で、なんらかの利益獲得ルールに則って会社は動いているのだ。あなたの意見がその利益獲得ルールを無視した理想論を述べても、会社にとっては動きのとりようがない。どうやって利益をあげているのか、自社の仕組みをよく観察してみたほうがよい。
自社の強みがソフトウェアの品質にあるのであれば、よりソフトウェアの品質を保つ方向で提案すればすぐに認められるだろう。逆に短納期を売りにしている会社で、「品質が1．5倍になるからペアプログラミングですよ！」と言っても、当然話を聞いてくれない。
もっとも、上記のようなわかりやすい例はほとんどない。顧客ありきの受託開発会社の場合は、顧客担当者によって優先順位がころころ変わることもよくある。この場合、顧客情報を持つ営業が偉いはずなので、営業の発言力が増す。
何が言いたかったかというと、自社のソフトウェア開発体制がまずいと思うのであれば、今自社はどうやって仕事を取ってきて、どうやって売上をあげているのか、ということを再確認して、それから提案内容を考えるのである。己を知り敵を知れば～、というのはいつの時代も当てはまる。