どの様な話？
専門職では、
- 似たような分野の仕事は手を抜いてしまう
傾向に有ります。
これは私自身がやり、上司にとても怒られた（他の部署の手伝いをして、自部署の感覚で物事を言った）事も有り、
特に、
- 上司が居て、規律など厳しい専門分野で、
- 似た様な仕事に出る
- 上司の目が届かない
- ややお客さん扱い
な状況で、いとも容易く手を抜く（していた筈の手間をしないなど）事が発生します。*1
さらに、
その部署で、既存の人を出し抜こうとして、その「手抜き」にさらに磨きがかかる事があります。
- うまくいっている、一番のキモの部分について手を抜く
やり方です。
- 手続きはダメだ
- 項目定義はダメだ
- ログはダメだ
- チェックはダメだ
- 手順書はダメだ
等々です。単なる無意識の手抜きに加えて、既存の人を出し抜こうとする、意図的に近い手抜きが加わるのです。
DXになって
DXとは
- なんでもいい、理屈を言ってもいいから
- とにかくやれ
だと思います。だから「DX」自体は無味無臭なのだと思います。
そうなった時に、無意識・意図的を問わず、手抜きをして、それに対する信奉者も得た人間が困るのは明白です。
なぜなら、そうなった時のその人達は、正しく「既存の人」だからです。
手抜きの結果
ソフトウェア開発で、「手抜き」をすると「可視化」に影響が出ます。
普通、「可視化」とは言いましても、結局の所、
- 問題をある基準で分類し、
- 重い方から並べて、
- 重い方から順に管理する
事になると思いますが、プログラミングの問題分野では、
- その基準が1つだと、
- どんな基準で分類しても、管理に耐えられないレベル（レベル1000とか）に問題が残ってしまう
性質が有ります。これがテスト後の不具合の原因そのものです。
解決策は、
- 基準を複数にする
事だと思いますが、「手抜き」とは、
- 1つがいいんだ、それも自分が持っている工具で！
と言う事だと思います。
オブジェクト指向は複数の基準ですし、公理も定理も宣言も（定説が無い分）複数の基準と言っていいと思います。*2とにかくやれの場面で上手く行くやり方は、ソフトウェア開発では、基準が複数です。
似た様な分野の仕事の人は、
似た様な分野の仕事の人がしゃしゃり出て来た場面では、無意識にせよ、意図的にせよ、
- 1つがいいんだ、それも自分が持っている工具で！
となります。
その分野では既存の人に（少なくとも当面は）勝てない事への焦りかも知れませんが、「とにかくやれ」の場面では有害・有毒以外の何者でも有りません。
結論
これからも「ソフトウェア開発の可視化に関わる手抜き」を周りの人にされる事でプログラミングが嫌いになる人は存在し続けることでしょう。
