ObjectSquare [2000 年 10 月号]

[OOエンジニアの輪!]


OOエンジニアの輪!

〜 第5回 長瀬嘉秀さんの巻 〜


ご無沙汰しています。ちょっとだけお休みしていたこのコーナーですが、皆さまから熱烈なリクエスト(があったかどうかは定かではありませんが…)により、今月より復活いたしました!(…また不定期にお休みするかもしれません??)

さて、今回のゲストは株式会社テクノロジックアートの代表取締役、長瀬嘉秀さんです。長瀬さんは「パターンハッチング」等の翻訳、bit 誌の連載など、多岐にわたりご活躍ですが、最近は XP(eXtreme Programming) に関する書籍「eXtreme Programming explained」の翻訳をされています。XP に関しては ObjectDay 2000 でもご講演いただきましたが、今回のインタビューでもお話を伺っています。


オブジェクト指向に至るまで

--- まず、オブジェクト指向に関わるようになったきっかけをお話いただければ。

私、構造化分析・設計を仕事でやっていたんで、その延長線上にオブジェクト指向分析があって。それをマスターするためには言語を知らなきゃいけないでしょっていうんで C++ をやり始めたというところですね。

--- それはいつ頃になるんですか?

Shlaer/Mellor のオブジェクト指向分析の本が出たぐらいですねぇ。あれをコンサルしなきゃいけない、という話になったんで。で、外国人の C++ のトレーニングを聞きに行ったんですよ。

--- お仕事はずっとコンサルティングみたいな仕事をやってこられたんですか?

どっちかって言うとコンサルティングですね。

--- テクノロジックアートさんを作られたのはいつですか。

平成元年です。こういう仕事をやり始めたのもそこからですね。その前は朝日新聞という会社にいたんで。情報システム部ですね。新聞社の社内システムを 3 年ぐらいやって、ちょっとそれじゃつまんないんで、辞めたという。

--- で、いきなり会社を興されたんですか?

そうですね。別に興す気はなかったんですけど、いろんな人たちが「せっかくやるんだったらどこかに勤めるんじゃなくて、コンサルみたいにやれば?」って言うから、やったんですけどね。


オブジェクト指向のメリット、デメリット

--- オブジェクト指向の好きなところはありますか?

アイディアが出せるって言うかね。例えばクラスの構造をこういうふうにしたらいいんじゃないか、とか。こういうふうにしたらすごくいいプログラムになるんじゃないか、とかね。

--- それをグラフィカルに表現できる、ということなんですか?

ま、それはグラフィカルじゃなくてもコードでもいいんですけどね。今まで構造化だと決まっているじゃないですか、ファンクションを呼び出して、っていう。オブジェクトじゃないと、ツリー構造で行って、戻ってくるという制限があるから、構造的に見て「きれいなプログラム」というところに限界があったって言うかね。きれいだけど、アイディア的にコードを見てうならせる、というものが少なかったと思うんですよ。

--- それはパターンの適用なんかにもつながるのでしょうか。

そうですね。自分で「こんな構造にしたらいいんじゃないの」と思い付くのもいいですし。もちろんデザインパターンを適用できたらそれもうれしいし。「こういうコードにしたらいいんじゃないのか」というのがオブジェクトだとそのまま表現できて。だから好きな人はすごくはまっていきますよね。それはいいところで、楽しいところだと思いますね。

--- やっぱり「楽しい」ということなんですかね。

COBOL 言語でも C 言語でも、あんまり楽しくないんじゃないかなぁと思うんですよね。トリッキーなことが少ないと言うか、書けることに限界があるんで。

--- COBOL や C の開発もされていたんですか?

朝日新聞のときは COBOL でしたからね。学生時代からバイトで COBOL のプログラムはやっていましたし。だから長いですね。7 年も COBOL をやっていたもんね。いい加減にいやですね(笑)。

--- 逆にオブジェクト指向の良くないところ、ってありますか?

コードの品質を上げる、見極めるのが難しいっていうところですかね。構造化プログラミングだとベタになっているから、テストとかをやっていくとある程度品質が測れるんですよ。オブジェクト指向だとオブジェクトとして飛んで行っちゃうのでなかなか測りづらいというのが、デメリットというか大変なところじゃないかなぁと思うんですよね。

あと、分かりやすい構造で作ると他の人が見ても分かりやすいんですけど、変な構造になっちゃうと悪くなっちゃう。その悪くなったのが、かなり大きく悪くなる、って言うかね。構造化で作ると、スパゲッティでかなり悪いんだけれど、でもこのぐらいだね、っていう範囲なんですけど。オブジェクトで悪くなると、どうしようもないくらい悪くなっちゃうんで。しかも大量にどうしようもない、という事態になるんですよね(笑)。

--- それはかなりまずい課題ですね(笑)。

COBOL のプログラマは昔いっぱいいたけど、その人たちはみんなある程度の品質でコードが書けるわけですよ。でも Java のプログラマでも、オブジェクト指向の概念を分かっていてきれいに書けるって、みんながそうではないですよね。レベルがすごくいっぱいあって、構造化プログラミングと同じような感じでシーケンシャルな流れでコードを書いている人もいるんで。だから書いたコードの品質もなかなか一定していないというところが課題かな、と思っているんですよね。その辺、教育だとかいろんなところを変えていかないといけないと思うんですよ。

--- どのようにしたらいいんでしょうね。

オブジェクト指向の基礎技術ということで、考え方を教えないとだめじゃないかなと思うんですよね。多分今って、言語のシンタックスだけ教えておしまい、みたいな感じが強いんじゃないかなと。もっと本質的なことを教えないといけないと思うんですよ。そうしないといつまでたっても「Java できます」という人がいっぱいいても、みんな使えないということになっちゃいますから。そうするとソフトウェアが作れなくなるわけですよね。で、日本で Java を書ける技術者が少ないからといって、インドから人を持ってくればいいのか、ってね。それも情けない話ですからね。


コンサルタントの悩み(笑)

--- コンサルタントとしては説得力ありますよね。COBOL もやっていた、構造化もやっていた、やっぱりオブジェクトは楽しいんだ、ということで。

デザインパターンでもなんでも、自分でやってみないと分からないじゃないですか。私は常に、コンサルやる人はプログラムもやらなきゃ絶対駄目だ、と思っているんですよね。モデリングやっているだけじゃやっぱり分からないし、さらに実際コンサルやるとプログラムコードが分からないと説得力がない。困ったことっていうのはコードに落ちて困ったことが出るんで、プログラム言語はやらなきゃいけないと思うんですよね。ただまぁ、自分が書いたコードがシステムとして動くということはほとんどないですけどね。

--- コンサルタントがコードを書ける、ということは大事だと思うんですけど、コンサルタントがコードを書いて失敗することはないですか?(笑)

(笑)

--- 私の経験で言うと、あるコンサルティングをやったときに、非常にモデルできれいごとを言って、「サンプルコードを作ったので動かします」って言うと、すごくくだらないところで落ちるんですよ。きれいごとを言う自分と、間違いを犯す自分のギャップにすごく悩んだりするんですよ。そういう失敗談ってないですか?

それはね、結構ありますね。きれいな構造になっているのに、コードを書いたら汚いことがいっぱい出てきて、「この文法どうやればうまくきれいにコードで書けるのかな」って分かんなかったり、思わず汚いコーディングをしたりして「いまいちだな〜」と思いながら、(お客さんに)見せる時に「ちょっとここ汚いですけど」って誤魔化したりしますけどね(笑)。

--- そういうもんですよね。

そうすると(お客さんから)「いや、ここ、こうやって書けばいいんですよ」って言われたりするんですよね(笑)。

--- 私だけじゃないんですね。ちょっと安心しました。

すべてにおいて完璧にできるっていうことはないんで。それはしょうがないと思っているんですけど。

--- だから、コンサルタントはコードを書けなきゃいけない、というのは非常にそう思うんですけど、目の前で書くと失敗するからやめておいた方がいいんじゃないかと(笑)。


XP の魅力

--- XP ってどういうところがいいんでしょう?

やっぱり人間味があるっていうかね、人間の真理を突くような進め方っていうか観点から見ているので XP は好きなんですよね。例えば、XP だと週 40 時間労働、っていうのがあるんですよ。それ以上やると、辛くなってやる気がなくなる、とか。雰囲気としてはオープンスペースでコミュニケーションしやすい方がよいとか。そこにはオモチャを置け、だとか。仕事がうまくいくのがチームの幸せというよりも、自分の生活を大事にする環境が作れることがチームにとってすごくいいことだ、みたいなね。

--- 方法論でそういうことまで書いてあるのって面白いですよね。

(そのような方法論は)なかったですからね。そういう意味で、人間味のあるというかヒューマンチックな側面のある方法論なんで、面白いなぁと思っているんですよ。

--- でも、本当に(アメリカでは)やっているんでしょうかね。

全部やっているかどうかってのは…。でもね、(アメリカの)XP のメーリングリストだとすごい量が流れてて、「やってみた」とか多いんで。随分やっていると思いますけどね。

--- 私なんか非常に怠慢な人間なので、週 40 時間だといい仕事ができないって言うか。適度にプレッシャーがかからないといけないんじゃないかなぁと思うんですけど。恵まれた環境でやったら遊んでしまうんじゃないかと(笑)。

でもね、そういう意味だと計画を立てるのが大変なんですよね。計画が 1 日単位とか、3 日単位とかすごく狭いんですよ。だから、時間を無駄にしないような感じなので、その方が大変なんですよ。

--- 楽しませながら遊ばせない、と。

そうそう。結構大変ですよね、達成しなきゃいけないので。まぁ、達成できなかったらそれは計画を見直すんで、別にいいんですけど。日本人はだらだらとやるタイプの人が多いんで、「そんなに細かくやるのか」という話はあるかもしれないですね。

--- そもそも XP を知ったきっかけは何ですか?

去年 OOPSLA に行って、そしたらみんな XP のバッジをつけていたんですよ(笑)。「ああ XP というのが流行っているのかなぁ」と。その時にちょうど「パターンハッチング」の翻訳が間に合っていたんで、アジソンからアメリカに直接送ってもらってアジソンのブースに出しておいたんですよ。そしたら、XP がいっぱい売れてて、アジソンの人と話したら「じゃあ君、XP を翻訳してみたら?」とか言われて。それで翻訳するようになったんですけどね。

--- これはいけるんじゃないか、と。

で、帰りの飛行機の中で読んでいたら「ああ、これは面白いな」という感じですね。

XP っていろいろありますけど、テストに関してはすごく面白いですよね。導入できること、できないこと、例えばペアプログラミングなんていうのはなかなか難しいと思うんですよね。1 台のコンピュータを 2 人でシェアするでしょ。どうしても 1 人 1 台ずつみたいな感じになるんで。それをやるのは難しいかな、とかね。

--- ペアデバッギングはやれますよね。

ああ、それはね。その辺とか、できそうなこと、できそうもないことがいくつかあって、その中で一番、自動化テストについては有益だと思ってて。さらに JUnit を Kent Beck と Erich Gamma が開発しているじゃないですか。それはすごく有効じゃないかと思っててね。

--- ああいうものがダウンロードしてみんなが使えるとはいいですよね。

ええ。だからそこについては、もうちょっとみんなで何かしよう、ということにしたいとは思っているんですよね。


カタリシスとは?

--- 「パターンハッチング」を翻訳されていますけど、パターンとの出会いはいつですか?

パターンとの出会いも「パターンハッチング」を翻訳するっていう話になってからですね。実際には、カタリシスのトレーニングを受けにアメリカに行った時、カタリシスのプロセスの中にパターンが出てくるんでそれでは知っていましたけどね。

--- カタリシスというのは方法論なんですか?

方法論ですね。ただし、開発プロセスのところはあまり書いていないんで。

--- パターンということを非常に意識した方法論ですよね。

そうですね。パターンとコンポーネントを意識しているんですよ。

--- それはどこで見つけられたんですか?

それはたまたま、3, 4 年前の OOPSLA に行って、なんか名刺交換をしたんですよ。そしたら分析・設計コースの案内が来ていて、コンポーネントベース…とか書いてあるから、「コンポーネントベースの分析手法なのかな」と思って行ったんですよ。そこからですね。

--- 書籍が出ているものなんですか?

出てます。英語でしか出ていないですけど。

--- 翻訳されないんですか?

翻訳はね…。やろうとは言っていたんですけど、そのままポシャりましたね。でもポシャったのは多分出版社としての事情もあるんで。分厚いんですよ、こんなに。こんなに分厚いものを訳して、果たしていくらになるの?どのくらい売れるの?ってね。昔みたいに OMT 本しかないっていう状況じゃないですから、そんなに出ないよね、というのがあってそのままになっていると想像しています。

--- もし出版されてたら「コンポーネントベースの UML に基づく開発方法論」とかというタイトルになったんですかね。

ああ、そうですね。でもみんな買わないんだろうな、高くて(笑)。だったら要約して薄いのを書け、という状況になっていますね。


オブジェクト指向はおとなしくなった?

--- オブジェクトを好きな人って、真面目で勉強好きな人ばっかりになってきたって感じですよね。

ああ、そうですね。ハックを好きな人が薄くなったですね。それはやっぱり、Java がハックできないから、やりようがないからおとなしくなったのかもしれないですね。

--- Smalltalk のような言語だといろんなことができちゃいますからね。

そう、ハックとか技とかメタモデルいじっちゃうとか。そういうことができるから、それは面白いなあということになるじゃないですか。でも Java だとできることが制限されるんで。それにやって意味があるのかっていうね。「Java でハックしたぜ」と言っても誰もすごいとは思わないよね。ハックしてすごいなと思う人が Java 言語に対してそんなに素晴らしいとは思ってないから。だから Java でハックしてもしょうがないし、しないし。そういう意味でおとなしくなってきたのかもしれないですね。

--- オブジェクト指向全体がビジネスに向いてきた、ということなんでしょうね。

そうですね。あと、UML とかにしても、統一されちゃったからおとなしくならざるを得ないっていうかね。喧嘩できないですからね。表記法や方法論がばらばらだったら、「うちの方法論はこれが違うんだぜ」みたいにやれるけど、あそこに乗らない人はケースツールで図も書けないから、どうしようもないですよね。

--- そのうち刺激のある変わったことも出てくるかもしれないですね。

おとなしくなった分、その欲求不満のはけ口がね。

--- XP なんてちょっとそうかもしれないですね。

そうかもしれないですね。みんなこぞって XP にいっているじゃないですか。Gamma とか Martin Fowler とか。


テニスで負けるパターン?

--- 趣味とか、仕事以外でご興味のあることはありますか?

趣味はね、テニスをやっているんで。週 1 回はやってますけどね。…でもなかなか集中できなくて。

--- お仕事が忙しいから?

そうそう。集中できないっていうことはどういうことが起きるかっていうと、例えば先月とか、試合で 1 回戦負けとかね。そういうことが起きるんですよ(笑)。

--- 試合中もパターンのことを考えていたとか?(笑)

いやいや、それはないけど(笑)。なんかちょっとメンタルにコントロールできなくて。

--- テニスで負けるパターン?

負けるパターン、ありますね。「意気込んで行ってしまう」とかね、「ミスを連発する」「自滅する」、なんかアンチパターンみたいだな(笑)。実力は全然こっちが上なのに、なぜか負けてしまったとかね。

--- その、実力が上だと思っていること自体がアンチパターンなんじゃないんですか?(笑)


若いエンジニアへのメッセージ

--- 若いエンジニアの方にメッセージなどありますか?

やっぱりオブジェクト指向でもね、基本的なことを一生懸命勉強してもらいたいですね。

--- もう少しかみ砕くとどういうことですか?

例えば、EJB だとか XML だとか流行っていることってあるじゃないですか。そういうことだけ飛びついてやる、ということがよくないんじゃないかなと思うんですよ。もっと本質的なことを勉強してもらいたいというですね。

あと、コミュニティ活動をいっぱいやってほしいと思うんですよね。その中からいいものが出てきたりとか、付き合いが出てきたりとかしてますんで。コミュニティ活動がきっかけで本を書いたりとかね、いろんなことになっていくと思うんで、積極的に参加してもらいたいですよね。

--- 確かに、コミュニティ活動で直接儲かるということはないんですけど、結構プラスになることって多いですよね、後から考えると。

そう。「自分は初心者なのにな」というのがあると思うんですけど、まぁそういうのは気にしないでどんどん参加されたほうがいいと思うんですよね。結局、人間って環境なんで。そういうコミュニティにいてみんなとやっていればできるようになるわけですよ。

--- 今はもう、あまり会社の枠とかは関係ないですからね。

だから会社のためにというよりも、個人のために。自分のスキルが上がったりとか、楽しいなぁと感じることをやっていく時代なんで、それが大事かなと思いますね。


--- 最後に、何か宣伝されたいことはありますか?本が出ます、とか。

XP、出ます。近日発売。(訳題「エクストリームプログラミング解説(予定)」、出版社: ピアソンエデュケーション、2000 年 10 月出版予定)

--- 結構、XP は今ブームなので、オブジェクトのコミュニティの人たちは皆さん買うと思うんですよね。それ以外のコミュニティの人々にどれぐらい広まるかはちょっと…。

そうなんですよね〜(笑)。



アンケートにご協力お願いいたします
記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点

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