【第4回】「戦いすんで日が暮れて」 ~設計できないシステムエンジニアを量産したオープン化の落とし穴

<IT産業は、いま・・・>

日本のIT産業の歴史を振り返ってみると、90年代初めにはディファクトスタンダード戦争がありました。それ以前の日本は「Japan as No.1」の時代で世界のトップランクでした。一番競争力がありました。その時代、ユーザー企業は自社のシステムを全部自分たちで企画し設計してものをつくっていました。パッケージなんかは買わなかったのです。その会社に合った優れたオーダーメイドのシステムがたくさんあったのです。それを作る能力もユーザーにあったのです。そのころは、COBOLやPL/1など、今で言うと刀に相当する武器を使いました。優秀な侍がいて剣を抜いて戦わせたら最強の軍団だったのです。

そこに突然、黒船が来航します。米国がディファクトスタンダード戦争を仕掛けたのです。これからは刀で戦う時代ではなく鉄砲の時代だとマーケテイングしてきて、鉄砲を持たないものは負けると喧伝(半分脅迫?)しました。慌てた付和雷同の日本人はいままで慣れ親しんだ刀と武士道(開発方法論設計法)を全部捨てて鉄砲に持ち替えました。鉄砲を持ったのはいいのですが、これがVisualBasicのように半年ごとにものが変わる。半年ごとに違う鉄砲を持たされる。そのマニュアルを読んでいる最中にまた違う鉄砲が支給される。そうして最強の侍軍団は戦う能力を失ってしまいました。これが最初のディファクトスタンダード戦争でした。これによって日本のIT産業の力が弱まり、後にグローバルスタンダード戦争が始まりました。

これはオープンシステムが浸透して数年経ち、経営サイドがそろそろ基幹システムを再構築しなければいけないとか、2000年問題で全インフラを変えなければいけないとなった時に、自分たちの戦う能力が非常に弱っていることに気づいたのです。そこでどうしたかというと、まず軍事顧問と呼ばれるコンサルタントに相談を持ちかけました。コンサルはBPRという旗頭のもと自前軍で戦う時代ではない、傭兵を雇いなさいと薦めたのです。これがグローバルスタンダード戦争です。
本当は自分たちの戦い方があったのに、傭兵を使うと傭兵の戦い方に自分たちの戦闘を合わせるしかない。そうすると強みも均一化されます。傭兵同士の戦い、これがグローバルスタンダード戦争です。これによって日本にERPパッケージが入ってきて、その結果、各社情報戦略で違いがないような横並びになりました。

<いまなぜ開発方法論が脚光を浴びるのか?>

グローバルスタンダード戦争でパッケージに侵食されて、日本はものをつくる力がなくなり情報システムがぐちゃぐちゃになったのです。傭兵では命をかけないし、その会社のために一生懸命やるわけではないし、合わないのです。
日本にあうものは日本でつくらないとだめです。そのときには和魂和才か、和魂洋才かどちらでもいいのですが、和魂というのは非常に重要で、ユーザーのフィロソフィーを壊さないようなITソリューション、もしくはフィロソフィーを伸ばすようなITソリューションを提供していくことが必要です。企業の真の強さの根源である「他社との差別化」をグローバルスタンダードと引き換えに失ってはならないのです。

われわれはECObjectsという製品をパッケージでありフレームワ-クであると公言しています。きちんと機能が完備されていて、なおかつ柔軟に変更できてどこが悪いの?とあらためて問い直しています。ちなみに、欧米に感化されてしまったコンサルはECObjectsがパッケージかフレームワークかで1時間も質問していました(両方できるのは欧米ではいけないようです。エンドユーザーにとっては福音ですが)。特許で武装された独創的なパッケージですが、Javaビーンズというクラスライブラリで組上げられているので修正や変更が柔軟なのです。
最近はRCA(Relocatable Component Architecture)という、マルチTierを動的に実装する仕組みで、開発時に、1 Tierモデルで実行時にマルチTierになる仕組み(Make 1 Tier, Execute Multi Tier)もリリースしました(宣伝しすぎですみません)。

この不幸な2度の戦争のせいで、上級SEの技術が後輩に伝承されずに今のちょうど30から40歳くらいまでのSEはソフトウエア工学やピープルウエアを学ばずに(UMLは学んでいるのでしょうが)育ってきました。
その結果、彼らが中堅SEとして開発の指揮をとるようになって事故が多発するようになりました。
昨年、日経コンピュータにショッキングな記事があって、なんと現在のシステム開発の70%が失敗しているというではありませんか?確かに、見渡すと設計がきちんと身についているSEが見当たらなくなりました。
SEは払底しています。
その反省から、CMMIやPMBOKやITSSのような体系が登場したのです。
ソフトウエア工学を学ばず、設計ができないSEなんて、歌を知らない歌手のようなものなのです。
そのような状況を打破するために、われわれは再度本物のSEの基礎技術を体系化してマニュアルを作成しました。そのマニュアルの中には構造化分析、データ中心、オブジェクト指向、UML、ウォーターフォール開発等々がすべて体系化して網羅されています。その基本原理が以下にあるSE八正道です。SEになるための心得です。これを正しく実践すれば皆さんもれなくSEになれるはずです(本当です)。以下に紹介します。


<SE八正道>

正 見:正しく見る。知るを知るとなし、知らずを知らずとなす。これ知る也。物事をあるがままに見る心を養う
正 学:正しい理論を幅広く学ぶ
正実践:正しい理論を何百回と体用し、技術を体で覚える
正工夫:仕事のやり方を常に工夫し、改革する
正設計:バランスのとれた、偏らず、しかも幅広い美しい設計を行う
正奉仕:ひたすらお客様の立場に立って、どうやったらお役に立てるかを常に考え、サービスを提供せよ
正指導:体得した全ての知識と技術を下に開示、伝承し、常に新しい境地に自らを導け
正精進:憎むべきは過去に成し遂げた最高の仕事である。全ての成功体験を捨てよ