IT産業で経験したこと　＜第1期　エンジニア時代＞

IT業界で進行していることや政治・歴史・社会についての意見などを述べていきたいと思っており、その前段として自己紹介を兼ねて自分自身の過去の歩みなどをご紹介させていただきたい。

大学を卒業して仕事に就いてからの人生は、第1期ソフトウェア開発エンジニア時代、第2期IT産業アナリスト時代、第3期IT企業立上げ屋時代、そして第4期海外時代とに分けられる。

まずは、1986年から1998年までの12年間（第1期ソフトウェア開発エンジニア時代、第2期IT産業アナリスト時代）のIT業界での経験とそこで考えてきたことについてまとめてみる。

＜＜第1期　エンジニア時代＞＞

1．　手作り弁当時代

僕は、1986年に法学部を卒業し、中堅のソフトウェア開発会社に入社した。80名ほどの社員を抱えた、当時日本最大手のシステム開発会社であったCSKの部長をされていた方が独立し、創業された大阪本社の会社だ。多くの仕事は孫請けとして入ってきた。僕は、IBMメインフレームのPL/1およびCOBOLのプログラマーとして、在職中に3つのクライアントのシステム開発に携わった。それらのクライアントは大手企業、M電工、F銀行、そして最後のプロジェクトは東京都の病院であった。

僕は、この会社に入社するまでにコンピュータというものを触ったことが無かった。1年間ほどワープロ、といっても液晶に3行くらいしか表示できない製品（でも当時はそれでもハイエンド機だった）を使っていたくらいの経験。ところが、通っていた大学の英米法の田島裕教授から判例や法律をデジタル化しキーワード検索できるように入力が始まっていると言うことをお聞きしたものだから、「今後はコンピュータを使えないと何もできなくなるなあ」と思い、ならばというのでソフトウェア開発会社に就職したわけである。本当は研究職に就きたかったが能力が足りなかった。

性分として「その他大勢」になるのが嫌だったことと、同じ大学の卒業生が就職するIBMや富士通などの大企業だと、同じ部門で同じ業種のシステムにしか携われないのではないかと思い、小さな企業でいろいろなシステムを経験したく、この会社を選んだ。

入社すると約2ヶ月間の研修があることになっていた。コンピュータの基礎知識とCOBOLというコンピュータ言語の習得だ。最後には、8問のブログラム作成を終えて終了と言うことになる。講師は2人の先輩。1週間たって僕はクレームを言った。あまりにもカタカナ英語が多すぎて、しかもすでに知っていることが前提のような質問が飛んでくる。「先輩、カタカナ英語を当たり前のように使用するのは止めてくれませんか。だってそれでユーザーさんたちはおわかりになると思えません。それらの言葉をわたしたちに分かるように説明できないのなら、それは先輩たちがご理解されていないということではないでしょうか？」とため口。

この業界は異常だと今でも思う。たとえば、クラウド・コンピューティングがトレンドになっているが、Amazonが提供しているAWSというクラウドサービスを勉強なさってみてください。なんと、日本語がどこにあるか分からないくらいのカタカナ英語が使われている。それを講演会や講習会で平気で使っておられる。これで本当にいいのだろうか。

これは大事なことだと思う。明治維新が短期間で「近代化」に成功できた背景には、福沢諭吉などによる外国語の日本語への「翻訳」主義があったからだ。多くの日本人が素早く西欧のマニュアルなどを理解するのに非常に貢献した。IT業界でこれを怠っていることが、IT村を作っている一つの原因になっていまいか。また、経営者がITの議論を避け人任せにする要因になってはいまいか。ぜひ考えてみて欲しい。

このころのプロジェクトの価格の決め方は、プログラムを書くのに、一つの命令を1行で表現する訳で、それはパンチカードで命令を入力していたことの名残で、Ⅰ行に1つの命令を書き込む決まりになっていた。このⅠ行が例えば200円、と言う風な具合で価格が決められる。または、1人月、つまり1人のジュニアレベルのプログラマーが1ヶ月仕事して60万円、シニアレベルだと80万円、設計ができるレベルだと120万円という具合に決められていた。いったいこれに何の根拠があるのか、さっぱり分からなかった。

F銀行の海外支店のシステムを開発（実際はメイン・コンピュータを新規に買い換えるので、以前使っていたプログラムを書き換え、同時に新規の技術を使って追加を作り込むプロジェクト）の時であったが、最終テストとしてニューヨークでテストデータを流し込み、日本側は待機して問題が発生したら原因を分析して修正すると言うことを行った。当然こちらは夜中だ。目をこすりながらの我慢の時が続く。ところが、全てのデータがエラー処理されてしまうことが数日続いた。僕のチームは孫請けなのでリーダーはクレームを出さない。僕はたまりかねて「いい加減に正しいデータを見つけ出してながしてくれませんか」と⒈次受けのプロジェクト・マネージャーに文句を言った。こんな同調圧力が業界の多重構造の中では当たり前だった。

約3年強であったが、業界の多重構造と手作りによる重労働に疑問を持った。しかもお客様の社内独自のプロセスにこだわるが故に、どうしても特注品になってしまう。その「独自」の部分が全てコストに化ける。例えば、伝票の入力画面の罫線を「うちは青色じゃ無いと困る」と言われれば設計段階で青色とする。設計段階ならまだしも、すでにプログラムのコーディング段階で、「やっぱり赤色にしてくれ」といわれると、変更箇所を探し出し、その変更でインパクトの及ぶ箇所を分析しなければならないので、余計なコストが設計段階での変更よりかかかる。これがコストとなるのだ。非常に生産性の低いしかも人依存の業界だ。しかも、提案能力が一向に使いない。なぜなら全体像（現実・現場）をみて仕事をしないからだ。

お客様のところの熟練技術者の経験知によって異なるプロセスがあって、それが数値化されている場合は、もちろんそれに応じたカスタム化が必要だと言うことは分かる。何故ならそれが差別化や競争力の源泉だからである。しかし、そうで無ければ多くのシステム開発の目的は、合理化や無駄を省くことでしかない。ならば既製品として標準のロジックを使えば、開発はスピード化され、コストも削減できるはず。しかもそれは、お客さまにとって大きなメリットとなるし、開発エンジニアにとっても困難な思いをせずにすむ。

2．　コンビニ弁当時代

そこで、僕は既製品を標準にする時代に今後は変わるだろうと予測し、アメリカの業務アプリケーション製品を開発販売するマコーマック＆ドッジ社（後にアシストが手がけていたMSA社と合併しDBS:ダン＆ブラッドストリートソフトウェアになる）へ転職した。入社した当時は、まだ20人にも満たない小さな会社だったが、流石に大企業ダン＆ブラッドストリート社の子会社だったので、帝国ホテルのビジネスタワーにオフィスを構えていた。ちなみにお隣は兄弟会社の米国大手の債券格付け会社のムーディーズ社だった。

僕は、R&Dチームに所属しローカライゼーション、メンテナンス、そして日立版・富士通版への移植（米国本社ではIBM版のみ）を担当した。日本で販売していた製品は、総勘定元帳（GL:M)だけでも3000万円以上するメインフレームをプラットフォームとした会計システムであった。

入社1年後には、メインフレーム用アプリケーション製品の当時世界トップのMSA（当時はビル・トッテン社長率いるアシスト社が販売）と合弁し、世界最大のアプリケーション製品ベンダーの日本支社となった。そして、会社名はDBS（ダン＆アブラッドストリートソフトウェア）となった。SAPがR3を販売するまでは、世界でトップ。別の機会に紹介したいが、DBSはとんでもない技術を多数持ち合わせていた。

この企業に入社が決まって、すぐにユーザーカンファレンスに招待されたのだが、そこで基調講演をされたのが、運命の出会いとなる現在ITRの会長である内山悟志氏であった。「ぼくもあんな風に人前で講演してみたいなあ」と憧れた。

1989年に日本では初めて消費税が導入され、日本企業全ての会計システムで消費税を計算するロジックが追加される必要があった。ところが、海外ではすでに消費税が導入されていたために、Milleniumというのが製品なのだが、すでに消費税計算モジュールは組み込まれていたために、即座に対応した製品が世に出せた。それが、成功の要因だった。

Milleniumシリーズは、OSの上のレイヤーにアプリケーションとやりとりするミドルウェア層を成すプログラム群があり、その上に会計を司るアプリケーションがあるという構成。ミドルウェア層はオンラインで画面設計したり、独自の言語でデータディクショナリーを使って報告書を作成したりという機能を含めてアセンブラー言語で書かれており、ユーザーには触ることのできないブラックボックスとなっていた。アプリケーション層のプログラムはCOBOLで書かれており、ユーザーによるカスタマイズも許していた。一つのすごさは、VSAMというフラットファイルが使われているのに、あたかもリレーショナルデータベースかのようにクエリーが実行できることだった。

とんでもなく難しいプログラムをローカライズし、メンテナンスしなければならないために、メインプラットフォームであるIBMのシステム370のOSであるMVSとアセンブラー言語、そしてオンラインシステム（リアルタイム対話型）であったCICSを、講習会に出るとともに必死で勉強した。電話帳ほどの厚さのあるマニュアルを数冊かかえて、人生で最も勉強したかもしれない。

入社数ヶ月して、R&Dの新マネージャーが米国本社から赴任してきた。その後、会議から報告書まで全てが英語になってとっても苦労した。正直僕は英語がとっても苦手で、もう務まらないから退職しようかと思ったこともあった。しかし、幸運にも他部署の先輩から「こういう風に3ヶ月トレーニングをしてみなさい」とアドバイスをもらい、食いしばってやってみるとなんと少しずつ会議の英語が理解できるようになってきた。やれやれ。

DBSで扱っていたシステムがとっても高い技術でできていたことと、時折アメリカ本社やアジア・パシフィックのヘッドオフィスだったオーストラリアからエンジニアが来て、メンテナンスやローカライゼーションのヘルプをしてくれるので、相当な勉強ができたと思う。イタリア系ブラジル人のダンテ、ニュージーランド人のアリステア、ベトナム人のテュアン、フィリピン人のバーニー、と多くのベテランエンジニアとともに仕事ができて貴重な経験だった。

このころ実はとても嫌なことが一つあった。となりに机を並べていた先輩がいた。東京下町育ちだと言うことだった。僕は社内で唯一関西出身だったので当然ながら言葉の端々に関西のイントネーションがでる。となりの先輩は、会議の議事録を当時関西弁に翻訳するサービスがニフティサーブ内にあって、それで関西弁に直したものを僕に回してくる。関西のお客様と電話で会話した後に、「日本語で話さないと意味が分からない」と嫌なことを言ってくる。遂に僕はぶち切れて、お客様へ一緒に訪問した帰りに、「いい加減にしてくれ、続けるなら許さんぞ」と殴りかかりそうな勢いで怒鳴った。それ以来、嫌がらせはやんだ。こんな奴もいるんだなと思った。ここにも僕の性格は良く表れているかもしれない（笑）。

海外のエンジニアとは、製品を格納したライブラリーのあるシステムのプログラムエディターを現在のemail代わりにしてコミュニケーションをしていた。後に分かったことだが、アメリカ本社のエンジニアの中で十数人が、スティーブ・ジョブズがNext社を立ち上げたときに移籍していた。Next社のキャノン主催による講演会で彼らと偶然出会って知った。それもそのはず、DBS社のCTOだったジョン・ランドリーはアメリカで5本の指に入ると言われていた天才エンジニアで、やはりそこには優秀なエンジアが育っていたわけだ。

また、当時ソフトウェアファクトリー構想というのが、NECや富士通でも盛んに議論されていたが、IBMのAD/Cycle（IBMのデータベースをリポジトリとして、アプリケーション開発のサイクル全体を通じての、半自動化や再利用などによる生産性向上と品質向上を狙ったアーキテクチャ）を標準としてDBSでも導入していた。新バージョンのローカライズは、このアーキテクチャを基本として僕がプロジェクト・マネージャーとなり初めて日本で実施した。当時僕はMacのSE30を愛用しており、マックプロジェクトというソフトウェアを使って、プロジェクトのタスクチャートを書いていた。あの7インチの画面で、打ち出せばプロッターが必要なデッカいタスクチャートだった。

入社して3年が過ぎようとしていた。世の中ではダウンサイジングが叫ばれはじめた頃だ。そして、3層型のクライアント／サーバシステムが盛んに紹介されるようになっていた。データベース層、アプリケーション層そしてプレゼンテーション層を分離し、グラフィカルUIを活用したシステムである。プラグラミング言語もCやC++が使われるようになった。更に人工知能ブームもあったりして、僕もPASCALと言うプログラミング言語を勉強していたのを思い出す。まあ、この時の人工知能ブームでなんら目立った成果があったわけではないが。

1990年当時、DBS内の約1％のエンジニアがCやC++を活用できたにすぎず、クライアント／サーバタイプ（C/S）の新製品を開発するのに四苦八苦し、完全にDBSは出遅れた。そこへSAPがにわか作りのC/SタイプのR/3を登場させ、日本市場へ乗り込もうとしていることを僕は聞きつけた。早期に新バージョンを出す、そのために新しいスキルを教育しなければならないと思って、経営に訴えたが明確な回答が帰ってこない。

確かに、DBSは素晴らしいコンポーネント（サイベース社のRDBMS、コグノス社のBIおよびアプリケーション開発ツール、そしてメインフレームとUNIXサーバとの間でデータ連係する製品）を選定し、開発を進めていたので完成すれば競争力のある製品になるだろうということは想像できたのだが、マーケットインが遅れると致命的になる。スペックにこだわるよりは、早期にマーケットインすることを優先すべきだと思った。なぜなら、ダウンサイジングをすればユーザーのITコストは大幅に削減できることが明白で大きなメリットを提供できるからだ。

1993年にマイケル・ハマーとジェイムズ・チャンピ―の「リエンジニアリング革命」が刊行されたが、それに先駆け1990年（だったと思う）にマイケル・ハマーが「ハーバードビジネスレビュー」誌に新情報技術を活用しビジネスをリエンジニアリングすることの必要性を述べていた。

それを熟読した僕は、社長に「今後の私たちの進むべき方向を顧客と対話させてください」と申し出て、ユーザー・カンファレンスの開催と僕がコンセプトを作成することを許可してもらった。このカンファレンスのシナリオは、当時の最先端のIT技術（オブジェクト指向技術等）や製品を提供されているベンダーさんをパネリストとして、新しいITトレンドとそれを取り入れることによってユーザーが何を手に入れることができるのかを提示してもらい、お客様がどのようなことに疑問や不安をもたれるか、そして今後の新規技術の導入の意向について尋ねることだった。

ここで、ディスカッションの司会を当時データクエストのIT産業アナリストだった憧れの内山氏にお願いをし、パネリストの選定とその依頼回りにご一緒してもらった。カンファレンスについて詳細は記述しないが、結論は不安を持ちながらもトレンドを早く取り入れたいというのがお客様の意見であった。これをみて僕は、DBSの現状に危機感を持った。すでにDBSは出遅れてしまっており、市場を失うだろうと確信した。結果、SAPのR/3に製品はにわか作りではあるが、ユーザーがそれに目を向け始めていた。つまり、このアプリケーション分野ではメインフレームからダウンサイジングへ向かうことは確実だと確信した。

DBSではエンジニアリングを通じて多くのことを学ばせてもらった。最初はコンピュータ言語だけで仕事になったが、ハードウェア、OS、コンパイラー、通信、つまり全アーキテクチャを学ぶことの大事さを知ることができた。ITはドッグイヤーと言われるように、技術の変化のスピードは凄まじい。ノイマン型コンピュータの「自動増殖機械」という面では無く、「計算処理能力」のみを追求してきた結果、計算能力とスピードはとんでもなく拡大した。「deep blue」が見せたように人工知能も実現可能なまでに計算能力は拡大したのだ。そうなると余計に「熟練技能者の経験知」と「計算限界性」の融合、つま全体システムを見越したアーキテクトの重要度がますます顕在化していくだろうなと考えるようになった。