ObjectSquare [2005 年 11 月号]

[OOエンジニアの輪!]

line OOエンジニアの輪!

OO エンジニアの輪 〜 第 32 回 丸山 不二夫 さんの巻 〜

今回のゲストは稚内北星学園大学 学長の 丸山 不二夫 さんです。Java のイメージの強い丸山さんですが、実は一番好きなのはネットワーク技術なんだそうです。今回は、そんな丸山さんの好きなネットワーク技術から、アジアで IT 教育を行うという野望まで、Java 以外のお話もたくさん伺ってきました。

 丸山 不二夫 さん
尊敬する人

特になし

好きな言葉

すべてを疑え / すべてを受け入れ、すべてを楽しめ

愛用のツール

teikade
(コードは書かずに見るだけなので、これを使っています。Eclipse でも同じことはできますが、Eclipse は容量を消費しますから。)


大学でのお仕事

-- まず現在のお仕事についてお話ししていただけますか。

現在は稚内と東京を往復する生活をしてまして、土日は東京、平日は稚内(稚内北星学園大学)で働いています。

-- 土日はこちら(東京サテライト校)でお仕事をされているのでしょうか?

そうです。ここ(東京サテライト校)に通うのは全員社会人ですので、開講が土曜日と日曜日なんです。授業の他にも、僕と浅海さんと佐藤さん*1の 3 人でゼミをやっていまして、僕はそのうちの半分くらいを担当しています。

-- ホームページで拝見したんですが、内容が実践的ですよね。

実践的なのは浅海さんのゼミですね。実は僕は実践的でないと言われています(笑)。例えば、去年一昨年と GridSOABPEL、JBI*2 をやってきたんですが、それを皆に役に立たないと言われたんです。ただそれは、IT 業界で働く人たちの日常からするとあまり実践的でないと感じるだけで、実ビジネスに近い話という意味では十分実践的なんですけどね。

*1 佐藤直生 氏 : 日本オラクル(株)システム事業推進本部 テクノロジエバンジェリスト

*2 Java Business Integration。ESB や PBEL エンジンなどを統合して SOA を実現するための仕様。


大学外でのお仕事

インタビュー風景

-- 丸山さんは大学教育以外に講演やセミナーもされていますよね。

そうですね。僕は“丸山レクチャーシリーズ”を東京でのメインな活動でやっていまして、始めてから 4 年目に入ります。今回も 11 月に東京である Sun の JavaOne Tokyo をキックオフに、また毎月 1 回のペースでやっていこうと思っています。またそれとは別に秋にはレクチャーの全国版も札幌、仙台、東京、大阪、福岡、沖縄でやる予定です。

-- 講演の内容はエンタープライズ向けの Java ですか?

そうですね。サーバサイド Java については話します。ただもともとは私はエンタープライズ向けの Java をテーマにすることが多かったのですが、必ずしも Java だけではないんですよ。例えば Web サービスで言えば、私が携わった BPEL は Java ではないですから。今は、Web サービスやその影響を受けた Grid をきっかけに 、Java の世界だけに閉じてる必要はないという気持ちが強まっています。


稚内北星学園大学 が目指すもの −先進性と実践性の両立−

-- 稚内北星学園大学(以下、wakhok)についてお伺いします。丸山さんは大学開学と同時に北海道へ来られたんですか?

ええ、wakhok ができた時に初めて北海道に行きましたよ。1987 年ですから、もう 17 年になるのかな。

-- 少し失礼ですが、稚内は場所として少し辺鄙なところだと思います。何か魅力を感じられたんですか?

ええ感じました。東京の大学が嫌だったので東京から一番離れたところに行きたかったんです。沖縄か稚内かで迷ったんですが、演歌の世界だとみんな北に行くので稚内を選びました(笑)。

-- 当初から実践的な教育を目指されていたんですか?

昔は実践性よりも先進性でした。“最北端は最先端”が wakhok のキャッチフレーズなので、現実的には少し早過ぎる技術だけれども、それをがんばって教えてきたという感じです。そのやり方は間違っていなかったと思います。IT 技術は変化が激しいので、最初は早過ぎると思っていても、4 、5 年経てば普通の技術になってしまいますから。おもしろそうな技術だったら何でも取り入れるというのが僕のスタンスなんです。

インタビュー風景

-- そのスタンスは大学のカリキュラムを考えられる時も同じですか?

ええ。wakhok のカリキュラムは節操がなくて、どんどん変わるんですよ。

-- カリキュラムを度々見直すというのはどこかで拝見しました。

それに関して批判もあると思いますが、僕は良いことだと思っています。よく IT 技術は基礎を勉強しないと繋がらないと言われますけども、僕は新しい技術をきちんとキャッチアップしておけば体力は付くんだという考え方なんです。だって基礎が大事と言ったら、数学を勉強させれば何にでも役立つという話に行き着くと思うんです。それなら、それで本当にいいかと言うと、ちょっと違うと思いますから。

他にも僕には、日本の大学がリアリズムを欠いてるという気持ちがあります。今の学校制度や教育制度は、安定した知識の体系が存在することを前提にして、それを子供の世代に伝えることが目的の制度なんです。そのためには学ぶべきことが安定してることと、親が子供より知識を持っていることが必要なんです。ところが IT に関して言うと、10 年前と今の IT 体系は全然違っているし、教えること自体が安定しない。かつ、不断に変化し続ける。

そんな状況だから Sun さん、Microsoft さん、IBM さん、Oracle さんなどのベンダーは、大学の外に大学とは別の教育体系をつくってるわけです。つまりベンダー資格などの形で IT 産業自らが、自分のビジネスの内部に教育をビルドインしています。IT の世界ほど、産業が教育に力を入れている分野はありません。日本の大学人は、大学の外部に、巨大な産業教育の体系が出来上がっていることに、あまり気づいていないんです。その結果、IT 教育に関しては大学はレガシーになってしまったんです。

さらにベンダーの教育体系は、最終的には自分たちの製品にロックインすることが目的ですから、ベンダー資格など、僕は正直あまり良いとは思わないんです。ただ現実にはそれが会社の論理ですし、それはそれで当然のことです。ではどうするかというと、やはり大学に改めて教育機関として IT 教育の役割を担わせることが良いことだと僕は思うんですよ。

だって僕も経験ありますけど、バブルの時はみんな大学に IT 教育の期待はあまりなくて、IT の教育は会社に入ってやりますって話だったでしょ。それについて会社の人がどう思ってるか知らないけど、僕たち大学側にとっては非常に屈辱的なことなんです。だって大学で教育しなくても会社で教育できるという話ですからね。でも案の定、バブルがはじけると、会社側でそういった体力は失われていって、今何が起きてるかというと、会社は、自分で勉強できる人は自分で勉強してくださいねと言い出しているんです。確かにそういう考え方は良いことですけれども、本当にそれだけだと会社にしても大学にしても情けないでしょう。

やはり大学が社会的な役割を果たす余地はもっとあって、そのほうがコスト的にも絶対に見合うと思います。だから僕の目指す教育の形は、大学の IT 教育が IT 業界で評価されて、大学の教育が生きることです。だから大学はきちんとリアリティを持ったほうがいい。そして僕の言っている実践的な教育というのは、資格を取らせることではなく、今の IT 技術に即応した教育を維持することなんです。


東京サテライト校について

東京サテライト校のある秋葉原ダイビル

-- 東京サテライト校にはどういった方が通われていますか?

ほとんどが IT 系の企業に勤める人ですね。ただ個々人の IT の分野やレベルはさまざまです。Javaに関心を持つ人が多いんですが、Visual Basic をやっている人、COBOL をやっていた人、それからバリバリ Java の使い手の人もいます。

-- みなさん個人で通われるんですか?

そうです。今年も 90 人近く入りましたが全員個人ですね。だから東京サテライト校は学費を安くしたんです。授業料と入学金で合計 75 万円くらいですから、個人負担できるギリギリの額で、国立大学より安いんです。授業のレベルとしては 2、3 段階に分かれていて、基礎的なもの、アーリーアダプター向けのもの、その中間に位置するものなどがあります。あとカリキュラムとしては大きく Java 系、ネットワーク系に分かれていて、その他の細かい技術単位でも分かれている仕組みです。


教育で企業と連携

-- 丸山先生の考える社会の中での wakhok の位置づけはどのようなものでしょうか。

僕たちが東京に来てからの位置づけは明確で、企業との連携を重視しようという立場です。ただ大学と企業の連携と聞くと一般的には研究での連携ですが、僕たちは教育で連携しようと考えています。

実は東京に出てくる時に社会人大学院をつくるか、今みたいなスタイルにするかで 2 つの選択肢があったんですよ。だけど僕は社会人大学院をつくることを拒否しました。これが同業者の悪口に聞こえるといけないんだけど、だいたい大学院をつくると途端にアカデミックになって、役に立たない方向へどんどん走る傾向があるんです。実際、日本の博士課程の大学院の主要な仕事は、大学教員を再生産することです。博士課程の定員が、かつてより水ぶくれになっていても、教育側の意識は変わっていない。でも僕たちがそんな大学院をつくる必要はなくて、それは、僕らよりもっとご立派な大学さんの仕事です。

IT 技術者は、日本でも 100 万人のオーダーで必要とされています。これだけの数の技術者すべてが大学院に進むべきだとは、僕は考えません。僕の大学のミッションはあくまで、教育に徹して IT の新技術をたくさんの人に伝えることなんです。だから東京サテライト校のコンセプトは、wakhok で学んで、 5 年か 10 年経ったらまた wakhok に戻ってらっしゃいということにしたんですよ。

インタビュー風景

あと教育で企業と連携することで言えば、今いろんなことをやり始めています。例えば Oracle さんだと、先々月*3アプリケーションサーバのオプションみたいな形で BPEL(Oracle BPEL Process Manager)という製品を出したんですが、僕たちの大学は一年前に Oracle さんと BPEL のハンズオンをやっているんですよ。そういった、新しい技術をアーリーアダプター向けの教育でベンダーと連携することを wakhok のスタイルにしようとしています。

さっき、IT ベンダーは内部に教育組織をビルドインしてると言いましたけど、ベンダーの教育部門では、実は新しい技術には追いつかないんです。どうしても半年か 1 年遅れるんです。それを僕たちが埋めるという位置づけですね。

*3 2005年7月


オブジェクト指向との出会い

-- 丸山さんがオブジェクト指向と出会われたのは Java からなのでしょうか?

Java の前に EiffelSmalltalk もやりましたが、本格的にオブジェクト指向と出会ったのは Java だと言っていいと思います。Eiffel も結構一生懸命やったんですが、やはり Java でしょうね。実は僕はもともとは Lisper*4 なんですよ。

-- そうなんですか。

そうなんです。だからどちらかというと型のない世界で仕事をしてました。僕はオブジェクト指向の前の世代ですから。

-- 当初から Java に関しては使える言語だという感触はあったんですか?

あまり使えるつもりはなかったんですよ(笑)。そういう意味では、大学は“先進的で実践的”を標榜しているんですが、僕はあまり実践的ではなく、あたらしもの好きなんです。ただ、ずっと wakhok で C 言語を使ったソケットプログラミングを教えてましたから、C 言語に比べるとなんと楽なんだとは感じました。だから興味を持ったのはネットワークからなんですよ。ネットワークで言えば Perl も楽でしたが、あれはコードとしては、わけわからないところがありますが。

-- シンタックス的に汚いですよね。

そうですね。だけど実は僕は、日本での Perl の紹介者でもあるんです。“Perl でネットワーク”という連載をやってましたが、全然はやりませんでした(笑)。Perl はインターネットの関係でブームになりましたよね。それよりずっと前なんです。ちょうどラクダ本*5が出てすぐくらいです。例えばメールシステムや、NIS*6 と NIS+*7 の変換を、Perl で書くとなんと簡単なんだという連載をしていました。Perl もそうですが、Java も C 言語に比べてネットワークプログラミングが簡単だったことが選んだ理由なんです。だからオブジェクト指向は後付なんですよ(笑)。ごめんなさいね、みなさんの気に障ったら(笑)。

-- いえいえ全然構わないです。オブジェクト指向技術はいろんなところで使われているので、私は全員がオブジェクト指向を大好きじゃなくても構わないと思うんですよ。

オブジェクト指向が大好きとはどういう人ですか(笑)?

-- やはり Smalltalk や Ruby が大好きな人ではないですか。

Smalltalk にはまってる人はいました。ただ僕もオブジェクト指向が好きか嫌いかと言われれば好きですと答えますよ(笑)。

*4 Lisp を使用する人

*5 Programming Perl。表紙がラクダの絵であるため、通称、ラクダ本と呼ばれる。

*6 Network Information Service : ネットワーク上の複数のUNIXコンピュータ間でユーザ情報などを共有するシステム

*7 Network Information Service Plus : NISの後継。階層的ドメイン構造のサポート、セキュリティの強化などがおこなわれている。


本当はネットワーク好き

インタビュー風景

-- やはり丸山さんのご関心はどちらかというとインフラに近いんですか?

ネットワークが好きなんですよ。なぜかと言うと、これからはネットワークが一番の基本になるというのが僕の考えだからです。コンピュータからネットワークへという大きなパラダイムシフトが進むだろうと考えているんです。よくコンピュータサイエンスと言いますけれども、コンピュータは 20 世紀の技術で、これからはやはりネットワークの時代だと思います。だから、ネットワーク上のオブジェクトを扱うプログラム言語みたいなものが出来てきたら面白いと思うんですよね。僕が、あと 30 才か 40 才若かったら、そういうことをしたいですね。今のビジネスの世界だけを見るとサーバサイドが力を持っていますが、それはあくまで過渡的な現象だと思っています。

-- 昔からネットワーク技術に興味をお持ちだったんですか?

いえ、昔はネットワークなんて無かったですからね(笑)。ネットワークというのは、サーバを高速なネットワーク上に立てられる環境ができてからですから。300 baud*8、9600 baud のモデムでメインフレームとつないでいた時代はネットワークとは言えないです。だから昔からネットワークが好きだというのは多分有り得ないです。ただ僕は UNIX をやっていましたから、そういう意味ではずっとネットワークと縁があると言えるのかもしれないですね。UNIX とメインフレームのどこが違うかというと、やはりネットワークを自分でプログラムできるところですから。

*8 アナログ通信回線における変復調速度の単位


EJB 3.0 の変化

-- では少し技術的な話を伺わせてください。EJB 3.0 はこれまでの EJB とは全く変わりましたが、どのように感じてらっしゃいますか?例えば EJB 3.0 は確かに簡単にはなりましたが、逆に覚えることも増えましたよね。例えばアノテーション*9なんかは、C# のアトリビュート*10を知らない人には新しい概念で難しいと思うんです。

あれはですね、別に EJB 3.0 が悪いわけではなく、テーブルとテーブルの関係というのはもともと複雑なんですよ。そういう本質的に単純化を許さない関係が、一対多や、多対多のマッピングになるだけであって、言語仕様の問題ではないんです。だからそこは我慢してデータベースの基礎理論や、テーブルとテーブルの関係をきちんと勉強するほかないと思います。ただ、それさえできれば表現の仕方や実現の仕方はやさしくなったと見ているんですけどもね。オブジェクトとテーブルのマッピングの定義はむずかしいですか?

-- プロジェクトによると思います。例えばデータベース屋さんとアプリケーション開発者が全く別のチームに分かれてるようなプロジェクトだとうまくいかないと思うんです。

だいたいデータベース屋さんに O/R マッピング*11なんて染み付いてないですしね。“染み付く”という表現はわかりにくいかもしれませんが。

-- あまり好きではないですね。

そうですね。あんな方法でスピードが出るのかとか、それならもっとチューンしたいとかそういう話になりますから。だから僕もみんなに O/R マッピング使えとは言いませんし、それは現場の判断でやっていくしかないですね。ただ、JDBC を直接叩くことが本当に良い設計方法かといったら、そうではないだろうとは思います。

*9 Javaコード上でのメタデータ記述を可能にする機能

*10 C#コード上でのメタデータ記述を可能にする機能

*11 Object Relational Mapping : オブジェクト指向言語におけるオブジェクトを リレーショナルデータベースにマッピングするための技術の総称


EJB 3.0 からのメッセージとは

インタビュー風景

僕は EJB 3.0 から二つのメッセージを感じているんですよ。今回の EJB 3.0 で、従来の Entity Bean の機能が“Persistence API”という形で J2EE の仕様から独立することになりました。それは 一つには、J2EE から Entity Bean を取り除いたほうがエンタープライズのサーバシステムはすっきりするという意味だと思うんです。今までは僕もそう思っていましたが、EJB の王様は Entity Bean で、難しいのがえらいんだという意識があったんですよ。だけど Without EJB*12 などを見ると、やはり悪の根源は Entity Bean だという話になるわけで、それはある種当たっていたかもしれないと思うんです。

もう一つは、O/R マッピングは難しい技術ではなく、簡単なデータベース設計にはむしろ どんどん O/R マッピングを使ったほうがいいんだということです。難しいものを作る時には勝手にやればいいでしょう。でも、きちんとしたものを、しかも簡便に作ろうと思ったら O/R マッピングを使うほうがいいんだと僕は感じているんです。コンテナも要らないですし。しかも、今後“Persistence API”として J2SE にも、そのうち入ると思います。そういう方向で O/R マッピングを考えるべきだと僕は考えています。ですから、EJB 3.0 アノテーションはきちんと勉強する必要があります。アノテーションは難しいとおっしゃいましたが、Hibernate*13 だって、マッピングを XML で書くのは面倒だというふうに思います。

-- そうですね、基本的にはアノテーションと同じだと思います。表現形式が違うだけでやろうとしてることは難しいでしょう。

ただ、もうこの流れは止まらないと思います。Hibernate も EJB 3.0 に合わせるために、クラスやメソッドの名称を変えつつありますし、EJB 3.0 のアノテーションが O/R マッピングの標準になってますから。僕はそのおかげで昔の Entity Bean よりもはるかに簡単で身近な技術になったと思っています。

*12 J2EE Development without EJB。EJBを使わずにJ2EEアプリケーションを開発する利点について解説し、軽量コンテナブームを起こす原因となった書籍。作者のRod Johnsonは、Spring Frameworkの開発者でもある。

*13 オープンソースの O/R マッピングフレームワーク。開発者の Gavin King は EJB 3.0 の仕様の策定にもかかわっており、EJB 3.0 の仕様におおきな影響を与えた。


エンタープライズ Java のこれから

-- JBI や SOA などのエンタープライズ Java が進んでいく方向についてお話していただけないでしょうか。

JBI はおもしろい技術だと思っています。JBI はもともと Web サービスが沢山使われている環境でマシンやシステムを繋げていくために出てきた技術です。Web サービスにはいろんな意味で限界があって、限界と言うのは正しくないかもしれませんが、基本的には HTTP 上にメッセージを乗せるので、必ずレスポンスを待たなければいけない同期型のメッセージなんです。それが鬱陶しいことと、現実のビジネスプロセスでは、処理に非常に長い時間がかかるものがあって、それを待つことができない問題があるわけです。それで非同期、ワンウェイメッセージが必要だということになります。その一方、昔から使われている MQ(メッセージキューイング)のようなメッセージング技術もあります。つまり今、Web サービス起源のワンウェイメッセージと MQ のようなメッセージが実は機能の上で近づいてしまったわけです。さらに今は RPC 型という、引数を渡して返り値を待つ形ではなく、ドキュメントとドキュメントを交換し合う形になってきてますから、メッセージの交換がサービスであるという認識が広がってきています。そこをきちんと整理しようというのが JBI だと思います。だから今 JBI というのは JavaEE 6.0 の中核になろうとしていますが、おそらく JavaEE は単なるコンテナであることをやめて、むしろコンテンツベースのメッセージルータになるような気がします。今まではサーバサイドにコンポーネントを配備して、その入れ物として頑張ってきましたが、それはもういいと。これからはメッセージの飛び交う中で自分がハブになるんだということです。JBI とは、メッセージ交換をベースにして、JavaEE のアーキテクチャを考え直していこうという試みなんだと思います。

ただし一方で僕は、JBI にもいくつか問題があると思っています。いろいろなプロトコルとつながる機能が用意されてそれはそれで面白いんですが、あれは要するに、一つの VM がメッセージングをすべて仕切るので、一つの VM で閉じてしまうんです。

インタビュー風景

-- Normalized Message Router *14も Binding Component *15もすべて同じ VM 上にあるということですか?

僕の理解が間違っているかもしれませんが、僕の見る限りはそう見えるんですね。おそらくメッセージがやり取りされるのは同じ VM 上のはずです。だからあの中はネットワークの世界ではなく一つに閉じているわけです。JBI の Normalized Message Router は、そのままでは JBI のシステムの外部には延長できないんです。もっとも、これも、ネットワーク上のノードが、内部に複雑な構造を持つ必要はないと割り切ればいいんです。ただ、おそらく複数の JBI を結合する別のネットワークを考えなければいけなくなる。そこでまた ESB が出てくるのではないでしょうか。おそらく完成した暁には、さまざまな JBI を ESB が結ぶというのが今のところ一番まとまっているシナリオだと思います。Sonic のChappell*16 などはそのあたり見抜いていると思います。彼は JBI の次に ESB が来るという見方をしていて、それは当たっていると思いますよ。このあたりは、面白いところで、Normalized Message Router を延長しようというアイデアもありうると思っています。

-- 私は SOA や JBI、ESB については若干疑問を持っています。これらの技術が企業内で通信基盤として使われることはあると思うんですよ。ただ、もう少し一般向けのサービスを実現する技術として考えると、実は向いてないのではないかと感じるんです。例えば Google が公開した API のようなもののほうが良いと思うんです。

確かにその通りだと思いますが、それは別の話題ですね。Web 2.0 とか、そういう問題ですよ。やはりエンタープライズの基幹システムというのは特殊な世界で、ベンダーがお金を稼がないといけないし、あーでもない、こーでもないと迷っているところもあるので、そこは差っ引いて考えた方がいいですね。そういう意味では、JBI は SOA 実現のインフラとしてどういう技術が必要かという議論をしていて、実はサービスの実現には興味を失っているんですよ。インフラの技術が、エッジでのサービス実現の技術に興味を持たないのは、アーキテクチャ的には、正しい選択だと僕は思っています。

*14 正規化されたメッセージフォーマットを使ってコンポーネント間のメッセージ送受信を実現するJBIの機能

*15 外部サービスのメッセージを正規化するJBI コンポーネントの一つ

*16 Sonic Software 社の David Chappell 氏。ESBのエバンジェリスト


趣味に傾向なし?

インタビュー風景

-- 趣味や休日の過ごし方についてお聞かせいただけますか。

休日はここで働いてます(笑)。

-- そうなんですか(笑)。では、働いていない時は何をされているのでしょうか?

映画を観たり、本を読んだりして普通ですね。特に傾向もなく、本も物理、数学の本からマンガまで何でも読みます。

-- ものすごく気に入っていて何度も観たくなる映画などはないですか?

僕自身、結構クールな人間なのであまりないですね。例えば最近観た映画でいうと、スターウォーズがありますけれども、あれを観て泣く男がいてそいつはおかしいなと思ったりしました(笑)。ただ実際のところ、休日も大抵は原稿を書いていてあまり時間がないんです。東京に来てから本当に忙しくなりましたね。


これからの夢 −アジアで IT 教育−

-- ほとんど仕事が趣味のような感じですか?

いえ全然趣味ではないです(笑)。ただ、楽しみながら仕事をするタイプですね。例えば大学の仕事で先週はベトナムに行ったり、今週はフィリピンに行ったりして忙しいんですが、結構楽しんでいます。それは Sun さんが後押ししてる JEDI というプロジェクトで、グローバルな規模でデジタルデバイドを解消することを目的に教育コンテンツをオープンソース化しようというプロジェクトなんです。MIT も同じようなプロジェクト*17を莫大な資金をかけてやっていますが、JEDI はそういったプロジェクトとは違った、もっと草の根でやっていこうというプロジェクトです。

また、JEDI とは独立のプロジェクトも考えています。それはまずベースとして英語で教育コンテンツを配信します。次にそこで勉強のできた人は wakhok に入ってもらい、wakhok のカリキュラムで学んでもらいます。そして母国に帰った後は wakhok で学んだカリキュラムをローカライズして、その国の言葉で教えてもらうという流れです。いずれは wakhok カトマンズとか、wakhok ホーチミンとか、wakhok マニラとかを自己増殖できればいいなと思っているんですよ。僕はこのプロジェクトはコンセプトとして成功すると思っています。wakhok のようにしっかりとした教育コンテンツを持ってアジアの人たちに教えられる大学はそんなにないですし、アジアの若者の IT 技術を学びたいという熱意は日本の若者よりもはるかに高いですから。

-- モンゴル人のソフトウェアエンジニアへのインタビューが掲載されている本*18を読んだことがあるのですが、モンゴルにはモンゴル語の技術書はありませんし、ソフトウェアについて学ぶ学校への入学はとても難しいらしいんです。

でも逆に言うと、1、2 割の先進国を除けば、地球上は似たような状況ですから、いくらでもチャンスがあるんですよ。楽観的なクツ屋と悲観的なクツ屋の話をご存知ですか?悲観的なクツ屋は未開の国に行ったら「だれもクツを履いてないところでクツは売れない」と考えます。反対に、楽観的なクツ屋は「誰もクツを履いてないんだからいくらでも売れるだろう」と考えるんです(笑)。僕はその楽観的なクツ屋なんですよ。だから今は IT 技術がないところでも、これから必ず IT 技術に対するニーズは生まれると思うんです。僕はそれを教育の面から支えて、次の担い手を育てていきたいんです。

*17 マサチューセッツ工科大学(MIT)のメディアラボが中心となり進めているプロジェクト。“子供1人にコンピュータ1台”をスローガンに、途上国の子供たちにコンピュータを提供するため、 $100 ノート PC の開発を目指している。

*18 “日本のSEはこれからどうなるのか” 萩原佳明 著


若手エンジニア、学生へのアドバイス

インタビュー風景

-- では最後に、若手エンジニアあるいは学生へのアドバイスをお願いいたします。

しっかり勉強しなさいと言いたいです。技術はどんどん変わりますし、若い方が吸収能力は高いはずですから。日本のエンジニアにもっと頑張ってほしいんです。今アジアを見ると、中国やインドはものすごくいい人材をたくさん排出していますが、日本の若者はそれに負けないくらいの勉強をして、国際的にがんばってほしいということですね。どうして日本人エンジニアは国際的に活躍できないんでしょうね?

-- そうですね。私が思うに、一つは言語の問題と、もう一つは大企業がエンジニアを囲い込んでいることが原因だと思います。

僕の印象だと、会話だけだったら今の若者のほうが僕たちの世代より英語できると感じますけどね。やはり言語は問題ですか?

-- 実際には、英語ができないわけではなく、英語にコンプレックスを感じてるだけなんだと思うんです。おそらく技術的な話題であれば、それほど英語を話せなくてもコミュニケーションは出来ると思うんですが、コンプレックスを克服することのできない気持ちのあり方に問題があるんだと思います。

もう一つの原因の、大企業が囲い込んでいるとはどういうことですか?

-- 優秀なエンジニアは日本にもたくさんいたと思うんです。ただやはり企業が外に出さず、クローズなものをずっとつくらせてたじゃないですか。だから日本のエンジニアは顔が見えにくいと思うんです。例えば UNIX で言えば、日本のメーカーで UNIX を開発して顔が見える人はそんなにいなくて、むしろ Linux や BSD など、フリーでオープンなものを開発していた人のほうが全然世界に対して顔が見えていますよね。

そうかもしれないですね。やはりグローバルな世界で何かできることはまだたくさんあるような気がしますね。そのためにはやはり日本の中にいるだけではだめで、外に出ていく意欲を持てばいろいろ変わると思うんです。例えば今回、ネパールの高校生に英語でコンピュータを教えるサマースクールのために、wakhok の学生を 3 人ほど現地に派遣したんです。そうすると、最初は大して英語がうまくなかった学生も、それなりの仕事をして帰ってくるんですよ。食べていくだけなら日本は豊かですから、なんとなく時間を過ごしてしまいますが、やはり若者は可能性を探してどんどん外へ出ていくべきだと思います。

-- もっと世界に出ろということですね。

そうですね。引きこもりだったらまず家から出ろという話ですが(笑)。とにかく出来ることから始めたらいいと思います。あとは、繰り返しますがしっかり勉強することも大切です。技術で先進性を維持することは基本ですから。それがビジネスにもなるし、自分のプライドにもなるし、自信にもなります。だから若者はしっかり勉強して、自分の確信を持つことが大事なことだと思います。

-- どうもありがとうございました。




記事の内容を 5 点満点で評価してください。
1 点 2 点 3 点 4 点 5 点
記事に関するコメントがあれば併せてご記入ください。



©2005 OGIS-RI Co., Ltd.
Prev Index Next
Prev. Index Next