[2006 年 8 月号]
[らぼなび！]
第 2 回目の「らぼなび！」は 東京工業大学 大学院情報理工学研究科の佐伯研究室におじゃましました。佐伯研究室はソフトウェア工学を専攻分野としておられる研究室で、その中でもソフトウェアの要求分析や設計など、上流工程に焦点を当てて研究活動をされています。
インタビューを通して研究室の皆さんの研究に対する熱心な思いを感じました。それはソフトウェア開発の活動を少しでも良くしてゆこうという熱意であり、現状の問題点を冷静に分析する科学者の目でした。また、感心したのは、焦点を当てているのは上流工程でありながら、しっかりと下流工程も意識をされていることです。
ソフトウェア開発の世界をより良くしたいと願う佐伯研究室の佐伯教授と学生 3 名へのインタビューです。佐伯研究室の研究に対する思いや夢をお伝えしたいなと思います。
-- さっそくですが、佐伯先生の専攻分野や研究テーマなどについてお聞かせ下さい。
私の専攻はソフトウェア工学でして、主に要求分析から設計工程、いわゆる上流工程っていうのを主眼に置いて研究しています。
現在、私はその中でも、下記の 5 つのテーマについて研究をしています。1 番目と、4 番目の研究についてはデモを見て頂きたいと思っています。
-- オントロジというのは人によって解釈が違うようですが、ORE という研究の中ではオントロジはどういったもので、どんな風に利用されているんでしょうか。
我々のオントロジの解釈は基本語彙集です。言葉っていうものは、聞く人によっていろんな解釈がありますけれども、ある分野を特化するとその言葉っていうのは単一の意味しか持たない、そういうものを集めてきて、構造化して使える形で蓄えたものを我々はオントロジと言っています。
この ORE という研究は、問題領域固有の知識をいかに要求分析に活用しようかというものです。誰が聞いても同じ意味しか持たない単語を集めて、その単語と単語との間にソフトウェアを睨んだ関係を付け、オントロジとして知識ベースに蓄えておきます。そして、そのオントロジにアクセスすることによって、要求の意味を解析しつつ、新たな要求を獲得していったり、矛盾する要求を検知していったりする手法です。
-- 具体的に言うと、どのような使われ方をするんでしょうか。
例えば、自動ドアを考えるとき、要求仕様に「ドアを閉める」というのがあったとしますよね。「閉める」という言葉に対して、「開ける」という言葉がないといけませんが、要求には「閉める」しか挙がっていなかった時に、「開ける」に対して「閉める」という関係をオントロジとして蓄えておくと、ドアを「開ける」という要求が漏れていたことを発見できる---そういうものです。
-- では、先生がこの要求工学というテーマに取り組むようになった動機を教えて頂けますか。
今の大学では一般的にプログラムの演習が中心になるので、学生はプログラミングはできます。ところが、仕様書は残さない。もちろん設計仕様書もありません。プログラムがどうなっているのかは作った本人しかわからず、非常にメンテナンス性が悪いんです。しばらくしてから、そのプログラムに不具合が見つかって直そうとしたときに、結局本人すらも忘れていて、改めてコーディングし直すというような状況が頻繁に起っているんですね。
だから、やはり大学でもきっちりと上流工程を研究のターゲットに据えて、その成果を学生に授業でフィードバックすることが非常に重要なんじゃないかと思います。こういう理由で、上流に焦点を絞って研究に取り組み始めました。
-- 上流工程をもっと重視すべきだという点は、大学に限らず IT 業界全体にも言えるのではと思いますが、先生もそのように感じられますか？
それは感じています。ただ、IT 業界の場合は、最初には仕様書を書きますよね。ところが、大学でのソフトウェア開発では最初に仕様書を書くことすらしないんですね。
まずは、この仕様書を書くという点を大学でもきっちりとやってゆきたいです。さらに、仕様が変わったときに仕様書のメンテナンスを行わないとコードとの整合性がとれなくなるという問題が出てきますので、そういった問題も研究のターゲットにし、クリアにしていきます。そのように考えていけば必然的に、要求分析の方法や設計の技術を学生に教えることができるのでは、と考えています。
-- 仕様書を書くというお話でしたが、佐伯研究室に入ってくる学生に対して、その他に「こんな風になって欲しい」ということがあれば、聞かせてください。
抽象化のテクニックを磨いてほしいです。プログラミングばかりやっていると、すぐにソースコード、アルゴリズムという話になるんですね。大学の授業で出てくるような問題に対してはそのような方法でも解けるのですが、現実問題をソフトウェアの上に乗せて解決しようとすると、どうしても抽象化するテクニックが重要になってくるんですよね。問題の本質をきっちりと捉えて、的確にモデル化し、そのモデルに従って設計仕様書を書き、それに合わせてコードを書くというテクニックです。ある種の数学に通ずるような技能ですが、そのような抽象化のテクニックをちゃんと磨いてほしいなと思います。
-- そのような抽象化のテクニックは、トレーニングすることで鍛えられていくということですね。
そうですね。要求分析の段階で仕様書を書くということが、いい訓練になると考えています。
-- 今後さらに取り組んでいきたい分野はありますか？
今取り組んでいる分野、特に要求分析の分野でやらなくてはならないことがまだまだあると思っています。
私が博士の学生だったころは、要求工学といわれる分野では「要求仕様記述言語」というものを作ることが主要な研究テーマだったんですね。同じ頃、企業の方も同様な活動をされておられました。ところが、実際はそのようなフォーマルなコンピュータ向けの言語を作っても、本質的には全然解決に向かわない。要求工学はますます人間サイドの方へ向かって来ているんですね。
その後、クラス図のようなものが出てきて、仕様書なども人間サイドを意識したものが出来上がってきました。それでも、やはりクラス図が書けない。最初にどのようにクラス図を書いたらいいのだろう、という疑問が出てきました。また、ユースケースも出てきて、ではユースケースはどう書いたらいいのだろう、となりました。
このように、要求分析の分野がますます人間サイドに近づいてきているので、心理学まではいかないとしても、もう少し人間くさいところを要求分析の上流工程に対して考えていかないといけない、と思っています。現在ビジネスモデリングのように、ソフトウェアの上に乗せるより前の話も出てきていますので、研究のターゲットをどんどん前の工程の方へずらしていきたい。もちろん、後ろの工程への接続も重要なんですが、前の工程を基点として、後ろの工程も考えていきたいなと思います。
-- IT 業界に対してメッセージがあればお願いします。
現場の生の声を届けてほしい、そして大学側の新しい技術を企業側で評価してほしいと思います。ソフトウェア工学は、企業の「現場の声」が届かないと全然研究が進まないんですね。大学の中で学生の声だけを聞き、学生のプログラミングの状況だけ聞いても、全然始まりません。ぜひ、現場の実際のデータ、あるいは、実際にどのようなことで困っているのかに関する生の声を聞かせていただければ、と思います。
私たちが新しい技術を考案したとしても、結局それは研究室レベルのものであって、現場の評価が全くできないんですよね。非常にまずい状況になっていますので、大学側に生の声を聞かせてくれる仕組みと、企業が新しい技術を評価できるような仕組みを、何とか作っていただきたいなと思います。
-- 産学が連携したコミュニティーなどを作っていかないと、なかなか難しいのかなと思いますね。
そうですね。
あと、日本企業が国際的な場にどんどん出ていかないといけないと思います。ここ最近は、国際的な場でほとんど日本企業の方とお会いしていません。日本にも確かにいい技術は出ているんですが全く PR しないので、欧米企業と同じようなことを考えても欧米企業の方が創始者ということになってしまうんですよね。だから、積極的に国際的な場に行って、自分が企業で行っていることを PR していかなければいけないと思います。
-- そうですね。欧米から入ってくる技術を見ていても、先に言ってしまった者勝ちというところがありますからね。
そうですね。結構ありますね。自分たちが行っているのと全然変わらないじゃないかとか、自分たちが行っている方がまだいいじゃないかとかね。
-- では、本日は貴重なお話ありがとうございました。
ありがとうございました。
佐伯研究室で研究に取り組んでいらっしゃる、博士課程 1 年目の林さん、修士課程 2 年目の柴岡さん、山本さんの 3 名にお話をうかがいました。
-- 専攻はソフトウェア工学ということですが、具体的な研究テーマを教えていただけますか。
山本さん
僕が今やっているのはアーキテクチャ (*1) 選択を支援する研究で、要求が決まった後にそれを設計にどう反映させていくかということをテーマにしています。得られた要求を満たすためには一体どういうアーキテクチャを選べば良いのかを評価して、それに合うアーキテクチャを提示してあげよう、ということです。
-- どういう方法でアーキテクチャ選択を評価するのですか？
現在取り組んでいるのは、機能要求から出てくるアーキテクチャの案に対して非機能要求を使って評価する、という方法です。アーキテクチャの間に依存関係があったり、要求の間にも依存関係があったりするので、選択したアーキテクチャで要求のすべてを満たせるという訳でもないと思うんです。ですが、その依存関係をうまく使って、どのアーキテクチャを選択したときに要求を最も満たすことができるのかを評価できればいいな、と考えています。
-- アーキテクチャと機能要求って、直交する概念ですから、それでどういうアーキテクチャを選択すればいいのか、という方法論は、なかなかないんですよね。いいなぁ、そういうのがあれば。
柴岡さん
佐伯先生に紹介していただいた ORE と近い研究になりますが、オントロジを使って要求獲得を支援する研究をしています。特にゴール指向要求分析法に注目していまして、矛盾のある部分や、足りない部分などを提示してくれるシステム、ゴールを分析し詳細化していくうちにさりげなく教えてくれるシステムを作りたいと思っています。
-- 要求の MECE (*2) 感はなかなか検証できないですから、そういうところでオントロジを使うのはおもしろいですね。
林さん
今は、ソフトウェアの設計や実装の改善を支援する研究を行っています。
まず、開発者がプログラムを編集する様子をソフトウェア開発環境が監視することによってリファクタリング (*3) の案を提示する、といったシステムを作成しています。うまくいけば、これを使うと簡易的な「ひとり」ペアプログラミングが実現する、というのが売りになるようなシステムを目指しています。
さらに、チームによっての開発の "くせ" とか、凄腕のプログラマが持っているノウハウなんかを知識情報として取り入れて、改善の支援に利用しようとしています。
-- "くせ" っていうのは、どういうことなんですか？
いろいろな着眼点があるんですけど、例えば、メソッドの適切な大きさとはこれぐらいです、などのコーディング標準がそうですね。こういった指標はこのくらいが良いと一概には言えなくて、主観が入っていたり、チームの総意っていうのが含まれたりするので、それをなるべく優秀なプログラマの "くせ" から取ってこれないか、と考えています。
で、こういった情報を、開発者の振舞いを考慮して利用できれば良いかなと。簡単な例だと、コピー＆ペーストしようとすると怒る、とか。
-- 確かに、そういう作る過程でチェックする、というのは必要ですね。プログラマがたくさんいるような現場だと、仕上がってきたソースコードに対して何かするといっても、その時にはもう遅くて、処置のしようがないことがありますからね。
-- ところで、皆さんに話していただいた研究は、それぞれの工程で繋げて使えるものですね。
林さん
そうですね。実際に、そのひとつひとつの手法を繋げていこうと考えています。うちの研究室ではソフトウェアを開発するというサイクルにおいて、一部分だけでなく、上流から下流にわたる全体と各プロセスの前後の繋がりを意識してそれぞれの研究を進めようとしています。
-- 今やっているそういった研究が、ソフトウェア開発において、こういうところで役に立つんだよ、というイメージ像があれば、聞かせてもらえますか。
柴岡さん
僕の研究で要求の洩れや矛盾点を早期に発見できるということもメリットとして挙げられますが、この研究や ORE の1つの目標として、オントロジで "ドメインに関する知識を補完する" ことがあるんですよ。開発者と顧客とで持っている背景の知識が違うと、顧客が言ったことを開発者が間違って解釈しちゃうこともありますからね。オントロジはそういった背景の違いを埋める役割も果たしてくれるはずなんです。
-- お客様から要求をしっかり聞き出せるかどうかっていうのは、どうしてもエンジニアに依存しちゃうんですよね。
林さん
今言われたように現在のソフトウェア開発は属人性が高過ぎると思うのですよ。皆がスーパープログラマにならなくても、もう少し何とかならないかなと。例えば、過去にはうまくいったソフトウェア開発例がいくつもあるわけで、それらがどうしてうまくいったのかのエッセンスをみんなが利用できるようにしたい。それはとても幸せなことだと思うんです。
山本さん
僕の研究も属人性を低減することに貢献できると考えています。具体的には、アーキテクチャの選択について客観的な妥当性を与えることができるようになります。現在は妥当性について専門家の経験に頼っていますが、誰でも納得することができる評価法を考えたいと思っています。
-- 今、言っていただいた目標に向かって研究するなかで、皆さんが、しんどいな、つらいな、と思うところはありますか？
山本
様々な種類の非機能要求をまとめて扱うモデルを作る必要があることです。アーキテクチャの評価に非機能要求を使っている研究は、すでにたくさんあるんですが、多くのものが、扱う非機能要求を絞ってそれに特化したモデルを作っています。僕は、その非機能要求間の関係をうまく扱いたいので、特定の非機能要求に依存しないモデルを作らないといけないところが大変だと思っています。
柴岡
研究対象とするオントロジ、実験などで利用するオントロジをどうするか、ということが研究を進める上での問題点ですね。一般的な語彙を集めたオントロジは公開されているんですが、要求獲得でこれを利用しようと思うと語彙が足らない、もしくは1つの語彙を違った意味として解釈したい場合が少なくないんですよ。必要なのは、要求獲得を行う問題領域に特化したドメインオントロジなんです。これはなかなか見つからないですし、オントロジを自動的に作る研究というのもやられてますけど、まだ発展途上です。
林さん
先生も仰っておられましたが、評価がしづらいことでしょうか。例えば、「私の作ったシステムでこれだけの開発ができます」と言っても、実績の薄いツールを大規模開発に適用するのは勇気がいる。すると、しっかりとした評価・検証が必要になるんですが、やはり人が絡むことですので評価をするためのコストがとてもかかってしまうというのがありますね。
-- そういう自分達のやった研究を評価してもらう場っていうのは、論文や学会の他にあったりするんでしょうか？
林さん
はい。実際に企業さんと連携して研究をするということになります。
-- 皆さんのやられていることは非常に実用に近いところなので、共同研究などをやるとフィードバックもあるし、より研究の内容は洗練されていくんじゃないのかな、と思います。
皆さん
そうですね。やってゆきたいですね。
-- 最後になりますが、将来やっていきたいことなどがあれば、聞かせてもらえますか。
山本さん
僕はプロジェクトマネジメントに興味を持っています。プロジェクトの関係者が誰でも積極的に参加できる方法を見つけることができればと思っています。
難しい理論を詰めていくというのも一つ大事だと思うんですけれども、実際にお客さんに作ったものを説明することも大事なことです。そして開発する全員がちゃんとそれを分からないといけないということがあります。そのためには、シンプルで誰にでも分かることをしっかりとやらないといけない。今後は、そういったプロジェクトの管理技術にも着目していきたいですね。
柴岡さん
僕は組み込み分野に注目しています。ソフトウェア工学っていうのは組み込みではないプロダクトが主なターゲットだと思っていまして、開発サイクルの早い組み込み系ですと、現場の中ではカオスのような混沌とした状態だという話もチラホラ聞きます。そういった現場でどういったソフトウェア工学技術を適用できるのかということですね。また、組み込みソフトウェアもどんどんと進化して、より大規模なプロダクトになっていくと思うんですが、そういった過程を進む上で適用できるソフトウェア工学の技術とは何かということに関心があります。
林さん
ソフトウェア開発技術の推移とか進化に注目しています。ソフトウェア開発にはこれまでにも多くのパラダイムシフトがありましたが、新しいパラダイムが来るまでの間隔は確実に短くなってきていると思うんですよ。つまり、そう遠くない先に新しい世界があると思っているんですが、そこでは今まわっている仕組みがどれだけ生き残っているのかとか、どのように変わっているのかとかにとても興味があります。特に、今いる世界と先の世界との間をどうやって繋いでいけばいいのかという問題はとても重要で、僕も何らかの形で貢献できればよいと思いますね。
-- ありがとうございました。ソフトウェア工学というのは企業の現場に役立つものばかりですので、我々も皆さんのご活躍を期待しています。本日は貴重なお話ありがとうございました。
皆さん
ありがとうございました。
インタビュー後、研究室で開発しているシステムをデモンストレーションしていただきました。
方法論工学を支援するツールは、一般に CAME ツールと呼ばれています。CAME とは、Computer Aided Method Engineering (計算機による方法論工学の支援) の略です。CASE (Computer Aided Software Engineering: 計算機によるソフトウェア工学の支援) ツールが特定の方法論に基づいてソフトウェア開発を支援するのに対し、CAME ツールは方法論自体の構成を支援します。CAME ツールによって、新しい方法論の考案と活用が行いやすくなります。本研究室で現在開発している CAME ツールは、クラス図などのダイアグラムの構造を記述することにより、そのダイアグラムを編集するツールを自動生成することができるという特徴を持っています。
ソフトウェアの要求分析法の一つにゴール指向要求分析法があります。 これは、様々な要求をゴールとして表し、それを徐々に分解・詳細化することにより要求獲得・分析を行う方法論です。AGORA (Attributed Goal-Oriented Requirements Analysis Method) は、ソフトウェアの要求分析法の一つであるゴール指向要求分析法に属性という概念を追加することで、効果的に要求分析を行う方法論です。 AGORA ツールを使用することにより、AGORA を用いて要求獲得・分析を行う作業を効率よく行うことができます。
我々の従事しているソフトウェア産業は、他の産業と比べて工業化が遅れています。開発の属人性は非常に高く、一握りの優秀なエンジニアにプロジェクトの運命が握られているのが現実であると思います。これまで様々な取り組み・研究が行われてきましたが、この問題に対する有効な解を我々はまだ掴めてはいません。
しかし、ソフトウェアの活躍する場は日々広がっており、開発すべきソフトウェアは増えるばかりです。優秀なエンジニアの存在はとても重要ですが、このような状況では、一部のエンジニアにばかり頼ってばかりはいられず、属人性を排除して工業化を成功させたいのはソフトウェア業界の願いです。
佐伯研究室では、まさに今、業界が直面している問題を解決すべく、研究に取り組まれておられました。取材メンバーが感心したのは、要求工学やアーキテクチャ選択という上流工程に着目しながらも、コーディングやリファクタリングなどの下流工程にもしっかりと目を向けて、ソフトウェア開発工程を総合的に研究しておられることでした。それによって、我々現場の人間の目から見ても、先進的でありながらも現実味のある「使ってみたいツール・理論」だと思いました。また、我々企業の側は、こういったすばらしい研究を発展させていくために、大学研究に積極的に参加して研究へのフィードバックをかける役割を担う必要があると強く感じました。
| 研究室名 | 東京工業大学 大学院情報理工学研究科 計算工学専攻 佐伯研究室 |
|---|---|
| 教授 | 佐伯 元司 |
| 主な研究内容 |
|
| Website | https://www.se.cs.titech.ac.jp/ |
山口 健（やまぐち たけし）：オージス総研アドバンストモデリングソリューション部 エグゼクティブコンサルタント。1995 年頃から、多くのオブジェクト指向を用いたプロジェクトにアーキテクトとして参画。最近は、ビジネスモデリング支援、開発プロセス改善支援などのコンサルティングに従事。
オブジェクトの広場では、「らぼなび！」で紹介させて頂ける研究室を募集しています。「是非、我々の研究室紹介をして欲しい！」という研究室は、オージス総研オブジェクトの広場編集部 (oosquare-editor@ogis-ri.co.jp) までご連絡下さい。
| ©2006 OGIS-RI Co., Ltd. |
|
