彼の廻りの同年配の知人友人達は、4〜5年前まではIT企業を辞めても、またIT関連の企業に就職することが多かったのが、最近では、全くの異業種へ転職するようになってきているそうです。
筆者は、若い頃は、「日本には日本のやり方がある」という意見に反発を感じていた方ですが、歳を取るに従い、従来のやり方に拘る年長者の気持ちも理解出来るようになってきました。しかしながら、この3K化の問題に関しては、日本の従来のやり方が間違っていると強く感じています。あえて失敗と呼んでいいとさえ考えています。
この３Ｋ化の問題は単に勤務時間が長いと言う点だけが問題なのではなく、様々な複合的な問題のようです。一々挙げるときりがありませんが、代表的な問題としては、上流工程の品質が劣悪で、その皺寄せが開発工程を直撃している、とか、IT企業がゼネコン化し、孫請けなどは当たり前で、5次受け6次受けなどもざらに存在し、中間搾取が甚だしい、あるいはエンジニアの技術レベルが低い、、等々。
そして、その多くが日本固有の状況である事を示しており、日本固有の解決策が必要です。（欧米の先進企業の部分的な模倣では決して解決しないことが、だんだんと明らかになってきました。）
そして、ここに興味深い事実が１つあります。多くの方々が、BPMが問題の解決あるいは現状の改善の糸口になる、あるいは、なって欲しいと期待していることです。
IT産業では、かつて、新しいテクノロジーの出現により、市場が激烈に変化したり、価値基準が逆転したりするような事が何度も発生してきました。日本の強固な労働慣行でさえ、強く影響を受けています。
BPMは、生産工程のテクノロジーと言うよりも、ホワイトカラーのテクノロジーと言う面が強く、人々の期待も決して根拠のないものではありません。
さて、筆者の短見では、BPMはもろ刃の剣に感じます。
この件については、今後また触れたいと思います。
配備、配備仕様の表現
前回（第106回）、ノード内に成果物を記述して、配備を表現する形式を解説しましたが（図H07 参照）、
同じことを、図H08のように、配備を示す依存関係（＜＜Deploy＞＞を使って表現することも可能です。
図H08
