OCEB 第24回 Why BPM?

源氏池

前回は、開発部門がドキュメンテーションをモデル化しようとした結果、組織内にコンフリクト（紛糾）が発生し、結果として開発部門が旧来のテキスト形式と新しいモデル形式の２重の作業をしなくてはならなくなった、と言う事例を紹介しました。

コンフリクト（社内の紛糾）に対する態度

世間ではコンフリクトは、組織にとっては往々にして問題児が引き起こす非効率性、混乱と見なされがちですが、最近のマネジメント理論では、『コンフリクトは変化に対して組織内に当然起るものであり、それ自身に大変に価値があるもの』とし、マネジメント・トレーニングではコンフリクトに対し積極的に前向きに取り組むよう教えられるようになってきました。

今回の事例では、開発部門が従来と異なる（モデリング）言語を使用したいと言い出せば関係部署との間にコンフリクトが発生するのがむしろ当然であり、その結果として、積極策としては社内の開発標準やプロセス標準を作ろう、あるいは見直そうと言った改善のチャンスに繋がって来ます。
また組織全体への波及効果を最大に持って行く戦略の策定の引き金にもなり得ます。
事実、例えば品質保証部としては、ソースコード・レベルのテスト（従来の潜在バグ分析とかテストの網羅性（カバレッジ）分析とか言った手法等）だけでは不十分な分野が増えて来ており、要求分析や設計段階での品質チェックがますますその重要度を上げて来ていますが、モデル化はそう言ったレベルでのチェックの大いなる助けとなります。（現実的には、システムの複雑度が増すと、テキスト・ベースでは精度の高いチェックが事実上不可能になってきます。）
モデル・ドリブン・テスト、もしくはモデル・ベース・テストと呼ばれる手法もその一分野です。

ところが今回取り上げた事例では、開発部門は従来の手法と新しい手法の二重化が要求されてしまい、本来生産性を上げるつもりで取り入れたはずの手法が、かえって自分たちの作業負荷を増やすだけの結果になってしまいました。

つまり、生産性を上げると言う目的に対し、その目的を無視し、逆に生産性を下げる手続きを強いられる結果となってしまいました。
 この目的の不在化（あるいは手続きのための手続き化）は、官僚主義が蔓延した組織によく見られる特徴であり日本だけに存在する問題ではありませんが、日本の特殊性は、その目的の不在が常態化し、誰も不思議と感じず、あらゆる組織に（往々にしてそれほど大きくない組織にも）遍在する点です。

経済産業省の調査資料によると、IT活用の効率性は製造業では米国の５４％、非製造業では米国の１４％だそうです。
逆に言うと、同じ結果を得るために日本はITに対し米国の約２倍（製造業）もしくは１０倍近く（非製造業）のコストがかかっていることになります。

日本の製造業の国際市場での存在感の低下傾向（非製造業の存在感は昔から無に近い）と無関係な数字とは思えません。

筆者は、日本のIT投資の非効率さは、モデリング等の技術的な問題を遥かに超え、戦略とマネジメントの問題だと感じていますが、続きは次回に。