objectsquare

[突撃インタビュー]


Gregor Hohpe さんインタビュー(後編)

7 月号の前編に引き続き、 Gregor Hohpe さんのインタビューをお届けします。 後編では、エンタープライズインテグレーションに関わるようになったきっかけや、 ご自身が経験されたインテグレーションプロジェクトに関するお話、 また、著書『 Enterprise Integration Patterns 』の執筆秘話、更にプライベートまで幅広くお届けします。
 また、OOエンジニアの輪ではおなじみの"若手エンジニアへのアドバイス"もいただきました。

エンタープライズインテグレーションは、複数(異なる企業間など)のアプリケーションやシステムを統合して1つのシステムとして活用するものです。 著書『 Enterprise Integration Patterns 』では、メッセージングシステムを利用した、疎結合な統合についてとりあげています。



 インタビュー風景

エンタープライズインテグレーション

エンタープライズインテグレーションに関わるようになったきっかけ

-- どのようにして、またいつ頃からエンタープライズインテグレーションに 関わるようになったのですか ?

そうだね、1999 年のドットコムブームの頃かな。 ドットコムブームの頃は、ISP やブロードバンド、DSL プロバイダーがいっぱいあったよね。 この頃はテレコムマーケットはとてもホットだったんだ。 これにはちょっと面白い話があるんだ。

私はリアルタイムな支払請求システムソフトウェアの論理設計をしていたんだ。 これは、パッケージアプリケーションなんだけど、非常に多くのインテグレーションが必要なんだ。 支払請求システムは、料金や税金を計算するために、アカウントシステムと接続する必要があるよね。 それから、税金システムや電話をかけるシステム、顧客の問い合わせなどを管理するシステムなどともコミュニケーションする必要があるよね。 つまり、支払請求システムでのほとんどの処理は、それがパッケージソフトウェアであっても、インテグレーションなんだ。 他のアプリケーションと一緒に動作するパッケージをインテグレーションするために、 Vitria のミドルウェアを使いはじめたんだよ。

2000 年ごろなんだけど、TIBCO ミドルウェアを使い始めたんだ。 その頃からベンダーやテクノロジー、用語が大きく違っても、開発では多くの共通性があるということを考え始めたんだ。 例えば、Vitria から学んだ事を、TIBCO を使って開発するためにも適用できるように、2 つの間にはよく似た設計の原則があるんだ。 メッセージングミドルウェアの種類に関わらず、同じようなアイディアが適用できる事は興味深いよね。 でも、この時は単に 2 つの技術の共通性が面白いと思っていただけで、本を書くとか、パターンについては考えていなかったんだよ。

ひとつ面白い話があるんだ。1994 年頃、カリフォルニア州の顧客のために働いていたんだ。 そのとき、私は他のメインフレームのシステム、つまり他の州の代理店の情報に、 ターミナルエミュレータを使ってアクセスして情報を取得し、それを処理して、 データベースに格納していく作業を簡単に行うモジュールを作ったんだ。 私達は、これを screen scraping って呼んでいたよ。 この時は、3270 ターミナルエミュレータに出力される文字をキャプチャするプログラムを C でコーディングしたんだ。

その仕事は実はインテグレーションプロジェクトだったんだけど、当時、新米の開発者だった私はインテグレーションプロジェクトだと思わなかったんだ。 2 つの州の代理店間のインテグレーションだったから、たくさんのインテグレーションプロジェクトがあったんだ。 データマッピングや、他にも多くの開発を行ったのに、その時はインテグレーションプロジェクトだと思わなかったんだ。 ずいぶん後になって、実はインテグレーションプロジェクトだったって事に気がついたんだ。変な話だよね。 奇妙な話だけど、これが私の最初のインテグレーションプロジェクトだよ。

でも、今でも、こういうインテグレーションのスタイルは一般的だよ。 だって、多くの場合、ターミナルエミュレーションがメインフレームにアクセスする唯一の方法だからね。 だから、もっとよい方法があっても、今でもターミナルエミュレーションを使うんだ。

簡単なプロジェクトはありえない

-- いままでに経験したもっとも困難なインテグレーションプロジェクトについて話してもらえませんか。

そうだなぁ、簡単なインテグレーションプロジェクトはありえないんだ。

-- そうですね。

そう、みんな難しいんだ。でも、その中でもっとも難しかったのは Telecom Italia のプロジェクトだろうね。 彼らは、6 か 7 つのパッケージアプリケーションを購入していて、しかも、カスタマイズしている最中のパッケージを全部統合したがっていたんだ。 つまり、これは走っている自動車の車輪を交換するようなものだから、すごく難しいんだ。 アプリケーションに変更を入れつつ、それらのアプリケーションをお互いに接続しないといけないからね。 それに、これはイタリアで行ったプロジェクトだから、すべての要求ドキュメントはイタリア語で書かれていたんだ。 だから、すごく辛かったんだけど、ドキュメントを読まざるをえなかったんだ。

-- イタリア語を読み書きできるのですか?

うーん、ほんの少しだけ、本当にゆっくりとしか読めないよ。 だから、ドキュメントはそんなに厚くなかったんだけど、読むのが遅くて結局いつも最後まで読めなかったよ。

それに、実のところ私達は 2 種類の言語に関わる問題を抱えていたんだよ。 ひとつは、英語やイタリア語のような日常使う言語。もうひとつは、アプリケーション間の用語の問題さ。 つまり、それぞれのチームがそれぞれのコンセプトにもとづいて別の言葉を使っていたんだよ。  だから、英語のドキュメントがあったとしても、それが役に立つとは限らないんだ。 アプリケーションは全てデータモデルを持っていたんだけど、モデルを探すのにも人々にそれぞれのアプリケーションを理解させなければならないから、 とても時間がかかったよ。そして、これはいまだに開発における非常に大きな問題のひとつだね。

-- そうですね。これはインテグレーションの典型的な問題だと思います。例えば、 "顧客"という言葉がパッケージによって、まったく別の意味を持つという。

うん。例えば、"顧客"について考えてごらん。これは典型的なアカウントだよ。 例えば、amazon だったら、"顧客"は"本の購買者"だって思うよね。 しかし、amazon の業務のある部分には、"提携者" と"再販売業者" が 関わっていて、少なくとも彼らはアカウントを持っているから、ある意味"顧客"と言っていいんだ。 それから、"配送業者"、彼らもアカウントをもってるよね。 "顧客"のアカウントというのは非常に幅広いコンセプトだし、システムによって全く違う意味を持つんだ。 だから、用語の定義を明確にしておくって事はすごく重要なんだ。そうでないと、大きな混乱を生んで、うまくいかないよ。

非同期メッセージを使ったインテグレーション

-- あなたの関わっていたインテグレーションプロジェクトでは、非同期メッセージを使っていたんですか ?

そのプロジェクトでは、そうだね、TIBCO 、TIBCO ソフトウェア、これは非同期メッセージングを使っていたよ。 例えば、顧客は web サイトでアドレスを変更する。 すると、その日のうちに他のシステムへ変更のメッセージを送信する。そう、これは非同期メッセージングシステムさ。 非同期メッセージングシステムで面白いのは、システム間の通信は複雑にはならず、むしろシンプルになる事なんだ。 システムに何か変更が伝えられたら、他のシステムに伝播するだけだからね。 その代わり、データはすごく複雑になるよ。だから、私達はデータのモデリングに時間をかけたんだ。

-- 多くの開発者は非同期システムについてよく知らないと思うんですが、 そのプロジェクトでは、開発者達はソフトウェアを容易に作る事ができていましたか?

うーん、簡単じゃなかったよ。イタリアのプロジェクトの話だよね?

-- はい、そうです。

その頃、僕の本*1があれば、どれだけ楽だったんだろうって思うよ。
 そのプロジェクトには、メッセージングの事を良く知っている開発者が数人しかいなかったんだ。 だから、教育したり、ドキュメントを書いたりしたよ。

*1 『 Enterprise Integration Patterns 』の事。

非同期メッセージを使った開発で一番難しいのは、メッセージとメタデータの管理だよ。 こういうコンセプトは、アプリケーション開発者にとっては今まで使った事ないから、なじみのないものなんだ。 でも、彼らが学ぶのは早かったよ。アーキテクトがチームと非常に親密に働いてたし、コミュニケーションもよかった。 だから、うまくいったんだ。
 実際のところ、大規模なインテグレーションプロジェクトに関わって、 開発の経験も豊富な人達は、この本で紹介しているほとんどのパターンを使っているよ。

時々、読者からメールをもらうんだ。「2 年前に、君の本が欲しかったよ。」ってね。 彼らはメッセージングシステムについて学ぶのに苦労したようだね。 ただ、今の彼らにとっても私の本は価値があるよ。この本でチームのメンバーに学んでもらったり、共通の語彙として使ったりできるからね。

-- 1 年ぐらい前、あなたのサイトを見つけたんですよ。その頃、僕は IBM WebSphere MQ を使って、帳票システムを作ろうとしていたんですが、 メッセージングシステムを使った事がなかったんです。だから、あなたのサイトでメッセージングシステムについて学んだんですよ。

ああ、そうなんだ。役に立ったかな?

-- もちろんですよ。

 インタビュー風景

『 Enterprise Integration Patterns 』をパターン形式で書いた理由

-- なぜ、パターン形式で本を書こうと思ったんですか ?また、それはうまくいったと思いますか ?

ああ、面白い質問だね。私はデザインパターンの本を出版直後の 1995 年に買ったんだ。それで、私はパターンは素晴らしいと思って熱中したんだ。 長い間、私の知っている本当のパターンの本は一冊しかなくて、それは GoF のデザインパターンの本だったんだ。 私は長い間、パターンをオブジェクト指向以外の領域では使えないと思っていたし、使わなかったんだ。 なぜなら、僕の思考はデザインパターン本に大きな影響を受けてるし、パターンはオブジェクト指向開発のためのものと習ってきたからさ。

Martin が『 PoEAA 』*2を書いていた時に、レビュアの 1 人に IBM の Kyle Brown が居たんだ。 彼は Martin に、「この本はメッセージングについて書かれていないね。」って言ったんだ。 Martin は「そうだね、でも、私は本を書き上げたいんだ。メッセージングについてとりあげたら、本は 2000 ページぐらいになるだろう。 それは無理な相談だよ。」って答えたんだ。

*2 『 Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series) 』の事。

私は 2001 年の秋頃に ThoughtWorks へ入社したんだけど、 Martin は私がエンタープライズインテグレーションの経験が豊富な事を知っていたんだ。 だから、 Martin は私に Kyle Brown を紹介してくれたんだ。彼らは、パターンが大好き(pattern people)なんだ。パターン形式で説明するのは、とてもよいアイディアだよ。

全てのパターンに関する本は、全く違うパターン形式で書かれてるんだ。例えば、私にはちょっと構造を重視しすぎているように見えるけど、 デザインパターン本はものすごく構造化されている。POSA本*3 もそうだよね。 それに比べると、 Martin の本はすごくルーズな形式だ。 だから、私達はどういう本を作るのか考えたんだ。 私は、パターンの形式が大好きなんだ。でも、私達はパターンについて知らなくても簡単に読める本を作りたかったんだ。

*3 Pattern-Oriented Software Architectureの略。

私達の本には見出し、コンテキスト、フォース、ソリューションといったものがないんだ。だから、もしパターンについて全く知らなくても、この本は読みやすいと思うよ。 もちろん、パターンを知ってれば、もっと楽しめる。フォーマルなパターン形式を重視しないという決断は正しかったと思う。 私は、この本で一番重要なのはエンタープライズインテグレーションで、それを説明するのに便利だからパターンを選択したんだ。 パターン中心の本で、たまたまエンタープライズインテグレーションを扱っているものは作りたくなかった。

エンタープライズインテグレーションは非常に広範囲な話題なんだ。 もし、この本が 700 ページあったとしても、それでもエンタープライズインテグレーションのほんの少しの範囲しかカバーできないと思うよ。 でも、パターンを使うと 1 つの問題に集中できるからね。別の問題を考えたいと思ったら、別のパターンとして扱えばいいからね。

それに、読者が特にプロジェクトで適用する際にリファレンスとして使ってもらうためにも、パターン形式は便利だよ。 プロジェクトで働いていて、何かを知りたいと思うだろ。 でも、700 ページの本を読む時間はないから、10 ページを読むだけにしたいだろ。 だから、短時間で読めるパターン形式はすごくいいんだ。 1 つのパターンを読んで、次に関係するパターンを読むのはすごく楽だしね。必要ならばもう 1 回読めばいいし。 あとは、パターンの事を意識する、しないに関わらず本が読めるというのは、読者に受け入れられやすいから、いい形式だと思うよ。

それから、パターン形式を使って書くのは楽なんだ。パターン形式には構造があるだろ。 長いストーリーで優れた技術書を書くのはとても難しいんだ。アレンジもできないしね。 それに、書く時にモチベーションを保ち続けるのも難しいんだ。 でも、パターンを使って書くと、これらの事が少しは簡単になるんだ。 だから、パターン形式で本を書くのは大好きだよ。 もし、またエンタープライズインテグレーションの本を書くとしても、きっとパターン形式で書く事になると思うよ。

何でもエンタープライズインテグレーション ?!

-- エンタープライズインテグレーション以外で、興味を持っているソフトウェア開発の分野は何ですか ?

いい質問だね。 エンタープライズインテグレーション以外に興味を持っているのは、ソフトウェア開発における社会性の側面だね。 ソフトウェア開発においてどのように開発者が交流するかという事さ。 視覚を通じた情報伝達や人間的な側面に興味があるんだ。

あとはアスペクト指向開発をどのようにサービス指向アーキテクチャに適用するかって事に興味があるね。 サービス指向アーキテクチャには、機能や横断的な関心、資産、サービスがあるだろ。 それとは別にサービス指向アーキテクチャにはセキュリティ、ロギングといったアスペクトがあるよね。 だから、これらの機能と横断的な関心の関係にはすごく興味があるのさ。 あと、イベントドリブンアーキテクチャにも興味があるよ。
 でも、最近は、興味を持った事が何でもエンタープライズインテグレーションに関係してしまうんだ。 私は色々なものに興味を持つんだけど、「ああこれもエンタープライズインテグレーションじゃないか!」って感じるんだ。 アスペクト指向開発も、イベントドリブンアーキテクチャもインテグレーションに近い興味だよね。


ソフトウェアパターン

-- ソフトウェアパターンの最初の印象はどうでした? それから、今はソフトウェアパターンについてどう思いますか ?

パターンとはどんなものかという話は聞いていたから、デザインパターンの本を初めて本屋で見つけた時は、面白そうに見えたね。 今でもデザインパターンの本は好きだよ。すごく役に立つコンセプトだと思う。 デザインパターンは、過去 10 年間に起こった重大な発見のひとつだと思うよ。 他にも Martin の本や J2EE パターン、たくさんのパターン本が開発者のコミュニティに大きな影響を与え続けていると思う。 パターンがポピュラーになるのはいい事だと思うし、そうなって欲しいよ。 でも、人々は、少しパターンという言葉を乱用しているように見えるよ。 パターンがポピュラーになって、誰もがパターンと関わりを持ちたいと思うようになっているんだろうね。 最近は、注目を集めたいものに対して何でもパターンという言葉を使うだろ。 たとえば、多くのカンファレンスで、◎◎パターン、パターン△△みたいに。まあ、これは成功の代償とも言えるけど。

-- Christopher Alexander *4の本は読んだ事がありますか。

*4 建築家。パターンランゲージの生みの親

うん、これについても面白い話があるよ。 私は、技術的な部分にしか興味がなかったから、デザインパターンの本*5の "概論"と"終わりに"の章は読んでなかったんだ。だから、パターンの源流は知らなかったんだ。

*5 『 Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing) 』の事。

その後、2001 年にインテリアデザインアーキテクチャのクラスを受講したんだ。 そこで私は、インテリアデザインのクラスで Alexander のデザインパターンの本を教科書として薦められたんだ。 その本を読んだときに思ったんだ。「不思議なくらいコンピュータのパターンとよく似てるよな。」って。 家に帰ってから、デザインパターンの本を引っ張り出してきて、参考文献の中に Alexander の本を見つけて、 「ああ、同じものだ!」って気付いたんだ。
 その後、インテリアデザインのクラスの先生のところにいって、 「コンピュータサイエンスの世界では、このパターンはすごく有名だよ。」と説明したんだ。 すると先生は、「 Alexander はアーキテクチャと数学の勉強をしたんだ。」って教えてくれたよ。

-- 数学ですか?

そうだ。基本的にはコンピュータサイエンスなんだけど、当時はコンピュータサイエンスの教育はなかったんだ。 だから、彼は建築家もあり、数学家でもあるんだ。 これは偶然の一致じゃないよ。彼は経歴の初期にコンピュータの人工知能に関わっていたんだ。すごく奇妙な関係だよね。

-- 面白い話ですね。

そうだろ、面白いんだ。


小さい頃の夢

-- 子供の頃、何になりたいと思っていましたか?

私はドイツで育って、10 年前にアメリカに来たんだ。だから、25 歳までドイツにいたんだ。 ドイツの子供はみんなエンジニアになりたがっていると思うよ。

-- 本当ですか?

そう思うよ。たぶん日本の子供も一緒なんじゃないかな。 日本もドイツも自動車や化学エンジニアリングで有名じゃないか。だから、たくさんのエンジニアリング文化があるんじゃないかな。

-- それはマイスターの伝統からきてるんですかね?

うん、そう、そう。ドイツは、マイスターの長い伝統があるからね。 あれは、ある種の クラフトエンジニアリング( craft engineering)だから。今でも文化的な影響はあるよ。 だから、子供がエンジニアになりたいと思うのはごく普通なんだ。

だから、私もエンジニアになりたかったんだ。 子供の頃は、私、いや誰もコンピュータを持っていなかったんだ。 だから、機械技師になりたかったんだ。私は機械で動くおもちゃをたくさん持っていたんだ。 でも、機械は難しいんだよね。壊れやすいから。だから、最初に電子回路機器を見つけたときには大好きになったよ。 だって、すぐに変更できるし、大きな機械のように高くないし、簡単なんだ。 だから、AND/OR ゲート、TTL*6 などをたくさん持っていたよ。

*6 Transistor-Transistor-Logic:半導体を用いた論理回路の代表的なもののひとつであり、1970年代にTexas Instruments社 の標準ロジックICファミリ(74シリーズ)により広く普及した。

ドイツの中学校に通っていたときに、全校で 1 台だけコンピュータがあって、そこで初めてコンピュータに触れたんだ。 そこで私はコンピュータに興味を持った人達が集まるグループを見つけて、参加したんだ。 コンピュータサイエンスのクラスじゃなくって、夕方に興味を持った人達が集まるグループさ。みんなすごく面白かったよ。 みんな、BASIC を書きたがってたんだけど、1 台しかコンピュータはないから、 黒板にコードを書いて、それからみんなで議論して、先生がそれをタイプして結果を見るんだ。今じゃ考えられないくらいプリミティブだよね。

その後、本当に自分のコンピュータを手にいれたんだ。 Commodore のすごく単純なやつだ。それで BASIC を始めたんだよ。すぐに、BASIC は遅いって事に気がついたので、 ホストコンピュータにレコードを送信するコードを書いたのさ。

変な話なんだけど、私は 10 本の指でタイプできないんだ。だから、本やソフトウェアを書くときには 2 本指でタイプするんだよ。 そもそも、私は 10 本の指を使うタイプを習った事がないんだ。 タイプを習った頃、私はとても小さかったんだ。機械式のタイプライターで習ったんだけど、私は小さすぎて、全部の指を使えるほど 指の力が強くなかったんだ。だから、2 本、あるいは 4 本の指を使う事しか学ばなかったんだ。それから変わってないんだ。

-- アメリカとドイツのキーボードのレイアウトの違いは関係ないんですか ?

ドイツのキーボードレイアウトはウムラウトなどがあるから、ちょっと違うんだ。 今はアメリカに居るだろ。実家に帰って、ドイツ語をタイプするのは難しく感じるね。


ソフトウェア業界で働き始めたきっかけ

-- いつソフトウェア業界で働きはじめたのですか?

長い間コンピュータを触ってはいたけど、うーん。 最初にコンピュータでお金を手に入れたのは、ソフトウェアではなくハードウェアを作ってなんだ。 私の友達の多くはCommodore、家庭用のコンピュータやゲームを持っていたんだ。 だから、コンピュータハードウェアの拡張モジュールを作って、20 ドルくらいで売ったんだ。

最初にプロフェッショナルなソフトウェアを開発したのは、17 歳の頃かな。 ビデオゲームを売ろうとして、カーレースゲームを作ったんだけど、誰も買ってくれなかったよ。 次は、1987 か 1988 年、私が大学生の頃に化学分析の数値分析を行うソフトウェアを開発したよ。これが私の作った最初の商用のソフトウェアだ。 当時は IBM PC と Turbo Pascal がポピュラーで速かったから、このソフトウェアでは、Turbo Pascal を使って開発したよ。 このソフトウェアを開発するために、私は自分 1 人だけの会社を持っていたんだ。


プライベート

-- 好きな本と映画、言葉を教えてください。

好きな本

実のところ私はほとんど技術書しか読まないんだ。私の持っている本の 80% はコンピュータの本だ。 技術書以外にも、建築のアーキテクチャデザインの本も読むよ。

好きな映画

あと映画は、色々なジャンルの映画が好きだね。アニメーションだと『もののけ姫』や『千と千尋の神隠し』が好きだね。
他には、暗い黙示録的な映画、『ブレードランナー』のような映画や、 『マッドマックス』のような車の映画、 それから、『メトロポリス』のような古いドイツの映画も好きだ。

-- フリッツ・ラングの映画ですよね ?

そう、彼の映画だ。知ってるのかい。『メトロポリス』はすごく好きなんだ。 家にはすごく大きな『メトロポリス』のポスターが貼ってあるんだ。でも、『ブレードランナー』がベストかな。 ああ、『ブラジル』もだな。

-- 僕はテリー・ギリアムが大好きなんですよ。

うん、ああいうスタイルは好きだ。

好きな言葉

技術系の言葉でいうと、 "Computer science is the field we can solve every problem with just one more level of indirection." みたいな感じかな。

-- どういう意味ですか?

これは冗談なんだ。コンピュータサイエンスにおいては、人々はデザインの問題を抱えているんだ。 つまり、常にもう一段上のレベルの間接性を求めるという問題だ。人々は、それが普遍的な解決方法だと思ってしまうんだ。 コンピュータサイエンスにおいては、もう一段上のレベルの間接性を導入すれば何でも解決できるってね。 だから、私達はつい、いいか悪いかに関係なく、もう一段上のレベルの間接性を導入してしまうんだ。 そう、これは聖杯さ。だからこれは冗談さ。


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

-- 私達の読者、特に若いエンジニアに何かアドバイスをいただけませんか。

先生を見つけよう・コミュニティに参加しよう

うーん、そうだね。ソフトウェア開発においてもっとも重要なのは、メンター、つまり個人的な先生、非公式な先生を見つける事だと思うんだ。
 私は始め、一人でコンピュータサイエンスを学んだから、習得はとても困難だったし、多くの間違いを犯していたんだ。 だから、アイディアを交換するコミュニティに参加する事はとても大事なんだ。 たとえ自分がすごく優秀でも、全ての問題は解決できないだろ。 だから、コミュニティの一部になる事は重要なんだよ。
 私は子供の頃、コンピュータで一人で遊ぶのが好きだったから、とても孤独な子供だったんだ。 コンピュータはすごく面白いし、中毒性があるだろ。でも、これは大失敗だったと思うよ。

ソフトウェアエンジニアのイメージは一匹狼、つまり非社交的だと思うんだ。これって、ステレオタイプだよね。 私は、このステレオタイプはよくないと思う。 最近、私は、大勢のとても社交的なソフトウェアエンジニアに会ってるから特にそう思うよ。 だから、若いエンジニアへのアドバイスは、コミュニティに参加しろって事だ。 オンラインの電子的なものでもいいし、オフライン、 例えばパターンワーキンググループみたいなものでもいいし、 カンファレンスに参加するのもいい。交流することは本当に重要だよ。 もちろん、学ぶために一番よい方法は、教えてくれるメンターを見つける事だけど、いつも可能なわけじゃないから。

-- 最近は、インターネットやオープンソースのおかげで、コミュニティに参加しやすくなっていますよね。

そうだね。だんだん容易になってるよ。私が子供の頃は、まったくコネクション*7がなかったから。 昔、300ボーのモデムを使おうとしたけど、できなかったんだ。 両親は電話料金が高くなるのを恐れて、私がそれを使うのを望まなかったからね。でも、最近は本当に簡単だよね。

*7 人間とネットワークの両方におけるコネクションを指していると思われる。

ソフトウェアで遊ぼう

もうひとつのアドバイスはすごく重要だよ。 学校に行っていたとき、コンピュータサイエンスとマネジネントの学位を勉強したんだけど、 コンピュータサイエンスとマネジネントの人達の態度を見るのはとても面白かったよ。 マネジネントは、「技術野郎はただ遊んでるだけじゃないか!」ってよく言うよね。

-- そうですね。

そう、よくある文句だ。 私は「そうだよ。私達は遊びたいんだ。だって、遊ぶ事は学ぶ事なんだから。」って答えるんだ。 子供はどうやって学ぶと思う?遊ぶ事によって学んでいくだろ。
 遊ばない人々は学ばないと思うよ。遊ぶって事はすごく重要なんだ。 コンピュータやソフトウェアで遊ぶって事は、学ぶ事の一部さ。 だから、「遊んじゃダメだ!」って言っている人は、「学んじゃダメだ!」って言っているのと同じだよ。 遊び続けている人々は誇りを持つべきだ。だって、彼らは学び続けているんだから。 多くの人々が新しい技術を学びたがっているよ。ソフトウェアで遊ぶって事は、ソフトウェアの重要な一部分であり、楽しみでもあるんだ。

-- そう思います。今、クライアントのオフィスで働いているのですが、彼らはとても厳しいのです。 だから、インターネットや新しいソフトウェアで遊ぶ事ができないんですよ。

君は多くのものを見逃しているね。 マネジネント、ビジネスの人は、遊ぶ事は学ぶために最適だという事を理解する必要があるよ。 それに遊びはとてもクリエイティブだ。だって、多くのソフトウェアはクリエイティビティに関するものだからね。 もし、自分がやっている事が面白くないと思えば、いいアイディアは浮かんでこないよ。 面白ければ、たくさんいいアイディアが浮かんでくる。 楽しみを取り除くと、たくさんのよいアイディアも一緒に失われるんだ。 ビジネスの人達はこの事を理解する必要があるよ。

私は、多くのソフトウェア開発は映画や広告のようなクリエイティブなビジネスだと思うんだ。
だから、もっと楽しんで、もっとクリエイティブな経験をして、もっと遊ぶ事を人々が考える事は重要だと思う。 だって、もっとも優れたソフトウェアが欲しいんだろ。それは、クリエイティブな行為だろ。 ソフトウェア開発は軍隊じゃないんだ。もし、軍隊みたいな感じにソフトウェアを開発しようとしても、それは不可能だ。最悪だよ。

最後に・・・

-- では、最後の質問です。他に読者に伝えたい事はありませんか。

ひとつは日本でインタビューを受ける事ができて、大変光栄に思うよ。

-- 本当ですか。

もちろんだよ。ビジネスでは今回初めての来日だ。そして、興味深い人にもたくさん会えたしね。

物事を面白くするのは自分自身!

もうひとつは、モチベーションについてだ。 ソフトウェア開発に関わる人達をたくさん見てきたけど、多くの人達はソフトウェアは退屈だと考えているよね。 古かったり、単純だったりするから、退屈して別の事をやりたいと望んでいる。 でも、これはほとんどの場合、間違いだと思うんだ。 表面をなでただけ、つまり、ハイレベルな部分だけを見ていると、退屈なのに感じるのかもしれないね。 でも、本当に調べ上げて、フォーカスを絞ると、単純なものでさえ、とても面白いんだ。

それなのに、人々は時々早くあきらめすぎるんだ。 「ああ、私は何でも知ってるよ。これはたいして面白いものじゃない。」ってね。 時間をかけて調べる事で、単純なものでも実は非常に興味深いものなんだって事を学ぶべきなんだ。

だから、開発者にとってとても重要なのは謙虚さだよ。謙虚であれば、多くの事が学べる。 多くの人達は飽きるのが早すぎると思うよ。 私は、どんな問題であれ、単純だとは思わないんだ。 だって、どんな単純なものの中にでも、とても面白いものを見つける事ができるからね。 だから、多くの人達も同じように考えて欲しいな。単純な問題は存在しないんだ。

物事を面白くするのは自分自身なんだ。問題自身が面白いわけではない。 自分がどう考えるかによって、物事が面白くなるかどうかが決まるんだ。 だから、自分で面白い事を見つける事ができるんだ。これはとても重要だよ。

-- とてもよいアドバイスですね。今日はありがとうございました。



取材を終えて(インタビュアーの感想)

Gregor さんは、おしゃれでパワフル、社交的、かつオタク気質な人でした。 会う前は、とてもテクニカルな人だという印象を持っていたのですが、 ソフトウェア開発におけるコミュニケーションに興味があったり、コミュニティへの参加を薦めるなど、バランスの とれた才人でした。


今回のインタビューは、Gregor Hohpe さん、Sidney G. Pinney さん (ThoughtWorks .Inc) 、 鷲崎 弘宜 さん ( 国立情報学研究所 ) 、パターンワーキンググループ のご協力のもと、行われました。 本当にありがとうございました。



©2004 OGIS-RI Co., Ltd.
Prev Index
Prev. Index