月: 2023年10月

　「中国やインドの技術者の方が日本の技術者よりも優秀だ」「中国にはＪａｖａの技術者がたくさんいる」などの話をよく聞く。技術の優秀さとは、教科書的な技術知識を膨らませることではなく、多くのビジネスの場で開発実践や失敗などの経験から培われる判断力をも含んでのものである。経済環境が大きく異なる中国や、米国の下請けをやっていたインドの技術者では、世界一複雑な日本のビジネス系アプリケーションを開発することは難しい。
　日本の地方のソフトハウスにも、沢山の「優秀な技術者」およびその予備軍が眠っている。昔で言えば紙と鉛筆だけで始められる（大きな投資が不要）ソフトウェア産業を、地域経済の活性化実現の中核に育てていくべ
きだ。

■　日本の情報処理産業の空洞化

　経済環境の悪化に伴い、大手コンピュータ・メーカーやＳＩ企業は、開発費用の抑制を狙って中国やインドなどオフショアでの廉価な労働力活用に躍起になっている。一方、地方のソフトハウスは、従来のメーカーを中心とした「系列」では、開発案件を確保できなくなって、少し大きなところは東京にオフィスを設けたりし始めている。
　このままでは、日本の情報処理産業は空洞化してしまう。
　以前、食品産業関連のセミナーで、日本の農業の自給自足率についての危機感の話を聞いた。このままのコストでは、ほとんどの農作物が中国産となってしまう時に、その会社が実施した施策は、四国や北海道などの日本の地方活用による中国と同コストへの挑戦であったと言う。

　我々も、情報処理産業の自給自足率についての危機感を持つ必要があるのではないか？

　はたして、トータルなコストで本当に地方のソフトハウスは、中国やインドに負けているのだろうか。何度も言われていることだが、現地とのコミュニケーション費用や管理監督要員の準備、更には、折角教育してノウハウを身につけさせた人材の流出リスクなどを加味すると、もともとの人件費は極端に廉価であっても、トータルではせいぜい日本の（東京の）半分に抑えられれば成功かも知れない。
　これに対し、日本の地方には、豊富な土地に裏打ちされた物価水準の安さ、快適で風光明媚な環境、そして米国と同じような車社会が用意されている。問題のＳＥ単価についても、これまでの下請け構造で叩かれた実績からいけば十分に戦えるし、オフコンなどで業務アプリケーションを開発した人たちや、その運用保守に携わり日本のビジネス環境や業務ノウハウに長けた技術者がいる。言葉も経済環境も同じなのだ。
　ネットワークがこれだけ発達した今こそ、日本の地方も見直しを図り、ソフトウェア開発者は地域経済の牽引役となって、自給自足率の充実を図っていくべきだ。

■　地方の活性化

　一昨年あたりから、地方からのお誘いで、セミナーでの講演に出かけることが多くなった。
　地方都市に行くと、よく見かけるのが郊外にある「テクノパーク」の存在である。「和製シリコンバレーは我が地なり」と、国家予算の支援を受けて、どこも華々しくスタートする。しかし、数年立つとベンチャー棟の入居者も疎らになり、大きなホールは芸能番組に貸し出されたりと、本来の主旨から外れてしまう。
　地方でのＩＴ企業育成で、もっとも重要なことは、自治体が地場のソフトハウスに仕事を出すことだ。東京の大手のコンピュータ・メーカーやＳＩ企業を元請けにして、数段階の中間業者を経てから地元へ戻す仕組みを止め、地場のソフトハウスに注文を出すことを徹底されたい。
　最近では、コンピュータ・メーカーの不振によって、この最後の地元業者の代わりに、より廉価なオフショアへ流れている。徴収された税金が、たかが情報システムのために、東京に流れ、オフショアに流れる。自治体は心して情報システム費用の削減と地元ソフトハウスへの発注による税金の循環を考えなければならない。これは、情報処理産業のみならず、建設業など他の業種にも同じことが言える。地方経済が低迷するのは、地元優先の意識が低下し、国家予算からの支援に頼りたがる現在の体質が最も問
題と考える。地方経済の自立化が重要である。
　光ファイバー網やＣＡＴＶを用意すれば、地域のＩＴ化が進展する訳ではない。
　経理や総務と同じように、企業のインフラとして情報システムは必要なものである。これを維持していくソフトハウスが、身近な企業だけではビジネスにならないようなＩＴ化では意味がない。
　地元の商店街や昔から続いているお店が、大型店舗に押されて閉店の憂き目にあい始めている。ＩＴも、これらの活性化を図れる仕組みに組込んでいかなければならないし、この提案を地場のソフトハウスが、流行の技術だけではなくオリジナリティをもって、積極的に進めることが重要である。

■　技術知識より実践経験

　ここでも、ビジネス系と制御系エンジニアリング系の差が出てくる。
　中国やインドには、教科書的な技術者はたくさんいるが、自由主義経済である日本のビジネス環境での多様なシステム構築経験をもった人はほとんどいない。このような知識だけの技術者は、ビジネス系においては「優秀」とは言わない。

　銀行が第二次オンラインを開発していたころ、某銀行へコンピュータ・メーカーから「優秀」な技術者を数名送り込むと言う話を聞いたことがある。先月まで、原子力研究の仕事をしていたトップクラスの優秀な技術者を銀行向けに用意したとのこと。いかにも、日本の「技術」に関する話らしくて面白い。
　情報処理システムとしては、確かに同じであるが、ご想像のとおり業務内容が全く違う分野では、その「優秀」さは発揮できない。システム規模が大きくなればなるほど、業務ノウハウが重要度が増すことから、結果は明らかであった。

　ビジネス系アプリケーションの開発において、地方のソフトハウスは豊富な経験を積んでいるので、オフショアに対して大きなアドバンテージがある。更に、最近の若い世代は東京へ出るよりも地元への就職を望む人も多く、ビジネス系技術ノウハウの継承も進んでいる。
　我々には、日本で情報システムを創り上げてきたのは、日本経済の成長と言うバックグラウンドとともに、徹夜徹夜の連続で戦って来たという自負があるからだ。この経済環境を理解でき、単なる仕様書の置き換えのようなプログラムを作るのではなく、創意と工夫をもって良い情報システムを親身に育んでいくことが重要なのだ。

　この業務ノウハウをベースに、最新のテクノロジーを利用して「人の営み」を支援するＩＴ化を提案していくことが、地方のソフトハウスのスタンスとして、自治体や地元企業などのＩＴに対する期待に応える回答ではないだろうか。
　このような仕組み作りに、筆者は貢献していきたい。

　２００３年４月、「鉄腕アトム」は誕生しなかった。ソニーやホンダの二足歩行ロボットは大きな進歩だが、人の心を持ったロボットは実現していない。同様に、制御系など機械に近い分野では比較的容易にシステム構築できるが、人の営みに近いビジネス系分野は、システム設計ミスが発生し易く、完璧なシステムを構築することは「絶対に無理」なことを前提とすべきである。

■Ｊａｖａが目指すもの

　Ｊａｖａは、１９９５年５月に発表されたＷｅｂシステム用のオブジェクト指向言語である。
　Ｊａｖａのメリットとしては、当初、以下の３つがあると言われていた。
　一つは、オブジェクト指向を活かしてのコンポーネントウェアによる「ソフトウェア部品の再利用」、二つ目は、ＪａｖａＶＭ（仮想マシン）を間にはさむことによって実現する「クロスプラットフォーム性」、そして、三つ目が、クライアントサーバー型の問題点であったプログラムの入換えを容易にし、Ｊａｖａアプレットの最大のメリットでもあり、サーブレットでも違う形で実現できた「プログラムの再配布」である。
　二つ目の「クロスプラットフォーム性」の確保は、今でも大きなメリットと考えている。基本ソフトとアプリケーションの間のソフトウェアがそれぞれの違いを吸収して、大型コンピュータからパソコンや家電製品に組込まれたコンピュータまで、同じソースコードで書かれたプログラムが稼働することなのである。ただ、現在はその基本ソフトごとの違いに十分な対応はできていない。
　そして、三つ目の「プログラムの再配布」についても、大規模なシステムになればなるほど、システムの更新の際に、一々利用者のコンピュータのハードディスクの中に入っているソフトウェアを、全て一気に載せ換えるのは大変な作業となる。したがって、Ｗｅｂコンピューティングがブラウザという一つのソフトウェアをベースとして、利用ソフトウェアの更新を吸収してくれる仕組みは素晴らしいし、Ｊａｖａだけのメリットではない。この当時の中心的な仕組みであったクライアントサーバー型が、利用するシステムをクライアント側に置いており、この更新作業に大変な労力を割いていたことに対する優位性の強調だったはずである。
　今でも、大企業ではたくさんのWindowsクライアントを均一化していくには、大変な労力とタイミングを見計らう必要があり、その運用費用の増大を回避するために、Ｗｅｂシステムへ移行しようとしている。

■ソフトウェア部品の再利用は永遠の課題

　問題となるのは、一つ目の「ソフトウェア部品の再利用」であり、最近のＪａｖａの傾向が、ＥＪＢやコンポーネントウェアなど、このことばかりに集中している様に見えるからである。
　ソフトウェアの部品化については、1960年代後半、故ダイクストラ（昨年８月に亡くなられたとのこと）の「構造化プログラミング」から始まり、筆者の世代にはモジュール化の動きが活発化して、一つの入口と一つの出口、一つの機能をモジュールとして部品化することが重要となった。その進化の結果が「オブジェクト指向言語」である。
　オープンソース・ソフトウェアの中心であるＣ言語についても、登場した時のキャッチフレーズは、モジュール化言語「Ｃ」であった。
　Ｃ言語によるソフトウェア部品化は、ハードウェアに近いレイアにおいては、大きな成果をもたらし成功していると思う。
　しかし、ビジネス系のシステムでは成功していない。
　我々がＣ言語を用いて業務処理システムの構築をした時も、このモジュール化を進め、再利用を心掛けたが、ビジネス系の処理は、実に複雑である。世の中の様々な状況をソフトウェア部品として、開発プロジェクト全員に徹底させなければならない。再利用しようとするビジネス向けソフトウェア部品は、次のシステムでは更に修正修正を繰り返し、意味を持たなくなっていった。
　この問題は、現在のＪａｖａでも解決されていない。
　いつの時代も、「そんなことはない、ソフトウェア部品化による再利用は実現できる」という人がいる。よく話を聞いてみると、制御系やエンジニアリング系であったりすることが多い。
　もともと「構造化プログラミング」の概念は、プログラムを「シンプル」にして維持管理をし易くすることが「目的」であり、部品化することはその「手段」だと考えている。
　現在のＪａｖａは、複雑になり過ぎている。
　このあたりで原点に戻り、「シンプル」さの追求などに立ち返ってはどうだろう。他の優れたメリットもあるのだから。

■ＸＭＬでの誇張が致命的

　Ｗｅｂサービスが、Ｊａｖａのソフトウェア部品化に拍車をかけることになる。
　ＸＭＬは、データに普遍的なタグを付け意味を持たせることの試みであり、ＪａｖａをＷｅｂサービスの世界へと導いた。
　Ｗｅｂサービスは、もともとマイクロソフトの「．ＮＥＴ」での提案であったが、ＩＢＭやサンマイクロシステムズも反応し、Ｊａｖａも同様の方向へ動くこととなった。
　筆者のＪａｖａに対する興味が失せていったのは、ほぼこの時期であった。アプレットとしてＶｉｓｕａｌＢａｓｉｃに匹敵するクライアント品質を維持していたのに、問題であったパフォーマンスの向上を図る道も、よりクロスプラットフォーム性を追求し様々な基本ソフトの上での稼働を保証していく道も、どこかへ行ってしまったからである。
　ＸＭＬが出現したころ、データの普遍的な意味づけを実現するナレッジマネジメントが注目を浴びた。
　この普遍化に大きな誤りがある。前述のソフトウェア部品化も同様であるが、人が行う処理やデータを、普遍的に意味づけることや適切な名前づけをすることはできないのである。
　ここに一つの書類があるとする。これをどの分野として整理するか？
　一人一人まったく違う分野に区分してしまうはずである。だから他人が作ったプログラムを理解するのに時間が掛かるし、自分では考えもつかないことに感動したりもする。
　また、同じ人間であっても、時とともに変化する。去年の自分と今年の自分では、この書類の区分は多分違ってくるだろう。自分の環境も変化しているし、何よりも自分も進化しているからだ。
　何年か前に、野口悠紀男著『「超」整理法』という本が大ヒットしたのを覚えている読者も多いと思う。この本でのポイントは、時間軸だけを基準に一つのファイルに整理することだった。様々な分野に分けてファイルを作ると、自分自身ですら探すことができなくなるからだ。
　このように、ＸＭＬやＪａｖａ部品を他人（同一社内であっても）とシェアしながら、しかもビジネス系システムで実現することなどできる訳がないのだ。

　Ｗｅｂサービスは、Ｗｅｂにおけるシステム基盤の考え方の整理としては、それなりに意味はあるかも知れない。しかし、一つのキーワードをネットワークに伝えることで、インターネットの様々な処理システムの中から適切な処理同士を結びつけて、回答を導き出していくようなことは、レイアの高い「人の営み」に近いビジネスの世界では実現しない。

　Ｊａｖａでのシステム開発に、そしてシステムの維持運営に苦慮しているユーザー企業が増加してきていることは事実である。
　もっと「シンプル」な仕組みが、必要となっていることは間違いない。