[OOエンジニアの輪!]
今回のゲストは、現在 OMG ( Object Management Group ) 日本代表 の技術補佐としてご活躍されている OTI ( Object Technology Institute, Inc ) の和田 周 さんです。
オブジェクト指向のトレンドに始まり、UML や MDA の動向について、広くお話を聞かせていただきました。
|
-- 現在、どのようなお仕事をされているのですか?
OTI ( Object Technology Institute, Inc ) は OMG ( Object Management Group ) の日本の窓口も努めていまして、そこでの技術補佐をしています。OMG の動向をウォッチして、そのものの観点を補佐していくということをしています。例えばイベントを組む際の補佐などですね。喋ることもありますが。あとはフリーでライターもやっています。
-- OMG と OTI の関係、位置付けについて聞かせてください。 OMG は標準化団体としてスポークスみたいな面があって、その上で標準化に関わるという位置づけですが、 OTI の立場とは違うのでしょうか?
OMG は標準化団体です。 OTI は OMG のインターナショナルパートナーの一つでして、そこが窓口として、地域に対する普及活動や啓蒙活動を行っています。
OMG 自体の活動は、標準化プロセスを管理したり、ドキュメントを管理したり、会議を取り仕切ったりといったことを行っています。実際に標準化に携わる人たちは、企業の方や、大学の研究者なので、 OMG そのものが標準化に関わっているということではないです。
-- そういう OMG の活動なり、そういうことをやっているということを広く一般的に紹介する立場というところですね。
はい、そうです。
-- OMG で、今一番ホットなことは何でしょうか?
ホットといえば、やはりドメインまわりですね。
宇宙システムなどに使う管制系の仕様やモデルなど、僕なんかが見て分からないような仕様もたくさんありますね。
あとは、最近の話で面白いのが、ある金融系の企業が OMG に入ってきたことですね。ちょっと意外な感じもすると思いますが、ここ数年はユーザー企業の参加が多いんですよ。その企業は、金融関係の標準を OMG の標準化プロセスを利用して作りました。そうすれば、彼らが元々持っているものが標準ということになるので、彼らとしては優位ですよね。 OMG はそういったドメインの標準を作る場になってきています。
もっと技術寄りな話だと、ビジネスプロセス絡みのものがあります。
ビジネスプロセスマネジメントに関連した仕様ですとか、他にはエンタープライズ系の仕様群もあります。既存のシステムからモデルを抽出するというモデルリカバリもその一部に含まれます。基盤技術群、例えば UML 2.0 の標準化自体は 1 年くらい前にほぼ終わっていますから、仕様化プロセスとしてはもっと先へ進んでいます。
-- やはり全体的に、テクノロジという部分から、より上流のほうに標準化が進んでいきつつあるということなんですね。
はい、その通りですね。
-- 今までは、私なんかの感覚でいうと、一番初めは CORBA というイメージがあって、それから CORBA から UML という方向に進んでいっている。そしてそれがだんだんと上流なりモデリングの方向にシフトしていっているという形ですね。
そうですね。 4 年位前の時点で CORBA の標準化は終わっていて、その後はドメインに進んでいっています。活動としては、いわゆるコテコテのテクノロジの標準化はほとんど完了しています。
-- 和田さんはオブジェクト指向にいつ、どのような形で出会ったのでしょうか?
初めてオブジェクト指向と関わったのは C++ との出会いですね。
C でプログラムを書いていて、 C++ というものがあるらしい、クラスライブラリというものがあるらしい、と知ったんです。でも、その頃はクラスが何かはわかっていなかったですね。 C++ の文法自体は、文法書みたいな本を一冊読んだので理解できました。でも、 「 何のためにクラスがあるのか 」 というところがやっぱり理解できなかったんですよ。そこで、オブジェクト指向というものは、きっと C++ の文法をわかっただけではだめで、クラス等々の存在意義を理解しなければ入っていけないものなんだろうと思ったわけです。
そこで、尊敬する人のうちのおひとりでもある青木淳さんが書かれた本を読んだんです。今にして思えば一番初めに読む本ではなかったなと思いますが。 ( 笑 )
当時は周りにも情報がなくて、どんな本を読んだらいいのかわからなかったんですね。たまたま nifty を見てこれが良いと紹介されていた、とにかく読んでみたんですよ。
その本の内容としては、 内包 ( intension ) や外延 ( extension ) に関してや、 「 関係の中にクラスがある 」 といったことが書かれていたのですが、今まで読んできたコンピュータの本とは全く違うことに驚きました。それまではコテコテの文法書とか、 API リファレンスばっかり読んでいたわけですから。でも、こういう哲学的な事がコンピュータの技術にも関わらず書けるなんて、オブジェクト指向はきっと面白いものに違いないと思いました。
それからは、プログラミング技術ではなくて、当時の僕にとっては難解なオブジェクト指向の本を良く読みました。本の中には Smalltalk も出てきていたので Smalltalk もやりましたね。 Smalltalk のライブラリには Magnitude というクラスがあるのですが、 Magnitude なんて、使わないのにどうしてあるんだろうなとすごく不思議でしたね。
だから、今の新人さん達がどんなふうに勉強されているのかはわからないのですが、 「 Java の文法を覚えて、 Java が書けたからオブジェクト指向がわかった。これで OK。 」 みたいな気持になる人がいたとしたら、オブジェクト指向にそうやって入っていくことは、僕にしてみれば少し可哀そうな気がしますね。もちろん理論っぽい話だけではダメですが、一度は頭まで浸かって色々考えないと、応用が利かないんじゃないかな。オブジェクト指向はもはや、色々なものの基礎になっていますから。 Java の API リファレンスを読むにしても、オブジェクト指向とデザインパターンが分かっていないと、なぜそうなっているのか、すんなりとは理解できないですよね。
僕自身は、そうしてずっとオブジェクト指向関連の本を読み漁りましたが、分散 OS に興味を持った時期がありました。そこで、分散 OS に関する本を読みましたが、 OS のアーキテクチャすらよく理解していない時期に読んだので僕には難しかったんですね。
その時、分散というキーワードで本屋さんの棚を見ていたら、すぐ隣に分散オブジェクトの本がたまたま ( 笑 ) 並んでいたんですよ。その本を読んだら、 「 分散オブジェクトは、メッセージパッシングがネットワーク経由になっただけ。 それだけで、オブジェクト指向の枠組みをネットワーク上に展開することができる 」 というようなことが書いてあったんですね。
当たり前といえば当たり前の話なのですが、初めて見たときはオブジェクト指向の応用の広さを感じて、僕はすごく感動したんですよ。
-- そこから CORBA を始めたんですか?
そうですね。これは CORBA をやらなければいけない、 CORBA をやらなければ僕の知的欲求は満たされないって思って。 ( 笑 )
そうして CORBA の本を読んだりしているうちに、当時、創研プランニング (現 OTI ) の鈴木純一さんにコンタクトを取ってみたんです。それからのお付き合いで、今こうして OTI にいるんですよね。 ( 笑 )
-- UML の今後の動きはどうなっているのでしょうか?
ファイナルはまだ出てないですね。いつ出るのか僕もちょっとわからないですが、最終プロセスが 5 月末に終わる予定でしたが、それが終わっていなくて代わりに最終プロセス 2 が出ていました。まぁ、 2004 年中ですかね。( 笑 )
-- 何か遅れていく理由があったりするのでしょうか?
パッケージの結合を行うマージという機能に問題があるという話を聞きました。
-- 我々も UML に対しては普及に関して早い時期から取り組んできたのですが、
最近 UML 2.0 になってから、一部批判的な動きがありますよね。それについてはどうお考えですか?
マーチン・ファウラーさんのような方ですね。批判的な動きがあるのもわかります。
自分が使わない範囲のものがたくさん増えても意味がないし、そのせいで仕様が巨大に、複雑になると、必要が無い人にとってはいい気分はしないのは当然だと思います。仕様化プロセスも長くなりますしね。
ただ、使う立場の人にとってみれば、不要な機能は使わなければ良いだけの話で、使い方としては従来と変わらないと思うんですね。ドキュメントとして使いたいときはその様に使えばいいし、ホワイトボードに書いて議論したいときはもちろんそう使うこともできます。必ずしも MDA ( Model Driven Architecture ) をやらなければならないということではありません。ただ、 UML 2.0 が求められていて、それを利用したいと考えている人もいるということです。
-- MDA と UML は一緒のものではないですよね?
はい、そうです。一緒のものではないです。
-- 和田さんから見た MDA は、どういう存在のものでしょうか?
僕は、 「 オブジェクト指向がオブジェクト指向らしくあるためのもの 」 だと思っています。
コードの自動生成、あるいは executable なモデル*1 という話を取り上げて見てしまうと、 CASE の二の舞だとか、シーケンス図を使って全部の振る舞いを書くなんて冗談じゃないという話になりますよね。実際のところは、そういう風に見る人が多いですが。でもそれは当たり前のことで、僕もシーケンス図をいっぱい書きたいなんて思いません。
コードに落とすことは一番最後のマッピングでの話ですが、それよりも重要なのは、複雑な情報を色々な方向から見たときに、それらの整合性をきちんと取ってくれる仕組みや、あるいは、上流工程でしか見なくていい情報と、下流工程で見なければいけない情報をうまく切り分けて、その間をうまく架け橋してくれるようなモデル同士、情報同士の変換です。
異なる抽象度の情報ってありますよね。 MDA だと、 PIM ( Platform Independent Model ) *2 、 PSM ( Platform Specific Model ) *3 といったものがひとつの切り分けとしてあります。ただ、 PIM の中にも何段階かあるかもしれないし、 CIM ( Computational Independent Model ) *4 と呼ばれるものがその上にあるかもしれないし、ないかもしれない。いずれにせよ、そう言った異なる視点/抽象度の情報をリンクすることが MDA の意義です。コードの自動生成というのは、最終的な 「 実行可能な情報 」 への変換という、いくつかある変換の中の一つというスタンスです。
*2 プラットフォーム ( CPU 、 OS 、ミドルウェア、言語 ) に依存しないモデルのこと。
*3 プラットフォームに依存したモデルのこと。実際に開発対象となるプラットフォームの開発言語と 1 対 1 に対応している。また、 J2EE や .NET などにも依存している。
オブジェクト指向の利点として必ず教科書に出てくるのは、 「 世の中のモノは全てオブジェクトとして考えられる。考えた方が自然である。だから実装もオブジェクトにしたほうがいい。 」 ということで、実装言語としてのオブジェクト指向ありきではなく、モデリングのパラダイムとしてのオブジェクト指向ですよね。ビジネスプロセスがオブジェクト指向でできるかどうかは別として、その次くらいの段階からはオブジェクト指向で考えていくと、世の中のモノが捉えやすい。その後、オブジェクト指向言語を使うと、モデルをそのまま実装に落とすことができる。即ち 「 トレーサビリティが確保されている 」 という話になりますね。
もちろん、そう簡単に行かないことは分かっています。でも、オブジェクト指向の元々の目的は 「 自然なモデリング。そして、自然な実装 」 ですよね。
ところが、トレーサビリティを確保しようとすると、ドキュメントをたくさん書き、ドキュメントの保守も常に行い、きっちりとしたプロセス、例えば RUP のようなものを使わなければならなくなります。ドキュメントのメンテナンスができなくなると、システムを 「 正しく表した情報 」 というのは、結局コードしかなくなってしまって、トレーサビリティも失われてしまいます。
「 オブジェクト指向を使ったからといって生産性が上がらないじゃないか 」 とか、 「 オブジェクト指向って難しいな 」 というような話を聞くことがありますが、この辺りが原因の一つだと思います。何でもいいから動くものを作る、というのに比べて、システムの柔軟性や保守性を高める代わりに開発コストは上がる。
XP というものがありますよね。僕はそれほど詳しくないのですが、XP の目指しているものの一つに、コードをドキュメントにすることがありますよね。余計なドキュメントはどうせメンテナンスされなくなるから、そこにコストをかけるのは止めよう。コードという最終的に必要になるものをドキュメントとし、これを常にメンテナンスして分かりやすくしていくほうが、メンテナンス性も上がるということですよね。上流工程をおろそかにするということではなくて、結果的に無駄になるような作業を減らしてしまおうということです。開発プロセス偏重へのアンチテーゼとしては良く分かります。
でも、executable なコードというのは、最終的には一つの抽象度となるし、一つのモノの見方しか提供しない。もちろん、 IDE を使って色々と違った見方をすることは可能かもしれないですが、少なくとも情報の抽象度という意味では、もう executable なものでしかないですよね。
そうなると、やはりシステムのメンテナンスが大変になると思いますし、複雑なものを作ったら、スキルの高いプログラマはいいとしても、後々メンテナンスを行う人のスキルによってはメンテナンスできなくなってしまいますよね。もちろん 「 成果物がコードしかない 」 ということは無いでしょうし、あるいは 「 今までだってコードしか無かったんだから、コードが見やすいだけでありがたい。 」 という言い方もできるかもしれませんが ( 笑 ) 、それではあまり進歩が無いように思えます。
そこで、情報を抽象化したり、あるいはビジネスプロセスから見えるようにするというような仕組みが必要になってきますが、これは元々オブジェクト指向が目指していたことで、ドキュメントのメンテナンスが大変になる。堂々巡りということです。
そこで、スーパープログラマやアーキテクトと言われる人が少なかったり、いなかったりする場合でも、マッピングができたり、ドキュメントをきちんと常にメンテナンスされている形で整合性を取れるようにするための枠組みとしてあるのが、 MDA というものだと思います。だから、何もモデル上で情報をすごく正確に書かなければいけないということではないと思います。 MDA は、抽象的な最初の段階から、マッピングした先でリファインし、その先でまたリファインをしていくという、ごくごく当たり前な作業を補佐するための枠組みで、ドキュメント地獄を防ぐための仕組みですよ。
-- MDA について語るときにはどうしても、コードが自動的に出来てしまうというところにスコープが当てられ過ぎているというようなきらいはありますよね。
それで従来の統合ケースツールと同等に比較されたりしていますが、局面ごとに目的の違うモデルを作って変換していくという考え方は MDA が提唱している考え方以前に本来あったはずなんですよね。
そうなんですよね。本来ならオブジェクト指向はそうあるべきだったはずなんですよね。
でも、うまくいかないから飛ばされちゃったりするという話になってしまいますよね。
-- 統合ケースとは違うのは、統合ケースもある種モデル化はしていたはずなんですが、モデルがツールベンダー依存ではなくて、 OMG というところで決められた標準だというところが明らかに違うんですね。
そうですね。明らかに違いますね。
-- MDA の取り組みは、まだまだ 「 あちこちでされてトレンドにもなってきている 」 ということではないと思いますが、
大きく分けて 「 ビジネスアプリケーション系 」 ・ 「 組み込み・リアルタイム系 」 と言ったときに、 「 組み込み・リアルタイム系 」 のほうが、かなり先に MDA 化への取り組みが進んでいるという感じがするのですが、そこには何か取り組みやすさのような理由があるのでしょうか?
それはやはり、UML を使う使わない以前に、例えばリアルタイムシステムだったら動かす前にシミュレーションを行う、ということを以前から行っていたからでしょうね。SDL ( Specification and Description Language ) のような言語が存在して、利用されてきたんです。そして、システム開発においてそういう文化があった。 Executable UML の基盤になったシュレイアー・メラー ( Shlaer-Mellor ) 法*5 は、もともと組み込み・リアルタイム系のシステムを対象としていたので、実行可能なモデルを作成して、コードを 100% 自動生成することが目的とされています。あと、システムの規模が比較的小さくて、利用する技術も、何を作るべきかはっきりと分かっているため、利用しやすいということもあると思います。
-- そういう意味合いでは、組み込みのほうが進んでいるというということですよね。
そうですね。モデルが重要な位置を占めるという文化が元々ありましたから。
-- ビジネスアプリケーション系では MDA についてコンセプトはわかっているけれど、 MDA を利用した製品や事例があまり出てこないことにはどんな理由があるのでしょうか?
ひとつは、文化がないという点がありますよね。
ビジネスアプリケーション系では、リアルタイムや組み込みほど 「 設計図 」 といった考え方を重視しませんよね。複雑なシステムを、人間が見て分かりやすくするように抽象化するというのがモデルの使い方になっています。現在は、コードの自動生成というのが MDA の入口になっていますから、そうなると、コードにマッピングできるぐらいのモデルをまず書かなければいけないということになります。もちろんそのようなモデルを書いている方もいますが、話を聞く限りでは、していない方のほうが多いと思います。コードを書いたほうが早いという話になりますから。異なる視点/抽象度のモデル間のマッピングやトレーサビリティがもっと強化されれば、ビジネスアプリケーション系でも使われるようになると思います。
また、ビジネスアプリケーション系では、フレームワークや統合しなければならない技術がたくさんありますよね。
例えば、 Struts に対してマッピングを行うような MDA ツールがあったとします。次に Struts に加えて、 Spring と Hibernate を使いたいと思っても、ツールをカスタマイズする手間やコストが結構大きくなってしまいます。
-- モデルを変換するインフラが異なる様々なものに対してポータビリティを高め、MDAツール自体をきちんと提供しようとすることはまだまだ難しいのでしょうか。
そうですね。少なくともマッピングルールの記述方法 ( Query/View/Transformation ; QVT 仕様 ) が標準化されて、マッピングルールがツール非依存となって流通可能になるまでは難しいかもしれません。
-- アクションセマンティクスを実現するためには、アクション言語的なものになり、結局それはある種ツール依存なんですね。
そうですね。アクション言語はメタしか決まっていません。アクション言語がエンタープライズ系でどれくらい使われるかはわかりませんが、あまり使われないのではないかという気はします。そういう抽象度の低い情報はモデル上で表記すべきではなく、 OCL ( Object Constraint Language ) *6 やビジネスルールなどの宣言的な制約でモデルの精度を高める方が良いという話もありますね。
-- となると、どういうレベルで MDA を取り組んでいくかは難しいですよね。
そうですね。やり方には色々な選択肢があります。あと、現在の MDA はプラットフォーム依存ではないかもしれないですが、残念ながらツール依存にはなっていますから、つまりツールによってできることやその方法、対応する技術などが大きく違いますので、取り組む際の第一歩は確かに難しいと思います。
-- 最終的な executable なものを作る目的とは別に、 PIM もしくは UML Profile *7 のように、あるドメインごとにプロファイルが作られたりしていることは今盛んなのでしょうか?
はい。あと、今は DSL ( Domain Specific Languages ) *8 の話が結構盛んですね。
-- DSL は、あくまでもひとつの UML Profile として作られているというイメージでしょうか?
そうですね。 MOF ( Meta-Object Facility ) から拡張するという手もありますが、既存の UML ツールを使い回せるということや、情報の互換性を考えると、たいがいはプロファイルを利用しています。ビジネスプロセスの DSL を今 OMG で作っていますが、それもやはりプロファイルを利用することになりそうです。
UML 2.0では、UML 自体の拡張性が高まりますので、DSL を定義するコストは下がって行きます。そうなると、 UML ベースの DSL が色々出てくるでしょうね。
-- 先ほどお話にも CIM というのが出てきましたが、 PIM のさらに上のビジネスプロセスも含めて、 UML で記述していこうという動きはあるのでしょうか?
はい、あります。 OMG のビジネスプロセスのメタ仕様と、BPMN ( Business Process Modeling Notation ) というモデリング言語との互換性を持たせようとしています。 UML とノーテーションは少し違いますが、メタのレベルで巡り巡って UML と互換性を持たせるという形です。アクティビティ図で利用する UML Profile になると思います。
あと、ビジネスルールの記述をビジネスユーザーが行えるようにするために、例えばオントロジー ( Ontology ) *9 を扱うための仕様やビジネスルールを書くための仕様が作られています。自然言語解析っぽい仕様になっていますが、ビジネスパーソン、ビジネスユーザーがルールを自然言語に近い形で書けるようになります。
-- より上流になればなるほど厳密性を求めるのが難しくなって、やはり抽象的になるのでしょうか?
ある程度、ルールを自然言語に近い形で書けるようにしておいて、そこに出てくる単語についてはオントロジーの側でうまく扱えるようにマッピングをしていき、フォーマルなものに落としたり、それをモデル化したりしていくという話になると思いますね。
-- もうひとつ、ビジネスプロセスという意味合いで言うとちょっと違いますが、標準化仕様として BPEL ( Business Process Execution Language ) *10 というものがありますよね。 BPEL のようなものとアクティビティ図との連携はあるのでしょうか?
ビジネスプロセスの仕様では、BPEL とのマッピングも想定されています。
仕様はまだ策定中でして、必須ではないのですが既存の仕様とのマッピングも行うことが想定されていて、標準化案には BPEL へのマッピングがあります。
-- そうなると、わかりやすいかどうかということは別として、我々からすれば上から下まで色々なものを使わないで、 UML を使っていくということができるので嬉しいですね。
そうですね。少し話は違いますが、 SOA ( サービス指向アーキテクチャ ) *11 もそういう流れですよね。
ビジネスプロセスやビジネスプロセスマネジメントやワークフローに関する話ではなくて、 Web サービスのような、繋ぐための技術ばかりにフォーカスが当てられていますが、本質はビジネスプロセスと実装部分のトレーサビリティを確保し、いかに早く業務の変更を追従させるかという話ですよね。
-- 基本的に MDA について単体では語れないですよね。サービスというレベルの動きもあるし、きちんとモデリングしてフローとしていくという動きもありますよね。
そうですよね。そういった基盤にあてはめたり、外注したり、あるいは自分で作ったり、という形でやっていこうということですよね。
だから、例えば DSL の話が盛り上がっているということや、 CIM の方に行く流れや、 SOA の話は全部同じ方向性の話だと僕は思っています。方向性は同じで、アプローチの仕方がそれぞれ異なっているということです。
*5 1989 年に Project Technology 社の Slly Shlaer と Stephen J.Mellor によって提唱されたオブジェクト指向分析/設計法のひとつ。システムをドメインという単位に分割して各ドメインについて分析を行い、分析されたドメインを変換 ( translation ) することでシステムの実装を行う方法。
*6 主にUMLメタモデルの記述に用いられ、オブジェクトの制約条件を記述するなど、UMLを用いたモデリングを行うために用いられる言語。
*7 UMLの拡張の機能を利用して特定用途向けの拡張を行うための仕組み。代表例としては UML Profile for CORBA がある。
*8 ある問題に特化したコンピュータ言語のこと。システム化対象となる特定領域固有のモデリングドキュメントをベースにして IT システムを記述しようとするアプローチの際に用いられる。
*9 「 存在論 」 を意味する哲学用語。語彙と語彙の関係などの概念の体系を表わすもののこと。
*10 XML ベースのワークフロー記述言語。複数のWebサービスを連携させることで、複雑なプロセスフローを定義することができる。
*11 ビジネスプロセスの構成単位にあわせて構築・整理されたソフトウェア部品や機能を、ビジネスの変化に応じて柔軟に再利用したり組み合わせたりして活用することで構築される、システムアーキテクチャのこと。
-- もともと構造化というものがあって、データ中心があって、その次にパラダイムとしてオブジェクト指向があるということですね。
アスペクト指向やエージェント指向、また SOA もひとつのパラダイムだと言えますが、オブジェクト指向を置き換えるようなパラダイムシフトと言えるものは他にあるのでしょうか ?
うーん、どうなんでしょうね。僕はずっとオブジェクト指向でいくのではないかという気がします。
考え方の基礎として強力ですから。
-- オブジェクト指向は、他のパラダイムに置き換わるのではなくて、エンジニアの基本的なリテラシ*12 として残っていくということですかね。現在もオブジェクト指向と言いながらも、実際のプロジェクトでは DOA ( Data Oriented Approach ) *13 や構造化アプローチも使っていますよね。
これからは、オブジェクト指向が素直に適用できる範囲がもっと広がって、そうでない部分と切り分けられていくとは思います。
例えば、 EJB 3.0 は POJO ( Plain Old Java Object ) で実装できるようになっています。これは、EJB 特有の実装に関する知識がなくても、素直にオブジェクト指向で考えられる部分が増えるということですよね。良いモデルを作ることが、良いシステムを作ることに直結しやすくなる。
上流サイドがビジネスプロセスに繋ごうとしているのであれば、下流サイドでは MDA の PIM と PSM のソリューションを使ったり、 attribute を使って実装を隠蔽したり*14 するという具合ですね。アスペクト指向も同じで、基本的にはオブジェクトモデリングをうまくできれば、実装に特化したような部分などはあまり気にしなくてもできるようにしましょうという方向性ですよね。
ですから、パラダイムとしては変わらずに、取り組み易くなる方向へ進んでいくのではないかと思います。
*12 データ作成やプログラミングの能力などに加えて、情報を検索したり、収集・分析・発信するような 「 情報活用能力 」 を意味する。
*13 データ中心アプローチ。システム設計において、システム化の対象となる業務で取り扱うデータの構造に着眼する方法のこと。
*14 属性指向プログラミング ( Attribute-Oriented Programming ) で用いられている方法で、クラスやメソッドに属性 ( attribute ) を与え、その属性によってコードを自動生成することを指している。
-- 和田さんが今後やっていきたいことを聞かせてください。
漠然としていますが、もっとオリジナリティを出したいというのは常々あります。何をしたら良いか、よく分からないのですが... 。
僕はインプット偏重型の人間だと自分で思っているので、もっとアウトプットしなければいけないというのは常日頃思ってはいます。知識があるというのは大事だけれども、誇ることではないですよね。
-- そういう意味合いでいうと、今のお仕事は非常に合っているんですね。
はい、面白いですね。ただ、何か違うこともしてみたいという気はしています。
-- 趣味は?
料理をすることですね。レシピがあれば何でも作りますよ。この前は、アジを買ってきて、三枚におろしてちょっとした料理を作りました。自分でも食べますし、時々友達にふるまったりもします。
あとは本を読むことですね。今、 『 独創が生まれない 』 という本 ( 写真右 ) を読んでいます。
紹介してもらった本なのですが、「 オリジナリティ 」 の原点のようなところに触れている内容で、すごく面白いですよ。色々考えさせられます。
-- それでは、最後に若手エンジニア・若手学生へのアドバイスをお願いします。
常に 「 Why 」 を問う姿勢をもつことですね。新しいものが登場したときに慌てないための方法としては、何かが出てきたときにどうしてそれが必要になったのかという 「 Why 」 をまず考え、次にそれがどんなふうに実現されているのかという 「 How 」 を見る。できれば、さらに、なぜそうやって実装したのかを考える。また 「 Why 」 ですね。テーマによっては、フォーカスとか抽象度が変わりながら 「 Why 」 と 「 How 」 の連鎖がしばらく続いたりします。
そうすると、色々なものや技術が、バラバラにあって混沌のように見えるけれども、ネットワークが見えてきますよね。知識のネットワークが見えてくる。
そういうスキーマみたいなものを自分のなかに作っておけば、次に何か新しいものが出てきたときにも 「 ああ、あのことか 」 という感じで、ここは今までと同じで、ここが違うといったことがわかって、自分の中にあるスキーマにカチャッと当てはまりますよね。そうすると、あらゆる物事を今までの差分として見ることができたり、今回はこれがこう変わったから、次は多分こうなるんだろうな、ということが見えやすくなってきますよね。
一歩引いてクールに考えると言うか、メタを考えていくことが大切だと思います。
常に、モノを抽象化し、具象であるモノと抽象であるモノを関連付けつつ、抽象世界でのネットワークを作りながら具象のモノを理解していくという。
-- まさにオブジェクト指向的な考え方ですね
そういうことをしていかないと、色々なモノの関係が見えてきませんし、 「 アスペクト指向が出てきたよ、どうしよう〜。 」 というように、新しいものに対して拒否反応を起こしてしまいますよ。( 笑 )
もっと上手くやれば、抽象から、新しい具象を生み出すことができるのでしょうけど、私にはまだそれが上手く出来ません。
この辺はもっと頭の良い方々に聞いて下さい。 ( 笑 ) 今のところ、様々な具象を理解するための抽象ネットワーク、というところに留まっています。
-- 本日はお話ありがとうございました。
こちらこそ、ありがとうございました。
©2004 OGIS-RI Co., Ltd. |
|