OCEB 第２３回 Why BPM 6

七里ケ浜

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

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

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