DXは脱「ITゼネコン」（SIer）から始めよう
10数年前、日本には「SE（システムエンジニア）」という職種がある、という事を知りました。同時に「SEって、企画や要件定義・設計を行うけど、プログラミング出来な（くてもなれる）い人達なんだよ」と教わりました。
当時、英語漬けのままソフトウェア開発にはまっていた頃で、内心「なんでプログラミング出来ないのに『システムエンジニア』なの？」「プログラミングしたことも無いのに要件定義・設計とか変じゃない？」と素朴な疑問を感じて、ずっと不思議でしょうがありませんでした。
ソフトウェア開発者を気取っていた自分は、そもそも要件定義やらなんやら、開発が分かっていない奴の戯言だ、ぐらいに思っていましたし。SE、一体なんやねん、と。
が、しばらくしてすぐに謎が解けました。
これ、どうやら和製英語らしく、SEとは主に「ITゼネコン」などで働く人達の事だったのです（そうでない人もSE名乗る場合もある＆最近の状況は知りません）。
このSEという人達、開発プロジェクトに関わりそうな所にはどこにでも顔を突っ込んでいて、自らソフトウェアを作る事も出来ないのに仕事を請けて、下請けに安く丸投げしているだけだったのです。
実際に開発するのは孫請け曾孫請け・・・なんという非効率な搾取構造でしょう。
ITゼネコンの人達は、「上流工程」とかいう余計な工程で「要件定義」だのなんだの仕様を決めるんだと言います。しかし本来は、要件定義とは、システム開発を請け負う契約上、後々お互いに齟齬が起きないように、予め「どこまで何をどうやるか」を決めておく「契約上の取り決め（予防線）の一部」に過ぎません。
しかも、LinuxやPostgreSQLなど、無料で自由なオープンソースのシステムを活用すればよいものを、わざと自社製品を使うように仕向けて億単位を請求している、というような黒い話し（超簡略化してますが）みたいなのも沢山ありました。（これ単体でもアレですが、結果的に、今でいうベンダーロックインにも繋がる話しですね）
「お偉いさんはなんにも（ITのこと）分からないし、爺さん達はNTT（みかか）と名前がつくのに弱いのよ」という愚痴を良く聞いたものです。
当時、気になってITゼネコンのサイトを覗いてみたら、ミドルウェアなどの「パッケージソフトウェア製品」を売りにしていることが分かりました。これも別にオープンソースので構わないんだけどなぁ・・・と、興味をもってどんな技術が使われているのかと調べてみると・・・なんと、実は全部、欧米のソフトウェアの名前を変えて自社製品にしてただけのものだったのです。
驚愕しました。
自らソフトウェアを作る事も出来ない人達が、良いシステムを作れる訳がありません。伝言ゲームで下請け孫請けに何が伝わるというのでしょう。
若き頃、日本のIT業界に絶望した瞬間です。
日本とアメリカでは、エンジニアの勤め先から大きく異なっている。日本のエンジニアの多くはIT企業に勤めており、ユーザー企業から依頼を受けて開発を行う。そのため大手企業の運営するサービスであっても、実は全く名前が知られていないような会社が開発したということが起こるのだ。
一方アメリカでは、エンジニアの多くが勤めているのはユーザー企業だ。自社サービスの開発に力を入れており、成功失敗に左右されるというのも先ほど述べた通りである。
この違いは発注者・受注者の関係に大きな影響を及ぼす。アメリカでは発注者・受注者は共に同じ会社の人間だ。コミュニケーションはスムーズに取ることができ、遠慮なく意見交換を行えるだろう。
[中略]
柔軟性に欠ける開発手法
日本のソフトウェア産業では開発手法としてウォーターフォール型が一般的だ。1970年に提唱され今なお活用されている手法である。しかし、これもまたやや時代遅れの手法となっている。
この手法は、まず始めに要件定義、それから設計、プログラミング、テストという手順を踏んで納品に至る。
なぜ、日本のソフトウェア品質は悪いと言われるのか？
えぇ、英語圏では日本のITゼネコンみたいな存在は聞いたことがありません。（大手ITコンサル会社が開発請負に手を出して派手に失敗した例なら知ってる）
ITゼネコンの人達は、単に自らに箔をつける為にわざわざSE（システムエンジニア）なんて和製英語の肩書を名乗って、「上流工程」などと言って、上から目線で下請けをこき使っているのでしょうか。幸い、自分は直接ご縁はありませんでしたが。
その後、世界的にブログが流行った時期がありました（今は普及して当たり前になっていますが）。当時は猫も杓子もブログ時代でしたので、ITゼネコンも最新のトレンド、ブログシステムとやらをやらねばなりません。
が、ITゼネコンの最大手、NTTデータが盛大にやらかします。
NTTデータのブログサービス「Doblog」が終了
ハードディスク故障によるサービス停止から復活ならず
ソフトウェア開発者として色々なシステムを評価していたので、自分も実際にDoblogのアカウントを作って使ってみたのですが、サービス開始当初から不具合とサービス停止が相次ぎ、ユーザーから大不興を買い、不安定なシステムで復旧のめども立たずにあれよあれよという間に終了してしまいました。Livedoorやココログとはえらい違いです。
ここにITゼネコンの実力を見たり、という気がしました。「ブログシステムを構築するための技術的知見を得た」とは良く言ったものです。ブログシステムの元祖とも言えるMovable Typeなんて、若い夫婦が作ったものですがな。
NTTデータのDoblogは、機能・デザイン・ユーザビリティ・安定性、全ての面で他のブログサービスより劣っていただけでなく、途中で放り投げた挙句に「技術的知見とノウハウを得るためだった」とか、利用者を完全にコケにした話しです。
その後、自分は不動産業界へ移りましたが、プログラミングというバックグラウンドを持つ自分は、不動産業界のITや情報流通システムにも興味がありましたので、業務に慣れてきた頃から、業界での動きにも注目する訳です。
すると、当然のように不動産業界にもITゼネコンの魔の手が・・・。
ただ、自分が顔を出した頃には、不動産業界の団体（東京都の協同組合）も、既にITゼネコンに痛い目に合っていて、組合の役員さん達の間では、失敗だった、という共通認識はあったようです。しかし、組合のその後のやり方も不味く、また頭を抱える事になるのですが・・・。（追記＞「日本の不動産業界団体による、失敗IT事業の数々をウラ話しを含めて一挙公開」）
さらに言うと、レインズという悪名高いシステムにもITゼネコンの権化たるNTTデータが絡んでいたりします。言葉にいい表せないほどのくそしすてむです。その辺は、「不動産流通機構：あらためてレインズの問題を考える」で詳細に触れています。
以上、前置きでした。
ITゼネコンとは
詳細はウィキペディアのITゼネコンの項などを参照して頂くとして、具体的には、NTTデータとかNTTコミュニケーションズ、日立システムズ、日立ソリューションズ、NECなんとか、富士通なんとか、といった、大企業の子会社がそれです。
お上品にシステムインテグレーター（SIer）などと言ったりしますね。
日本企業のIT化が進まない理由として挙げられるのが、諸外国とは異なる「日本特有のSI業界の産業構造」だ。国内のIT人材をSIerが一手に抱え、ユーザー企業はそのSIerにITシステムの企画・構築・運用を発注する――。日本ではすっかり常態化したこの産業構造だが、実は海外ではこのようなやり方は必ずしも多くはない。そしてこの産業構造は、過去には有効に働いていた時期もあったが、現在では非効率な面が目立つようになってきている。
日本企業のIT化はなぜ進まないのか――日本特有のSI構造とエンタープライズITの在り方から探ってみると – データのじかん
とってもお上品で控えめに解説されていらっしゃいます。メディアは広告主さんに配慮しなければなりませんから大変ですね。
ITゼネコンの問題点
（画像「日本のITゼネコン『官民癒着』の問題点」より）
官民癒着といえば天下りですが、先週だったかも、例によって例のごとくまたNTTデータが高額接待なんてことを、文春がスクープしてましたね。
未だにそういうことやってます。
・政府から受注したITゼネコンには自らソフトウェアを書く人・書ける人がおらず、仕様書を書いて下請けに丸投げするだけ
・その下請けは、大学でちゃんとソフトウェアの勉強をしていない文系の派遣社員を低賃金で雇い、劣悪な労働環境でコードを書かせている
・書かれたコードをレビューをする習慣やシステムが存在しない
クライアントの打ち合わせ、仕様書の作成、見積書の作成などには膨大な時間を書けるわりに、コードのクオリティを上げることには時間をかけない
・ITゼネコンには役所からの天下りが、下請けのソフトウェア会社にはITゼネコンの天下りが役員・顧問・相談役として働いており、ほとんど仕事をせずに「口利き」だけをして高給をもらっている。
などの、日本特有の事情があると考えて間違い無いと思います。
「なぜ、日本政府が作るソフトウェアは使えないモノばかりなのか？」
この問題、本当に10数年以上前から指摘されてきたのに、一向に変わっていません。
「大手の技術者はサラリーマンで、政府から仕事を取ってくるだけ。実際に作るのは下請けの個人事業主のような技術者です。大手に実際にシステムを組める人材はほとんどいません」
9月発足の「デジタル庁」に群がる“ITゼネコン”
ぶっちゃけ、ITゼネコンの仕事とは、政府官公庁や業界団体に接待や天下りで取り入って仕事を囲い込み、下請けに丸投げするだけ、な訳です。
で、下請けは、ITゼネコンから流れて来たものを何も考えずに作るだけ、作って納品したらおしまい。という・・・。そういう風にやってこざるを得なかったのです。
優秀なエンジニアであれば、そんな状態に我慢できる訳もありませんから別の所に行きます。そもそも、ITゼネコンのやり方だと、エンジニアの能力で評価されるのではなく「人月」が安いで評価されるので、単価が安い素人の方が評価されてしまいます。結果としてITゼネコンに丸投げしても、素人が作ったみたいなものが出来上がるばかり。
その未来（ざま）が今の日本のITの現状であります。
エンジニアは独立する気概を持てや、という指摘もありますが・・・まぁ人材流動が固定化されてきた日本ですし、そもそもITゼネコンがのさばっている日本では、独立してもITゼネコンに仕事を囲い込まれて潰れる、という構図だったわけです。
政治家や官僚は、どういうシステムをつくったらいいかイメージができない。イメージできないのでどうするかといえば、システム開発を請け負う企業、いわば「ITゼネコン」を呼んで、すべてをぶん投げてしまうのだ。これは泥棒に鍵を渡す行為に等しい。
大前研一｢日本のシステム開発が失敗ばかりする根本原因｣
つまり、ITゼネコンとは、日本が「IT後進国」に落ちぶれることになった元凶である「外注丸投げ＞多重下請構造」と「官民癒着」の元締め、であるわけです。
日本独自の悪習であって日本のIT社会に巣くうヒルか吸血鬼みたいなものと言っても過言ではありません。
NTTデータを始めとするITゼネコンは、不動産業界のみならず、日本のITを後進国にまで貶めてくれたわけで感謝感激涙の嵐です。（建設的コメント）
ITゼネコンの歴史
先日、日経新聞に興味深い記事が載っていました。
日本企業におけるIT（情報技術）人材の不足は、平成バブル崩壊後の1990年代に情報システム部門が本体から切り離された影響が大きい。当時「ノウハウ集約」「専門性の向上」といった大義名分で設立された情報子会社の多くは、コスト削減目的のアウトソーシング（外部委託）が実態だった。システムを受託開発する大手の「システムインテグレーター」の下請けからエンジニアを出向で派遣してもらい、依存が強まった。
60～70年代に大型汎用機（メインフレーム）を導入した当時の「電算部」から蓄積してきた「情シス」のノウハウと人材が途絶え、IT投資はシステム業界への丸投げが常態になった。自社業務に都合よく独自仕様で導入したERPは継ぎはぎ改修を繰り返し、設計にかかわったシステム会社しか触れない「ベンダーロックイン」にはまっていく。
この間、欧米では汎用パッケージソフトが広がったが、日本企業は身動きがとれずにいた。経営トップにDXが競争力を左右するという意識が薄く、システム会社もベンダーロックインで稼いでいたからだ。ある大手ソフトウエア会社の経営者は「情報システム担当者は業者との蜜月関係を守ってきただけ。ある種の怠慢があった」と日本企業の不作為を嘆く。
「名ばかりCIO、場当たりDX システム開発なお丸投げ」
ここにもバブル経済のツケが影響していたんですね。バブル世代よ、反省しる！
丸投げするほうも、怠慢と不作為のそしりを免れません。
変化の兆し
最近になって、DXみたいな言葉が出てきました。
流行り言葉の横文字はたまには役に立つようです。
約160人を中途採用、内製化に舵を切る
DX銘柄に初選出されたセブン＆アイ・ホールディングスは、ここ数年でシステム開発の内製化に大きく舵（かじ）を切った企業の1社だ。[中略]
「ITやDXを自社の競争優位の重要施策と位置付けるなら、それを外注するという選択肢はあり得ない」。セブン＆アイ・ホールディングスの米谷修執行役員グループDXソリューション本部長は内製化に力を注ぐ理由をこう語る。
従来、同社は開発をすべてITベンダーに依存している状態だったという。「開発をアウトソースすると自社にノウハウがたまらない。ITベンダーから出てきた見積もりやスケジュールが正しいのかどうかを判断できない状態だった」と米谷執行役員は語る。
ITベンダー依存の弊害はそれだけではない。「外部に任せるとスピードが出ず、自由度も上がらない。なので内製が必要と判断した」（米谷執行役員）。
セブン＆アイがエンジニアを大量採用、「DXの内製化」に注力する理由
また、政府の方にも、やっとこういう風に言う若い人が出て来てくれました。
「サービスをリリースしたら終わりではなく、リリースしてからが勝負だ」と話した。そのためにも、デジタル化のプロセスについて「アジャイルで小さくつくるように変えていく必要がある。小さくつくってから発展させること、失敗をある程度許容していくこと、時にはやめることも大事だと考えている」（津脇企画官）
デジタル庁は失敗恐れずアジャイルで、DX「仕掛け人」が挑む3つの変革
ITゼネコンがずっとやってきた、ウォーターフォール型の「要件定義」なんて分からんヤツの戯言、と考えていた自分は一応先見の明があったわけです。「納品したらお終い」なんて、あり得ません。アジャイル型の手法で開発していくべきなのです。これ語ると長くなりますので、またの機会に・・・・書きました。
まとめ
ITにしろ、DXにしろ、始まりの一歩として、「丸投げせずに、自分達の事として、自分達で試行錯誤しながらやる」という事ではないでしょうか。
皮肉にも、DXだ不動産テック、なんていう言葉が出てくると、例によって例のごとく、すわっとばかりにITゼネコン関係の人達が飛びついてきて、例のごとくバズワードを散りばめた中身空っぽの売り文句で宣伝や広告営業を仕掛けてきます。そういう時の為に、ポスターでも掲げておくと良いかもしれません。
「ITゼネコン依存 ダメ。ゼッタイ。」
「ITゼネコン関係者入店お断り」
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？