イントロダクション藤井 それではワークショップを始めます。まず、モデリング技術部会主査の山城さんから、本ワークショップの趣旨の説明をしていただきます。
山城 私たちはUMTPのモデリング技術部会というグループで、ソフトウェアのモデリングについて体系化しようとしています。いろいろな有識者の方を3ヶ月に一度招いてワークショップを開き、モデリングについての議論をするという活動を継続しています。それを1年半と少し続けて、今回が7回目です。今日はアーキテクチャや、講師にKruchtenさんに来ていただいたのでRUP[Rational Unified Process]なども含めて、このメンバーで議論したいと思っています。よろしくお願いします。
藤井 それでは、Kruchtenさんに自己紹介をお願いします。
Kruchten 生まれたのはフランス北東部のドイツとの国境近くです。1970年代初めまでは機械技師をしていましたが、プログラミング言語もいくつかやっていたのでIBMで働くようになりました。1973年頃です。APLもやっていました。その後、Alcatel社でハードウェアやシステムエンジニアリングの経験を積み、70年代から80年代はテレコム関係で大規模システムの開発に関わってきました。その後17年間、Rationalで働きました。始めはコンサルタントをしていて、その中でカナダの航空管制システムに4年ほど従事しました。その後、Rational Unified Processの開発責任者になりました。2003年にRationalを退職して、カナダの大学のソフトウェア工学の教授をやっています。大学で白髪のprofessional engineerの学位を持った人が必要だったからです。 自分自身の経験は技術系の開発分野が多く、ビジネス系はあまりやったことがありません。航空宇宙や、command and controlシステム、通信の交換機、ネットワークルーターなどの仕事を主にやっておりました。 藤井 続いて、参加者の自己紹介に移ります。
山城 東芝ソリューションの山城です。私はソフトウェアエンジニアリング、特にオブジェクト指向の分野で仕事をしていて、最近は要求分析にも携わっています。オフショア活用に伴い、上流設計や要求分析は今、日本で非常に重要視されています。
中佐藤 テクノロジックアートの中佐藤と申します。弊社の照井の代理で参加しています。最初に入った会社では、10年ほど、社内のシステム開発を行っていました。その後、転職してRationalのインストラクタになりました。ですから、Kruchtenさんの4+1ビューはよく知っています。今はテクノロジックアートで主にアジャイル開発やUMLなどのインストラクタをしています。
中原 バブ日立ソフトの中原です。最初は日立製作所でCASEの開発などをしていました。現在はバブ日立ソフトで社内の開発プロセスやプロジェクト管理の標準化の推進などを担当しています。
河合 河合と申します。1998年に、オーランドで行われたRUC [ Rational User Conference ] でスリーアミーゴの皆さんやKruchtenさんにお目にかかっています。RUCから戻った後、勤めていたユニバックを退職しました。3年くらい後に日本でRational Universityが始まったときに、インストラクタになりました。RUPやアジャイルメソッド、それから特にパターン言語に興味を持っています。
竹政 オージス総研の竹政です。最初はAIシステムをやっていましたが、その後オブジェクト指向システムに携わるようになり、10年ほど前はRationalのトレーニングコースの講師をしていました。UMTPではいくつかの部会に参加しており、最近ではオフショアシステムへのUMLの適用についても検討しているところです。
猪股 富士通の猪股です。UMLツールや情報統合インフラストラクチャなどのソフトウェア製品を開発しています。現在、製品開発では、モデルを使ってソフトウェアの正しさを検証することが必要になっていることを感じているので、今日のソフトウェアアーキテクチャの話をその観点で伺いたいと思っています。
羽生田 羽生田と申します。10年前は私もオージスの社員でした。その後、豆蔵という、オブジェクト指向やソフトウェアエンジニアリングのコンサルティング会社を立ち上げました。
Kruchten アジャイルという話が出ましたが、私もアジャイル手法には興味があります。5年ほど前にAgile Vancouver [http://agilevancouver.ca/]というコミュニティを創立して会長になりました。初回は15人ほどしか集まらないだろうと思っていたのに、実際には170人もの人が来て、それ以降600人ほどに増え、月に1回、このワークショップのようなミーティングを行ったり、年に1回カンファレンスを開催したりしています。
山城 今も継続されているのですか。
Kruchten もちろんです。来年、大学のサバティカル休暇でバンクーバーを離れるため、会長の座をおりましたが、3、4週間前のカンファレンスは盛況でした。Martin FowlerやMary Poppendieck、Eric Evansなどが来て、話をしてくれました。
講演内容に関する確認藤井 それでは、セミナーの内容についてのQ&Aに移ります。何か質問などはありますか。
河合 19ページのスライドで、横方向の矢印には「利用」と「抽象化」と書いてあるのですが、縦方向の「暗黙」と「形式」の方の矢印にとても興味があります。21ページのスライドには縦方向のピラミッドが書いてあるのですが、そこをどう実践するのでしょうか。そこでパターン言語などをツールとして使えるのではないかと思います。
 図1 (講演資料19ページ)  図2 戦略 & 知識タイプ (講演資料21ページ)
Kruchten お互いに行き来するところはSECIモデルとして表現されているので、それに追加された部分だけをこの図に描いてあります。パターンについてはどちらかというと、特殊なものから一般的なものを引き出すabstraction(抽象化)だと思うので、汎用のものをパターンにしていくということで、左下のところに含まれると思います。さらにパターンの記述の仕方を改良することで、よりよく成熟化していきます。そしてパターンが特定の分野のシステム開発に使われると、それがutilization(利用)されるというように考えています。
中原 17ページのスライドですが、右下の箱に「コード(?)」と書かれています。汎用部品のようなものなら使えるように思うのですが、クエスチョンマークが付いているのはなぜでしょうか。
 図3 アーキテクチャ上の知識 (講演資料17ページ) Kruchten コードがドキュメント化されていない場合や、設計書が改訂されていない場合には、設計上の情報はコードから得るしかなくなります。そのため、コードを形式知として使わざるを得ません。これは実際に2000年問題のときにCOBOLなどのコードを対象に行われました。コードからアーキテクチャに関する情報、知識を引き出したわけですが、ただ、それが知識を表現する最善の手段だとは思えません。ですからクエスチョンマークを付けています。それから、ライブラリなどに関しては左下の「汎用」「形式」のところに分類できると思いますが、すべてをこの図に含めているわけではなく例を挙げているだけなので、コードの方だけ書いています。クエスチョンではなく困った顔のマークの方がよかったかもしれませんね。
山城 ただ、設計判断はソースコードに埋め込まなければならないと思うんです。Kruchtenさんがおっしゃったように、設計文書は時間が経つと現状に合わないものになります。ソースコードは最新なので、設計判断はソースコードにくっついている方が、そのソースの設計判断として分かりやすいように思うのですが、設計判断はどこに書くのがよいと思われますか。
Kruchten その意見には賛成です。そういう考えも取り入れて、コードの中にマーカーを入れて、それと根拠が結びつくようにしています。
山城 Javadocのようにですか?
Kruchten そうです。Javadocも1つの形です。ただ、それによって根拠と結び付けられる設計判断は1/3に過ぎず、残りの、コード中の複数のものに同時に適用されるようなものについては、設計ガイドラインで記述していかなければなりません。インターフェースの命名規約など、コードに表現できない、きれいにマッピングできないようなものがあります。それから周囲の環境、たとえば、重役の判断だとかツールだとか、会社が合併したのでシステムを統合するといったことは、設計上の判断ではないのだけれど設計に大きく影響する判断だといえます。そういうものはソースコードの中には表現できません。
竹政 アーキテクチャを表現するときに、アーキテクチャ記述言語ではなくUMLを利用できるというお話でしたが、UMLのどの図を主に使うのでしょうか。
Kruchten 問題としているものが何かによって使うべき図は変わります。確かに、パッケージやクラスを表現することは一般的に必要ですが、振る舞いが必要ならシーケンス図を使用します。コードの構成を示すならコンポーネント図を使っていく。複雑な振る舞いを持つ組込みシステムならステートチャート図を使用しますが、eコマースのシステムならステートチャート図は使わないでしょう。ですから、問うべきことは逆で、アーキテクチャ上何が重大なのかをまず考えたら、使用する図が決まるのではないでしょうか。一般的にクラス図、シーケンス図、コンポーネント図はよく使われると思いますが、クラス図だと整理されてすっきりし過ぎるので、オブジェクト図で具体的にインスタンスレベルで示す方が分かりやすいこともあります。
中原 性能や信頼性などの非機能要件を表すときにはUMLを使うのですか。
Kruchten あまり使えないと思います。そのため、他のモデリングアプローチを使う必要があります。
羽生田 具体的に何か考え方などはありますか。
Kruchten 複雑な分散並行システムの場合は、queueing theory[待ち行列理論: システムの混雑現象を数理モデルを用いて解析することを目的とした理論]を使ってスループットや、バッファ、サーバーがどの程度必要かを考えたり、チューニングしたりすることができます。これはUMLではありません。また、セキュリティに関してはUMLにプロファイルが定義されていますが、それが本当にセキュリティを表現するのに適したものかどうかは疑問です。どちらかというと、1つの道具を中心にして、その道具が何に対しても使えると思うのは間違いだと思います。高可用性などは、配置図で表現することはできますが、それだけでは不十分なので、UML以外のものも含めて、色々なものをニーズに合わせて使いこなしていくことが必要だと思います。 安全性についてですが、かつて航空管制のシステムを扱ったときには、数多くのルールを満たさなければならなかったので、妥当性確認をするためにPrologを使う必要がありました。最善のツールが必ずしもUMLではあるとは限りません。異なる観点で適したモデルをその都度考えていく必要があると思います。 羽生田 今日のアーキテクチャの話が非常に興味深かったのですが、アーキテクチャについて議論するためには、山城さんの話にもあったように、要求をどうモデリングするかや、要求をどういうオントロジーで捉えるのか、といった話とトレーサブルにしておかないと、どういう理由(rationale)でそういうアーキテクチャになったかが紐付きませんね。そういう意味では、要求工学とリンクする話だと思うのですが、要求との関係はどう捉えればいいのでしょうか。
Kruchten 実は質問されたその点について、来年、オランダのソフトウェアアーキテクトの人と研究する予定なんですが、要求とソフトウェアアーキテクチャは独立したものではなく、非常に近くて、実際にはつながっていると考えています。ソフトウェア開発自体のモデリング過程を考えても、要求を定義するときにはシステムについての判断を下していて、その判断が次の段階の要求となり、さらに判断をしていくことになります。その要求と判断のチェーンが開発過程でできていきます。それは、スペースシャトルのロボティックアームについての設計判断のモデルを作ったときに、若い人2人が気付いたことでもあります。彼らのモデルを見ると、その中に要求の判断が混じっているじゃないか、ということになりました。そして、それについて要求とアーキテクチャの設計判断との境界線を引こうとしたんですが、よくよく考えると、両方とも同じようなもので、切って切り離せないものだということに気付いたのです。アムステルダムの大学の人が書いた’magic well’のメタファーについての論文があるのですが、切り離せない連続した判断だと考えています。 つまり、要求とは、誰かが行った別の設計判断だということです。 羽生田 UMTPには組み込みモデリング部会があって、「これは一体ドメインモデルなのか、それとも設計モデルが混入しているのか」という議論が先日もありました。ですからやはり、時代時代で、その時点で使える技術や設計上の前提知識は、常識になってしまえばそれを要求として使ってしまっても問題なかったりするので、そういう意味で切り離せない連続したものだなと思います。非常に興味深いご意見をありがとうございました。
山城 今のお話に関連して質問があります。アーキテクチャは一時的なもので寿命があるのでしょうか、それとも永続的なものなんでしょうか。
Kruchten 寿命があるかないかというのは、システムのアーキテクチャについてなのか、ソフトウェアアーキテクチャに関するdisciplineについてなのか、どちらですか。
山城 具体的な製品の具体的なアーキテクチャに関してです。ソフトウェアは特定のコンテキストで動きます。制御システムの場合はあまりコンテキストは変わりません。物理規則に則っているからです。でも、我々が携わっている製品などのエンタープライズビジネスシステムでは、セキュリティルールやコンプライアンスルールなど、多くの規則が変わります。技術も変わります。その場合、アーキテクチャが陳腐化して時代遅れのものになる可能性があります。ですからソフトウェアも進化しなければなりません。一部のアーキテクチャには寿命があって、そういうアーキテクチャは、コンテキストや技術の変化に合わせて変更しなければならないのではないかと思っているのですが。
Kruchten アーキテクチャが旧式化するのはその通りですが、アーキテクチャを変えるというのは簡単なことではありません。取り外して分解することができればいいのですが、現実問題として何かを取り外すのは非常に難しい。本当に設計の中で結合度や凝集度をきちんと守っていけば、少しはアーキテクチャの変更が可能になるかもしれませんが、なかなか困難だと思います。 もう1つ、変化というのは確かにあるのですが、変化が本当に必要な変化かというと必ずしもそうではなくて、技術の変化があるゆえに変化を入れてしまうということがあります。本当に必要かどうかではなく、世の中の流れに従って入れるような場合です。たとえばSOAの場合だと「みんながやっているからSOAをやろう」というのは、どうなのでしょうか。SOAが本当に必要かを考えていく必要があります。賢いベンダーが売り込もうとしている戦略にはまっているだけかもしれません。もちろん、SOA自体に反対しているわけではありませんよ。 河合 スライド6ページのアーキテクチャの定義の最後に「美学」と書いてあります。美学というのはエンジニアリングの範囲外なので、インストラクタをやっていると説明が非常に難しいのですが、どのように説明すればよいでしょうか。
 図4 ソフトウェアアーキテクチャ(続き) (講演資料6ページ) Kruchten セザンヌやルノワールや日本の書道などを見るのと一緒で、良いものに触れるのが大事です。美しいシステムを見て「何てエレガントなんだ」と感じたり、ひどいシステムを見て「こりゃひどい」と感じるようなことが大事です。ただ、なぜそれが美しくてなぜひどいかの説明は難しいですね。
河合 「美しい」というのは非常に属人的で、人によって評価が分かれると思います。アレグザンダーの『The Nature of Order』では、「美とは客観的なものである」と言い切っていて、具体的に15の特性を挙げています。建築の世界ですが、boundaryがあるとか、local symmetryがあるとか、strong centerがあるといった、客観的な美があると言っています。ソフトウェアアーキテクチャにも客観的なesthetics(美学)というものがあるといいなと思うのですが。
Kruchten その意見には賛成で、自分自身でも、少ない要素で構成されるとか、直交しているとか、そういうことで美しくアーキテクチャを表現できて、美しさの基準のようなものを確立できるんじゃないかと考えています。そうすることで、アーキテクチャの効率性などではなく、コミュニケーションするときの分かりやすさなどはかなりよくなるのではないかと考えています。そういう意味で、アレグザンダーの話に通ずるところは私も考えています。
講師とモデリング藤井 それでは、ここからは議案に従って進めたいと思います。まず、モデリングについてお話をいただけますか。
モデルとは何かKruchten 「モデルとは何か」「モデリングの目的」「モデリングに目覚めたきっかけ」という質問を見て思ったのは、Alfred KORZYBSKIというポーランドの人の「The map is not the territory」(地図は実際の土地ではない)という言葉です。モデルというのは抽象化であり、何らかの側面から表現したものです。その中に取り入れるか取り入れないかの判断が必要であり、その判断は何かの目的によってなされます。何かを考えるため、何かの性質を表現するため、人に伝えるためなどです。そういうわけで、モデルにとって本質的なのは、「すべてを包括しているものではない」ということです。モデルを本物にしてしまうのはたぶん間違いです。複雑になってしまって、特定の観点で考えるというメリットが失われてしまいます。地図の例でいうと、運転するためなのか、道路を補修するためなのか、水の配管を考えるためなのか、という目的ごとに地図を作るのが正しいアプローチであり、全部を同じ地図で表そうとして、それ自体が本物になってしまうと役に立たないと考えています。このことを最初に述べておきたいと思います。
山城 ADL[architecture description language]はexecutableですよね。これは本物のモデルといえますか?
Kruchten ADLは最終システムではないので、そういう意味では本物じゃないですね。
山城 ある観点でのみ実行可能だということですね。
Kruchten モデルが実行可能であってはならないという意味ではありません。特定の質問に対する回答を得るためにモデリングする、実行可能なものを作るという場合は、モデルです。画面の振る舞いやデッドロックなどを確かめるためのモデルであればいいと思いますが、モデルがそのまま最終システムとして動くのであれば、それはモデルじゃないですね。
モデリングに目覚めたきっかけ藤井 では、モデリングに目覚めたきっかけについてお聞かせください。
Kruchten モデリングについては先ほどお話したように、何か特定の問題に答えるために作成するものがモデルだと思うのですが、複雑度に対応していくことが大きな動機になっています。Alcatelの時代に、とかく要求をそのままコーディングしていくということを行っていました。それで50万行ほどのコードを書いてしまうという風潮があったんですが、それではだめだということで、UMLではないんですが、色々なモデリングアプローチを使いました。SDLや有限状態機械を使ったり、CCITT(SDLを定義する団体)にも関与したことがあります。それ以外に、さっきの待ち行列に関するモデルや、セットモデル(SETL: set-theoretic language)などの数学的なモデルや、Prologなどを使って、問題に対処していました。こういったツールは、一部の問題に対して非常に効果的です。その後、Boochたちに出会い、クラスや関係などオブジェクト設計を使ってモデリングするというやり方を取り入れました。ただ、それだけではなく、並行性などを考えるときにはAdaのタスキングを使ったりもします。というように、私自身はとても実務的に考えていて、今目の前にある問題に一番合ったモデルをそれぞれ使い分けていくという形でモデリングを学んでいきました。 それ以外に、色付きの付箋紙などをペタペタ貼り付けながらGUIのモデルを作ったり、Z(フランスの形式仕様記述言語)などを使ってフランスの原子力発電所を仕様検証したりすることも行いました。色々な問題に対する回答を得るためにそれぞれのモデルを使ってきました。
現状のモデリング技術の問題点藤井 現在のモデリング技術の課題はどのようなものがありますか。
Kruchten OMGの人たちがどんどん色々なものを入れていって、UML3.0をとっても巨大な奇怪なものにしないよう願っています。
山城 UML2.0でも巨大すぎますね。
Kruchten その通りです。3.0になったらどんなものになるか、怖くなっています。 何もかもを解決するために使えるよう、UMLをどんどん膨らませていくのはよくないと思います。そんなことをするくらいなら、違うものでそれに適したものを使っていったほうがいいと思うのです。何でもかんでもやたらと複雑にするのは良くないことです。
要求のモデリング藤井 特に話しておきたいトピックはありますか。
Kruchten 「要求のモデリングはどう行うべきか」という項目ですが、要求に関していうと、効率的にモデリングすればよいと思います。ただ「効率的に」というのが難しくて、やはりドメインによって表現などを変えるべきだと思っています。組み込みとプログラミング言語コンパイラとeコマースなら、それぞれ違う形で表現していくことになります。ただ、利害関係者などいろいろな人がからむので、図をメインに使用するのがいいのかどうかは疑問です。それよりも制約された自然言語を使う方が、誰にでも分かるのでいいのではないでしょうか。それを補完して適切なものにするために、たとえば概念やドメイン知識を表現するのにクラス図を使ったり、複雑な振る舞いを表現するのにステートマシン図、文法なら言語学のツールを使うというように、テキストじゃないモデルを補完的に使っていく形がいいかと思います。要求自体がペトリネットのようなものであまりに抽象的に表現されると、利害関係者の3/4の人が理解できないことになり、役に立たなくなると考えています。
4+1ビュー羽生田 Kruchtenさんというと4+1ビューが有名ですが、この4+1ビューについて初めて聞いたときに、「+1」がかなり画期的だと思いました。「4」の部分はたいてい思いつくと思うのですが、「+1」の方はどういうきっかけで取り入れられたのですか。それから、今考えると、この「4+1」以外にもビューポイントを設定すべきだと思うかどうかをお聞かせください。
Kruchten 最初はユースケースとシナリオを対象に考えたんですが、それはコードの一部ではなく要求側に属していて性質が違っています。けれども、アーキテクチャに対して重要な影響を与えるものなので、他のものとは分けて「+1」にしました。 昨日話をした中で触れましたが、高レベル/低レベル、抽象化/インスタンスという4つの軸に対して、アーキテクトの思考がぐるぐる回っていきます。それを4+1ビューで表現したのです。
羽生田 「+1」についてなんですが、ユースケースやシナリオで4つのビューを検証するという考え方ですよね。ユースケースやシナリオは、非機能要件を定義するときに非常に重要で、例外的なシナリオや、ミスユースケースや、セキュリティを破るハッカー的な人がどうシステムをアタックするかというシナリオなど、非機能要件に関わるシナリオを色々と出していかなければなりません。ですから、その部分をもう少し構造化したユースケースオントロジーのようなものが必要かと思っているんですが、そのあたりのアイデアをお聞かせいただけますか。
Kruchten ユースケースビューを字義通りに捉えないでください。一般的なことを表現するのには適していますが、ユースケースとはまったく関係のない非機能要求はたくさん存在します。でも利害関係者に説明するときには、あまり抽象的なものではだめで、たとえばセキュリティのこの部分がこうなっているからこう、と書いても理解してもらえません。どちらかというと、このユースケースにおいてabuseやmisuseがあったり、パフォーマンス上こうなる必要があるなど、ユースケースに関連付けて具体的に説明した方がいいと考えています。レスポンス時間に対する要求を表現するために、最低１つのクリティカルなユースケースを用いるのは有用です。時として、表現の問題であるにすぎないかもしれません。だから、ユースケースは機能要求と非機能要求の両方を表現するのに有効です。ただ、ユースケースが万能かと言うとそうではありません。たとえばコンパイラなどのシステムでは、シンタックスなどはユースケースという形では表現されないので、ユースケースにこだわっているつもりはありません。
山城 特に、ユースケース図の表現にこだわる必要はありませんよね。表形式ならとてもいいんですが、ユースケース群を図形式で書くと1枚の図面で表現できる情報が少なくなってしまします。
Kruchten まったく賛成です。ユースケース群の図表現は必須ではありません。ユースケースに関連付けなければならないのはユースケース図ではなくてシーケンス図ですね。ヤコブソンとそのことを議論したことがあります。
藤井 他のトピックはいかがですか?
Kruchten 「SOAに関してどう考えるか」ですが、SOAは非常に興味深いアーキテクチャパターンの1つだと思っています。
モデリング教育Kruchten 教育については興味を持たれていますか?
藤井 はい、お願いします。
Kruchten どういうことをすればモデラーになれるかとか、モデリングを教育するためにはどうすればいいかに関して、子供も含む様々な人たちやチームを対象として自分のキャリアの中で試したことがあるんですが、まず有益なのは離散数学です。フランスやロシアでは数学を一生懸命教育しているんですが、アメリカではあまり教育していないようで、議論の時にホワイトボードに数学の概念を出すとアメリカの人は引いてしまいます。でも、実際には集合論やグラフ理論やトポロジーは、モデリングを理解したり概念を扱うときに役に立ちます。 「入門教育・モデリング導入教育」としては、UMLを描くのではなく、練習として何かについての地図を描いてもらいます。シンボルとそれに対する凡例をそれぞれ考えてもらって、その地図によって何が解決できて何が解決できないかを考えてもらいます。それ以外に、パラダイムを見つけたり、外国語を習うのもいいと思います。異なる言葉の間では概念が1対1で対応するようにはなっていません。特定の概念に対する言葉がなかったり、1つの概念を複数の言葉で表したりすることがあります。たとえば、カナダのイヌイットの人たちは「雪」という言葉を7種類持っているんですが、フランス語や英語では1種類しかありません。また、「serendipity」のように英語なら1つの言葉で表される概念が、フランス語では文章で表現しなければならないこともあります。ですから、外国語を学ぶことによって、色々なレベルで抽象化してものごとを考えられるようになったり、言葉を組み合わせてどう表現していくかを分かるようになると考えています。そういうわけで、離散数学ほどではありませんが外国語の習得は効果的だと思います。 言語を習うことでパターンを学習していくこともあると思います。文法には言語ごとのパターンがあります。文法からパラダイム(paradigm、語形変化表)という言葉が出てきたんですが、言語を学ぶことで色々なパターンに気付いたり、モデリングを行うための思考が養われます。特殊化されたものからスタートして、一般的なものを導き出してパラダイムとして使うことになると考えています。たとえばドイツ語でいくつかの文を学んで、そこでパラダイム(語形変化表)に気付いたら、他の動詞にもそれを適用できます。それで数多くの文を話せるようになるのです。 「実践で適用するモデリング技術」に関しては、モデルを書けることだけが重要ではなく、モデルが読めるようになることも大事です。興味深いことが1つあります。数年前、自らそれほど能動的にモデリングを行わないがモデルを見る人に、少しモデリングを教えなければならないということがありました。その時に、モデルをシンプルなものにして、詳しいところを省き、記法の説明などを付け加えてモデルの読み方を教えましたが、テクニカルライターやマネージャにそういうことを教えることは大切だと思います。開発者はとことんまで詳しくモデリングして、色々な情報を盛り込もうとしますが、むしろシンプルにする、他の人にとって分かりやすいようにすることも大事だと考えています。 「大学教育と企業教育の関係」ですが、大学の役割はテクニックを教えることではありません。大学の教育(education)と企業のトレーニング(training)は別のものです。大学の役割は、生涯を通じて学ぶ人を作ることです。自分自身で学ぶことができるようになり、自分自身が知っていることと知らないことをわきまえて、自分自身の仕事を整理することができ、適切にコミュニケーションを取ることができ、どうやったら不可欠な存在になれるかを理解できるようになることです。 大学に職を得る前に、大学の産業界からのアドバイザリーボードのメンバーだったことがあります。Java や C を知っている人材が欲しいとか、いや C# を知っている人材が欲しい、あれやこれやを知っている人材が欲しいという意見を雇用者側が述べ、必要なテクニックのリストを作るということが非常に頻繁にありました。私は、それは大学の役割ではないと思います。１つの例としてJavaやUMLを学ぶということはあるでしょう。しかし、そこで身につけて欲しいのは新しいことを学ぶという能力です。トレーニングを行うのは、会社の役割です。あるいは、テクニックだけを身につけるためのテクニック専門の学校の役割かもしれません。高等教育では、教育に注力すべきで、技術の集合に注力すべきではないと思います。 興味深いことに、最近学生と議論しました。学生から、新聞の求人広告で求められている技術を並べ上げたものを見せられ、大学ではその20パーセントくらいしか学んでいない、大学に来たのは無駄だったと文句を言われたことがあります。その学生には「大学に来た目的を全然分かっていないね」と言い返しました。
モデリング技術の体系化山城 では、「モデリング技術を体系化するときの軸やフレームワークについて」お話いただけますか。
Kruchten 「モデリング技術を体系化するときの軸やフレームワークについて」ですが、これはモデリング技術のモデルを作るということ、そのモデルをどう整理するかということですね。 軸にはいくつかありますが、まず、visual（図）かtextual（テキスト）かについて考えましょう。SDLを使う場合もあればUMLを使う場合もあって、適切なツールがあれば両方を使って行き来することも可能です。ただし、図形式とテキスト形式で同じように思考するわけではありません。テキスト形式の分析での思考にはある側面があり、図形式のものには別の側面があります。 1つだけの質問に特化したモデリング技術もあります。たとえば私は、待ち行列理論を使ってバッファやキューやプロセスのサイズの分析をします。そこで欲しい答えは1つだけです。クラス間の関係などといった他の答えが欲しいわけではありません。逆に、幅広い問題の答えを出せるモデリング技術も必要です。その代わりに、モデルは非常に複雑になります。つまり、narrow（狭さ）とbroad（広さ）も別の軸になります。 他に、比較的粗いセマンティクスでいいか、非常に厳密なセマンティクスが必要か、という軸もあります。色紙とハサミを使ってウィンドウのモックアップを作る場合、セマンティクスは非常に緩いものです。航空管制システムの安全性を分析する場合にPrologでプログラミングするルールは、非常に厳密なセマンティクスでなければなりません。 また、純粋なモデルを作成し、それを廃棄して本当のシステムを構築する場合もあれば、最終システムに極めて近いものを作成できるモデリング技術が必要な場合もあります。後者はモデル駆動設計が目的としているものです。このようにさまざまな軸があります。 厳密なセマンティクスは、強力な数学的なモデルを拠り所にしていることが多く、特定の種類のユーザには理解しづらいものになるでしょう。私はペトリネットを使ったときに、そこから何かを構築することはできても、多くの人に何かを伝えるのは非常に困難だと感じました。でも、クラス図はずっと容易に伝えることができます。それでも、自分自身を再帰的に2度も指しているようなクラスなどは理解しづらく、オブジェクト図で説明する必要があるでしょう。 そのように、どの軸にも利点と欠点があり、モデリング技術を選択するときに考慮しなければなりません。先ほどもUMLについて言いましたが、1つのモデリングアプローチが唯一のものであるかのように、さまざまなものを詰め込みすぎるのが危ないと思っています。
今後のモデリング藤井 ではモデリングに関する「お奨めの本」を教えてください。
Kruchten 古典的なものでは、20年ほど前のものですが、Grady Boochの『Object-oriented analysis and design』が優れています。それから、Rebecca Wirfs-Brockさんの本もいいですね。大学の若い人にスリーアミーゴ以外の本を尋ねられたときには、Martin Fowlerの『UML Distilled』第3版を薦めています。読み物ではありませんが、Gang Of Fourの『Design Patterns』も優れています。 それから、非常に役に立つ設計アドバイスが含まれている本が2冊あります。Eberhardt Rechtinの『Systems architecting』と、Mark Maierと共著の『The art of systems architecting』です。設計について原則が述べられていて、ソフトウェアの設計やモデリングをするときに非常に役立っています。重複もあるので、後者だけ読まれてもいいかと思います。一時期、私のバイブルとなっていました。
藤井 最後に、モデラーを目指す若いメンバーへ一言、アドバイスをお願いします。
Kruchten モデラーになること自体は目的ではありませんね。16歳の少年が「お父さん。僕はモデラーになりたいよ」と言うわけではありません。「システムを構築したい」と考えている人が対象であれば、「社会に貢献したい」とか「革新的な製品を作りたい」というチームの1員という人を見つけることができると思います。そのような人たちにとってモデリングは仕事の一部だと言えるかもしれません。 実際、皆さんはソフトウェアのモデリングを非常に強調されていますが、他のエンジニアリング分野でもモデリングは行われています。機械技師も常にモデリングを行っています。私の娘は土木技師ですが、モデリングをよく行っています。ただそれを「モデリング」と呼ばないだけです。UMLではない技法を使ってモデリングしています。建築家であれば、設計図や図面などと言います。「モデル」は小さい建物があって車や木なども置かれている縮尺模型のことだからです。縮尺模型ももちろんモデルで、ユーザーの承認を得るという目的を持っています。目的には色々ありますが、承認を得るのも立派な目的の1つです。つまり、「少なくとも1つの目的を達成するために現実を抽象化したもの」というモデルの定義に当てはまります。 モデラーになること自体が目的かどうかは疑問ですが、エンジニアリングを学ぶ学生にとって、モデリングは人生の大きな部分を占めます。マーケティングやビジネスを重視するエンジニアもいれば、モデリングを重視するエンジニアもいます。他の工学分野でもソフトウェアが役立っていて、ほとんどのモデルの背景には物理学が存在します。娘が橋のモデリングを見せてくれましたが、物理学や力学、圧力、材質などのプロパティを使って橋の特性を表していました。ソフトウェアでは物理学のような基本ルールがないため、実行可能なプロトタイプを作成してテストする必要があります。ですから、モデリングの役割は少し異なってきます。でも、モデリングをしているのは私たちだけではありません。 藤井 モデリングは目的ではなく、エンジニアリングの中の、問題を解決するための手段であって、ソフトウェア以外の分野でも当たり前のことなんだ、ということですね。興味深いお話をどうもありがとうございました。
参考文献
|
「UML」でモデリング技術の向上を推進
