 |
[2004 年 7 月号] |
|
[2004 年 7 月号] |
［ＯＯエンジニアの輪！］
今回のゲストは、榊原 彰さんです。 榊原さんは、日本 IBM の IT アーキテクトとして社内外で幅広く活躍されています。今回は、仕事の話から好きなものまで、RAS（Reusable Asset Specification）、アーキテクト、外資系の会社で感じることなど、ざっくばらんに話していただきました。
|
|
-- 現在、どのようなお仕事をされているのですか？
今、私は「ソフトウェアエンジニアリング」という部署で「ソフトウェアエンジニアリングの施策」を担当しています。
まず、どういう部署なのかと言いますと、IBM にはハードやソフト以外でお客様から対価をいただいているサービス、つまり、SI の開発とかアウトソーシングとかコンサルティング、研修サービス、その他諸々のサービスを提供するビジネスがあるんですね。その技術的なヘッドクォーター部門として「技術」という部署があります。その「技術」の下にあるのが「ソフトウェアエンジニアリング」という部署です。
それから、「ソフトウェアエンジニアリングの施策」というのは、主に開発プロジェクトに対してソフトウェアエンジニアリングのいろんな技術を適用したり、アセットをためこんだり、ソフトウェアエンジニアリングプロセス自体を作ったりします。
そういう社内のコンピテンシーを高めるような仕事を半分して、あとの残り半分はプロジェクトのサポートを行っています。私の専門としては、職種でいうと「ITアーキテクト」になるのですが、アーキテクチャ設計を専門分野として仕事をしています。
あと、仕事に絡んで書籍の翻訳をすることもあります。例えば、現在、仕事で Eclipse を使った開発などをしているのですが、その絡みで EMF（Eclipse Modeling Framework）を使っています。それで、今、この EMF に関する書籍「Eclipse Modeling Framework: A Developer's Guide (The Eclipse Series)」を有志で翻訳しているところです。その前に翻訳したものとして書籍「MDA モデル駆動アーキテクチャ」があります。
-- 榊原さん、社外でも幅広く活動されていますよね。
なんかいろいろ活動してきたら、すごく増えてた、という状況です。
最近だと、情報処理学会のパターンワーキンググループの活動をやらせていただいてます。また、日科技連のソフトウェア品質管理（SPC）の運営委員を 4 年前からやっています。SPC は、ソフトウェアの品質をいろいろ高めるためにどうすればいいのか、ということを研究したりしているところです。その絡みで子団体 S-open の幹事を 2 年間やらせていただきました。S-open の方は、今年の 4 月から御役目御免で、今は普通の会員ですね。あとは、同じ絡みで、ソフトウェアテストシンポジウム（JaSST : Japan Symposium on Software Testing）の実行委員をやっています。
他に所属しているのは、プロジェクトマネジメント学会（SPM）や WWISA （Worldwide Institute of Software Architects）*1です。
*1 書籍「職業としてのソフトウェアアーキテクト」の著者の一人であるマーク・スウェルが代表を務める、職業としてのソフトウェアアーキテクトの確立および育成を通じて、よりよりソフトウェアの設計・構築に貢献することを目的とする非営利団体（書籍「職業としてのソフトウェアアーキテクト」の著者紹介より一部引用）。
-- その中では、どれに一番関心があるのですか？
関心は全部にあるんですけれども、一番、ワーク・ロードがかかってるのは、テストシンポジウムです。なにせ少ない人数で、カンファレンスの計画とか実施とか、そういうの全部やりますので。
-- テストシンポジウムに参加した同僚に聞いたのですが、結構、幅広い層の人達が参加しているようですね。品質管理の人からプログラマから、すんごいバラバラの層だったと聞きました。
今年の 1 月の末にやったやつですよね？それ、第 2 回なんですよ。去年の 3 月に第 1 回を日科技連の東高円寺にある建物の中でやったのですが、そのときはテスト屋さんばっかりでしたね。今回は、トム・デマルコさん*2を呼んで客層が広がったというのと、あとロケーションが品川のコンファレンスセンターでよかったのとで、いろいろな方々に来ていただけました。
*2 書籍「構造化分析とシステム仕様」の著者であり、「品質と生産性を重視したソフトウェア開発プロジェクト技法―見積り・設計・テストの効果的な構造化」「ピープルウェア」「デッドライン」「ゆとりの法則」などの書籍を通じてソフトウェアの幅広い分野において著名。
-- オブジェクト指向と初めて出会ったのはいつですか？
正確には覚えてないですけど、92, 3 年だと思います。Smalltalk/V っていうのがあったんですよ。それを使ったのが最初です。
-- それは、お仕事で使われたのですか？
そうです。社内で使うプロジェクトマネジメントのサポートツールみたいなものを作る仕事のときに、なんか新しい技術で作りましょうか、という話になったんですね。それで僕は、Smalltalk をちょっと評価してみようか、と思って使いました。そのとき、実は、あんまり Smalltalk は好きじゃなかったですね。やけに遅いなぁ、と思って。というのも、当時は、ずっと C でコードを書いていたので、速いのが好きだったんですよ。
-- C と Smalltalk では設計思想が対極ですからね。
オブジェクト指向を、ほんとにやるようになったのは、C++ を始めてからです。
-- それは、いつぐらいですか？
Smalltalk の評価をした、すぐ後ぐらいです。
そのプロジェクトマネジメントツールは、プロジェクトの進捗とかをグラフを表す部分に Smalltalk を使って、データを作ったりする部分に C++ を使って作ったんですね。僕は Smalltalk の評価をしただけで、実際には、Smalltalk の部分ではなく、 C++ の部分を担当したんです。
-- それ以降は、ずっとオブジェクト指向に関わられているのですか？
そうですね。最近は、プログラムを書かせてもらうのが少なくなってきて残念なのですが、オブジェクト指向で一番書いたのは、たぶん C++ です。次が Java と Delphi（Object Pascal）だと思います。
-- 前回の鷲崎さんから榊原さんを紹介していただいたときに、榊原さんは「オブジェクト指向の信者じゃない」と伺いました。それは、他に何かもっといいものがある、ということなのでしょうか。あるいは、もっとプラクティカルに、使えるものであれば何でもいい、という感じなのでしょうか。
どちらかというと後者です。ソフトウェアの構造を OO 的にどう考えるかとか、そういうところは好きなのですが、こっちの言語のどこそこの文法が優れているとかコンパイラが優れているとか、そこに対してはあまり情熱を注げないんです。ちなみに、僕のコンパイラ・マニア的な情熱ってPL/I（Programming Language/I）の時代で終わってるんですよ。だから、あんまりマニアではないです。
でも、OO の重要性というのは認識しています。例えば、コンポーネントモデリングとか、いろんな技術が出てきていますよね。その根底を為す技術として OO がある、というのは重要なことだと思います。それから、今だと、パターンとかフレームワークとかがあって、かなりアーキテクチャに制約をかけることができますよね。何も制約せずに野放しにしてソフトウェアを作ると、場合によっては大変なことになると過去のプロジェクトで実感したことがあります。だから、そういうところも重要だと思っています。
ただ、技術にこだわる人って OO じゃない方がやりやすいと思える場合にも OO で作ることがありますよね。例えば、どバッチ*3なのに OO で作るとか。そうではなくて、適材適所を考えるのが好きです。
*3 典型的な手続き型のバッチ処理の意味。造語だと思われる。
-- では、パターンは、いつぐらいから始められたのですか？
パターンは、95, 6 年だったと思うのですが、GoF の本*4を日本語版が出版されたときに読んで、かなり感動したんですよ。それがきっかけです。やっぱり、今でもパターンというとすぐ GoF って連想しちゃうぐらいインパクトがあったんです。その後、金澤さんが訳されたソフトウェアアーキテクチャの POSA 本*5を読み始めるようになって、それからアナリシスパターン…と、だんだんパターンの種類を広げていった、という感じです。
*4 書籍「オブジェクト指向における再利用のためのデザインパターン」の初版のこと。今は改訂版が出版されている。
*5 書籍「ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系」のこと。
-- RAS について書かれた論文*6を読んだので、どちらかというと言うと、ノウハウの共有という方面から興味を持たれたのかな、と思っていました。けれども、そういう訳でもないということなんですね。
今は、そうなんですよ。だんだん、パターンの粒度とかアセットとか、そういったものを正しく使うための仕組みやノウハウを、どう定義するか、どう使いやすくするか、ということを考えるようになったんです。ですから、今、デザインパターン一筋という感じではないのですが、やっぱり根底にはデザインパターンがあります。デザインパターンって、内容を理解するのは難しいのですが、パターンとして一番イメージしやすいところではあると思うんですよね。
*6 IBMプロフェッショナル論文 : ツールによるアセット再利用支援に関する考察─IBMグローバル・サービス・メソッドをサポートする開発支援ツール作成の試み─
-- あの論文を読むと、IBM さんの中では、結構、知識を共有する文化があるように感じたのですが、実際のところはどうなんでしょうか。
日本の例ですが、アーキテクトのコミュニティがあります。
ITアーキテクト向けに「アーキテクチュラル・シンキング」という社内の研修コースがありまして、その研修のインストラクタが最初に 5, 6 人ぐらいで集まったのが、アーキテクト・コミュニティの始まりです。私も最初のインストラクタだったのですが、みんなで「アーキテクチャをつくるにはどうすればいいのか」「そもそもアーキテクチャというのは何ぞや」というところから熱心にディスカッションしたんですよ。そこからですね、始まったのは。
アーキテクト・コミュニティでは、アーキテクティングのやり方を研究しています。
-- それは、日本だけの文化なのですか？
いいえ。社内に ICM（Intellectual Capital Management）というナレッジマネジメントの活動があります。ナレッジマネジメントの単位は、例えば、プロジェクトマネジメントのナレッジマネジメント、アプリケーション開発のナレッジマネジメント、などといった 60 個ぐらいのカテゴリに分かれていて、ICM では、それぞれのカテゴリに対して、いろいろなノウハウやアセットの蓄積・展開をやっています。
ただ、パターンに関して言うと、「パターンをどう適用するか」とか「パターンをどう抽象化するか」とか、そういうことは、すごく限られた人間でしかやっていないというのが現状です。
社内の話からは逸れるのですが、パターンに関することと言えば、細谷さん*7が、パターンの適用などには「パターンエンジン」というパターンに関する活動のフレームワークに従ってやっていきましょう、という提案をしていますよね。それは面白いと思います。
*7 細谷竜一。パターンワーキンググループ幹事。パターンエンジンについては、パターンワーキンググループが 2004 年 1 月に開催した「ウィンターワークショップ・イン・石垣島」の「組織活動とパターン」セッションにて「知識創造装置パターンエンジン」として発表している。
-- そうですね。細谷さんの活動って、結構、面白いですよね。
私、細谷さんの講演*8で、ナレッジマネジメントとパターンの類似性に初めて気づいて、びっくりした覚えがあります。
*8 パターンワーキンググループが 2003 年 5 月に開催した「第 141 回 ソフトウェア工学研究会 パターンワーキンググループ設立記念セミナー」の講演「形から入らないパターン活動」のこと。
-- RAS は、まだ始まったばっかりですか？
標準になったのは、つい先週*9ですからね。これから学会の人とか、特に大学関係の人とかが始めるといいのかな、と思います。今、アセットの再利用なんかをスタンダードな規格でやろうとしてるのは RAS しかないんですね。それで、僕は、それに乗っかるべきだと思うんですよ。IBM だから言ってる訳じゃなくて。そういう意味では、やっと土壌が整ったかな、と思います。
*9 このインタビューを行ったのは、2004 年 5 月中旬。RAS の採用が OMG に承認されたことは、2004 年 5 月 10 日に発表された。
-- 実際に現場の人が使うのは、まだまだ先だと思っていいのでしょうか。たぶんツールができないと普及しませんよね。
そうですね。まだ Rational XDE や WSAD（WebSphere Studio Application Developer）といった一部のツールに乗っかってるだけですし、その乗っけているツール自体も RAS の実装がフレキシブルではないので、まだまだ有効活用できない側面もあるかと思います。ただ、フレキシブルではないことに関して言えば、RAS の規格に絡む話でもあるでしょうね。で、ちゃんとツールに実装されてくると、一気に普及するのかな、という気がします。
あと、RAS の規格のサポータに Borland が入っていますので、彼らが Together にも乗っけてくれることに期待しています。というのも、Together とか XDE とか商用のメジャーどころの IDE に乗っかることになると、IDE の種類を問わず部品の流通ができるようになりますよね。そうやって部品が流通することを嫌がる人もいますが、アセットを再利用しやすいという観点でみると、ファイル（部品）の流通ができるのが理想です。それは、すごく期待しています。
-- 今までも、そういう再利用のためのツールっていろいろつくられてきたのですが、ツールを導入してもなかなかうまく使えなかった、ということがあったと感じています。一つには表現形式が標準じゃなかった、ということがあると思います。RAS の登場で、きっとそれは変わりますよね。
と、期待しています。
-- でも、もう一つの、知識を収集して育てていくノウハウがない、ということは、なかなか難しいのでしょうか。
そうですね。でも、それをやるのが各社の競争力に繋がっていくような気もします。勿論、一般的なコミュニティの活動で、こうやるべき、というのはあると思うんですよ。ただ、いかにパターンを効率よく蓄積して、いかに活用していくのか、というのは各社の競争力に、もろに左右していくと思います。
-- 確か、IPA の ITアーキテクト委員*10をやられてますよね。
アーキテクトという言葉は、結構、幅広い意味で使われていると思うんです。例えば、IPA のところで言っている「ITアーキテクト」は、建築の文脈でいうアーキテクトというものだと思うんですね。でも、実際には、もうちょっと狭義の、ある特定の技術分野を専門とするアーキテクトがいたりして、どうもアーキテクトの定義が確立していないな、と感じています。
榊原さんとしては、アーキテクトをどのようなものだと思われているのでしょうか。また、アーキテクトという職種ができると、仕事の仕方はどう変わると思いますか？
*10 IPA（Information-technology Promotion Agency, Japan）: 独立行政法人 報処理推進機構の ITスキル標準センターが設置した ITアーキテクトを対象としたコミュニティである「ITアーキテクトコミュニティ」の委員。
う〜ん、難しいですね。僕は、いわゆる上流と下流とに分かれて、アーキテクトが上流になるとか、アーキテクトがビジネス寄りになるとか、という見方はしていません。もっとテクノロジーが進んだ時代の話を仮定すると、アーキテクトは、いろんな場面場面での構造をつくる人だと思うんです。つまり、ビジネスプロセスメタモデルのようなメタモデルやメタソリューション、そういった枠を決める人なんだと思います。
例えば、IT のインフラのメタモデル。
インフラってモデリングされないじゃないですか。だから最初からハードやソフトの製品ありきで始まってしまったりする。それ、すごく不幸なことだと思うんです。まず最初に抽象的なモデルがあって、そこから詳細のモデルに落とし込んでいって、最後に製品のマッピングがされるのが一番いい。そうすれば、WebSphere でも Weblogic でも、お客様は自由に選べますよ、という話になると思うんですよ。これはインフラの例なんですが、そういう、いろんなところに対してメタな構造を定義できるような職種になるのかな、と思っています。
MDA（Model Driven Architecture）とか UML ツールを嫌いな人はいますが、メタな構造を定義していく仕事をする上では、そういうのに期待してたりします。
-- インフラの例に関係するのですが、アスペクト指向的なアプローチで非機能要件を検証するという論文*11がありますよね。あれは、やっぱりそういう関心があって、やられたんですか？
*11 IBM プロフェッショナル論文 : オペレーショナル・モデリングにおける非機能要件の効果的検証方法
そうですね。アーキテクチャを決めるときには複数の視点で考えますよね。一つは機能要件をいかに実現していくか、もう一つは非機能要件をどう実現していくか、という視点で考えると思います。非機能要件は機能要件の中に隠れていますので一概には引き出せないのですが、多くは、インフラをどう構成するか、ということで決まってくるんですね。
非機能要件には、使いやすさとか可用性とか信頼性とかいろいろありますよね。で、可用性を高めるにはどういうデザインにするべきか、スケラビリティが欲しい場合にはどうするべきか、パフォーマンスが欲しい場合にはどうするべきか、ということを、今、大抵のプロジェクトはプロポーザルを書くときに経験のある人が一気に考えてるんですよ。
そうすると、本当にそれがパフォーマンスを考慮したことなのかスケラビリティを考慮したことなのか分からずに構成が組まれてしまって、たぶん柔軟性の少ないインフラ構成になると思うんですね。
そうではなくて、MDA と同じように、PIM（Platform Independent Model）があって PSM（Platform Specific Model）があって最後に実際のものがある、という考え方をインフラにも適用すると、柔軟なインフラ構成を組むことができると思うんですね。つまり、パフォーマンスのときはこういうモデルを作りましょう、スケラビリティはこういうモデルを作りましょう、で、最後に構成しましょう、という考え方です。そうすると、インフラを抽象化したモデルと具象化したモデルとを作っておいて、具象化したモデルに対しては最終的に製品をマッピングする、ということができますね。そうやって考えていく手段として、アスペクト指向のアナロジーを取り入れてみました。
-- 大学を卒業後すぐに入社して、ずっと IBM で働かれているのですか？
はい。IBM だけです。
-- やっぱり外資系の会社って違うんですか？
日本 IBM に居ると、あんまり外資系って感じがしないですね。普段、例えば、お客様のプロジェクトに行ってシステム開発しているときに、外資系だな、と感じることはあまりないです。
IBM が外資系だと感じるのは、やっぱりワールドワイドなエンジニアとの情報交換を非常に密にやれるところです。自分達が考えてもいなかった色んな情報が入ってきたり、あるいは、日本の話をすると「なんじゃそれ、おもろいな」みたいなことを言われたりするんですね。そういうときに感じます。IBM はワールドワイドで組織の形態が同じなんですね。例えば、アメリカにもヨーロッパにもアフリカにもブラジルにも同じサービス事業があるんです。世界中どこに行っても同じなんですよ。その同じビジネスユニットの人達と特に付き合いがあって、ノウハウを共有したり、ということはあります。自分が海外の人と付き合おうと思えば、いくらでも付き合えますね。
-- 例えば、人間関係がクールだとか、そういうこともないんですか？
そんなことないですよ。やったらしつこい奴とか居るし。その辺は、あんまり変わらないと思います。
あ、一つだけありました。日本の会社と違うなって思うところ。
IBM って、なんでもフレームワーク作るんですよ。枠組みをつくって、きっちり体系をつくってから始めるんです。それはソフトウェアに限らず、ビジネスにおいても、サービスビジネスのフレームワークだとか、e ビジネスオンデマンドはこうだとか、コンセプトとフレームワークを作ってから、それから隙間を埋めるみたいに施策を展開していくやり方なんですよね。
幾つかのコンピュータメーカーさんに話を聞くと、コンセプトより先に製品とかが出てきて、それからシナリオを考える、という逆のパターンなんですね。それを聞いて、ちょっと違うな、と感じたことがあります。
-- 日本はボトムアップだけど、例えば、アメリカとかってトップダウンで結構やりますよね。
ストラテジーありき、みたいなところはあると思うんですね。それに慣れているので、その方がスッキリするんじゃないかな、と思います。
IBM は、きっちり体系をつくるのですが、その後が無鉄砲だったりするんですよ。コンセプトを作った後に、この部分は製品がないのに突っ走っちゃったとか、サービスがまだ整ってないのに始めましたとか、それはありますけども、ある程度の枠を決めて無鉄砲に走るというのは、とても僕のスタンスに合うな、という気がします。
-- 難い話が続いたので、もう少し軟らかい話をしようと思います。趣味は、ジャズギター演奏、料理、マイナーな言語でのプログラミング、という話を伺っています。
-- マイナーな言語というのは、どういう言語ですか？
そんなにマイナーじゃないですけれども、Python とか、どっちかというとスクリプト系を、試したり遊んだりするのが好きです。
-- それは趣味でやられてるんですか？
そうです。
-- プログラミングの方は、いつから始められたのですか？
プログラミングは大学の終わりぐらいからですね。大学のときに、Pascal を、ちょっとやって、で、あと BASIC でパソコンの上で人がペコペコって歩くのを作って喜んだりとか、そういうことをやっていました。本格的にやったのは会社に入ってからですね。会社で最初にやったのは COBOL、アセンブラ、PL/I、ま、銀行系のいわゆるメインフレームのプログラミングです。
-- じゃ、好きで始められたのでしょうか。
そうですね。僕は、ほんとは、CAD/CAM をやりたかったんですよ。よく分かってなかったのですが、要は、ビジュアルに動かせるようなものを作りたかったんです。そしたら、なぜか、銀行系に配属されまして。銀行のオンライン処理って何もビジュアルなものがないですよね。同僚で、ずっと CAD/CAM をやってるエンジニアが居て、中身まで全部知っているスペシャリストなんですけど、羨ましいな、と。
-- ジャズギターの方は、どういうのを演奏するのですか？
フォー・ビート系が多いですね。昔は、バンド組んで、フォー・ビートとかフュージョンみたいなこともやってましたが、最近は、やってないですね。
-- それは、お仕事の方が忙しいということでしょうか。
それもありますけど、最近は、育児です。二人目が生まれたばかりなものですから、オムツを取り替えたり、料理を手伝ったりしています。
-- フォー・ビートはどのようなものを聞かれるんですか？
いわゆるビバップとかモード系などが好きでして、どっちかというとダークな感じ、重い感じのフォー・ビートが好きです。あまり BGM っぽいキャバレー・サックスみたいなのは嫌いなんですよ。マイルス・デイビスとかジョン・コルトレーンが好きですね。
-- 私は、あまりジャズを知らないのですが、そのあたりって、あんまりギター中心の演奏スタイルじゃないですよね。
そうですね。ジャズにはギターで有名な人もいますけど、どっちかというと、管楽器とかピアノとかがメジャーだと思います。ギターだとジム・ホールが大好きです。最近だと、パット・メセニーとかジョン・スコフィールドが好きですね。僕、パット・メセニーと中野サンプラザの楽屋で一緒に写真を撮ったことあるんですよ。それが自慢です。
-- それでは最後に、若手エンジニアへのアドバイスをいただけないでしょうか。
僕自身の反省も含めて、自分が何をやっているのかちゃんと考えながら仕事した方がいいよ、と。
プログラミングとかの技術があっても、なんのためにやってるのか分からない。物事の本質をみない、というか、原理原則を知ろうとしない。例えば、ソート書け、と言われたら、何百万件データがあっても、シーケンシャルにサーチするようなロジックしか書かないとかね。バイナリサーチとかクイックソートとか、いろいろテクを使えよ、と思うんだけど、要は、ソートを書くことだけが目的になっちゃって、本質的なソリューションに結びついていない。
システムを作ることが目標じゃなくて、それを通じてビジネスをどううまくするか、ということが目標じゃないですか。僕も若い頃はそうでしたけれども、システムを構築したり、テクニックをマスターしたり、ということに一生懸命になっちゃって、ソリューションを忘れちゃうんです。その辺を、ちゃんと考えながらやっていった方がいいのではないでしょうか。そうでないと、自分のマチュリティは上がらない、とは思います。
中国や韓国の人に話を聞いていると、日本だけでなくて、アジアにはブームに乗りたがる文化があるようなんです。Java と言えばみんな Java に走って、Web サービスと言えばみんな Web サービスに走って、なんにも他のことを見ないでブームに乗ってしまう。一方で、メインフレームでなら何でもできる、みたいな人もいますよね。マインド的には中間でも、やってることは意固地か流行に乗っかるかの両極端な人が多いように感じます。流されない、けど、取り残されない。そんなのがいいと思うんですけどね。
-- 今日は、どうも、ありがとうございました。
| ©2004 OGIS-RI Co., Ltd. |
|
