OCEB 第24回 Why BPM?

源氏池

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

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

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

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

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

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

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

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

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

OCEB 第２３回 Why BPM 6

七里ケ浜

前回は（と言っても随分前になってしまいましたが）、筆者の属する世代の話を書きましたが、これは、一言で官僚主義と言っても国によってその状態が異なり、日本は日本独自の理由で官僚主義に陥り、独自の官僚主義が形成されている事を、他国との比較で議論するために、筆者の世代の相対主義を話の枕にするつもりだったからです。（官僚主義は決して日本の専売特許ではなく、あらゆる国のあらゆる大組織で見られる現象ですが、どうも日本には日本固有の官僚主義がありそうです。）

さて本日は、筆者のまわりの話題から筆者が日本独自と考える官僚主義の具体的な一例を挙げてみましょう。

３０年ほど前、筆者はアメリカのソフトウェア関係の開発部門にいた事があります。
当時のソフトウェアの開発部門のワーキング・スタイルは、日米にそれほどの差異はなく、製品開発は基本的にアセンブラ言語で生産性は高くなく、非常に多くのプログラマや設計者が長期間に渡って１つの開発プロジェクトに携わり、毎朝会社に来て長時間に渡る会議の合間に設計やプログラミングをし、カフェテリアで同僚達と雑談を交わしながら昼食を摂り、夕方になると帰宅していました。
そして、それから時は流れ、かつての同僚達の職場は随分変わりました。
職場に開発ツールが導入され、多くのエンジニア達は在宅勤務となり、ツール上で開発やテスト、そしてコミュニケーションを行ない、人それぞれのワーキング・スタイルを取って働くようになりました。また人数的にも少数精鋭になって来ました。
方や我が日本の方は、ソフトウェア開発の現場に開発ツールを導入して生産性を揚げようとする意識が薄く、またワーキング・スタイルも３０年前とほぼ同じ状態を続けていますが、ツールやワーキング・スタイルは本日の議題ではありません。
日本の開発現場でも最近になってようやくモデリングが普及して来て、ある会社ではドキュメントがモデリング言語で書かれるようになった開発現場も増えて来ました（多くはドキュメントの品質向上を直接の目的にし、最終的な生産性向上を狙っての措置です）。
ところが開発部門がプログラミング作業の一部を外注に出す段になって、購買部が、外注先がそのモデリング言語が読めるにもかかわらず、購買部で外注先を管理する手続き上、従来の設計書式で提出するよう要求され、開発部門では仕方なく、設計を昔の方式に書き直したそうです。
これに似たような話は他でも聞きます。　品質保証部が新しい設計図が読めないから（あるいは自分たち使用している品質メトリックスに合わないから）、昔の設計手法で書いてくれと要求して来たと言う話もあります。
これらの話に共通するのは開発部門はそれらの要求を受けてわざわざドキュメントを従来の方式に書き直し、それを変とも不思議とも感じない点です。
サポート部門が開発部門の生産性を下げているのですが、長年に渡ってそんな状態が続いた結果、サポート部門の役割は開発部門の邪魔をする事だと、思い込むに至ってしまったように思えます。