【IT】日本型失敗の典型、客の意向を忖度し炎上するITベンダーの悲惨。忖度し空気を読んだ結果がデスマに

ノチラ ★

忖度し空気を読んだ結果がデスマに
日本のIT業界は言うまでもなく、元請けのSIerを頂点とする多重下請け構造だ。ただ、SIerに仕事を発注するIT部門も、言うならばユーザー企業内のSIerの立場。実際、“客”である事業部門の要望に受け身で対応するなど、日本のITベンダーと体質的に似たところがある。だから、開発するシステムの本当の客がユーザー企業の事業部門ならば、その案件はIT部門を頂点とする多重下請け構造と捉えたほうがよい。

それを前提に先ほどの忖度の多重化を説明すると、こんな話になる。IT部門はシステム開発の際、事業部門や経営者と徹底的に議論せず、彼らの要望を忖度する。SIerもその要望を忖度し要件を定義する。下請けベンダーも要件定義書の行間を“忖度”し……。要するに伝言ゲームである。もちろん、会議やインタビューでのやり取りは文書化しているはずなので伝言ゲームとは言い過ぎだが、詰め切れていない曖昧な部分が忖度の対象になる。

しかも、忖度の対象になった曖昧な部分こそ、システムのコンセプトに関わる核心部分だったりする。よくある話としては、経営トップは「システム刷新に併せて業務改革を推進せよ」と言うが、現場は「新システムでも現行通りの機能が無ければ、業務が回らないぞ」とすごむようなケース。「社長も現場も納得するのはこの辺りか」という落とし所が、IT部門が大いに忖度する対象だ。

だからSIerもIT部門の苦渋を忖度して、抜けや漏れのある仕様だけを基に“うまく”作らなければならない。間違ってもIT部門との会議で、場の空気を読まず「それでは仕様が確定できません」などと、IT部門の長や担当者を困らせる発言をしてはならない。商談中ならなおさらだ。若い元気な技術者の中には、そう発言する人がたまにいるが、同席する営業にさえぎられたうえ、後で「あんな話をするんじゃない」と説教される。

こうした忖度の連鎖が、IT部門を頂点とする多重下請け構造の中で行われる。SIerが元請けの場合なら、まだマシ。ユーザー企業のシステム子会社が間に入り元請けとなった場合は、さらに大変だ。なんせ、設計どころか要件定義すら満足にできないシステム子会社もあり、忖度ぐらいしか仕事がない。かくして忖度の多重化が進み、実際にプログラムを書く下請けITベンダーの技術者が「なんじゃ、こりゃ」と目をむく仕様が出来上がる。
http://itpro.nikkeibp.co.jp/atcl/column/14/463805/062900145/