はじめに

私は、アメリカ、フランス、韓国などの各IT企業と日本のIT企業にこれまで関わってきた。　その中で、日本のIT企業特有の非合理性や非効率さを、目の当りにしてきた。　これまではそれでも日本国内だけでビジネスとしてやってこれたが、これからはグローバル競争の時代になる。　生き残るためにはかなりシビアな環境になってきたことは、明白だ。　

私は、これまでの経験を通じて、日本のIT企業の課題を浮き彫りにすると同時に、どのように改善していくべきか、それを論じる。　論点を明確にするために、アメリカではこう、日本ではこう、等と言う形で一般化した表現が多いことを許されたい。　実際には企業によっての違いもあるし、一概に言えない部分もあるが、大まかなレベルではある程度の真実をとらえているはずである。　

そして、この本の主旨は日本のIT企業に欧米企業になれ、ということではない。　欧米企業の行き過ぎた合理性も大きなひずみを生んでいる。　広く外のIT企業の文化を学び、日本企業の良い部分は大事にして、真にIT企業のあるべき姿を描き出すのが本書の目的である。　最後に、私のIT企業の経験のほとんどは、金融業界におけるものである。　金融業界におけるシステムの特徴として、システムの規模が大きい、条件がシビア、そしてシステムへの投資額も大きいという特徴があり、このような分野でシステム業界に関われてきたということは、得難い経験だった。

SEという職業

私は、2002年に日本に帰国した。　帰国することだけを決めて、転職先を決めていなかった私は、とりあえず一時帰国して、日本で仕事を探そうと思い、まずはリクルート社に足を運んだ。　私の担当コンサルタントA氏は、私の履歴書にざっと目を通すと、こう切り出した。
「あなたはずっとITをやっていたんだね。　なら、あなたはSE（エス・イー）志望ということでいいですね？」
私は混乱した。　SEという単語に慣れていなかったのだ。
「SE、ですか？」
「そう、SE。」
A氏は、当然だよね、という態度である。　その頃の技術者にありがちな引っ込み思案だった私は、とてもSEが何かとは聞き返せなかった。　ただ、SEとはシステム・エンジニアの略称だろうと思い至ったので、
「はい、SE志望です。」
と答えた。　アメリカにおいては、システム・エンジニアとはコンピュータプログラマの会社における肩書きにすぎない、つまりSE＝プログラマ、だと私は思ったのだ。

その時は、私は自分の思い違いに気付かず終わった。　私は結局一時帰国中には転職先は決めず、米国に戻ってから、たまたま縁のあった、米国のベンチャーソフトウェア会社に就職することを決めたからだ。　そしてその会社の日本法人の立ち上げのために、日本に帰国してから、私は再びSEという言葉と再会し、真の意味を知ることになる。

とあるプロジェクトで、私の扱っているソフトウェアを導入してもらえることになり、某国内大手IT企業B社とパートナーを組んでその顧客に導入を始めた。　B社の担当SEは非常に頭脳明晰で、しかも人柄も良く、私はすぐに彼と親しくなった。　ところが、ある日、彼と話をしている最中に、彼がぽろっと言った一言で私の目は丸くなった。
「僕、あまりプログラムを書いた経験がないんで、自信がないんですよね・・・・」
「えっ、でもあなたはSEですよね？」
「はい、そうです。　でもSEはプログラムを書くわけじゃないんですよ。　私は入社当時にJavaを1年程研修で勉強しただけで、すぐにSEになったので・・・」

SE=プログラマではなかった！　これは大きな衝撃だった。　後々わかったことだが、日本ではどうやらプログラムを書くことは、卑しい仕事らしい。　優秀な人はプログラムなんか書かず、SEになって、それ以外の付加価値の高い仕事をしなさい、ということ。　これでは優秀なプログラマが育つ土壌がない。　アメリカでは、プログラマは優秀であれば、技術職としてきちんと評価された。　そして企業のITマネージャーやCTOなどの技術系管理職の人間には、プログラマとしてある程度経験を積んだ上で、対人コミュニケーション能力や、マネジメントに秀でた人間も多い。　

日本では、優秀な人材程、プログラマという下積み経験が少ない人が多い。　これは、実際にシステムの導入における決定権を持つ人が、往々にしてシステムについての知識が欠落していることを意味している。　結果として、日本においては、なぜこの程度のシステムに、これだけお金がかかるのかわからない、というプロジェクトが多い。　自分である程度プログラムを書いたことがなければ、システムの開発にかかるコスト規模を図る方法などなく、このような状況に陥るのだ。　私は、日本でこのような事例を数多くみてきたし、同じようなことを他のエンジニア出身の人間からも時々聞く。

結論から言うと、日本のIT企業は、プログラマを軽視しすぎている。　プログラマを劣悪な環境で、卑しい仕事として扱う限り、質の良い技術者は集まってこないだろう。　

会議室の怪

ニューヨークで、債券システムの開発の仕事をしていたころ、私は7人のチームの一員としてプログラムを書いていた。　そのチームでは、全員が集まるミーティングは一週間に一度あるかどうか。　そして、ミーティングは、特に話す必要がなければ、10分程度で終わることも多かった。
"So, do you guys have any issue or topic to bring up for the current task?"
と上司が聞く。
"Ok, I have one question. How can I do this task?"
と一人が質問をする。
"Well, you can try this way or that way..."
上司が答える。
"Anything else? No? Ok, then meeting is over. Let's get back to work."
と言って、チーム全員は、さっと自分のパソコンに戻り、黙々と自分の担当しているプログラムに向き合う。

アメリカでは、ミーティングは中身ありき。　中身のないミーティングで時間をつぶすことは悪だった。

日本では、その逆。　よくある情景として、
「今何時？　お、あと15分あるね。　それじゃあついでに次のトピックについても話し合おうか」
という流れで、1時間なら1時間ミーティングのために使い切ることが多い。

あるとき、気づいたことがある。　外資系企業を訪問すると、会議室は常に空いている。　もし会議室が空いてなければ、近くの喫茶店でもどこでも必要なミーティングなら行う。　日本企業では会議室はよく埋まっている。　さらに下手すると会議室が無いという理由で、ミーティングの日を先延ばしする。

ちなみに、外国人にとって、日本におけるミーティングで驚くのが、ミーティングに出席する人数だ。　沢山の人間が参加するのに、実際にしゃべるのはたった一人だったりする。　まあ、これは日本だけではなく、アジアではまだよくみられる光景でもあるのだが。　

会議、会議で、えんえんと時間を使う。　疲れる。　集中力が切れてくる。　仕事が終わらないので残業する。　家族との時間が減る。　モチベーションが下がる。　悪循環が起きている。

エンジニアの質と数

あるとき、某大手金融機関で、大規模なシステム障害が起きた。
新聞では、その金融機関のシステムを構築した某国内系大手IT企業が、SEを確か60人ほど投入して問題の解析にあたる、と報じていたのを記憶している。
ITを熟知している人間は、このような報道に対して違和感を覚える。　なぜなら、ソフトウェアシステムの質は、関わった人間の総数に「反比例」することが常だからだ。　人数が沢山いれば、良いシステムができるのか。　答えは、否である。　沢山の人が関わる程、人間同士のコミュニケーションミスが起こりやすく、また人数が多いということは、玉石混交を意味する。　本当に技術力のあるエンジニアは、数が少ない。　

だから、「このプロジェクトにSEをXX人投入しました」というような話を聞くたびに違和感を覚えるのである。

ちなみに、私のアメリカ時代の上司の口癖は、
「できるエンジニアは欲しいが、天才はいらない」
だった。　天才と言われる人間はえてして、チームで仕事をする現場では、邪魔になってしまうことも多いということだ。

ここで言いたいことは、エンジニアの数ではないよ、ということだ。　その時の状況やシステムによっては、人数が多く必要なこともあるだろう。　しかし、適材適所と、人数信仰は根本的に違う。

買収の結末

私は、ある欧米のソフトウェアに、一時期関わったことがある。　

ソフトウェアを扱ってみて、いろいろと開発元の会社に確認をして唖然とした。　製品を良く知っているエンジニアがほとんど社内にいないのだ。　

「なんで、こんなことも答えられないの。　こんなのソースコードを見たら、すぐわかるじゃないか」、と言っても
「えー、とにかく時間をください。　調べますので」
と言ったっきり、返事が全然かえってこなかったり、二人のエンジニアに聞くと、二通りの全く異なった回答が返ってきて、どちらが正しい製品の情報なのかわからない。

こんなことが続いた。　まだ開発したてほやほやの製品なら、ベータ製品ということで理解もできる。　すでに100社以上が世界で導入している有名なソフトウェアなのに、この質とサポートはどういうことなんだ。

そして理解したことだが、この会社は数年前に大手IT企業に買収され、買収によって、もともといたすばらしい技術者は皆いなくなってしまったということ。　残っていた優秀なエンジニアも、このソフトウェアより他のソフトウェアの方が利益が出るからと言う理由で、リソースとして別プロジェクトに移動させられたりするうちに、やる気を失ってやめていく。　当然だ。　エンジニアからすれば、ソフトウェアは、大事に開発してきた自分の息子のようなものだ。　それをある日いきなり儲からないから、という理由で、引き離されたら、やる気を失ってしまう。

エンジニアを単なる「リソース」として扱う。　こういう文化の中で良いシステムができるだろうか？

Work Life Balance

アメリカ時代の上司の話に戻る。　この人は、アランという名前で、エンジニアとしてはA級のエンジニアだった。　大規模で複雑なシステムが全部頭の中にきちんと整理されて入っていて、どんな複雑な問題に対しても、かならず回答を導き出した。　そして、プログラミングを彼は心から愛していた。　彼は管理職ではあるが、少しでも自分でプログラムを書きたいという人で、私が何か問題に突き当たって彼に質問をしなくてはいけない時、彼に
「Hey Alan. Do you have a minute?]
っていうたびに、彼がいかにもいやいや没頭していたコンピュータ画面から目を離すので、私は彼にくだらない質問を絶対にしてはいけないと思っていたものだ。　そして、この人に出会ったことで、私は、自分はエンジニアとして一生は送れないなあ、と思ったものだ。

アランは、ニューヨークから電車で1時間くらいの郊外に、奥さんと3人の子供との五人家族で住んでいた。　そして、会社には週三日出社してくる。　あとの二日は家から仕事をする。　家の仕事を手伝ったり、子供を学校に送ったりしながら、その週にやるべきことはすべて終わらせてくる。　電車の中が、一番誰にも邪魔されずにプログラムを書ける至福の時間なんだ、と笑っていた。　見事に仕事と家庭の両立をしながら、すばらしいシステムを構築していた。　これは1997年の頃だ。　日本もワーク・ライフ・バランスをどう確立するのか、そのことに真剣に向き合う時代になっている。

もう一つ、話をする。　私の顧客の一つのフランスのIT会社は、本社が、パリではなく、地中海に近い、観光地に本社を置いてあり、それを聞くとお客さんは皆びっくりする。　え、パリじゃないの？って。

本社を訪ねると、一年の300日以上が快晴というすばらしい天気と、森に囲まれ、広い芝生の真ん中に会社がある。　窓はすべて大きく、採光がすばらしい。　昼になると、技術者の奥さんが子供を連れて会社にやってきて、みんなで芝生に設置された木のテーブルでランチを楽しむ。　

CTO（技術の最高責任者）に、なぜこんな場所を本社にしたのか聞いた。　
「うちの会社のシステムはとても複雑で大量の金融取引を処理するので、責任も重大だ。　だから、エンジニアには最高の環境を提供しようと努力している。　非常に高度な集中力を要するから、こうやって、リラックスした環境で仕事をしてもらうことにより、最大限の生産性を発揮してもらっている」

とのことだった。

なぜ外資系ソフトウェアパッケージが評判が悪いのか

日本においては、外資系ソフトウェアパッケージというのは、非常に評判が悪い。　何故悪いのか？　そもそも、導入すべきではない粗悪なパッケージを導入してしまう、という根本的なケースがある。　これは完全に日本の金融機関の調査不足、情報不足だ。　日本では、実績ということを非常に重視する。　海外で沢山の導入事例がある、とか、日本国内での導入実績がある、と聞くと、それだけで大した調査もせず、それなら良いソフトウェアに違いないという安易な結論を出して、あとで痛い目を見ることが多い。　

なぜ調査をがんばらないか、というと、他のユーザですでに実績があるものを導入するのだから、大丈夫だと考えた、という言い訳が立つからのようだ。　そして、そもそも外資系のソフトウェアを検証するだけの、技術力を持っていないというケースも多々ある。　技術力があるなら、わざわざ外資に頼る必要もない、という鶏が先か、卵が先かという話である。　

さらに情報収集能力と言う意味で言うと、欧米人は非常に個人レベルでのネットワーキングが盛んだ。　気軽にコーヒーショップで、情報交換をしたり、仕事帰りにバーで一杯飲みながら情報交換をする。　そういうネットワーキングの中で、「このシステムを導入しようと考えているけど、評判はどう？」という話をお互いする。　そして、ベンダにも定期的に会って、情報収集を怠らない。　日本の金融機関も、もちろんそういうことはしている。　ただ、前述の多すぎる会議や非効率な仕事のやり方などにより、忙しすぎて、なかなか十分な時間が取れていない、ということもある。　そして、近年のコンプライアンス、情報統制により、このような個人間の情報交換はさらに難しくなっている。　

そして、欧米では、転職がさかんなことによって、転職によって入社した者から、その前職の会社で使用されていた会社のシステムに関する良し悪しなどの情報がもたらされる。　もちろん、会社の情報が流れることになるので、諸刃の剣ではあるが。

なぜ外資系ソフトウェアパッケージが評判が悪いのか　～　その２　～　外資系日本支社長の心構え

外資系ソフトウェアパッケージの評判が悪い理由の2番目として、そのソフトウェアの開発をしている外資系企業の日本支社長の在り方に起因することも多い。　本社の顔色をうかがってばかりいるような支社長だと、本社の言うなりに、なんでも日本で売ろうとする。　そして、クォリティが悪くて、売るべきではないソフトウェアを導入する羽目になったり、本来外資系ソフトウェアを導入すべきでないような案件に対しても導入してしまい、ユーザーがひどい目に合う。　そしてユーザーが怒ってクレームを出しても、ぺこぺこ謝るか、もしくは本社の威を借りて開き直るか、そんな対応しかできない。　こういう日本側責任者の在り方が、外資系ソフトウェアの評判を落としていることも見逃せない。

私は、日本支社長のあるべき心構えとして、まず、いつでもクビにしてください、という覚悟で仕事をすることだと思っている。　本社からいくら売れと言われても、売ってはいけないものは、売るべきではない。　それでも売れというなら、いつでも自分は辞める準備がある。　そういう姿勢がないと、本社のいいなりにならざるを得ない。　そして、もちろんそういう覚悟に意味があるのは、それなりに結果を出して本社にも信用される必要がある。　全く売れない支社長であれば、本社としてはさっさと解雇して次の人を雇うだろう。　

そして、同時に、お客さん側に完全に立つことも良くない。　日本ではお客は神様、という文化がある。　そういうところから、ベンダとしてお客さんの要求を全部呑んでしまうと、本社からは、お前はお客の肩ばかり持ちすぎるということになり、信用を失う。　信用を失うと、お客さんの声を本社に届けることができなくなる。

日本企業同士でもインターフェースとなる人間のこのような心構えは大事だと思う。　ましてや、外資系企業と、日本企業の間で、長期的な友好関係を結ぶのは、容易なことではない。　日本支社長というのは、クビになってもいいという覚悟と相応の結果、そしてバランス感覚が要求されるポジションだ。　

なぜ外資系ソフトウェアパッケージが評判が悪いのか　～　その３　～　適切な交渉

大手証券会社から、「外資にやられた・・・」という声を聞く。

外資系ソフトウェアをとんでもない高値で購入し、仕方なくそのまま使い続けているが維持費もバカにならない。　そんな話はごろごろある。　

金額の交渉において、日本企業は、よく外資の提案を鵜呑みにしてその値段をベースにちょこちょこっとネゴをしただけで購入してしまう。　外資としては、あ、その値段でいいんだ、それならラッキーだね。　ということに、なる。　外資が皆そうというわけではないが、要は購入する側の自己責任なのだ。　日本人は、とくに外国人が相手だと、主張すべきところで主張せず折れることが多い。

交渉をきちんと行い、適当なソフトウェアを適切な条件と値段で購入しないと、あとあと、不平等感が残り、不信感としてそれはその後の両社の関係に影を落とす。　だから、単に得した損したの域を超えて、きちんと交渉し、お互いがすっきりと納得する条件と値段で購入することが大事なのだ。

だから日本企業側の担当者も、いつでも外資企業に対して、”NO"を突き付ける覚悟も必要だ。　その覚悟を持たずに交渉を始めると、もともと交渉達者が多い外国人にすぐに足元を見られ、交渉に置いて押し切られてしまう。

なぜ外資系ソフトウェアパッケージが評判が悪いのか　～　その４　～　現場との乖離

日本のある程度大きな会社では、現場と意思決定者の間に、乖離が生まれていることが多い。　システムの知識があり、社内でソフトウェアを利用する業務ユーザのニーズも把握できている現場の担当者は得難い存在だ。　しかし、彼らにソフトウェア導入の決定権はないことが多い。　どのようなシステムを選定するかの意志決定は、しばしば現場を知らない、システムや業務も良く理解できていない人によって行われる。　このような現場と意思決定者の乖離は、欧米企業でももちろんあるが、日本企業のほうが顕著のように思える。　そもそも、システムを開発した経験が十分にある人間が、上層部に少ないのだから当たり前と言えるだろう。

現場の担当者の話を聞いていると、

「なぜうちの会社は失敗するのわかってて、あのソフトウェアを導入するんだろう。　一度他の部門で使って大失敗をした経験があるじゃないか？」

「こんな非合理なシステムの組合せをしている会社は他にないよ。」

もう導入する前から、失敗することがわかっているのだ。

そんなシステムを導入しなくてはならず、そして導入でいろいろなトラブルや障害があると、一番苦労をするのは現場なのだから、浮かばれない。

なぜ外資系ソフトウェアパッケージが評判が悪いのか　～　その５　～　石橋を叩いて渡る代償

外資系のIT会社はレスポンスが遅い！　という意見を聞く。

一つは、単にその会社のサポート体制がそもそもよくないということもある。
もしくは、時差の関係や、欧米の休日、担当者の長期休暇などによって、レスポンスが遅れるケースもある。
そして、英語が苦手な日本人に、いちいち翻訳をしなくてはいけないという手間もある。

そういった理由とは、別にもう一つ大きな理由がある。 日本企業は安定しているかどうかのリスクを一番気にするため、なるべくソフトウェアの最新版ではなく、2，3世代前のバージョンを導入することが多い。

ところが、外資系ソフトウェア会社としては、通常開発チームの主力は一番新しいバージョンのソフトウェアに投入されている。　当然だ。　そして、なるべく旧いバージョンに、今更手を加えることはしたくない。　だから、日本のユーザから旧いバージョンに対して、いろいろ機能追加をお願いされても、及び腰になりがちだ。　

また、そもそも旧いバージョンのメンテナンスを行うのは、どちらかというとエンジニアの中でも、主力ではないことも多いから、そもそも知識不足や技術力が不足している場合もある。　エンジニアにとって、旧いバージョンのお守りは一番やりたくないことだからだ。

ソフトウェアは建物ではない

リクルートの担当者の話に戻る。

私がSEです、と答えたら、彼は、「それならまずはここの5社の面接を受けてください。　そして、もし全部駄目だったら次にこれらの10社の面接を受けてください。」と言った。

これも、当時の私からすると、「え、なんで？」という印象だった。

要するに、日本におけるシステム開発は、全て元請けがあり、その下にぶらさがっている、中請け、下請けなどの企業が沢山あるということで、彼は親切としてまずは元請けを受けなさい、と言ってくれたのだ。

アメリカでももちろんこういうケースはあるが、完全にケース・バイ・ケースである。　

なぜ、日本はこういう仕組みが定着したのだろう、と考えた私の結論は以下の通りだ。

①　これは建築業界と同じ仕組みだ。　つまり、日本においては、建物を作るのと、ITシステムの構築が同じようにとらえられているのではないだろうか。

②　日本では誰が責任を取るのか、と言う時に、客は責任を取らない。　あくまで業者に責任を取らせる。

こういう文化、概念から生まれたのだろうと推察する。

しかし、このような仕組みは、ソフトウェアの開発には必ずしもそぐわない。　理由としては、

①　一つのシステム構築に関わる人の数が多くなる。　これは、ソフトウェアのクオリティに反比例する。

②　客と業者、という上下関係では、真のパートナーシップは生まれない。　業者は、本当に良いシステムを提案しようとするのではなく、ただの御用聞きになってしまう。　

③　元請けは開発をしないので、システムの詳細知識がないし、下請けは全体像がわからない。　これでは、システム障害時の対応にも時間がかかる。　また、下請けのプログラマは、仕事が面白くないので、他の業界や会社に移ってしまうという離職リスクを高める。　そしてより良い仕事をしようというモチベーションに対する阻害要因ともなっている。

納期を守る

私は、とある非常に要件の厳しいシステム開発に、プロジェクトマネージャとして参加したことがある。
そのプロジェクトは、東京証券取引所のようなシステムをわずか6ヶ月で突貫工事で作るというものである。　そのために外国の精鋭エンジニアが集められ、中核メンバー7人で開発が行われた。

システム完成まで2ヶ月ほどと迫ったころ、外国人のエンジニアから、システムのリリースを2ヶ月伸ばしたほうが、システムとして安定するので、そうしたいという提案があった。　聞くと技術的にもっともな話なので、私から日本の顧客に対して説明を行ったが、顧客側担当者の回答は、機能は削っても構わないから、納期に完成させてほしいということだった。

納期に完成させてほしい理由を聞くと、「いや、納期は納期で、上にもそう説明しているから」というだけ。

納期を守る重要な理由があるなら理解できるが、そのような漠然とした理由で、せっかくあと2ヶ月かければ、数段良いものに仕上がるのを、逆に機能を削るなど、その頃の私にとっては理解しがたい話だった。

日本の企業は、とにかく納期にこだわる。　たしかに、それは大事なことだ。　しかし、納期を守ることがかならずしも、最良の選択とは言えないこともある。　その判断ができないと、折角大金を投入して作ったシステムが中途半端なシステムとなり結果としてユーザにとって不満が残るシステムになってしまう、そんな話がごろごろある。

ソフトウェアの理念と魂

私の扱っていた、アメリカのソフトウェアの開発会社には、Benというエンジニアがいた。　彼はそのソフトウェアを開発当初から関わっていて、彼さえいれば、どんなに難しい技術的な問題やシステム障害も、クリアできるという人だった。　私は、お客さんに良く言っていたものだ。

「Benがこのソフトウェアに関わっている限り、安心してください」

Benはこのソフトウェアの良心であり、魂なのだ。　このソフトウェアが世界にユーザを拡大しつつもだんだんと旬の時期を過ぎ、エンジニアがどんどん転職していく中で、Benだけはこのソフトウェアに関わり続けていた。

こういうソフトウェアは強い。　5年間で30社以上のユーザに導入をさせていただいたが、障害らしい障害はその5年間で2件だけだった。

フランスのIT会社にはまた別の意味で感心させられた。　会社設立時からこういうソフトウェアを作ろうという理念があり、理念を曲げずに14年間やってきた会社だ。　私が、お客さんがこういうものだったら欲しがっているからどうだ、と聞いても、「いや、それはうちがやるべきことじゃない」と言われたことが何度もある。　お金になるならなんでもやるという会社が多い中、理念をとても大事にしている。　そして理念を本当に実践しているかどうかは、お客さんにも伝わっているものだ。　こういうソフトウェアは、本当にすばらしいものだ、という風に営業マンも自信を持ってお客さんに薦めることができる。

キャリアを考える

私がコンピューターの勉強を大学ですることを決めたのは、アメリカにいたということも大きいと思う。　アメリカは、日本よりずっと個人主義の国だ。　社会が優しく助けてくれるわけではない。　そしてましてや外国人である、ということで仕事を探す上では不利だ。　だからこそ手に職をつけておく必要を、高校生のころからすでに感じていた。　

そして外資系の会社で働くようになって、それこそいろんな経験をさせてもらった。　自分の働いていた企業が倒産した経験一回、買収された経験が4回。　上司は8年間で、7人以上変わった。　別にこれは珍しいことではない。　大量解雇や、買収、倒産、そういうことがごく身近なアメリカでは、常に社員は自分の価値を高めることを考え、何が起こったとしても、すぐに次の仕事が見つかるように、というスキルアップを心がけている。

私がなぜこんな話をしているかというと、日本のIT企業は、あまりにも社員数が多いからだ。　数年前ある大手証券会社の常務と話をしたことがある。　その会社が、外国のソフトウェアシステム企業に年間50億円の支払いをしているときき、そのシステムの利用されている事業範囲をみたとき、どう考えても高額すぎるので、そんなお金を使うべきではない、と言いたくて話をしに行った。　私は会社の上層部が、このような無駄遣いを知らないのだと思ったからなのだが、案に相違して、常務は知っていた。
「その通り、そのシステムはあと数年以内にこの会社からは消えるだろう。　ただし、うちの会社にとって、今最大の問題は、そのシステムの費用じゃない。　700人いるIT部隊なんだ。」
と言っていた。　それを聞いたとき、私はうーん、なるほど・・・・と思わざるを得なかった。

これから、日本のIT企業が生き残っていくためには、収益を確保し続けるか、もしくは合理化していくしかない。　そういう厳しい時代だからこそ、企業は社員のキャリアの事を真剣に考え、ITならITを本気でやる、ITを一生やる気がなければ、他の選択肢を選べるように、機会を与えたり、訓練したり、意識を高めたり、していく必要がある。　そして企業自身も社員の活躍できる場をどうやって提供できるのか、柔軟に活路を求める必要があるだろう。　一人一人が真に価値のある仕事をできる企業になれば、社員は活き活きとして創造性を発揮するし、それは顧客にも伝わる。

あるべき日本のIT企業像

つらつらと書く中で、すでにIT企業のあるべき姿について伝えさせていただいた。　今はグローバルな競争の時代。　いろいろな国のいろいろな企業の良い所をどんどん吸収していくこと。　そして、常にこれでいいのだろうか、と省みて、改善し続ける姿勢が企業にも個人にも求められている。　しかし、省みるということは本当に難しい。　一度こうだと形を決めたら、その形を崩したくないのが人間の気持ちだ。

それでも、行動し、省み、新しい形を作り、発展していく、そういう企業だけが生き残っていくのだろうと思う。

大きな方針としてまとめるならば、

①　IT企業自体のアジャイル化。　短期間のスプリントで、新しいアイデアを考え、実証し、結果を見る。　結果を見て、また改良し、新たなスプリントを行う。

②　エンジニアにすばらしい環境を提供する

③　ワークライフバランスの面で大胆な改善を行う。　ただし、結果を検証する仕組みを創っておくこと。　責任はきちんと取れることが必要。

④　会議は、必要なだけ、必要な人数で行う。　

⑤　中核となるエンジニアを大事にする。　

⑥　顧客と真のパートナーシップ関係を構築する

⑦　プログラムを書くことを推奨する。　

⑧　新しいアイデアや技術に挑戦し続ける。　

ここで書いていることは常識的なことが多いと思う。　でもどれだけのIT企業がこういった、言わば当たり前のことを実践できているだろうか？　

そしてこういう改革を断固として行っていけば、非常に良いサイクルが生まれるだろう。　エンジニアが就職したい会社になる。　そして製品のクオリティがあがる。　そして顧客満足度が向上する。　受注が増える。

パーソナルコンピュータからクラウドコンピューティングへ

私が高校生だったころ、メインフレームと端末というものに触れる機会がった。　
そしてパーソナル・コンピュータの発展と一緒にIT産業に関わりながら、いつしか、ネットワークのスピードが十分に速くなれば、またメインフレームと端末という時代に戻るのだろうと思うようになった。　そして実際にクラウド・コンピューティングの時代がやってきた。　

パーソナルコンピュータが、時代の最先端ではなくなりつつある今、世界的にITエンジニアの需要は減るだろう。　クラウドコンピューティングでは、少数精鋭の技術者で、大量のユーザをサポートできる。　ましてや、そもそも数が多すぎる日本のIT企業と抱えるエンジニアは、どこに行けばいいのか。

もう遅すぎるくらいだが、今から大転換が必要となる。　これからは、IT会社、そしてエンジニアの一人一人が、ただ言われるままに、開発をしているだけでは、会社としても、エンジニア個人としても厳しい時代になるだろう。

今すぐできることとして、提唱するのが、以下のことだ。

①　合理化によって時間を捻出する。　あまりに忙しいと、会社や自分の置かれている状況や今後を省みる時間がない。　そして、自分を磨く時間もない。　まずは、英語力を磨く。　英語のできるITエンジニアはまだまだ現在では需要が高い。　これからはサバイバルになる、当然英語くらいは勉強する。　

②　分社化し、責任の範囲を絞る。　要は自己責任と言う文化を根付かせる。　エンジニアとしても、会社がいつまでもつかはわからない、最悪のケースを早い段階から意識、覚悟しておくことは大事だ。

③　積極的にネットワーキングを行う。　会社や国、業界を超えた交流を促進する。　その中で、いろんな情報が手に入る。　そして、これからは、厳しい時代なのだから、信頼できるネットワークを構築することで、お互いに助け合って、一緒にがんばるということも可能になる。　こういうネットワークを会社としても、個人としてもどんどん広げていくことを推奨する。