IT業界の裏話

ついにやってきました。エイプリルフールです。今年も各サイトともに趣向を凝らしています。いつもの通り、GIGAZINEが都度更新をしているので、そちらのリンクも掲載します。

GIGAZINEの2012年エイプリルフール便乗サイト取りまとめ
http://gigazine.net/news/20120401-aprilfool-matome/

グーグルではモールス信号で思い通りの日本語入力
http://www.google.co.jp/ime/-.-.html

ファミコン版グーグルマップ登場
http://www.youtube.com/googlemaps

グーグルマップでドラクエ
http://maps.google.co.jp/

某作品のオマージュ。名もなき３人と最強武装マフィア軍団100,000人の激闘。謎の男ジャッキーチェン登場。
http://movie.nifty.com/april.htm

星一徹監修の大リーグボール養成スマホ
http://www.au.kddi.com/jiyu/0401/

ファイナルファンタジー7でお馴染みの「神羅カンパニーの社員食堂」を東京・丸の内に開業
http://www.i-mezzo.net/log/2012/04/01235955.html

面白法人カヤックは「世の中に飲む人を１人でも増やす」ことを目的に存在する組織。
http://www.kayac.com/company/event/mission/2012/

らばQがラバー好きなサイトに
http://labaq.com/archives/51644833.html

デイリーポータルZはデリーとポーランド情報を伝えるデリーポーランドZに生まれ変われました
http://portal.nifty.com/cs/april2012/list/1.htm

映画コムは終了して中国語サービスに変わりました。画面から立体貞子登場。
http://eiga.com/

映画キリングショットからブルースウィリスが育毛剤をプロデュース
http://gacchi.jp/movies/killing-shot/

バーグハンバーグバーグのメイン事業は「人間椅子レンタル事業」
http://bhb.co.jp/4gatsu-baka2012

アニキのガチャができる
http://muscle.gmobb.jp/

太陽の塔が立つそうな。
http://gorimon.com/blog/log/eid1617.html

月面サバイバルゲームを成田空港から無料スペースシャトルにて
http://www.hyperdouraku.com/april12/index.html

今年もいまいち萌えないっ娘フリーきっぷ
http://www.engan-bus.co.jp/aprilfoolsday/index.html

誰でもエイプリルなニュースを投稿可能な『虎構新聞』をオープン！
http://www.yukawanet.com/archives/4155858.html

巨人に踏みつぶされたのでアイレップは溜池山王に移転します
http://www.irep.co.jp/tameike/

室蘭―森間に内浦湾横断大橋建設へ
http://pucchi.net/hokkaido/blog/20110401.php

ダライアスに巨大戦艦復活
http://darius.jp/dbac/game/battleships.html

KLab、人気ソーシャルゲーム「恋してキャバ嬢」をリアル店舗でOPEN！
http://www.klab.jp/press/2012/120401kr.html

皆さんは約1年前に起きた、みずほ銀行の大規模システム障害を覚えているでしょうか？ 東日本大震災の義援金口座で処理上限を超える振り込みが生じたために、その後10日近くに渡って振り込み遅延が多発し、4日間もATMを停止させる事態になってしまったという事件です。詳細は過去の参考記事を参照下さい。

『同行のシステム障害は、3月14日に東日本大震災の義援金口座に大量振り込みがあったことをきっかけとして、24日まで続いた。大規模な為替処理の遅延が起きたほか、ATMや営業店の業務もたびたび停止した。遅延した為替処理は、仕向為替（顧客からの送金/振り込み依頼を他の銀行に対して実施すること）が合計120万件、被仕向為替（他の銀行からの送金/振り込み依頼を受けること）が合計101万件である。』
（出典ITpro）
http://itpro.nikkeibp.co.jp/article/NEWS/20110520/360539/

いまさらこの話なのかと思う方もいると思いますが、この話が銀行業界に与えたインパクトは甚大であり、2012年に入ってから、金融業界を統括している金融庁から銀行業界へ向けて、ついに最後の一歩を踏み出すメッセージが発表されました。

（システムリスクの総点検の結果について）
http://www.fsa.go.jp/news/23/ginkou/20120120-1/01.pdf

この文書には2011年夏から金融機関に向けて行われた”システムリスク総点検”を受けて、今後はどのような対策を行うべきなのか、言い換えると、何をやっていないと改善命令を受けてしまうリスクを抱えるのかが述べられています。

書かれていることは当たり前のことが多いですが、ひとつ見逃せないことが書かれています。

『[不十分な取組事例]システムの上限値を超えた場合に、システムがどのように作動するのかを把握していないほか、どのような事務処理を行うのかなどを定めていない事例』

これまた当たり前に思えるかもしれませんが、よく考えてみてください。

そもそも金融機関の重要システムというのはパッケージ製品として提供されたものをカスタマイズして使っていることがほとんどです。ということは、パッケージ製品のパラメータについて、「業務影響が生じるようなパラメータをつぶさに調べて、その設定値を把握しておけ」と言われているのと同じ意味になるのです。

皆さんが扱っているパッケージ製品を思い浮かべてください。Webサーバ、Appサーバ、DBサーバ、NWアプライアンス、どの製品がどんなパラメータを設定しているか、全ての値について理解しているでしょうか。

システムの規模が小さいなら、設定項目が数百程度で済むかもしれません。しかし、金融機関が使用している勘定系システムともなると、パラメータだけで百万項目を超えるものあります。

百万項目の全てについて業務影響を把握するだけでも気の遠くなりそうな話ですけど、金融庁が要求しているのはそのレベルではないのです。前述の話に加えて、上限値を超えた時にどのように設定変更しなければいけないのか、それはパラメータ間の相関関係を熟知しなければできることではありません。

さて、過去最高に厳しい要求を突き付けてきた金融庁。これに対して、各金融機関はどのように対応するのでしょうか。今後の動向が気になります。

企業は自社の未来を背負って立つ有益な人材を探し求め、世の就活生は自分を採用してくれる企業を探し続けるのがこの冬の季節です。一部の人材に内定が集中している昨今の就職活動では、企業側と言えども決して優位にあるわけではなく、買い手市場とも売り手市場とも評することが難しくなっているのがこの数年間の特徴でしょう。

社会人1年目として会社勤めの方々においては、就職活動のときには見えていなかった、「実際に働いてみて分かる会社の一面」が分かってきた頃でしょう。そうなんですよね、内側に入り込んでみなければ分からないことはたくさんあります。

（面接時）
「うちの会社はサービス残業なんてないよ」
【入社後】
「定時後の作業は自己勉強だから、残業代なんて必要ないだろ？」

（面接時）
「アットホームな雰囲気でプライベートも仲が良いよ」
【入社後】
「会社の飲み会は絶対参加、社員運動会やボランティア活動も必須だ！」

（面接時）
「年功序列なんて古い制度は無い、実力主義の会社さ」
【入社後】
「入社1年目から完全歩合、売れなければ給料無しだぞ！」

ここまで極端な豹変ぶりをみせるところは稀でしょうが、世の中の過半数以上の企業は多かれ少なかれ、採用面接時には美辞麗句で自社の業務スタイルを着飾っているもの。だからこそ、客観的な視点で労働環境の良い／悪いを評価してくれる組織があったら、つい参考にしてしまうのがヒトの性。ランキングサイトや評価機関、格付け会社が何を言うのか、結構気にしているものです。

しかし、第三者の評価結果も、それが門外漢のトンチンカンで的外れなモノだったら何の参考にもなりません。もしかすると、特定の結論に不当誘導しているのではないか、とも疑ってしまうこともあるでしょう。

インターネットの「信頼できるサイト」というのも、ベリサインのように国際的に信頼されている企業が発行する証明書があるからこそ。各国の国債だって、ムーディースやS&Pのような世界的に信頼されている組織がトリプルAなどの評価を下すことで、調達金利も変わってくるのです。私が勝手な意見を表明したところで、日本の国債調達の金利が変わることはありません。

ところが、私が就職活動について調べていたところ、聞いたことが無い評価サイトを見つけました。

（就活アワード）
http://shukatsu-award.com/

就活アワードの目的とは以下の通りだそうです。

『就職活動において、「いい企業」の定義とは何でしょうか？一言で「いい企業」と言っても、人によってその定義は異なります。そこで就活アワードでは「成長性の高い企業」「働きがいのある企業」「働きやすい企業」「社員満足度の高い企業」の4部門を設け、就活生一人ひとりが求めている「いい企業」を探せる場所をウェブ上で提供することを目指します。企業情報と経営陣・社員の面談をもとに企業を審査し、合格企業を就活アワード受賞企業として就活アワードウェブサイトに公開します。就活アワードを通じて、各受賞企業独自の強みや良さを発信し、就職活動における大きな判断基準となれるように活動しています。』

就活アワードの大まかな流れは下記URLに書いてありました。
http://shukatsu-award.com/about_us/index.html

（申し込み）→（書類審査）＆（社員面談／経営陣面談）
→（評価・選考）→（結果発表）

どうやら企業側の申し込みからスタートするようで、社員面談／経営陣面談もするそうです。その結果、選ばれたのが下記の企業たちとのこと。

（受賞企業一覧）
http://shukatsu-award.com/enterprise/index.php

中小企業がラインアップされています。大手企業は含まれていないのは、このアワードの仕組みを利用しようと考える会社に大企業は含まれず、社長や採用担当の裁量が大きい中小企業だからこそ、こういったサービスを利用しようと考えるのでしょう。

ちなみに、このアワードは2年前からやっているようです。

http://2012.shukatsu-award.com/
http://2012.shukatsu-award.com/2011/

過去2年の方は勝手に大企業を表彰＆ちゃっかり運営会社自身の本業も表彰しちゃっているだけの「誰得」評価でした。本当にどうしようもないアワードだなぁと思っていたのですが、2013年版は世の中に埋もれている中小企業の発掘という点で意味があるかもしれません。

仕事と作業の違いについて、これまでに多くの先人が言及してきました。しかし、仕事の本質を勘違いしている人をこれまでにもしばしば見ており、世間一般では理解している人がそれほど多くないのかもしれません。

そこで今回は「仕事と作業の違いで注意すべきこと」について、私なりの考えを述べ、皆さんにも仕事と作業でそれぞれ意識すべきことは何かを知ってもらいたいと思います。

まず読んでもらいたいのは、数年前に私がエントリーした「仕事と作業の違い」における引用です。

『私たちは普段、仕事という言葉と作業という言葉を同じ意味で使っていると思います。辞書を調べてみると、両者とも似たようなことが書かれているため、なおさら同じ意味で考えてしまいそうです。でも、本当にそうなのでしょうか。

次の２つの例を考えてみましょう。

Ａさんは上司から、下期の経営課題を解決するために必要となる社内システムの改修費用算出を命じられました。Ｂさんは上司から、上期の経営課題のうち、解決しなかったものをリスト化して提出するよう頼まれています。

さて、ＡさんとＢさんに与えられたタスクについて、何か違いが分かりますか？

Ａさんのタスクは、所与の条件である下期経営課題を基にして、システムに求められる追加機能やその費用を、”自分で考えながら”まとめていかなければなりません。Ｂさんのタスクは、所与の条件である上期経営課題に対し、それをまとめるだけ、つまり”自分で考えず、与えられた指示に従って”まとめていけばいいだけです。

私は、Ａさんのやっていることを「仕事」、Ｂさんのやっていることを「作業」だと認識しています。仕事は、その背景にある内容を積極的に理解しながら、新たな価値創出に取り組むものです。それに対し、作業とは、与えられた指示に沿って何かを行うことを意味します。

作業はどんな職場でも必ず発生するものですから、それ自体を否定するつもりはありません。注意しなければならないのは、本来「仕事」であるべきものが「作業」と化していないかということです。

作業と化した仕事は、その成果も薄っぺらで、指示内容を逸脱する状況が発生しても対応することができませんが、本当に仕事をしているなら、指示内容の背景も理解して取り組んでいるはずですから、不測の事態にも臨機応変に対応できるものです。』
http://it-ura.seesaa.net/article/7658672.html

これを読んで、仕事と作業の違いを大括りで分かってもらえたかと思います。ここまでの理解を求めているエントリーはWeb上で散見されますが、それだけを鵜呑みにしてしまうと、他人に迷惑を掛ける仕事をやりかねません。

特に「仕事のやり方」でよく問題になるのは、次の2つのポリシーです。

（1）「やることの背景を隅々まで理解することが仕事をする上で重要だ」
（2）「任された仕事には最善を尽くすべきだ」

１つめの背景理解に関するポリシーはなぜ問題になるのでしょうか。

自分のテリトリーについてキッチリ責任を取ってくれる姿勢が好印象だ、と感じる人もいるかもしれませんが、そのような印象を抱けるのは、対象業務の範囲が限定的な場合に限ります。

IT業界の場合、1ヶ月で数十人以上が参画する大規模なシステム開発プロジェクトはしばしば発生しますが、これくらい大きなプロジェクトになると、プロジェクトマネージャーは末端で行われている内容を細部まで把握できません。1日24時間働き続けても、自分の作業と各チームからの進捗確認、それに重点課題への対応で手一杯です。もし、末端までのすべての内容を把握しようとするプロジェクトマネージャーがいるなら、彼自身が全体のボトルネックになって、プロジェクト全体に多大な迷惑を掛ける事になります。

２つめの最善を尽くすポリシーはどうでしょう。

責任感があって望ましいと考えるのが一般的だと思いますが、これも度を越すと大変な迷惑になってしまいます。

1週間後までに仕上げて欲しい資料があったとして、これを部下に依頼したとしましょう。部下は自分の知識だけでなく、社内の様々なデータを探して、期日キッチリに資料を提出したとします。しかし、提示された資料があなたのイメージしていた内容と大きく異なっていたとしたらどうでしょうか。どうしてもっと早い段階で資料作成の方向性を確認しに来なかったのだ！と思ってしまいますよね。

もちろん、部下の仕事のやり方にアドバイスをするのは上司の務めですから、こういった方向性のすり合わせは率先して上司からも声を掛けるべきではありますが、抱えている仕事量が比較的多い上司が個別に気を回すよりも、個別案件として抱えている部下から問いかける方が効率的ですし、デキる部下というのは、そういうことを誰に言われるでもなくやることができるものです。

ここまでは仕事のやり方における注意点でしたが、続いて作業におけるそれを考えてみたいと思います。

「作業のやり方」でよく問題になるのは、次の2つのポリシーです。

（1）「依頼を受けた内容が適切でないと感じたら、自分なりの改善案を示すべき」
（2）「ルーチン作業といえども、作業前提や手順は毎回精査すべきだ」

これまた一見すると何ら問題のないポリシーに思えますが、それも時と場合によるということを私たちは理解しなければなりません。

１つめの改善に関するポリシーは、作業に対する自主性を持たせるという点で好印象を与える姿勢ですが、それは作業者であるあなたが依頼者の意図を十分に汲み取れているという条件下での話です。

例えば、役職が相当上の人間から依頼される情報収集や資料作成の依頼では、現場の視点からは不合理を感じるような作業を強いられることがしばしばありますが、意外にも経営陣の中で議論するには丁度よい粒度の情報であったりするものです。

一般的に、上司や上役の視点は自分が持っている視点よりも経営側に近く、それゆえ、自分が善かれと思って手を入れた資料が上司の思惑と異なっていた、ということはよくある話です。

２つめのルーチン作業に関するポリシーは、姿勢として好ましいものの、日常的に行われる作業で毎回確認するのは時間の無駄です。

そもそも、なぜルーチンワークになっているかを考えてみれば、これは自明の理。完成されて決まりきった手順で行われているのがルーチン化できている理由であり、むしろどれだけ早く作業を終えることができるのかが求められます。なのに、手順や前提条件の精査に時間を掛けてしまうというのは、確実性と迅速性のバランスの取り方が間違っているとしか言いようがありません。

もちろん、定期的な作業改善の取り組みの中でルーチンワークの改善案を検討することは重要ですが、日々の作業の中でそれを求めてはいけません。

仕事と作業の注意点について、すでに社会人となっている人はもちろん、これから社会人になろうとしている学生や就活中の学生にも是非理解してほしいと思います。

最初に断言しておきます。

「業務ユーザーこそがITプロジェクトの進捗を遅延させる最大のリスクです」

企業における経営層の相当の割合が、「システム開発プロジェクトを仕切るのは情報システム部の役割だ」と考えています。それゆえ、ユーザーである業務側と開発作業を委託するベンダーを結びつける重要な役割を期待して、情報システム部を中心としてPMO（プロジェクト・マネジメント・オフィス）が組成されることになります。

しかし、認識しておきたいのは、システム開発プロジェクトではユーザー側が担うタスクにこそ重要なものが多い、という事実です。特に旧システムから新システムへの移行が含まれる業務改革では、「データ移行」と「受入準備」の２つはユーザー側にも主要なタスクが割り当てられ、それらが実施完了とならない限り、プロジェクトは終わることができません。

こういった重要タスクにアサインされるユーザー側の担当者は兼任者であることが多いです。

兼任者というくらいですから、現業をこなしつつプロジェクト内の作業を担当するという位置づけです。まず100％の工数でプロジェクト作業に従事することはないため、要員計画では一定割合の工数を計上するに留めますが、実際にはその割合さえも捻出されません。

なぜなら、兼任者の作業優先順位は、現業＞プロジェクトになるからです。これは単純な話ですね。兼任者の人事考課を評価するのは現業における上司。現業のタスクを劣後させてプロジェクトタスクを優先させているような部下を高く評価する人はまずいませんから、自己評価を高めるために現業タスクを優先するのは兼任者の自然な心理です。

これに加えて、トラブルに起因する予期しない追加作業が散発的に発生してしまえば、もはや日中にプロジェクトタスクを遂行する余裕なんてないでしょう。その結果、兼任者のタスクはオープンになってからも全然進捗が進まず、気づけばプロジェクトで遅延タスクの常連と化していることでしょう。

この状況を改善するには、現業を抱える兼任者がプロジェクトに参画する際の作業優先順位を明確に定めて、現業の責任者と合意をしておくことが重要になります。これは、兼任者の人事考課にプロジェクトでの活動評価も加えることが必須となることでしょう。

リスク管理こそがPMOの真髄です。バカ正直に各チームの進捗報告を鵜呑みにするだけではプロジェクト管理は成功しません。報告の言外に潜むリスクを顕在化させ、それに向けたアクションへ担当者が取り組める環境を作り上げることに腐心して下さい。それが優れたPMOであり、プロジェクトの遅延を回避する最も有効な方法です。

NTTデータといえば、日本を代表するSIerであり、売上高は2011年3月期で1兆1600億円を超える大企業です。製品を持たずにこの規模を誇っているのはスゴイことですよ。製品を若干抱えるSI主体の野村総研で売上3300億円、富士通のSI部門が8300億円（製品等含むと国内4兆5000億円）ですから、その巨大さがうかがい知れます。

このNTTデータ、国内SIerの頂点に立ち、抱える子会社も数多いことから、会社のロゴシンボルである月見団子のピラミッドは搾取構造を模しているとも、頂点の飛び抜けた○こそがNTTデータ自身だとも皮肉られていたのはIT業界のお約束でもありましたが、ついに企業ロゴシンボルが一新されることになりました。これは、同社が2012年1月からアメリカ地域のグループ会社（Keane、Intelligroup、MISI、Revere、NTT DATA Agile Net、Vertex）を順次統合・再編するからだとのこと。

以下、CNET Japanから引用です。

『2012年1月に「NTT DATA, Inc.」を発足させ、順次米州地域のグループ各社を同社に統合させていき、米州地域では「NTT DATAブランド」で事業展開していく。統合後は1万6000人規模の体制で、顧客に対してインド、カナダのリソースを活用したアプリケーション開発や運用、ERPパッケージ、インフラサービス、BPOなどのサービスからITコンサルティング、スタッフィング、ウェブ開発までを総合的に提供する。

また、今後2012年以降はEMEA（欧州、中東、アフリカ地域）、APAC（アジア、太平洋地域）、中国地域においても順次グループ会社の統合や再編を進める予定だ。NTTデータグループは、一段の成長に向けてグローバル戦略を推し進めており、現在では5万7200人の社員の半数近くの2万6500人が海外拠点で働いているという。

（中略）

さらに、こうしたグローバルな再編を象徴するように、1988年の設立以来23年以上にわたって使用してきたコーポレートロゴデザインも変更する。』
http://japan.cnet.com/news/business/35011686/

NTTデータは23年前に設立された会社なんですよね。もともとは日本電信電話公社（後のNTT）のデータ通信本部として設立された組織であり、1988年に分離独立しています。NTTデータが手がけていた当初案件はこんなものがありました。

全国地方銀行協会システム（ACS、1968年稼動開始）
全国銀行データ通信システム（全銀システム、1973年稼動開始）
気象庁地域気象観測データ通信システム（アメダス、1974年稼動開始）
郵便貯金システム（1978年稼動開始）
社会保険システム（1980年稼動開始）
共同利用型クレジットオンラインシステム（CAFIS、1984年稼動開始）
都銀キャッシュサービス（BANCS、1984年稼動開始）等

こうした会社が、気づいたら社員の半数が海外にいるというグローバルカンパニーになっていたというのは感慨深いです。

話を戻しますが、現在のNTTデータのロゴシンボルは、ITカースト制度を表したものだとも、少し離れた頂点の○がNTTデータを示し、2段目はNTTデータ子会社、3段目は他社の中堅下請け、4段目はさらに小さなソフトウェア会社の下請けを意味する、なんて解釈がされていたりもして、IT業界の住人にとってはいい酒の肴だったのですけど、それがなくなってしまうのは寂しいですね。

＿＿＿＿０ ←元請け：NTTデータ本体（例：1億でカスタム開発受注）

＿＿＿０ ０ ←1次下請け：子会社（元請けから6000万円で受注）
＿＿０ ０ ０ ←2次下請け：他社（1次下請けから4000万円で受注）
＿０ ０ ０ ０ ←3次以降：中小ベンダ（2次下請けから3000万で受注）

IT業界の多重請負は社会的な問題にもなっていますが、これは、官公庁や大手企業のプロジェクトでは月当たりで100人以上を投入するものも珍しくないことと、それだけの大人数を1社で賄うことが難しいという人の調達問題が主な原因です。

例えば、「今月リリースされる人員は100人だが、開発案件受注が好調で来月必要になる人員は150人が必要になる」というケースでは、来月に50人のリソースが純粋に不足しますよね。この50人を手っ取り早く賄うのが、2次請け以降の下請けベンダーなのです。この仕組みが多重請負による不適切な指示系統と仲介ベンダーによる鞘抜き問題を引き起こすのですが、ITバブルまで右肩上がりで急拡大をしてきたプライムベンダー（1次請け）にとって、この構造がなければ、プロジェクトを仕切ることができる人材を確保しつつも大量の案件を捌くことができなかったと思います。

参考として、Tech総研に元請けと下請けの給与格差に触れた表から内容を抜粋します。
http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=000962

・元請け：（プライムベンダー）
→ 20代後半 年収500万円くらい
→ 30代後半 年収690万円くらい
・1次下請け：
→ 20代後半 年収460万円くらい
→ 30代後半 年収650万円くらい
・2次下請け：
→ 20代後半 年収440万円くらい
→ 30代後半 年収560万円くらい
・3次下請け：
→ 20代後半 年収410万円くらい
→ 30代後半 年収550万円くらい

見ての通り、プライムベンダーと比較すると、1次請け以降は収入面で開きが出ています。特に管理職となった以降の30代後半では、プライムと3次下請けの年収が3割程度も差が開くという状況です。それだけ、プライムベンダーの利益率は高いということなんですよね。

プライムベンダーは、受注するまでの営業力／受注した後の実行力の双方が問われます。特に後者は、プロジェクト全体を俯瞰しながらクライアントの要件をまとめて各種作業の頭出しをしていくことが求められるため、システムそのものを実装する力（プログラム開発やパッケージ製品の設定作業）とは問われる能力が異なり、それゆえ、下請けの仕事ばかりを引き受けてしまうベンダーは、プライムベンダーに必要な能力を確保し続けることが難しいという事情もあり、先に示した給与格差はなかなか埋まりません。

なお、経産省が調査した「特定サービス産業実態調査」からローランド・ベルガーが作成した日本のIT業界の概要が、ITmediaにて次のように紹介されていました。

＿＿＿＿０ ←（1）超大手プライムベンダー：5社

＿＿＿０ ０ ←（2）1次下請けorプライムベンダー：6社
＿＿０ ０ ０ ←（3）1〜2次下請け：150社
＿０ ０ ０ ０ ←さらに下請け：13000社

（1）富士通、NEC、日立、IBM、NTTデータ
（2）NRI、UNISYS、ITホールディングス等 売上3000億円以上
（3）大手グループ会社や中堅IT会社 売上100億円以上

分り易すぎる構図です。特に超大手プライムベンダーに位置づけられているのは、いわゆるメインフレーマーというメインフレーム開発運用を手がけるベンダー各社であり、メインフレームを1つ納品すれば、初期投資で100億円、その後の保守メンテナンスで毎年数十億円の売上が見込める世界です。

一方、オープンアーキテクチャによる案件も多数かつ絶対金額も大きいため、全体的に見れば、（1）と（2）で能力の差があるわけではありません。展開しているクライアント企業への面の広さが売上差の違いだと理解しておけばよいでしょう。

NTTデータのような個性的なロゴシンボルが消えてしまうのは残念ですが、新しいステージに向けてどんな動きをするのか、今後の同社の動きに注目したいと思います。