 |
[2004 年 5 月号] |
|
[2004 年 5 月号] |
［ＯＯエンジニアの輪！］
今回のゲストは、国立情報学研究所の鷲崎 弘宜さんです。*1 鷲崎さんは、パターンワーキンググループ、XPJUG をはじめ、様々なコミュニティで活躍されています。 今回は、現在取り組まれている研究内容や興味を持たれている事を中心に、奥深いお話をしていただきました。
*1 このインタビューが行われた当時（ 2004 年 3 月）は、早稲田大学 理工学部コンピュータ・ネットワーク工学科にお勤めでした。
 |
|
-- 現在の主な研究内容を教えてください。
2004 年 3 月までは早稲田大学理工学部で助手を務めています。そこでは、主に研究と教育に携わっています。
研究では、ソフトウェアの部品化と再利用に取り組んでいます。特に、コンポーネント、ソフトウェアパターン、アジャイルの 3 つを中心に取り組んでいます。
また、最近は、オブジェクト指向の拡張である、アスペクト指向と、これらの関わりについても探求しています。
教育では、学部生の実験指導や、セミナーの講師などを行っています。
-- 今おっしゃった研究内容って、あんまり繋がりが無いように見えるのですが・・・。
いえ、この 3 つの研究は、「ソフトウェアの再利用をいかに実現するか」というテーマで
繋がっています。
ソフトウェア再利用を実現するには、1 つ 1 つ別個ではなくて、3 つの包括的な取り組みが必要だと考えています。
まず、コンポーネントは、直接的な再利用の対象であり、再利用可能ソフトウェア資産（アセット）の一種です。
そのようなコンポーネントの実装や、組み立て、および再利用のプロセス全体について、ノウハウとしてのソフトウェアパターンの蓄積と共有が不可欠と感じています。それに、パターンもアセットの一種ですね。
また、再利用を実現するためには、再利用の対象だけではなく、再利用の手順を含むプロセスの確立が不可欠と考えています。
プロジェクト単位での開発資産の共有を促すアジャイルプロセスは、
コンポーネントを再利用する環境の形成に繋がると感じてますし、
実際にそのような考察が海外でなされています。
さらに、アスペクト指向は今後、オブジェクト指向と密接に関わるこれらの 3 つの技術を発展させる役割を担うと考えられます。例えば、通常のオブジェクト指向クラス集合を、特定のコンポーネントアーキテクチャ上で修正無しにアスペクトによって動作させる試みなどがなされています。
-- では、1 つ 1 つの研究内容について詳しくお話を聞かせてください。 まずは、コンポーネントについてお伺いしたいのですが、鷲崎さんがコンポーネントの研究を始められたきっかけは何でしたか？
元々は、私が研究室に入った学部の 3 年の終わり頃に、
JDK1.1 が出た後に JavaBeans という Java 言語上でのローカルコンポーネントアーキテクチャが出まして、
指導教授から「これが面白そうだから、君ちょっと卒論でやってみない？」と勧められて始めたのがきっかけです。
最初は、JavaBeans 上での Model-View-Controller アーキテクチャモデルをやっていました。
-- JavaBeans 上で MVC ですか。
JavaBeans コンポーネントを組み合わせて、得られる複合コンポーネントを再利用する状況を考えます。 複合する際にロジックとなる部分と、ユーザインターフェース になる部分の再利用性・拡張性をそれぞれ保つために、 複合コンポーネントの内部でコンポーネント間が疎に結合するモデルの実現に取り組んでいました。
-- 昔、ちょっと見たことがあるんですけど、小さい部品をたくさん作られてましたよね？
そうです。最初は自分の扱える範囲というと、いわゆるウィジェット中心でしたね。 数年前からは、EJB/J2EE も扱っています。
-- コンポーネントに関する、色々な研究をされてますよね。
そうですね。ウィジェットレベルの研究は一応、学部時代に終えて、 その後に、コンポーネント間の類似度を測定する仕組みや、 再利用性を測定する仕組み、 コンポーネント単体で条件テストを行う仕組み、 柔軟なコンポーネント間接続方式、 J2EE システムの複雑度を測定する仕組みといった、 JavaBeans や EJB/J2EE アーキテクチャで出来る様々なテーマに学生らと共に取り組んできました。 その中でも、今はコンポーネントの自動抽出に基づくプログラム検索に 力を入れて取り組んでいます。*2 これらの研究は、文部科学省の科研費に特定領域研究というカテゴリがありまして、 支援していただけるプロジェクトの 1 つとして、 代表者である深澤教授と私で「統合化されたコンポーネント指向開発環境の実現に関する研究」を行っています。
*2 インタビュー終了後、研究室にてデモを行っていただきました。（右写真）
-- では、次はパターンについてお話を聞かせてください。
学部生の頃は JapanPLoP*3 ( 以下 JPLop) には入っていませんでした。
ただ、オブジェクト指向全般で、自分の知らない事が山程ある事が分かったので、色々と本を読んでいました。
その時、パターンカタログを片っ端から読むのが好きだったんです。
例えば、 GoF のデザインパターン、ソフトウェアアーキテクチャ（ POSA ）、CORBA デザインパターン、
金澤さんらが翻訳されたPree のメタパターンですとか・・・。
ただ、その頃は、カタログをたくさん読んでいても、パターン自体はあまり好きではありませんでした。
ところが、修士 1 年生の頃に、開発手法について既に私の頭の中で制約を与えられていて、オブジェクト指向をベースとしたコンポーネントベースありきの世界しかなかったんです。それで考え方に行き詰まりを感じてしまい、違う見方が欲しくなりました。
その時ちょうど、同級生の太田君が、ソフトウェアパターン・パターンランゲージの熱狂的な愛好家だったんですね。
それで、「優秀な彼が JPLoP の活動に積極的に参加しているのには、何か理由があるな！」
と思い、のこのこ JPLoP の会合へついていったんです。
*3 日本におけるソフトウェアパターンコミュニティの草分け的存在。2003 年 5 月 23 日をもって解散。
行ってみたら、ちょうどパターンワークショップの日で、
書かれたパターンを皆でレビューしたり、
入門者向けに「パターンを書いてみよう」といった様々なセッションがあって非常に入りやすかったんです。
また、ワークショップでは、ゲームを重要視していました。
色々な所から集まった人達が打ち解けるために、別にじゃんけんでもいいんですけど、大抵は名前を覚えることを付加価値として考えて、マイムゲームをやるんですよ。
例えば、" ゲーム " というお題だと、僕が「鷲崎・麻雀」とジェスチャーをしながら言って、次の人が山本さんだとすると「鷲崎・麻雀。山本・トランプ」・・・と次々に言っていきます。
大のいい大人達が、真昼間から会社の会議室で一生懸命遊んでいるんですよ（笑）。
でも、そうすると自然と名前を覚えて、打ち解けられます。
それがきっかけで、JPLoP の会合に定期的に顔を出すようになり、パターンが好きになっっていきました。コミュニティにいる人々の面白さ・楽しさがきっかけとなったんですね。
-- なるほど。じゃあ次はアジャイル・ XP について伺いたいと思います。そもそも、XP に興味を持たれたきっかけはなんだったんですか？
2001 年にXPJUGが結成されました。
その頃の私は、ソフトウェアパターンよりも、
ソフトウェアパターンに惹かれる人に惹かれていたんです。
当時の JPLoP は非常に活気があって、平鍋さんや、藤野さん、友野さんといったソフトウェアパターンの先駆的な方がたくさん活躍されていました。
そのお一人の平鍋さんが、どうやら eXtreme Programming というものに注目しているらしい。と飛びついたのがきっかけです。
最近は、Ward Cunningham さん が提案している FIT（ Framework for Integrated Test ）に注目しています。
-- FIT ってどうなんですか？
XP による単体テストがここまで普及したのが JUnit のお陰であるように、FIT は、受け入れテストの JUnit 的な存在と言えます。 これまで、XP を構成するプラクティスの中で、受け入れテストを行う共通の基盤環境がなかったので、受け入れテストの方法が XP の本によってそれぞれ違ったんですね。 しかし、FIT の登場によって、受け入れテストを行う基盤が整いました。
-- FIT ってどうやって使うんですか？僕は Web ページみて、こんな画面なんだという程度しか知らないんですが。
FIT を用いる場合は、受け入れテスト駆動で開発を進めます。 単体テスト駆動開発の目的は、単体テストの実施ではなく、プログラマが実現したい最も重要な事柄に集中してインクリメンタルに設計と実装を進める事ですよね。 FIT を用いた受け入れテスト駆動開発も同様で、実システムを開発する前に、まずは顧客の要求であるストーリーを HTML や Wiki で表として書いておきます。 次に、その表を解釈して、実システムに値を送って、結果を評価するような Fixture という、HTML 表と実システムのインターフェースとなるものを書きます。後は、Fixture に従って、HTML 表で指定された受け入れテストに通るように実システムを開発します。最初に要求を受け入れテストとして表し、テストを通るように開発しますから、得られる実システムは要求を満たすものとなります。要求を実行可能な受け入れテストとして表すことで、要求に対する顧客の理解とプログラマの理解の乖離を防ぐわけです。
-- Fixture っていうのは、使う側がシステムに合わせて書くんですか？
そうです。そこにちょっと手間がかかります。
JUnit が受け入れられた良さは、ASSERT 文を書いていけば、それっぽい単体テストが出来る扱いやすさですよね。
FIT で、JUnit のテストケースに対応するものは、顧客が書く HTML 表です。
そして、HTML 表を解釈するものが Fixture ですので、わざわざ Fixture を受け入れテストのために作る必要があります。
しかし、数多くの典型的な処理、例えばオブジェクトの集合に対する問い合わせ処理には、あらかじめ基本となる Fixture が用意されています。
ですから、1 から Fixture を作るわけではなくて、既にある Fixture を継承などを用いて再利用し、できるだけ受け入れテスト実現の負担を軽減させる形になっています。
-- FIT を使うことで、受け入れテストのやり方って変わりますか
JUnit は、テストケースの作成方法に関して割り切っていて、使う側で好きに頑張ってくれたまえ。という感じで普及していますよね。
FIT も、基本的なスタンスは JUnit と一緒です。プロダクトシステムが提供する機能の内で検証したいものについて、
顧客は、全ての値を書かずに、望む結果や、思いつく代表的なケースを書くことになります。
-- 連続したシナリオなどをカバーすることはできるんですか？
可能です。 1 つの HTML のページが生きてる間は、インスタンスも生きてるんです。 例えば、1 番目の表を用いて、カートに商品名とお金を入れると、その結果は以降も残ります。で、2 番目の表でカートの閲覧をすると、1 番目の結果が残っています。実行時の流れを扱うことができるんです。
-- なかなか使えそうな感じですね。
ただ、以前XP-jpへの投稿があったんですが、 「 FIT ＋ Wiki 」である FitNesse は、今日本語が使えないんです。
-- 永和の北野さんが紹介してましたね
今、FIT の解説記事を執筆しているのですが、北野さんに FIT を日本で初めて紹介した記事を先に作られてしまいまして（笑）。ちょっとくやしかったですね（笑）。
FitNesse はこれから普及していくと思います。
そうすると、どうしても日本語化が必要になりますので、これから何とかしたいと思っています。ただ、現状の FitNesse でも十分に旨味があります。
-- 最近あまりアジャイルなことをしていないので、是非今度確かめてみたいと思います。
あ、アジャイルのブームってもう終わりましたよね。
-- もう終わったんですか？なぜそう思われるのですか？
そう思われませんか？私はそう思うんですけどね。
一時期、アジャイルな開発プロセス・アジャイルな開発手法であればどんなプロジェクトでもうまく行くと妄信的・熱狂的に信じていた人達が居ましたよね。ところがそれは全くの幻想でした。
XP のカンファレンスなどに行くと、「大規模開発でも XP を部分的に適用した。」という話も聞きますが、
一般的にアジャイルは小規模開発にしか向かないようですよね。
私がアジャイルのブームが終わったと思う理由は、そのような現実的なところが認識されてきたからです。
何らかの手法・方法論には適用範囲があります。その適用範囲がきちんと分かってきたということは、
アジャイルという開発プロセス・開発手法が地に足をついてきたということだと思います。
それはとてもいいことですね。
-- 昔からアジャイルのような開発手法を使っているところはあったと思いますが、 アジャイルという名前もないし、手法として整理もされてないし、知られてない状態でしたよね。 逆に、非アジャイルなところで働く人達は、全くアジャイルのような手法を知る機会がなかった。 しかし、XP が流行したことで、皆が「アジャイルという開発手法もあるんだな。」という認識を持つようになったと思いますね。
はい。大規模開発に向くプロセス・開発手法の他に、アジャイルなプロセス・開発手法も知っておくことは大切だと思います。
-- あとは、若い人達に、開発プロセスやテストに対して興味を向けるものとしては、凄くいいものだったと思いますね。 もう終わっちゃったように言ってますけど（笑）。アジャイルってキャッチーだと思いますし、あのお陰でテストの仕方などが明確になりましたよね。
今まで、テスターにしか興味を持たせなかったテストを、一般のプログラマーにまで興味を持たせた功績はありますよね。 ただ、XP で言ってる単体テストは、いわゆるテスト手法とは違いますよね。それは XP の功罪のようなところがあります。
-- 品質保証屋さんからすると、あれはテストじゃないって言われますよね。
単体テスト駆動開発と、JUnit による単体テストフレームワークと、実際のテスト手法の 3 つが混沌としてますよね。 JUnit って、設計手法としてのテスト駆動開発にも用いることができますし、 伝統的なテスト手法としてのテストにも使えますよね。 それらの理解が人それぞれに食い違ってる点は、これから整理されていくと思います。
-- では、最近取り組まれているアスペクト指向についてお話を伺えますか？？
日本語による初めてのアスペクト指向の本*4を最近出版しました。 「 AspectJ によるアスペクト指向プログラミング入門」という本です。 アスペクト指向プログラミング（以下、AOP ）という プログラミングパラダイムを説明した後に、その AOP を実現する 1 つの実装技術として、AspectJ を説明しています。この本で、ぜひとも AOP 及び AspectJ を実務に生かして頂きたいと願っています。
-- 今、なぜアスペクトなんでしょうか？
複数のクラスやインタフェースにまたがるような記述は、Java だけで行うのは難しいことがありますよね。
誤解を受けることがあるのですが、AspectJ で記述できる事は、Java でも記述できます。逆に、Java で記述できないことは、AspectJ では記述できません。
-- Java で記述できないって、具体的にどういことですか？
例えば、VM レベルでの制御を AspectJ で書くことはできません。 要するに AspectJ で書いたプログラムは、内部的には Java のクラスとインターフェースの集合からなる Java プログラムに変換されます。 あくまでも Java で記述できることを、かなり高度にかつ容易に AspectJ で記述できるということです。
例えば、Visitor パターンってありますよね。オブジェクトが 2 つあった時に、両方のオブジェクトの型の違いに応じて処理を変えるパターンです。
ただ、たったそれだけのことをするためだけに、非常に面倒くさくて分かりにくいクラス設計になってしまいます。
AspectJ の場合はそれを非常にシンプルに書けるんです。例えば、メソッドの呼び出しの際に、呼び出す側のインスタンスと呼び出す先のインスタンスを取得できますから、あとは、このインスタンスの型が A で、呼び出す先のインスタンスの型が B なら、こういう処理を行うって事をさらっと後付けで記述すればよいのです。また、そういったパターンの実装が複数の個所で必要な場合にも、モジュール化された一つのアスペクト、もしくは、共通部分をまとめた抽象アスペクトとそれを継承する具象アスペクトの定義のみで対処できます。あっちこっちに実装する必要がなくなるわけです。
そういった意味で、これまでに Java ・オブジェクト指向言語で非常にシンプルなことを実現したいがために、
複雑な設計になってしまっていた部分を、AspectJ ・ AOP が変えてくれると思います。
-- それは、Java っていうよりオブジェクト指向言語だけでは解決できない何かがあるってことですよね
はい。オブジェクト指向言語では、継承や委譲などを用いて「親と子」「全体と部分」というように対象をきれいに階層化します。しかし現実には、きれいな階層上で簡潔に表現できないこと、つまり、異なる階層をまたがって共通に必要な処理であるとか、本来は分離して表現したいのに同一のクラス・メソッド内に混ぜざるを得ないような事柄があります。例えば、先ほどの Visitor パターンの実装であるとか、Proxy パターンによるメソッド実行への事前処理・事後処理の追加実装などです。特に後者は、ログ管理やトランザクション制御・アクセス制御などで使用されることが多いでしょう。 AOP では、そういったオブジェクト指向言語において " きたなく " 表現せざるを得なかった事柄を、" きれいに " 表現できます。
-- 最近雑誌でもよく特集されていますもんね
そうですね。 JavaDeveloper では鈴木淳一さんが連載されていますし、 Java World でも JBoss のアスペクト指向フレームワークが取り上げられていましたね。 今後、AOP で実装することを前提としたアスペクト指向な分析・設計手法が研究・実践されてくると、世の中のソフトウェア開発手法に大きな変化が生じると思います。
| *4 | ||
| タイトル | ： | 「 AspectJ によるアスペクト指向プログラミング入門」 |
| 著者 | ： | 長瀬嘉秀, 天野まさひろ, 鷲崎弘宜, 立堀道昭 |
| 出版社 | ： | ソフトバンクパブリッシング |
| ISBN | ： | 4797326387 |
-- 鷲崎さんは、パターンワーキンググループの設立に携わっていらっしゃいますが、どんなきっかけだったんですか？
JPLoP が諸般の事情から解散してしまって、それが非常に残念でした。
当時、私の研究はあくまでもコンポーネントベースが主で、パターンの方は、別の視点を持つためというスタンスでしたが、それでもやはり残念でした。
JPLoP に参加してた人達は、大体皆さんそう思ってらっしゃって。
オブジェクト指向シンポジウム 2001 が都内で開催された時に、偶然 JPLoP の人達が会場周辺にいらっしゃって。
ちょっと飲みに行った先で「もう一度、JPLoP が目指していたことを別組織としてやりたいですね。」ということになったんです。
といっても、JPLoP に似たユーザコミュニティを作っても、似たような結果になるだろうし、少なくとも外部からはそう見られるだろうから、
情報処理学会という傘をお借りして、その元に集えば、新しい人も入りやすいだろうと考えました。
そして、2001 年から 2003 年まで準備期間を設けて、2003 年に
パターンワーキンググループを設立しました。
-- ようやく最近いろんな勉強会が開かれていますね
ワーキンググループの設立当初は、 「独自のパターンカタログを作る」といった様々な計画があったのですが、 様々な事情から有効なアウトプットをあまり出せていないのが現状です。 まずは興味のある人々が定期的に集まれる機会を設けようということで、 毎月必ず勉強会を開催して、 パターンに関する様々なトピックについて議論することになりました。
-- どちらかっていうと、源流に戻ろうという動きが 1 本あると思うんですが。
はい。Christopher Alexander が提唱する建築におけるパタンランゲージを捉え直そうという動きは JPLoP 時代からあった話なんですが、 JPLOP よりも、もっとオープンに誰でも参加できるようにして、その結果もオープンにしようとしているのは、ワーキンググループの一つの大きな成果ですね。
それ以外についても、幾つか継続的に取り組まれています。 例えば、ソフトウェアパターンに対する工学的な取り組みを網羅的に調査して、 どういう部分が明らかになっていて、何が明らかになっていないのかを、共同で明らかにしようとしています。 また、ソフトウェアテストやライフサイクルといった特定の領域について、パターンを集めていこうとしています。 これらの活動に基づいて、5 月にはワーキンググループの有志によって本が刊行される予定です。*5
-- パターンを考える時って、もの凄く時間と労力が掛かると思うので、最初の敷居が凄く高い感じがするのかもしれないですね。
しかし、それがパターンランゲージの良さだと思います。
ソフトウェアパターン・パターンランゲージの与える良さには 2 つあって、
1 つは記述形式がもたらすのスムーズな意思疎通。単なる問題解決対ではなく、解決に至る過程などが伝わりやすいということです。
もう 1 つは、考えなければ、解決に至った理由が書けない事ですね。
私はうんうんうなることが大事だと思います。
「このソフトウェア構成はどういう理由で得られて、どういう理由で使うんだ。」と考える機会って結構少ないんですよね。
パターンは「なぜそういう解決策を取るのか？」「なぜそういう解法に至ったのか？」という理由と過程を真剣に考えるきっかけを与えてくれます。
-- 一般的に、最初にパターンのどの部分に惹かれるかというと、いい感じの解決方法とか、そういうグッとくる部分を見つけるところだと思うんですね。 でも、そこからパターンを書くまでには、大きなギャップがありますよね。
そうですね。
パターンを使うには、多分 3 段階あるんでしょうね。1 段階目は、解法のインスタンスとして使う。 2 段階目に進むと、単に解法インスタンスを再利用するだけではなく、そのパターンから学ぶ事が出来るようになると思います。
-- それは特定のパターンからですか？
特定でもいいんですけど、他のパターンや周辺技術との関係について考えることも重要でしょうね。例えば、デザインパターンは、
第 1 段階では、Observer パターンといった個々のパターンを再利用しようとするんですけど、
もう 1 段上では、どうして Observer パターンが出てきたのかに思いを巡らせるわけです。
そうすると、オブジェクト指向言語やプログラムおよび処理系が持つ特徴や制約が見えてきます。
例えば、デザインパターンであれば、既存のオブジェクト指向フレームワークの理解を深める際に役立ちます。
そのような段階を経て、デザインパターンがカバーしている解決領域が見えて、" 今自分が扱っているこの部分はパターンとして記述されていないな " と認識するのであれば、3 段階目である、パターンを書く段階に至ると思いますね。
我々が「パターンを書きたい！」と思うに至る理由には 2 つあって、
1 つは、色々なパターンカタログを見て勉強して、こういうパターンがあるんだという事を知った上で、自分が知っている解決と重なっていない部分に関しては、純粋に書いてみたいという衝動に駆られるから。
もう 1 つは、藤野さんや友野さんの考え方に影響を受けてるんですけど、
それぞれのコミュニティ、例えば開発チームでも家庭でもいいのですが、
そのコミュニティでしか特定の解釈がなされない造語や隠語が生まれてきますよね。
そういった造語は、既にパターンの雛型になっています。
そのように考えていくと、パターンランゲージは今後、記号論*6に基づいた解釈が進められていくと思います。
私は記号論について詳しくないのですけど、
人々の対話は、記号を交換することで成り立っています。
例えば、赤という漢字一文字は記号表現ですよね。それを誰かに伝えると、ただ、" 赤 " という記号表現が伝わるのではなくて、そこから想起される赤いもの、例えば火のような熱いイメージも一緒に伝わります。
つまり、記号には、発音や表現そのものに加えて、意味があるんですね。
コミュニティの中での造語自体は、記号表現ですが、その表現には必ずそのコミュニティでのみ伝わる意味がある。
また、造語には、存在する理由があります。
*6
人間活動や自然現象など、人間が認識の対象としている記号を一般的に論じる学問分野。
言語学者ソシュールは、記号を「意味するもの ( シニフィアン ) 」と「意味されるもの ( シニフィエ ) 」の 2 つの要素に分ける事が可能であると定義している。
-- 全く新しいモノではないけど、複合して新しい意味を持つ概念を示すいい言葉がないということですよね。
はい。全くおっしゃる通りです。
-- あと 1 つ、は他のコミュニティと区別化するためにもあると思いますね。
バウンダリとしての造語ですよね。ローカルな造語によって表されるノウハウ・知識の存在が、きっとそのコミュニティを特徴付けているのだと思います。
今までパターンっていうと、誰でも、どんな組織でも、どんな開発プロジェクトでも使えるパターンであると思われてきた節がありますよね。例えば、GoF のデザインパターンはユニバーサルなものといえます。
しかし、それは恐らく本質ではなくて、ユニバーサルではない、そのコミュニティでしか使えないパターンランゲージもソフトウェア開発の世界で重要性を増してくると思います。
例えば、私は学生と研究の打ち合わせをする際に
「じゃあそこは "set-do-get" でどう？」って言います。
初めて聞く人には訳が分からないでしょうけれど、私と学生の打ち合わせの中では、「こんな事だな」と意思の疎通ができています。
ちなみに、"set-do-get" は、コンポーネントと外部との相互作用を表す造語です。あるコンポーネントに処理を依頼して、結果を外部で受け取りたいとします。単純には、コンポーネントへの通信として do 1 回で済ませて、結果を do の戻り値で受け取ろうとします。しかし、結果の持続性や問い合わせ方式の変更可能性、処理の非同期化などを考えると、入力値を set して、何か do させて、コンポーネント内に蓄えられた処理結果をあらためて get するという 3 つのステップに分けたほうが都合が良いわけです。
要するに EntityBeanや
JavaBeans のような使い方ですね。
この造語 "set-do-get" はパターンの雛型ですけど、この段階だと、パターンの名前と解法しか言っていません。パターンとして書く場合は、問題、および問題と解法の間を埋める部分に思いを巡らすことになります。そうすると、なぜ "set-do-get" するのかというコンポーネントの特性上の理由や、"set-do-get" の適用範囲も見えてきます。
-- 内々の伝達で満足していて、うまく行ってる時ってあるんでしょうけど、結局パターンとしてまとまってないんだろうな。と思いますね。
一見するとうまく行ってるのかもしれませんが、造語が表すノウハウが破綻した時には、そのノウハウを使っていた箇所を全て探して、Fix していく必要があるので、問題になるでしょうね。
きちんとパターンとして文書化しておくと、後から参照という形で使用個所や使用方法を残しやすくなります。
例えば、細谷さんが提案するパターン活動として、『一直して十直す』というものがあります。これは、あるパターンを修正したら、そのパターンを適用している全ての個所を修正しようというものです。パターンの適用状況を追跡可能な仕組みを整える必要がありますが、パターンとして文書化しておくことで、ナレッジマネージメントの一種としてノウハウを運用する下地が得られるということだと思います。
-- そうですね。細谷さんのお話を伺ってから思うんですが、パターンを書くことと、ナレッジマネージメントは、実は近いとところにあると思います。ナレッジマネージメントを考える人達の方が、きっと同じような問題意識を持っている気がしますね。
そうですね。ソフトウェアパターン及びパターンランゲージを、ナレッジマネージメントのツールや環境の一つとして捉えようとするのがこれからの一つの流れになると思います。
-- オブジェクトの広場の読者で、鷲崎さんのことをご存知な方は、大体ほげ日記を通じてだと思うんですけど
そうですね。最近全然更新してないんですけど（笑）*7。
ほげ日記は、もともと普段の研究活動のメモを残す意図がありました。
今は研究メモ用のノートやテキストファイルを作ってまとめているんですけど、当時はそれを日記として書いていたんです。国際会議の参加報告なども載せていたら、意外な方に「え、あなたもご覧になっていたんですか？」（笑）と見られるようになりまして。
-- 昔から日本には日記文化があったんですけど、最近、Weblog が 流行っているのは、blog という言葉がキャッチーだったことと、ツールがよくできているからだと思いますね。
そうですね。トラックバックとか、コメントとか。
昔から Web 日記をつける文化はありましたよね。
私も細々とやっていましたが、積極的に反応してくださる方が結城さんでした。
Java の細かいことを書いていたら、結城さんの興味と重なっていて。
今ならば、コメント欄などで会話するところを、直接メールで会話していました。
-- じゃあ、結城さんとは結構長いお付き合いなんですか？
結城さんがデザインパターンの ML を立ち上げられてからですね。
その後、結城さんが書かれたマルチスレッド本の公開レビューに参加していました。
また、首藤さんも色々と日記にお返事を下さいました。blog がない頃のコミュニケーションは、Web 上で終わらないで、メールベースでも出来たので、むしろありがたかったですね。
-- 首藤さんとは元々お付き合いがあったんですか？
いえ、直接には首藤さんとは 2 回しかお会いしたことがないです。
私、これまでに何回か挫折してまして（笑）。
とある、挫折を味わった会場にちょうど首藤さんが居らして、私が失敗する様子をご覧になっていて、
日記へのコメントの中で、「あれは残念だったね。これからはこうするといいよ。」とメールを下さいました。それがきっかけです。
余談ですが、アスペクト指向本を一緒に執筆させていただいた立堀さんは、私が別の挫折を味わった際に会場にいらして、この時も色々とアドバイスをいただきました。失敗時にアドバイスをいただけるのは嬉しいことですし、不思議と、それをきっかけに長くお付き合いさせていただけるのだなあと思います。
-- 毎日書いてらっしゃる時期もありましたよね
そうですね。ネタが無いときは、ネタを探すために記事や論文を読んで、「これは面白そうだから書いてみよう。」と、そこまでして日記を更新していました。 今は、日記を更新するための時間を、コミュニティの活動や、メールのやり取りを行う時間に割いている状況です。
-- 復活の予定とかはないんですか？
そうですね。4 月から国立情報科学研究所に移りますので、それを機に再開しようと思っています。*7 結構日々ネタがあるんですけど、まとめるための時間がないんですよね。 URL を貼り付けて終わりではつまらないので、自分のコメントを入れたいですね。
*7 このインタビューをきっかけに、ほげ日記が復活しました
-- リンクの選択だけでも本人の趣味や思想が垣間見えるから面白いですけど、でも、やっぱりコメントがあったほうが面白いですよね。
今の ほげ日記 って原始的な CGI でやってますので、更新の仕組み上めんどくさいものがありまして（笑）。 だから、blog タイプや高機能日記 CGI にすれば、気軽に更新していけるかなと思います。
-- 鷲崎さんのところに、日記のアンテナがありますけど、あれはどういう繋がりなんですか？結構興味の対象がバラバラですよね。
初めは研究室で Web 日記をつけてる学生分のアンテナだったんですけど、 序々に知ってる人とか他の大学の人を追加していきましたね。 学会でお知り合いになった大学院生ですとか、若手の研究者の方々ですね。
-- それでは、最後に若手エンジニア・若手学生へのアドバイスをお願いします。
はい。3 つあります。
私は以前修士の 1 年から 2 年の時に、毎日 1 本論文や解説記事を読む事を心がけていました。
当時は、飲み会があろうが、旅行に行こうが、必ず読んでいました。
今思えば「何だこいつは？！」という感じですけど（笑）。当時は自分の知識のなさを痛感していたので、日々こなしていました。
毎日 1 本読むというリズムが自分に合わなかったので、今はやっていませんが、読む量としては変わってないと思います。
ただ、読むと言っても、全部読むわけではなくて、アブストラクトと各段落の一行目に目を通す程度です。
で、面白そうだなって思ったら全部読みます。全部読むのは、大体 10 本に 1 本位ですね。
-- 多いですねぇ。
でも、それ位読み込まないと、質の高い研究はできないと思っています。 例えば、私が詳しくない分野について新しく研究を始める際は、最低 100 本は読むようにしています。
-- 研究者って平均的にそんなもんなんですか？
多いほうだとは思いますけど、私が言う文献の 1 本っていうのは玉石混合なんです。例えば、2 ページしかないペラペラの日本語のものから、 英語の長いものまで、何でもありなんですよ。想像されるほど、凄いことではないですよ。
-- その分野で、どういうものがあるか、どういうことが起こってるか、全体像を掴むために読まれるんですよね。それにしても 100 本は凄いですよね。
例えば、私がソフトウェア検索の研究を始める時は、ソフトウェア検索に関する重要な文献が 20 本位あります。
それは皆さん普通に読まれると思います。でも、それだけじゃまずいんですよ。
例えば、テキスト検索に関する文献、画像検索に関する文献・・・と関係する領域を追っていくと途端に本数が増えますね。
ソフトウェア検索の研究をするときに、ソフトウェア検索だけ知ってる人と、テキスト検索や、画像検索といった関係する領域を、詳しくはなくても知っている人だと、雲泥の差があります。
そういう差っていうのは、日々の文献を読むことから生まれると思いますね。
他人の論文を査読することがあるのですが、関連研究が網羅されていないと、成熟した研究成果ではないという判断が働いてしまうため、論文としての印象が良くないです。
-- 耳が痛いですね(笑）。
ソフトウェアに関する雑誌の記事や本は、良い文章が少なくて、酷い文章が多い印象を受けます。私が考える良い文章とは、文章のあらゆる粒度において、結論が先に来る。
つまり、文章全体を通してみて、結論が先にくる事。各段落において、先頭の一行目に段落の結論が来ている文章だと考えます。
それが守られていない文章が余りにも多すぎて、その結果、それを読んだ人が
「あ、こんな文章でもいいんだ。」と錯覚して良くない文章を書いてしまう悪循環になっている気がします。
私も昔は悪い文章を結構書いたんですが、英語で論文を書くようになってから、意識的に直すようになりました。
-- それはどうしてですか？日本語と英語だと論文のスタイルが違うんですか？
日本語と英語の違いが大きいと思います。
日本語はあれこれ言って、段階を経て最後に結論が出ますよね。
英語は、その逆で、先に結論を持っていきますよね。
小説であれば、むしろ前者が好まれると思うんですが、
技術を解説する文章は、結論が先に来るスタイルでなければと思います。
技術的な事柄を、伝えるテクニックを磨きましょう。ということですね。
-- それ以前に「て」「に」「を」「は」がダメな文章もありますよね。
それはもう論外ということで（笑）。 ソフトウェアの業界はサイクルが早いですから、きちんと書かれた文章ではなくとも、 とりあえずスピード優先で許されてきた風土があるようですね。
-- 翻訳って特にそんな感じで悲しくなりますよね。
翻訳はタイミング命で、きちんと書かれていない文章が世に出てしまうので、
それでいいんだなと誤解しないように気をつけたいですね。
技術系の文章に関しては、多分万国共通の表現方法があります。
結論を先に述べて、その後に「具体的には・・・」、「例えば・・・」が続く。
そのスタイルを、早い内に訓練して覚えるべきですね。
学生の卒論などをチェックしていると、最初は酷いのを書いてくるんですけど、赤を入れて、修正させて・・・を繰り返すとだんだんよくなりますよ。
ただ何となく動作するのではなくて、きちんと要求どおりに動作するシステムをオブジェクト指向で開発するには、システム全体や各オブジェクトの状態変化に目を配ることが重要と考えています。UML でモデリングする際のステートチャートですね。対象の捉え方として、構造・機能・状態の 3 種類があります。ところが、オブジェクト指向言語が備える継承や委譲といった特徴から、構造や機能の分類と抽象化に目がとらわれがちなようです。
動的な側面として、状態がどのように変化していくのか。例えば、Web アプリでも、画面遷移や簡易的な状態遷移ってありますよね。そういうのを捉える際には、集合論ですとか、グラフ理論ですとか、オートマトンといった数学上の技法が非常に重要だと思います。それらはもちろん、構造や機能を捉える際にも有用です。コンピュータのための数学という本が色々と出ていますから、ああいう本を 1 冊、最初から最後まで通して読むと、凄く力になると思います。
-- なるほど。是非読んでみたいと思います。
-- では、最後にオブジェクトの広場の読者に宣伝したい事があればお願いします。
ソフトウェア技術に関する様々なコミュニティがありますから、それらに参加して議論や活動の成果を是非ともご活用下さい。take and take ではなくて、give and take の姿勢で参加されるのであれば得られるものは非常に大きいと思います。
情報処理学会ソフトウェア工学研究会では、ソフトウェア開発に関する理論から実践までを幅広く議論しています。OO2004 などの同研究会主催シンポジウムに参加される場合は、会員割引の方が会費よりも大きいため、先に入会されているとお得です。また、パターンに興味がありましたら、同研究会パターンワーキンググループに是非ご参加ください。
日本 XP ユーザグループでは、アジャイルな開発プロセス・開発手法に興味のある人々が集まって、活発に活動しています。こちらも興味がありましたら是非ご参加ください。
-- 今日は殆ど世間話のようでしたが（笑）ありがとうございました。
こちらこそありがとうございました。
インタビュー内でも紹介されている「AspectJ によるアスペクト指向プログラミング入門」を鷲崎様から提供していただきました。
(ご本人のサインも書いていただきました)。
こちらの図書を抽選で 1 名様にプレゼントいたします。
| ©2004 OGIS-RI Co., Ltd. |
|
