http://www.asyura2.com/16/hasan107/msg/219.html
Tweet |
巨大化した「詐欺的」IT業界が、国民の生命や社会・経済を破壊する危険が現実味
http://biz-journal.jp/2016/04/post_14543.html
2016.04.04 文=佃均/ITジャーナリスト Business Journal
先月から今月にかけ、大手国内航空会社の日本航空や全日空のシステム障害が発生し、多くの利用客に影響が及んだが、大規模なITシステムの開発では、受託型IT/ソフトウェア開発業(以下、受託型IT業)のひどい体たらくが指摘される。ユーザーの要望を理解しようとしない、仕様書が読めない、言われたことしか(言われたことも)しない、技術力がない、モラルが低い、向上心がない、頭数(人の派遣)で儲けている等々。同業界がこの国の社会・経済をおかしくしないために、建築基準法並みのルールと厳格なチェックが必要ではないか。このままIoT時代に突入するのは危険すぎる。
■出口なきダメ論のループ
受託型IT業はユーザー(原発注者)から「所詮は下請け」と小馬鹿にされ、「3K」といわれて久しい。「きつい・帰れない・給料が低い(結婚できない)」が新卒就職希望者から敬遠される要因だが、もうひとつ、「経験・勘・神頼み」という仕事の進め方の3Kもある。そのような声に発奮して改善に向かうならともかく、当の同業界が「だって3Kなんだからさ」と開き直っているのでタチが悪い。
筆者を含めて受託型IT業ダメ論者は「問題の根源は平均4階層の多重取引構造にある」と結論づけ、返す刀で「最大の問題はユーザーにある」と斬って捨てる。ここでいう「ユーザー」とは、ユーザー企業内のIS(Information System)部門もしくはIT子会社を指すのだが、自社の業務知識がない、きちっとした仕様書が書けない、プロジェクト管理ができない、下請け丸投げの元凶、ITベンダーの代理店、所詮は社内下請けと散々な言われ方をしている。
受託型IT業やユーザーIS部門の関係者と話をすると、阿漕な人足稼業や能天気な殿様と出会うことはほとんどなく、みんな真面目で正直である。ダメ論者の指摘を認めつつ、少しでも良い方向に向かおうとそれぞれがそれなりに努力をしているのだが、しかし簡単には実行できない事情をそれぞれがそれなりに抱えている。結局、ダメ論者の舌鋒はそこでハタと止まってしまい、出口の見えないダメ論がループすることになる。
受託型IT業の実態について、自他共にダメ論を認めているので業界内は平和なのだが、実はとんでもなく困ったことなのだ。この国の企業ばかりでなく、国の機関や地方公共団体、教育機関や医療機関、さらには交通、運輸、エネルギー、通信といったインフラはITがなければ機能せず、それを支えているのが同業界だからである。
■「名ばかり」エンジニアが増えた
受託型IT業やユーザーのIS部門は、最初からダメだったわけではない。1960〜80年代後半にかけて、世界に先駆けて大規模なオンラインシステムを構築したのは日本の企業だったし、大規模データベースの高速検索技術を開発したのは日本のITエンジニアだった。IoT(Internet of Things:モノのインターネット)で世界から注目されているTRONの本格的な研究開発がスタートしたのは84年だった。
これに対して、今世紀に入って、都市銀行のシステムトラブルやM&A(合併・買収)に伴うシステム統合の失敗、特許庁や人事院の「終わらないプロジェクト」などが目につくようになった。下請けITエンジニアによる個人情報の持ち出し・漏洩といった事件も起こっている。
10年前と比べると、受託型IT業の就業者数は1.7倍の98.3万人、売上高は1.3倍の19.3兆円(いずれも経済産業省「特定サービス産業実態調査」による)と拡大したが、就業者ひとり当たり売上高は2割以上減ってしまった。「ITの利活用で生産性向上を」と訴えている受託型IT業が、マンパワー依存で生産性を落としているのは皮肉な話だ。
多重下請け構造による劣化は、偽装派遣だけでなく、受発注価額の欺瞞にもつながっている。ユーザーが人月単価(1カ月・ひとり当たりの発注単価)100万円で発注しても、多重のピンハネが行われるので現場に派遣されるのは月60万円レベルのエンジニアだ。やむを得ない事情もあるのだが、考えようによっては、業界をあげて詐欺を働いている、と言えなくもない。そうしたあれこれがダメ論に拍車をかけている。
だが一方で、JRのSuicaに代表される電子交通チケットシステムやH-2【編注:正式表記はローマ数字】ロケットといった大規模・複雑かつ100%の正確さが求められるシステムを実現しているのも事実。優れたプロジェクト・リーダーやエンジニアは一定数いる。しかし、全体の8割以上が「名ばかり」エンジニアということだ。
■IoTは生命のリスクにかかわる
現場にいるのが「名ばかり」エンジニアばかりでも、仕様や設計を厳密化し部材を規格化する、CAD/CAMを使う、作業を機械化する、構築手法を研究するようなことに、受託型IT業が真正面から取り組んでいるならまだ救いがある。しかし実情はマンパワー頼みで、建てることができるのはせいぜい“5階建ての鉄筋コンクリートビル”が目一杯かもしれない。それでもなんとかやってこられたのは、「名ばかり」とはいえ現場のエンジニアが踏ん張ってきたからにほかならない。
そうこうしているうちに、時代はITシステムからIoTに移りつつある。表記は小文字の「o」が入るか入らないかの違いだけだし、コンピュータ、ソフトウェア、ネットワークの組合せ・融合で実現するという点で共通している。ところがトラブルが発生したとき、その影響範囲が決定的に違う。
ITシステムは特定企業の内部や特定業務に限定され、トラブルが発生したときはほかのシステムから切り離すことができる。その復旧と修復は「時間+マンパワー+根性+陳謝」で乗り切れるが、IoTはそうはいかない。
IoTはYes/Noがはっきりし、影響範囲が想定をはるかに超える。わかりやすい例は自動ドアだ。人やモノが近づいたのをセンサーが検知して、モーターを動かすことでドアが開くというのが理屈。センサーが正常に検知しなかったり、モーターに信号を送らなければドアは開かないので、人がぶつかってしまう。
もうひとつわかりやすいのは、自動車の自動運転システムだ。自動車に内蔵されたコンピュータが道路やビルのセンサー、ビーコンと交信し、通信衛星からデータを受け取りながら、内蔵したカメラやレーダーで障害の有無を認識して自動走行する。誤動作はただちに事故に結びつく。金融システムが暴走したら預貯金のデータが消えてしまうかもしれず、心臓のペースメーカーや人工呼吸器、血液ポンプといった医療機器の誤動作はただちに人命にかかわる。
■建築基準法並みのルールを
むろん地震や火災、破壊行為、サイバーセキュリティへの対策基準はあるし、品質に関する国際標準規格もある。セーフティケース(安全性の確立手順)やインシデント(事故)管理・対策の研究も行われている。だが、それは表向きであったり、企業内IS部門や受託型IT業のごく一部、大手企業に限られる。
IoTは、複数のITシステムがセンサーの信号で相互に連携し、データをトリガー(起点)に起動する。JRなど複数県にまたがる鉄道では、他県で発生した信号機故障が全線に影響するが、IoT/ITは事故や生命・財産に直結する。IoTの需要は素通りするとしても、既存のワークフロー型ITシステムを担っているのは受託型IT業だ。そこで受託型IT業を所管する経済産業省は昨年の秋頃から、「データ駆動型社会・経済の安心・安全」を目的に、「ITシステム構築における丸投げ下請け禁止」を検討し始めた。
ところが「禁止」を謳うベースとなる業法や安心・安全の法令がない。強いていうと「情報処理促進法」が唯一で、70年に制定された「情報処理振興事業協会等に関する法律」にさかのぼる。当時は受託型IT業を振興することに主眼があって、自由度の確保が優先、規制は後回しという施策だった。
「自由度が高い産業」といえば体裁はいいが、実態は放任、野放しといっていい。その基本方針を変えないまま、多重受発注が蔓延し、就業者100万人、売上高20兆円という巨大な規模になってしまった。
ソフトウェア工学の必要性をいくら叫んでも、3次請け、4次請けのソフト会社には届かず、そもそも原発注者(ユーザー)にリーチしていない。ソフトウェア工学者を自認する人ほど、ソフト開発の現場から遠いところにいて、現場に「がんばれ」と声をかけて自己満足に浸っている。
「建築基準法並みのルール」ですべてが解決することはないが、基準があればこそ、それを達成するための工法や技法が登場し、説明責任を果たすことができる。 「規制のない自由さ」を是としながら共同無責任の体質を形成してきたのは、60代以上のオールド(レガシー)ITエンジニアではないか。
この国の社会・経済の安全・安心を守っていくには、受託型IT業の契約や作業指示と作業内容を照合できるエビデンス、建築基準法並みの品質・安全基準とルール、公共調達における標準価額などを、いまこそ業界自らが率先して本気で検討すべきだ。
(文=佃均/ITジャーナリスト)
投稿コメント全ログ コメント即時配信 スレ建て依頼 削除コメント確認方法
▲上へ ★阿修羅♪ > 経世済民107掲示板 次へ 前へ
スパムメールの中から見つけ出すためにメールのタイトルには必ず「阿修羅さんへ」と記述してください。
すべてのページの引用、転載、リンクを許可します。確認メールは不要です。引用元リンクを表示してください。