忖度費用を計上しない日本のIT業界

上流工程で具体的な設計書が降りてこないから、下流工程で「忖度」してしまう。
要件書は抽象的な表現ばかり。
「使いやすく」「柔軟性があり～」「拡張性が高く～」とか、どうにでも解釈できる。
設計書なんかあって、ないようなもん。
「現場の操作手順に準ずる」って何？
質問すれば、あの人に聞いて、この人に聞いて、とたらいまわし。

そうして、プログラミングする人は、限られた時間で想像を巡らして作り上げるわけ。
まぁ、ほとんどの場合、実際に作られたものを見て、
本当に何を作ろうとしていたのが分かり始める、プログラマー以外の人はね。

そして、あれが違う、これが違う、と言い始める。
さらにひどいのは、
「常識的におかしい（仕様）」だとか言い始める。
もっとひどいのは、

「なぜこう作ったの？、わからなければ、聞いてくれ」とか言い始める。
聞いても、答えられなかったクセに、だ。
上記の内容を会議で偉そうにしゃべるのが、上流工程、プロジェクト管理の人たち。
加えて、管理職は人の管理が仕事だと「しか」思っていないから、

PDCAのチェックができない。

大抵、下流工程で上流工程の要件内容がはっきりしてくる。
実際にモノを作って、試作品が出て使って見なきゃ理解できない人たちだから。

そして、プログラミングする作業を誰もやらなくなる。
作業に見合った成果・承認要求を得られない損得勘定が働くからね。

だったら、日本特有の訳のわからない、SE（システム・エンジニア）になって、

伝書鳩ごっこに興じて、自分の作業工数だけはがっちりガチホの世渡り上手に
なろうかと思う。

もしくは、プロジェクト管理になって、評論と社内政治に興じる。
そっちのほうが昇進も昇給も速い、何かを実際に作るわけじゃないから、
不具合は直接目に見えないしね、不具合は実際に作った人に負わせる算段。
IT業界も、多くはピンハネの階層が出来上がっているしね。

「下流」工程の「下流」は良くない表現。

下流＝下請けみたいにイメージしてしまう。
上流工程を下請け企業に出して、下流工程を自前で作業するＩＴ企業は、
今まで見たことがない。

上流工程は文書を直せば済むかもしれないが、下流工程ではそうはいかない。
現代のプログラマーはコード言語のほかに、数多くあるフレームワークの知識も必須。

海外なら、プログラマーは忖度しないだろうな。

仕様を書いていない設計書が悪い、だから、そこは作らない、で終わり。

「忖度する」は日本の労働の最高峰に位置する作業。
日本では誰もが期待するように教育されているが、それは日本だけ。
そして、その忖度費用が払われることはない。

米国ソフトの日本代理店ばかりじゃん。日本のIT業界はさ。一太郎が懐かしい。