それではワークショップを開始します。今日はNTTデータの山本修一郎先生をお招きしています。質問事項はあらかじめ山本先生にお渡しして、回答の資料を作成していただいております。まず、自己紹介と今回の講演のテーマの確認を行っていきたいと思います。

山本です。1979年に電電公社のデータ処理研究部に入りまして、言語処理方式、コンパイラ、ソフトウェア開発環境などを開発していました。大学を卒業してから20年くらい経った96年に、インターネットの技術が出てきて、NTTディレクトリという、日本で最初の検索サービスのエンジンの開発などを行いました。その後、名古屋大学で博士論文を取りました。その後、KBSE研究会[知能ソフトウェア工学研究会]の委員長をやったり、WebBASEというミドルウェアの開発で情報処理学会から業績賞を頂いたりしました。WebBASEはNTTディレクトリでも使われたし、今でも色んなところでまだ運用されているようです。それから1年後にICカードの開発をしました。これは住基カードにも使われたシステムなんですが、それで今度は電子情報通信学会から業績賞を貰いました。その後、2002年にNTTの研究所からNTTデータに転籍して、今で7年と数ヶ月です。最近はドッグイヤーなので、私がずっとNTTデータにいると思っている人も多いようです。それから、2年ほど前にNTTデータのフェローにしていただきました。最近はIPA[独立行政法人情報処理推進機構]のSEC[ソフトウェア・エンジニアリング・センター]で高信頼性システム技術ワーキンググループのリーダーをやっています。そういう関係もあって、今日ご紹介したSysML[Systems Modeling Language: システムをモデリングするための記述言語]やAADL[Architecture Analysis & Design Language]など、組込み系で標準化されているアーキテクチャ記述言語についても、最近研究しています。それから、去年ですが、知識流通ネットワーク研究会というものを人工知能学会の中に作りました。そこでは、SNS[Social Network Service]やCMC[Computer-Mediated Communication]などの新しいコミュニケーション技術が会社の中でどのように使われるか、知識を流通させるためにどのように活用できるか、などを観察しています。

図1 主な経歴 (ワークショップ資料2ページ)

そこでどんな技術をやってきたのかをまとめたのが次の図です。大学を卒業したときのテーマが、プログラムの正当性の証明だったんですね。その頃はコンピュータでやるなんてほとんどできなくて、手でプログラムの証明をしていました。その後、大学院でプログラム図式の等価性判定方式の研究として、「2つの抽象プログラムが等価であることを証明することはできません」というようなことを証明していたら、修論の発表会の時に先生に「その研究は何の役に立つんだね」などと言われました。その後、会社に入って、主に言語処理系の開発と、CASEツールの開発をやりました。図には「データフロー図の自動生成法」と書いていますが、入力と出力の関係を表で与えると、そこからデータフロー図が自動生成できる、というアルゴリズムを考えていました。それから、オブジェクトモデリングや構造化分析設計手法の有効性を実験的に評価したりもしました。同じ手法のチームを何チームかと、別の手法のチームを何チームか用意して、生産性や品質にどう影響するかをソフトウェア研究所でやっていました。それからインターネットが出てきたので、インターネット上のミドルウェアとして、Webとデータベースの連携エンジンや、XMLを使ったサービス連携、これは今から振り返るとWebサービス連携だと思うんですが、XMLをベースにワークフローを書いてインターネット上のいろんなサービスを連携するようなプラットフォームを開発していました。その後がICカードのプラットフォーム開発です。

それから、今日の講演でも言ったんですが、5年ほど前から要求工学が重要だと考えていました。具体的には分からなくても要求工学という分野があるということは今でこそ認知されていますが、5年前はソフトウェア業界の人もほとんど知らなかったと思います。でも重要に思えたので、要求工学というサイトに毎月記事を書き始め、今まで続けています。ただそれは、いろんな技術を紹介するということがメインで、そこで新たな研究をするつもりではありません。それから、今年の3月に『すりあわせの技術』という次世代リーダーのための本を書いています。私は30年くらいずっと開発をやっているので、プロジェクトをたくさん経験しています。よくよく考えると成功させる秘訣というのが何かある。それを9つのベストプラクティスにまとめて、教育サービス開発という小説仕立てで本に書いたものです。

図2 これまでの研究と方向性 (ワークショップ資料3ページ)

次の図は、どういう技術をこれまでに開発してきたかの一覧です。これがすべてではなく、ある程度形が残ったものだけです。プロトタイプとして試して捨ててしまったものもさらにたくさんあります。SoftDAはCASEツールです。VGUIDEは簡易版のTPモニタです。ちょうどクライアント/サーバーが出てきた頃、1990年前後に作ったシステムで、OracleやInformixなど、独立系RDBベンダーのデータベースを統合するミドルウェアです。それからWebのブラウザを連携する技術の開発もしました。その後、10年くらい前にXMLが出てきたので、XMLベースのいろんな連携エンジンや配送エンジンを作りました。その後がICカードです。最後の3つはNTTデータに移ってからやったものです。今の仮想化技術の走りで、PCグリッドやVPN、RFIDのプラットフォームなどをやりました。ですので、要求モデリングそのものを追究していたというよりは、いろんなシステム開発をやってきたというバックグラウンドを持っています。

図3 実践した主なソフトウェア技術 (ワークショップ資料4ページ)

少し順番が前後してしまいましたが、続けて我々の自己紹介をしたいと思います。

豆蔵の岸です。83年に社会に出て、最初は通信衛星のシステムをやっていたのですが、2年目くらいから3年間ほど、要求定義に人口知能を利用するというIPAの研究に参加し、そこでオブジェクト指向や、LISP、Smalltalkなどをやった後、一貫して社内でもオブジェクト開発を行っています。2000年にRational Softwareに移って、そこで2年くらいRoseやRUPを扱っていました。2001年の終わりに豆蔵に移り、ソフトウェアエンジニアリングや、最近では要求エンジニアリングのコンサルティングやトレーニングなどをやっています。よろしくお願いします。

バブ日立ソフトの矢藤と申します。入社して今年で11年になります。主に広島でシステム開発を行っています。モデリングやUMLはまだまだ勉強中ですが、よろしくお願いします。

バブ日立ソフトの中原です。私は日立製作所に長年勤務していまして、その内15年間は、CASEツールを開発していました。日立のEAGLE/SEWBです。4年前にバブ日立ソフトに転属になりまして、現在は、社内の開発プロセスやプロジェクト管理の標準化、人材育成などを担当しています。

テクノロジックアートの照井と申します。主にオブジェクト指向技術を活かした業務系のソフトウェア開発をやっています。小さなシステムであれば要件定義も行っているんですが、普段一番モヤモヤしていたところが、お話を伺って少し自分なりに構造化できたような気がします。

オージス総研の藤井と申します。93年ごろに社内でOMTやBooch法などの勉強会があって、オブジェクト開発方法論に入りました。2000年くらいからUMLがブームになりつつあったんですが、UMLで表現できることは結構限られているし、難易度が高いことが問題だと感じました。そこで、より簡易なモデリング方法論がないかと探し始め、アジャイルモデリングなど多様なモデリングを探求しています。よろしくお願いします。

東芝ソリューションの山城です。2年間、この技術部会の主査を担当しています。この技術セミナーでは毎回アンケートを実施して、モデリング技術の適用分野として考えていきたい分野を尋ねているのですが、これまでの累計で一番人気が高かったのが、ビジネスモデリング/要求定義モデリングの項目です。前回にビジネスモデリングをやって、今回が要求モデリングになっています。 今日セミナーに来てくださった方は、だいたいUMTPのL2試験に受かった、モデリングについて興味のある人なので、どんな風に自分の業務に応用するかについて知見が得られたのではないかと思います。

私自身は、80年代に入社して、最初の10年は、ER図、データフロー図や状態遷移図を使った構造化分析設計をやっておりました。その頃、上司がSofTech社のSADTという分析手法をやっていまして、そこで初めて要求分析というものに触れました。90年代はいわゆるオブジェクト指向の分析設計をずっとやっていて、2000年になってからMDAや要求定義に関わることが増えました。80年から90年にかけては設計パラダイムが構造化からオブジェクトに変わるという時期だったと思うのですが、90年代から2000年代は、より上流工程に向かっていくというソフトウェア工学の流れに乗ってここまで来ました。よろしくお願いします。

富士通の吉田です。入社したときは富士通研究所で、80年代は人工知能をやっていたのですが、その頃は設計などしないでバリバリとプログラムを書いていました。オブジェクト指向も当時はプログラミングテクニックでした。90年代に人工知能のほとぼりが冷めてから、ソフトウェアエンジニアリングに移って、真面目に設計や分析を始めました。私の場合はオブジェクト指向から入ったので、さきほどおっしゃったER図は書いたことがなく、最初からクラス図でした。10年前に研究所からミドルウェアの事業本部に移って、特にJavaやSOAのアプリケーション開発を支援する立場になりました。要求というとかなり上流の話で、「そこはSEの本職だろう、もっと具体的になってから持ってきてね」という立場であえて避けていてたので、勉強不足なのですが、この機会に勉強させてもらえればと思っています。

オブジェクトデザイン研究所の河合と申します。ずっと開発畑にいて、メインフレームのアセンブラから始めてPC系の開発、Microsoft OfficeみたいなものをOS2上で作っていたこともありました。そのちょっと後、UMLより前のOMT法やBooch法やOOSE法の頃からオブジェクト指向に入りました。フローチャートをごちゃごちゃ書いてアセンブラでコーディングするなど、開発は思ったよりも汚い仕事だなと思っていたのが、オブジェクト指向で「こんな美しい世界があるんだ」とはまっていきました。最近はパターンランゲージに興味を持っています。

それでは講演内容に関する質疑に移ります。先生はソフトウェア工学全般をご存知のようですが、今回は要求に絞ってお願いします。

ゴール指向要求モデリングについて42ページの分りやすい図でご説明いただいたんですが、非機能要件の要素にはセキュリティや性能などいろいろとあると思います。実際に適用するときには、この図をそのそれぞれについて作成するのか、ある程度不安なものに絞って作成するのか、アプローチの仕方を教えてください。

図4 セキュリティのNFR分析例 (講演資料42ページ)

性能についても同じ図は書けますね。システムアーキテクチャに沿って書いているので、「セキュリティ」を「性能」に置き換えてもらうと「性能[システム.端末]」、「性能[システム.ネットワーク接続]」のように分解されていきます。それぞれの性能のところでもっと具体的な応答時間や同時接続数など、主要な視点に分解していくことだと思います。

性能にしろ信頼性にしろ、非機能要件の項目単位で作成するのですか。

そうです。ですが、実際的には項目が多すぎてどうしようもなくなりますよね。ある程度モジュールとしてできているものについては端折ってもいいんじゃないかと思います。逆にこれから手を付ける未知の部分については、こういう手法を使って分析することになると思います。全部について作成するかは、そこで判断ポイントが入りますね。闇雲にやると時間がかかりすぎますから、もっとも重要なところに絞って適用するといいと思います。

分かりました。

資料の中で要求と仕様の違いについて説明がありましたが、もともとIEEEの定義を見ると、requirementという言葉自体に2つ意味があって、顧客の問題を解決するために必要なものが1つ、そのためにシステムが満たさなければいけない条件が1つです。これは、CMMだと顧客要件と成果物要件となっていたり、『ソフトウェア要求』を書いた方だとユーザー要求と機能要求に分けていたり、羽生田の翻訳した『ソフトウェアエンジニアリング』だとカスタマー要求と開発者要求に分けていたりします。その関係とこのテキストの要求と仕様の関係とは、どういう関係になりますか。

前者がユーザー要求で、仕様と言っているのが開発者要求に近いと思います。顧客の要望を、開発者サイドで要求仕様、要件というものにする、というイメージですね。その次の問題として、その要求と仕様の対応付けをどうするか、というところが必要になります。だんだんそういうことが日本の実際のユーザーとベンダーの間でも安定しつつあると思います。

ありがとうございます。

誰が要求を作るかという件についてですが、お客様もやらなくてはならないことがあると思います。特に6ページのポラニーの暗黙知の次元の図でも、自然法則や人間行動に対応するようなビジネスルールの部分、境界条件の部分を、ベンダーはよく分かっていません。目的についても、ソフトの目的は手にできても、お客さんの目的についてはお客さんにしか分からないことが多いので、実は要求定義の部分でお客さん側でやらなくてはならないことがもっともっとあるんじゃないかと思うのですが、いかがでしょうか。

図5 境界原理 〜システム開発の仮説〜 (講演資料6ページ)

ありますね。ただ、先進的なユーザー企業、特にグローバルな競争をしている企業は、そのことが分かっています。要求、つまりビジネスモデルやビジネスプロセスをちゃんと変革しない限りビジネスに勝てない、ということを認識しているので、ビジネスモデリングなどを自分でやろうとしています。ですから、ちゃんとしたユーザー企業と、そうじゃない、そもそもITが何かもまだよく分かっていないところとは、ちゃんと区別する必要があります。でも、ユーザー企業にとってはビジネスに勝つことが仕事であって、ビジネスプロセスモデリングをやっていることを広めてもしょうがないので、技術サイドのほうで「ちゃんとしたユーザー企業はこんなことをしています」というのを広めていく活動が必要じゃないかと思っています。さっきアジャイルの話がありましたが、アジャイルプロセスはユーザーが自ら責任を負うのが最大の成功条件ですよね。意思決定してくれないと、開発サイドが口を開けて待っているだけになりますから。

つまり、線引きの境界の位置が相手によって変わるということですね。

変わりますね。普通のユーザー企業は、ベンダーサイドが不勉強なせいもありますけど、中途半端な提案を持っていくと「君たちは提案力がないね」と言います。ですが、本当の先進ユーザー企業は、自らが何をすべきかを語れるはずなんですよ。でも日本はまだそこまでいっていない会社のほうが多いですね。

その質問に関してですが、要求工学、エンジニアリングとは、開発であり、人工物を作ることです。じゃ、人工物とは何か。要求工学の適用範囲で、たとえばユースケースなどの考え方で、システムの境界は何かというと、アクターがシステムの外にいて、アクターとつながっているところがシステムである。アクターによってシステム境界を決めるという、そういう考え方があります。ただ、アクターまで含めたものをシステムとして捉える場合もあります。ユースケースの考え方ではアクターは直接システムと対話をする人なんですが、ITシステムと直接対話しない周辺の人もみんな含めて、会社全体としてシステムと捉える境界もありますね。要求工学が対象としているシステムの境界がどの辺にあるのかと考えたんですけれども、たとえば人工物というと、ソフトとハードだけじゃなくて、社会システムも人工物、会社も人工物と考えられます。たとえば年金システムや教育システム、防衛システムも人工物なんですね。そういうものに対しても人工物だから要求工学は適用対象範囲と捉えているのでしょうか。境界はどの辺になっているのですか。

i*(アイ・スター)フレームワークは社会システムも対象にしていると言っています。ソフトウェアの境界条件だけじゃなくて、人間系もシステムの中に考えていいと言っています。その極端な例として、最近はSSM(ソフトシステム方法論)も、要求モデリングの考え方に近くなってきています。なので、要求モデリングの対象範囲がソフトウェアからシステムに、ITシステムからビジネスシステムに、どんどん広がってきていると思います。それは上に行くほうですね。もう1つ下に行くほうがあります。アーキテクチャが要求とコードのブリッジとなるので、アーキテクチャを前提にした要求モデリングというものが最近すごく重要になってきています。特に組み込み系はそうです。今おっしゃった、人間をアクターにするかどうかだけじゃなくて、デバイスを前提にして、デバイスごとにソフトウェア要求、ハードウェア要求を組み合わせて割り当てていくという考え方が必要で、SysMLなどはそういう拡張になっていると思います。UMLの中に、AADLのためのプロファイルもできていますね。

今私がSECでやっている活動も、AADLやSysMLを前提にしないと、システム全体のディペンダビリティが上がらないだろうと言っています。単にformal methodを適用すればシステムを高信頼化できるというのは夢ですよね。そんなところまでは行っていないんだから、その上で要件も定義しなければいけません。つまり、このコンポーネントがdependableだと言うためには、コンポーネント自体が正しくできているということと、そのコンポーネントに要求されるセキュリティなどの非機能特性が定義できているということが必要です。でも、コンポーネントができればそれが定義できるのではなく、その前段で要求モデルとして非機能特性などを定義できていないといけません。そこから引っ張ってきて、「その要求があるからこのコンポーネントはこういう特性がなきゃいけません」ということが決まって初めて検証できるようになります。その全体の紐付けのところを今議論しようとしています。

要はコンテキストというか、動く領域においての正しさですね。

そうなんです。要求モデリングもそれ自体に閉じてちゃいけません。要求モデリングにはforward traceabilityが必要です。このアーキテクチャでいいんだということを証明するための根拠にならなくてはならない、という状況になってきています。そのため、要求モデリングとその周辺技術との関係が重要になってきます。

だとすると、そこを研究開発できる人はなかなか少ないんじゃないかなと思います。要求モデリングの専門家は要求の世界だけでやっていますね。山本さんはたまたまいろんな開発をしてから今の時点で要求工学をされていますが、なかなかそういう背景を持っている人はいません。吉田さんも開発をされてからオブジェクトに入ってこられたので、同じかもしれませんが、それでもできる人が限られるなと思います。

要求は、実現性を考えずに定義して、はまっていくケースが多いですね。その、見通しを立てるとか、実現性を評価するというところが、難しいんじゃないかと思います。

だからアーキテクチャが必要なんです。古い、出発点としての要求工学の教科書には「設計制約などを考えてはだめです」と書いてあります。要求で具現化すべきものの思考の範囲を限定するから、設計など後工程のことを考えてはだめだ、というのが神話になっています。でも、それは現実社会では通用しないんです。所詮製造できないものは夢物語のままで終わるんですから。そういう社会の現実が分かっていない人が結構要求モデリングに生き残っているんですね。

少なくとも、仕様は作れるように考えないといけませんよね。要求もたぶんそうなんでしょうけれど。

SysMLなどは、最初からアーキテクチャを相当意識しています。欧米ではちゃんと考えられているんです。オブジェクト指向の最初の頃は、機能モデルはゴミだと言って排除していました。構造化手法は機能中心主義だからだめだと言って。でもユースケースは機能モデルそのものだというような、あたりまえのことを最初は誰も見ようとしていなかったんです。それが最初に言った「モデル絶対主義者」です。今まではモデルがなかったから構造化手法でやろう、構造化手法がだめなのはオブジェクト指向じゃないからだ、オブジェクト指向がだめなのはゴール指向じゃないからだ、というように、古いものがだめになって新しいものがよりよくなる、つまりよりよいモデリングになっていくという、モデリング進化論を唱える絶対主義者の人がいます。でも、それは間違っているんじゃないかという視点も重要だと思うんですね。よい構造化モデルもあるんです。よいオブジェクトモデルももちろんあるし、よいゴールモデルもあって、そこを冷静に見たほうがいいと思います。

そもそもUMLの体系自体が全体を総合したようなモデルになっていますから。その極めつけは、SysMLの中にゴールツリーみたいなものが入っていることですよね。あれには驚きました。

要求はすべてをUMLやユースケースやモデリングで書ききれるわけじゃありません。それ以外に自然言語で書いたり表で書いたりもします。ただ、静的なクラス図が表すもの、たとえばビジネスルールで受注と発注にはこういう関係があるとかいうのを、全部自然言語で書いてどこかにまとめておくかというとそうでもなくて、それはモデルで表します。モデルで表したものとモデル以外で表したものをどう扱うか、少なくともこれが要求のフルセットですという成果物を作りたいときに、モデルで書いたものと文書で書いたものをまとめて「これが要求のドキュメントです」という風に使う。そうすると多分、変更があればもともとの要求のモデルもずっとメンテナンスしていかなきゃならないことになります。そういうやり方がいいと思われますか。それともモデルはあくまで要求を分析するために書いて、結果はどこか別の要求仕様書などに全部まとめるかたちで成果物を作るのでしょうか。どちらがお勧めですか。

私は両方あると思います。さっきのモデル進化論と同じように、モデルを使うプロセスの進化論もあって、それはプロジェクトの文化ですよね。モデルをどう使いこなすかという文化論だから、いろんな文化があっていいと思います。でもそれは、開発対象とセットなんですね。あるときはスナップショット的な使い捨てモデルでもいいんです。安定していない場合はその方がきっと効率がいい。でもある程度安定してきたら、ちゃんとしたモデルが残っていないといけません。人も入れ替わりますし、システムの運用フェーズに入ってずっと動き続けているときに、コードと対応するちゃんとしたモデルがなければ、「現行通り」という一言で全部引き継がれていくような世界になってしまいます。それは最悪ですよね。そういうことについてのメッセージを整理することは大切だと思います。どっちかを選べというのではなく、両方の可能性があり、それぞれの可能性が役立ったケースは何ですかというのを、ちゃんと記録していく地道な活動が必要だと思います。どっちがいいかを選ぶのではなく、そういう冷静な議論をしなくちゃいけません。

今日はすごくたくさんのことを学ばせていただいたんですが、私の勉強不足もあって、それぞれの関係がよく整理できていません。要求工学というものの枠組みがあって、それに当てはめて整理できればいいなと思っています。まず、基本的には要求を仕様に変換するプロセスが要求工学の対象だという認識でいいですよね。それに対する技術として、要求を網羅する技術や、要求を仕様に落とし込む技術や、落とし込んだ仕様が要求に対して十分かどうかを考える技術とか、そういう風に枠組みの中で技術を分類できるだろうという考えでよろしいですか。

はい。

そうすると、たとえば非機能要求の話がありましたが、これは今の枠組みで言うと、仕様の網羅性に関する話でしょうか。

そういう意味では、非機能要求自体も抽出しなければいけないし、非機能要求自体を仕様化しなければいけないし、非機能要求のセットで十分かどうかも確認しなければいけません。

非機能要求は要求だから、要求の方の網羅性の話だということですか。

それもあります。今日は省略したんですが、要求の基本的なプロセスには、まず要求獲得というフェーズがあります。それから、それを仕様化するプロセスがあります。

そうすると、非機能要求はどこの話になりますか。要求獲得の話ですか。

要求獲得と仕様化です。今までは仕様化したときにほとんど機能仕様しか書いていないんです。非機能要求が仕様化されていないケースが多い。つまり、この機能が欲しいって書いてあるだけで、性能などが仕様になっていません。あるいは、「応答速度が2秒以内」のようにすごくアバウトなことしか書いていない。非機能要求としてテストできない書き方になっています。

ちょっと私が混乱しているのは、非機能要求としては「応答速度が2秒以内」とかいう例がよく出てくるんですが、それは先ほどの要求と仕様という言葉でいうと仕様に思えるんですが、本当は要求なんでしょうか。

仕様だと思います。

仕様ですよね。だから、仕様には機能に関するものと非機能に関するものがあるということですね。

そうなんですが、フェーズとして非機能要求も「操作性がいいこと」「応答性がいいこと」というようなものがあります。これはまだ要求レベルです。

それは要求なんですか。

要求です。ただそれを具体的に、たとえばシステムの入出力で「この入力からこの出力まで何秒」とか決めていくのは仕様になります。たとえばセキュリティを強化してほしいという要求があったら、それに対して必ずしも非機能の仕様が対応するとは限りません。たとえばログインの機能を付けるように、機能仕様にマッピングされることもあります。要求とそれを実現するための仕様が、必ずしも機能と機能、非機能と非機能のようにマッピングされるとは限りません。

重要なポイントですね。それがちゃんと整理された書物を私も知りません。

そもそも日本語になるときに、requirementを全部「要求」と訳しているから、どの部分が本来の要求でどの部分が仕様に対応する成果物の要件なのかが、翻訳したものを読んでいると分からないんです。たとえば「要求が必ず検証可能であること」と書いてあっても、要求を検証するのは困難です。数値で表現しろと言っても、「操作性能がいいこと」を数値で表せないですよね。ただ、仕様は「この入力からこの出力までどれくらい」のように必ず数値で表せます。そこをみんな区別しないで使っているので、定義が分かりにくいです。

SECのエンタープライズ系の要求アーキテクチャ領域では、今年度から要求と要件という言葉をきちんと定義していますよね。非機能要件に変わったんじゃないですか。

変わったんですか。要件という方が「システムが持つべき特徴」ですか。

そうです。要求は言いっぱなし。

外部からの「こうして欲しい」というやつですね。

非機能か機能といっているのは、要求の区別だと考えるのが正しいですか。

両方あるので、ちゃんと区別して整理しないといけないですね。

要求から仕様の流れの中で、機能に関するものと非機能に関するものがあるわけですね。次に、ゴール指向のテクニックをいくつかご紹介いただいたんですが、これは先ほどの、要求から仕様に変換するという枠組みの中では、どこの技術だと考えればいいですか。

主に要求のところですね。

要求の網羅性を上げるための技術ですか。

何のためにこのシステムを作るのかという部分です。

そうすると、我々ベンダーからすると、お客様が何をしてほしいかをお客様と一緒に考えるときのテクニックと考えていいですね。

システムの境界上にある要求よりも、もっとシステムの元の目的とか、ビジネスをどうしたいとか、業務を効率化したいとか、いろんなレベルで要求が出てくるんです。ビジネスの役に立つシステム要求を導き出すには、上のレベルから段々に目的と手段の連鎖を落としていきます。その連鎖を逆にたどってみれば、ビジネスの役に立つ要求ですよ、ということが保証できるんです。そこにゴール指向というものが使えます。それは要求から仕様というより、システム要求を導き出すための1つのテクニックです。

でもそれだけじゃなくて、スコーピングなどをするためにも使えますね。

それはそうです。スコーピングもあるし、要求の妥当性の確認をするためなど、色んな面で使います。手法はいろんな目的で使うので、どの目的で使っているかを常に意識していることが大事です。たとえばユースケースも、要求を定義するために使うという立場と、要求を抽出するために使うという立場など、色んな使い方があるので、ユースケースとかゴール指向のレベルで論じてしまうと、それをどういう目的で使っているかによっていろんな意見が出てきてしまいます。

ざっくり言うと、目的と機能と構造を対応付けるためのグラフですよね。今までは機能リストだけ書いて要件にすることがほとんどでしたが、そうではなくて、ひとつひとつの機能がいったい何のためにあって、それがビジネスにどう活用されるかをちゃんとトレースできるようにしましょう、ということだと思います。AIでもゴールとプランの関係があって、もともとゴール指向はAIから来ているんですよね。

要求工学とは要求と仕様の変換だ、というだけでなくて、他にもいろいろ登場人物がありそうで、その辺を整理していただけると助かります。たとえばこのi*というのはこういうことを考えるのに使える技術ですよ、とか、SysMLの要求図はこれとこれの関係を表現する図ですよ、とかを整理すると、ひとつひとつの技術の関係や体系がもうちょっと分かりやすくなるような気がします。

整理するためのフレームとしては、要求を抽出し、分析し、仕様化し、妥当性を確認するという、要求に必要なプロセスにマッピングして考えると分かりやすいかもしれません。

そういう手順があるのであれば、このフェーズのこういうことに使える方法としてi*がある、といった整理をされたものはないんでしょうか。特にこのアシュアランスケースという、言葉からして中身が全然想像できないものなどは、どこの枠組みに入るんでしょうか。たとえば、先ほどのフェーズでいうと、どこで何に使うものですか。

もとはセーフティケースと言っていたもので、要求の確認で使います。

抽出した後の確認に使うんですか。

分析と確認は似ているので分け難いところはあるんですが、作られたものによって、「この要求でシステムは安全だ」ということが確認できます。システムの安全性や正当性を確認するための手法です。assuranceは日本語に訳しにくいので難しいんですが。アシュアランス自体が1つの非機能特性だったりします。

ゴール指向というと、とかく新たな価値を創造するようなスタンスで語られているような気がするんですが、実際のソフトウェア開発においては、今まで存在した当たり前の機能を実現することが暗黙的に求められることがあって、ボリューム的にはそちらが大きかったりします。そういう場合は既存のシステムやオペレーションを維持することをゴールに設定して考えていくということですか。

既存システムの機能があったら、「それをそのまま作ればいいんじゃないか」という考え方もありますが、「既存のシステムの機能を維持するとはどういうことか」のように、既存システムでは明確になっていなかった既存システムの価値をゴール指向で再定義していくというのも重要です。

たとえば、あるシステムで大きな3つの目標を掲げて開発を始めたんだけど、いざ要求を抽出していくと、その3つの目標と関係のないものがどんどん入ってくるんです。今までのシステムに存在した機能なのでこれもあれも入れてくださいというように。

1つの対策はBPRです。日本の文化の悪いところは、捨てることができない点です。捨てるためにゴール指向を使うというのはあるんじゃないですか。そうしないと増えるばかりで何のためにやっているか分からなくなりますから。そういう引き算をするために使えると思います。

アシュアランスケースの話に戻りますが、アシュアランスケースはセキュリティなどと同じように、アシュアランスという観点での要求の獲得や仕様への変換のテクニックと理解してよろしいですか。

そうです。OMGでもソフトウェアアシュアランスというワーキングができて、その中で議論されています。そのうちアシュアランスケースのためのステレオタイプやUMLプロファイルが出てくると思います。

先週でしたか、OMGとSEIが一緒にコンソーシアムを作りましたね。Consortium of IT Software Qualityというものですが。あれはまた別なんですか。

それは知りません。でも、SEIはずっとアーキテクチャの議論をしているので…

では同じ方向を向いている可能性がありますね。

向いていくと思いますよ。つまり、アシュアランスケースをちゃんとやろうとすると、システム全体のアシュアランスを定義することになりますが、結局はアーキテクチャのコンポーネントごとのアシュアランスに展開されていきますから。逆に言うと、OMGやSEIはちゃんとしているなと思いますね。着実にやっている。だからなかなか勝てないんじゃないかと思います。

いいことをやって頂いているんですが、伝えるのがだんだん難しくなってきています。メタモデルやメタメタモデルが入っていると、普通の人が見ても分からない仕様書になってしまって、活用するまでの敷居が高いですね。

そうですね。日本の技術者にとって分りやすい、具体例で理解できるようなテキストは、日本で作るしかないでしょうね。

具体例も、企業の人間であれば自社の事例で作れるのですが、それは公開できないので社内の資産にしかなりません。

共通な例を作らなければいけません。今日もいくつか例を書きましたが、全部自分の経験にあった例を一般化して書いたものです。OMGで使われている例をそのまま持ってくると、ごちゃごちゃしたことになりますし、具体的な経験に基づいたものの方がわかりやすいと思って書いています。でも、全体の方向感としては、OMGはしっかりしていると思います。ただそれも、個別にバラバラに動いているように見えますので、全体像が見えにくいですね。それはこっちで想像するしかありません。OMGでどういうワーキングが走っているかを見ると、今欧米で何が重要視されているかが分かる気がします。やってみないと分からないことの方が多いですから、彼らもやりつつ軌道修正しているということだと思います。逆に言うと、ゴールは最初から定義できるのか、という問いです。システム開発をするときに、アバウトなことは分かっているけれど、それは本当のゴールにはなっていません。ゴールモデリングにもそういう面があって、開発が進行するに従って安定したモデルができる。このフェーズでゴールのモデルをかっちり作ります、なんていうのは、それも神話だと思います。でも、システムができたときには、ちゃんとしたモデルになっていますね。ちゃんとした理由があれば後付けでもいいんです。開発が進行したあとで「ゴールはこうなる」という定義になると思うんです。それが現実です。現実をすぱっと捨てて、理想的にはこういうゴールモデルができます、それから仕様書が出てきます、というのはちょっとどうかなと思います。

話は変わりますが、「要求獲得モデルとアクタ関係」のスライドに非常に興味があって気になるのですが、これはモデルの組み合わせのようなことをおっしゃっているのですか。

図6 要求獲得モデルとアクタ関係 (講演資料81ページ)

アクターの捉え方が違うのですが、結局は全部図なので、アクターとアクター関係で表現できるのではないか、と言っています。もっと言ってしまうと、要求獲得モデルはいろいろありますが、それをコンピュータで実装しようとするとどうなるか。全部グラフなので、ノードとノード関係になりますね。ノードとしてアクターは何をしていますか、ノード関係は何を取っていますか、ということによって、全部説明できるはずだ、ということです。そうすると、何か統一できる可能性があるんじゃないかと思うんです。もう1つは、アクターとアクター関係で表現できるのなら、左側に書いた図じゃなくても、表として表現できますね。そうすると、今は色んなモデルがバラバラと出てきてお客さんに説明しにくいのですが、表なら分からない人はいないんじゃないかという仮説です。ただ、階層関係を表現するのは図じゃないと難しいかもしれません。SysMLは、辞書式の順序を与えて、表で階層関係を表現していますね。

公開されているNTTデータさんの研究論文で、ARM[Actor Relationship. Matrix、アクタ関係表]というマトリックスで表現しようというものがありますね。

何故ああいうマトリックスでやったかというと、i*フレームワークを学生に教えるときに、まともに書ける人がいないからです。相当練習しないと、ちゃんとした図は書けないんです。でも、まず表で分析させると、そこそこ書けるようになります。

確かに状態遷移図なども、一見正しいんだけれども抜けてばっかりの遷移図を書きますね。

正しいかどうか分からないでしょ。

STM[State Transition Matrix、状態遷移表]を書くと、これは考えていないね、とかいうことが確かに分かりますね。

表の方が網羅性が上がるんですが、僕たちは「図の方がちゃんとしている」という神話を持っているんです。でも現場ではほとんど表ですね。

私はこのスライドを見て、そもそも要求や要求エンジニアリンクで決めなきゃいけないことはこういうことだから、それをきちんと定義するために何を残さなきゃいけないかということと、こう組み合わせれば書けますよという話かなと思ったんですが。

そういう面もあります。要求獲得モデルでは何をするんですか、と考えると、所詮はアクターとアクター関係をある視点から切り取っているだけなんです。そういうことがコンパクトに説明できている。もっと言うと、これから新しい要求獲得モデルが出てきたとしても、それは新しいアクターと新しいアクター関係を規定しているんじゃないか、という予測もできます。

そうなると、OMGあたりがまた要求定義のメタモデルを作ってURMLみたいなものをやりそうですね。メタモデルが考えられるとおっしゃっているんですよね。

そういうことになると思います。もし統合的な要求獲得モデル体系ができたとすると、ここに出てきているアクターの間のトレーサビリティを説明できなきゃいけないということも分かりますね。たとえばクラスとゴール図のアクターはどういう関係か、ユースケース図で出てくるアクターと他のものはどういう関係か、といったリンクが張られなければいけません。

これに関連してもう1つ教えてほしいのですが、UMLで設計をするときには、UMLはあくまで表記法なので、設計論は別だと言います。いい設計を残すために、デザインパターンのようなものを提唱したり、あるいはMVCのようなもっと大きなアーキテクチャを提案する、といったことがなされていますが、この要求定義の世界でも、いいパターンの収集のような研究もあるのでしょうか。

あると思います。スライドに用意しましたが、モデリングケースというものを作ったらどうかと思います。社会情勢変化、つまり、なぜ新しいモデリング技術を使わなきゃならない状況になったのか、ビジネス環境の変化なのか、技術環境の変化なのか。モデリング技術が対象としているものは何か、そのモデルを使わなきゃいけなくなったのはIT自体が変わったからなのか。たとえば新しい期待が出てきたからビジネスモデリングしなきゃいけなくなったなら、その背景は何か。そういうなぜなぜ論をちゃんと記録しなければいけません。そうでなくて結果としてのモデリングのパターンだけだと、使えるものになりません。美しいけれどそれを使ってどうなるのかが分からない。その人が使うときに、その会社の状況はどうなっていて、作る対象がどうなっているか、というところも説明の必要があります。あと、技術的な課題ももちろんあります。モデリングによってどのようなソフトウェア生産性の課題や品質が解決できるのか。モデルにはどういう要素があって、構成要素間関係があるか。これはさっきのアクター/アクター関係と同じです。それから、それでいいんだということを保証する評価条件も必要です。いいか悪いかの判断ができなければ使えませんので。それから、山城さんがおっしゃった「モデルをどのようにして構成したか」の構成手順、プロセスもなきゃいけない。それからそのモデリング技術が使える組織、お客様はどういう条件なのか。それから、そのモデリング技術を実際に適用したときに、組織に対して教育しなきゃいけない、あったはずですよね、ということを残す。それが重要ですね。これはセットじゃないといけなくて、パターンのところだけを取り出してもうまくいかないと思います。

図7 モデリングケース(案) (ワークショップ資料11ページ)

これがパターンランゲージなんですね。

そうなんです。例ですけれど。これでいいかどうかは全然分からないんですが、たとえばこういうランゲージを用意したらいいんじゃないでしょうか。パターンそのものはモデル構成のところだと思うんです。要求モデルはこういう風になりました、こういう課題に対してはこういうモデルでうまくいきました、というところですね。

パターンそのものの蓄積、たとえばMVCみたいな要求の典型的なものはまだないんですか。

1つあるのは、問題フレームです。Problem Frame。あれはいくつかのパターンを用意しています。もっとあるんじゃないかと思いますが。でも、モデル構成しか書いていないので、すごく抽象的で分かりにくいです。

パターンになるためには、問題定義だけじゃなくて共通の解決策を言わなければいけませんね。問題フレームでは、問題の定義はされているようですが、解決策は提示されているんですか。

そういう意味で、SysMLの記述と対応付けています。信号機の問題などは、問題フレームで仕様と要求の対応が付いていたら、それをSysMLでアーキテクチャに落とせます、という後工程の展開とセットでないといけません。今までの問題フレームだけだと、何がご利益なのかピンとこないですよね。でも、あそこでは実はシステムの要求と仕様の関係をものすごく抽象的に整理できているんだろうなと思います。それをどう使えばいいかの応用の仕方を開発しなければいけないと思います。

さっき自己紹介の時に、成功のための9つのベストプラクティスというお話がありました。ベストプラクティスをまとめたものをパターン言語と言っているんですが、要求のベストプラクティスのようなものをまとめて行かれたらパターンになるのではないでしょうか。

そういう意味では『すりあわせの技術』という本に書いたものがそれに近いかもしれません。まず、外を見るというパターンで、顧客が誰かを特定できなければならない。顧客に対してどんな価値が創造できるかを定義できなければならない。オペレーション(活用)としてお客さんがそれをどう使うかが明確になっていなければならない。それが絶対条件です。これが落ちると、完成した後で「こんなもの無価値、要らない」と言われて終わるケースが非常に多いです。

それから、つくるときのベストプラクティスは、分解と再結合です。アーキテクチャに近いですね。ちゃんと分解できていないとうまく再利用できません。分解と再結合ができていれば、間違いなく生産性が上がるはずです。再結合するために何が必要かというと、構造化と相対化と統合化です。つまり、どれがいいかを選ぶためには相対化ができなければいけない。相対化するためには要素が構造化されていないと要素単位で比較できない。オープンイノベーションというのは、「自前開発するな」というベストプラクティスの1つです。自前開発するなと言って何でもかんでも鵜呑みにしていいかというとそうではなくて、評価しなければいけない。だから相対化と統合化が必要なんです。つながり指向というのは、「ギャップを調べなさい」ということです。抜け漏れがないことを確認しないといけません。

最後の2つは情報共有と進化指向です。進化指向とは境界条件です。どんな人工物も限界があります。だから、前提条件が間違っている可能性があるので、それを再評価してください、ということです。だいたいベンダーサイドは、作ったら終わりにしてしまいます。「バンザイ、終わった!」とほったらかすんだけれど、実はやった後で、システム開発でどんな課題が発生してそれをどう解決したのか、前提条件は本当にその通りだったのか、間違えていてこんな風に変更したのか、というところをプロジェクトが終わった後でちゃんとまとめてほしい。それが経験になるんです。だから、ベストプラクティスを整理しろということです。情報共有というのは、このプロジェクトで解決した課題、解決できなかった課題を、プロジェクトを越えて共有しなさい、ということです。

図8 すりあわせの技術 (ワークショップ資料29ページ)

この本を読めば詳しく書いてあるということですね。自前でものを作るなというのは、『人月の神話』にも書かれていますね。

でも作りたくなるんですよ。技術者魂には「他人を信用できない」というようなところがありますよね。つながり指向もないんです。チームで開発すると、誰よりも先に作ったら他人の制約を受けなくていいから、自分が先に作っちゃうんです。「後は僕の仕様に合わせてね」などと独りよがりにやってしまいます。なぜそうなってしまうのかというと、最初に分解と再結合のアーキテクチャを決められないからなんです。その仕組みづくりが非常に重要なんですが、なかなかできないですね。

要求のパターンというと、たとえば販売するシステムを作るときには、基本的に、ユーザーを登録できるとか、物を購入するとかという要求は必ずどこにもありますね。そういうのは1つのパターンになりませんか。

i*フレームワークなどもそういう視点があります。顧客というアクターと、営業や販売というアクターがいて、その間の関係の構造、糸のネットワークのパターンは記録できます。

そういうものを蓄積して、それを使って説明すると、社内などで話しやすいのかなと思いますが。

そういう意味では、ビジネスプロセスモデリングがパターンになるのではないですか。これは別に要求ではないんです。プロジェクトマネージメントです。逆に言うと、何故このシステムが必要なのかというその論点を説明できれば、後は何をやってもいいという感じなんです、お客さんに対しては。たとえば何かの計画を立てても上層部に説明できないと費用が出ません。でも、上層部には細かいことは分からなくて、論点が適切かどうか、社会的価値やビジネス価値があるかどうかが重要になります。そういう意味では一番最初が重要なんですが、それは要求じゃないんです。要求モデリングの先の企画の話です。要求モデリングの次は企画だと思います。企画案が通らない限り、システムの要求などはさせてもらえません。次のテーマは「企画と要求」だと思います。でもそんな技術はまだありません。

まったく違う分野ではあるのかもしれませんけれど。理系の分野ではなくて。

OMGの活動そのものも、だんだん理系じゃなくなりつつありますよ。ビジネスモチベーションモデル(BMM)をOMGでやっていますが、どうしてOMGがこんなことをやるの、というような話ですよね。手段などを見ても、ミッションと戦略と戦術、ビジネスポリシー、ビジネスルールですよ。ビジョンや成果のところは企画書で書くことですよね。こういったものもパターン化されていくんじゃないでしょうか。でも、どこまでやるんでしょうね。

図9 ビジネスモチベーションモデル (ワークショップ資料23ページ)

それこそゴール指向じゃないですね。

やってきたことを説明するためには「これがなきゃいけない、これがなきゃいけない」と上下に伸びてる感じですね。一方ではアーキテクチャレベルで要求のフィージビリティを確認しなきゃいけない、一方で、なぜこの要求でいいのかを説明するためのビジネスモチベーションになります。動機のモデル化って何なんでしょうね。

このモデルのいいところは、たとえばビジネスモデリングでは何をするのか、といったところをこのモデル上で説明できることです。企画でやっている作業をこのモデル上でちゃんと説明できるという意味では、非常にいいと思います。

私もそう思います。そういうことをアメリカ人はちゃんとやりますね。後はこのモデルを日本の文化にどううまく分かりやすく取り込むか、だと思います。これがどうなっていくか、私は注目しています。

ゴール指向とものこと分析の関係についてですが、ものこと分析はゴール指向の1つのアプローチと考えていいんでしょうか。本質的でない部分をそぎ落としていってモデルを作っていくというスタンスだと思うんですが、それはゴール指向の1つの形なんでしょうか。プロセスを扱っている点はそうではないんですか。

中村善太郎先生の話は分りやすいですね。生産する最終製品に着目して、不要なものは全部そぎ落とすという意味で、ゴール指向です。どちらも、中間プロセスで無駄が入っていれば捨てる、同じことがあれば削る、と明快です。ただ、なぜそれができるかというと製造業だからです。ソフトウェアでそれができるかというと、なかなか難しい。ものこと分析ができるソフトウェア開発があるとすると、それは組込み系に近いんじゃないかと思います。つまり、製品アーキテクチャがちゃんと決まっているということです。材料があって、最終製品に向かってどう部品を組み立てていくかなので、それと同じようなソフトウェア開発をするなら、アーキテクチャベースでソフトウェアを組み立てていくことになるんでしょう。アーキテクチャを前提としたソフトウェア開発だったら、ものこと分析でソフトウェアの生産プロセスを定義できます。

BPRをするためにものこと分析的な視点がいいという意見もあります。つまり、ビジネスプロセスから本質的でない部分をそき落としてTo Beモデルを作っていくということですが、いかがでしょうか。

できると思います。最終サービスを提供するために無駄なプロセスを減らそう、と考えられます。たとえばクレーム処理などですね。それは可能だと思います。TOC[theory of constraints、制約理論]も近いですね。生産管理の仕組みですから。どこにボトルネックがあるかを見つけて、そのボトルネック工程を改善します、そのプロセスを解消します、という話ですね。

やっぱりエンタープライズ系は、さっきのポラニーの図[「境界原理 〜システム開発の仮説〜」のスライド]でいうと、人間行動という部分がルールチェンジできちゃうじゃないですか。自然法則のようにちゃんとしたルールがありませんから。そこが難しいのではないでしょうか。逆に、組込み系などのハードの世界は制約が明確ですね。

だからモデル化しやすいというのはありますね。エンタープライズ系では、なんでこのプロセスになっているか、という理由がつかないものが結構あります。「これまでの経緯」のような感じで。でも、アメリカなどでは、そういうものを簡単に変えられるんですね。日本だと下手に変えられない。でも、モデル化はできると思います。16ページの図なんですが、エンタープライズ系でも実はソフトウェアの内部に人間行動のモデルを持っているはずで、それをexplicitに書いていないだけじゃないかと思うんです。たとえば組み込み系などだと、自然環境に対応するモデルをちゃんと持っています。シミュレーションできようなモデルを持っているし、要求レベルでそれを分析して、モデルで定式化された結果がソフトウェアになっています。でも上の方の人間活動や価値観はそういう風にやっているかというと、そうではない。モデルなしにコードになっているケースがあるんじゃないかと思います。そこは一旦抽象化したモデルを境界条件として明確にすることで、管理しやすくなるんじゃないかと思います。

図10 ソフトウェアとビジネス (ワークショップ資料16ページ)

確かにそうかもしれません。

他に質問はありませんか。

資料80ページに要求獲得手法がいくつか書かれていますが、この使い分けというか、お客さんによってこういうのを組み合わせて使えばいいなどの指針はありますか。

図11 要求獲得手法の分類 (講演資料80ページ)

あると思います。現場を見せてくれるなら行けばいいですし、忙しいと言われたらアンケートにする、などということだと思います。色んな手法があるので、お客さんの事情によって使い分けられると思います。でも、明確にこういう組み合わせがいいというのも言いがたいですね。できたら全部やった方がいいので。でも、やはり現場観察はやった方がいいですね。現場が分からないと、システムが出来上がったあとのオペレーションがどうなるか分かりません。また、システムを導入すると経営層が勝手に決めた場合には、現場の人が抵抗する可能性があるんですね。現場の工場に行ったら全然相手にしてもらえないような場合があります。システムを入れることで現場の作業がどう良くなるのかのコミュニケーションが取れていないと本当のことが分からないから、システムがちゃんと使えるものにならないですね。そういう意味で、連帯感が必要です。そういうことをやるためにいろんな手法を使うんですが、少なくとも左下に書いてあるモデリングを最初にやっても、お客さんにはなかなか理解されにくいと思います。

非機能要求と機能要求と言った場合に、境界を決めないことには非機能要求がどこまであるかが分かりません。人工物をデザインする中に、機能以外に非機能をどこまで入れるかという問題で、たとえばiPodの裏が鏡面に磨いてあるというのが非常にいいと言われます。でもそれを誰かが要求したのかというと、ただスティーブ・ジョブズが裏を磨けと言ったから磨いたというだけで、完全に非機能要求なんです。そうすると、人工物のqualityは、非機能要求で性能、容量、セキュリティを考えても、全部見つからないと思うんですね。

それは価値ですよね。どんな顧客価値を提供するかというところで、それはジョブズも最初からは分かっていないと思うんです。たまたまそれがヒットしただけじゃないかと思うんですけど、でもその価値観を持つことは重要ですね。このiPodという製品で顧客にどんな価値を提供できるのかという点について、つっこんだ議論をしていると思うんです。そういう意味で今おっしゃったことは、『すりあわせの技術』の中で「顧客価値」とか書いているまさにそのことで、これからは非機能要求の中に価値観がないとだめだと思います。工場に新しいシステムを入れるというさっきの話でも、単なるBPRではなく、それによってどんな価値が現場の作業者にもたらせるか、という価値の共有が重要になります。それはモデリングできるのかと言われると難しいのですが、たぶん言葉でSysMLの箱に書くんでしょうね。でも、それはすごく重要なポイントです。

紺野登さんの『アートカンパニー』という本があるんですが、そこに「誰も気が付かないところで差別化する」と書かれています。具体的にどうやるかはまったく分からないんですが。それは要求工学の範囲外なんでしょうか。

要求工学の国際会議では、そういうペーパーも出てきています。イノベーションのための要求工学というような形です。だんだん怪しい話になりつつありますが。でも、大切だと思いますよ。

使ったときにワクワクするといった要求ですよね。でも、業務システムの世界では、そういうことは気にしていないというか語られていません。コンシューマ用の製品を作るときには必要な要素になりますね。

魚の骨のフィッシュボーンチャートでは、わくわく感のような製品価値を扱いますね。たとえばマツダのRX-7やRX-8では、そうやって車のコンセプトを作っていきます。それも1つのゴール分析だと思います。フィッシュボーンチャートは横になっていますけど、あれを縦にするとゴールツリーですよね。

では、そろそろ次に移りたいと思います。質問事項を先にお渡しておいたところ、回答のスライドを作成してくださったので、それに沿ってご説明いただけますか。まず、「モデリングに目覚めたきっかけ」からお願いします。

このスライドには、以前に書いたペーパーをまとめてあります。前に再利用のための開発環境をやっていたんですが、再利用が今うまくいっていないのは、ソフトウェアの設計情報が記録されていないからだ、それなら設計情報をコードと対応付けて管理しよう、というのが最初のペーパーです。それから次の論文は、モジュール構造図をデータフロー図から作ろうというものです。要求レベルのデータフローから構造レベルを自動生成するとか、入出力関係からデータフロー図を自動生成するとかいうもので、その下は英語の論文です。そういうところでモデリングに目覚めました。それまではプログラムコードを一生懸命書いていました。

図12 モデリングに目覚めたきっかけ (ワークショップ資料7ページ)

モデルとは何でしょうか。どのようにお考えですか。

これはジャクソンが言っているのと同じなんですが、ドメインのモデルとソフトウェアのモデルがあります。最終的にはモデルは見えなくなって、ドメインとソフトウェアの相互作用しか起きません。たとえばオペレータとITのようになるんですが、その相互作用は実はモデルによって規定されているんです。逆に言うと、モデルが境界条件を決めているんじゃないかと今は考えています。

図13 モデルとは何か (ワークショップ資料8ページ)

モデリング技術の問題点はどのあたりにあるとお考えになっているでしょうか。

いろんなモデルがありますが、そもそもそのモデルでいいという判断はどうするのか。モデルには境界条件がある。モデルがいっぱいあるので、さっきのアクター関係じゃないですけどモデルチェーンを構成しなければいけないということ。最終的にはモデルさえ書けば、あるいはモデルに対する仕様を書けば、モデルが調達できるようなマーケットを作る必要があります。今のモデルは個々のプロジェクトに閉じちゃっているのですが、そうじゃなくてモデル市場を作ればモデル調達ができますね。無茶苦茶なことを言っていますが。あと、さっきのモデリングケースですね。そういったものを使ってパターン化する必要があります。

図14 現状のモデリング技術の問題点 (ワークショップ資料9ページ)

モデルチェーンというのをもう少しご説明いただけますか。

プロセスに合わせてモデルが少しずつ変化していきます。たとえば僕が昔やった入出力関係が分かったらデータフロー図ができて、データフロー図から設計が出てくるといったような、いろんなレベルのモデルがあります。最近はもっと難しくなっていて、さっきのビジネスモチベーションのようなモデルがあって、それをどう使うかが分かっていなかったら孤立してしまうじゃないですか。そういうことです。

次の図は、ボーイングやエアバスがやろうとしている話です。このシステムインテグレータはボーイングのことです。最終製品を作るためにこういう部品が必要だ、というスペックを言います。そうすると部品のモデルが出来てきます。この部品のモデルの中には機能要件だけじゃなくて非機能要件も入っています。だからバーチャルインテグレーションできます。そうすると、システム全体をモデルレベルで構築できて、かつシミュレーションできます。そして、モデルレベルでいい提案をしてくれた人のところから、本当のモデル、部品の実装を調達します。というような考え方が進められようとしているんです。それはなぜかというと、エアバスやボーイングのシステムはめちゃくちゃ巨大で、何億行という規模なので、とても1社では作りきれなくて、モデルレベルである程度信頼性や性能を検証しなければ、手戻りがものすごく大きくなるんですね。将来のソフトウェアもこういう環境になってくるんじゃないかと思います。エンタープライズ系もこうなるかもしれません。モデルが本当に普及するには、こういうマーケットが構成できていないといけないんじゃないかと思います。今は、1つのプロジェクトに閉じて、内部で勝手にモデルを書いてコードを作っていますね。そうでなくて、もっとモデルレベルでマーケットを構成できるといいですね。

図15 モデル調達 (ワークショップ資料10ページ)

ここでいうボーイングのモデルというのは、目に見える有形のモデルですか。

アーキテクチャです。

ソフトウェアとしてのモデルですか。

ソフトウェアコンポーネントです。

そういうことができているんですか。

やろうとしている段階です。

UMTPの副会長もそういうことをやろうとしているんですが、なかなか業界が乗ってこないんですね。

だってまずモデルが書けないし、とか、こんなところで分割されたらいやだし、とか。

書けないのと、読めないのも理由ですね。価値が分からなかったり、いいか悪いかを判断できないんですね。

似たようなことをやっているんですが、標準的な言語を使っていないから、実質的にできないんです。こういったことをやるためには、アーキテクチャ記述言語やモデル記述言語を標準化しなきゃいけないんですが、日本ではそれがなかなかできない。その価値が分からないからです。

なぜボーイングはこれができると思っているのかが逆に疑問なんですが。

そうしないとシステムが作れない、飛行機が作れないからです。ボーイングだけじゃなくてエアバスもそうです。これはSEIがやろうとしているんです。

その他にどのようなことを用意して、これができるような仕組み作りをしているんですか。

AADLです。それとツールですね。仮想統合したときに、そこでどんな性能が発揮できているのかということが自動的に検証できなければならないので、その検証環境も作っています。そういうツール開発もAADLの回りにいっぱい要るんです。

実行可能である、シミュレーション可能であるということが前提なんですね。

シミュレーションできないと意味がありません。

エンタープライズ系でもこのように調達しようとしたら、何らかの形で効果が分かるようなモデルじゃないといけないんですね。

たとえば、最近バブルになっているクラウドとかも、本当はシミュレーションできないといけないんですが、そんなことお構いなく「XXクラウドを使ってください」などと言っていますね。でもそれができないから、運用がすごく大変になるんです。その結果、個別に、ベンダーごとに何かをすることになります。でも本来はクラウドサービスのアーキテクチャをまず出して、「うちはこうやるよ」と言わなければならない。ですから、ユーザー企業にもそういう見識がなきゃだめです。ハードルは高いですけど、モデル調達のような考え方ができないと、戦っていけないんじゃないかと思います。

調達側に見識があると統制できるという例ですね。

そうです。ボーイングやエアバスは、ユーザー企業として自分たちのためにやるんです。先ほども言いましたが、本当に進んでいるユーザー企業はちゃんと考えています。ですから、そういうところと組んで一緒にやっていくのがいいと思います。

仕組みづくりを行って、それからその他にも展開していくということですね。

そうです。日本はそういう仲間作りが難しいですが。標準化の価値が分かっていないですからね。

次はモデリング原論というテーマでお伺いします。モデリングの方法論やモデリングの原理などについてどのようにお考えになっているでしょうか。

僕が使っている方法論は、すりあわせのところで紹介した構造化と相対化と統合化です。比較する必要がどうしても出てきますから、これは役立っていますね。

図16 モデリングの方法論 (ワークショップ資料13ページ)

モデリングも人工物なので、モデル化の範囲という境界原理が必ずあります。これが質問に沿っているかどうかよく分からないんですが、モデリング原理の1つにモデリング境界原理というものがあるんです。モデリングの範囲と範囲外とを明確にしないと、そのモデルが使えるか使えないかが判断できません。「なんでもできます」というみせかけのモデルがたくさんありますが、境界原理をちゃんと守ってもらうことが大切です。

図17 モデリング原理 原則 パターンとは (ワークショップ資料14ページ)

境界を決める方法は何ですか。

そこまでは考えていなかったので、これから考えてみます。

やはり何かゴールがあるということですか。

自分ではコントロールできない前提や制約は、モデル化する人にとっては境界になりますね。

モデルを作る人は、自分では境界に気付かないんですよね。

全部コントロールできると思っているということですか。

そういう人が多いんじゃないですか。

多いかもしれません(笑)

でも、使う人は絶対に知っておかないと落とし穴にはまりますね。パッケージなどがその典型例で、パッケージのいう通りにするととんでもない目にあったというケースはあるんじゃないですか。

原則は、最低限これを守らないとモデルではないという原則があるはずなので、それも明記しないといけません。それから、モデリングのパターンは、繰り返し現れる適用事例だと思います。こういうパターンは、原則と原理を守っているんだろうと思うので、相互に関係するんでしょうね。

サンプル集、ベストプラクティス集として蓄積されるといいですね。

そうですね。1つずつ溜めながら、こういう視点で検証していくのがいいと思います。これは一般論でしかないので。

ここでいう境界原理は、たとえばビジネスの制約など、自分の範囲の外のものであってコントロールできないんですけど、ここでいうモデリング原則の規則というのは、機械的にチェックできるものを想定されていますか。

そういうものもあります。

コンパイラエラーのような形でチェックできるようなものですか。

よく分からないです。書いただけなので。でも、方向感としてはよさそうなので、今後時間があればブレークダウンしたいと思います。そういう意味で、構文論的なものもあれば、意味論的なものもあると思います。そういう風に、もっと皆さんで展開されるといいと思います(笑)

1つ前の13ページのスライドについて質問があるんですが、構造化の他に、コラボレーションや振る舞いのようなものはどう捉えるのですか。

振る舞いも、役割連携という視点から見れば、役割構造があって、役割と役割の間のコネクティビティがあることになります。そうすれば構造化できます。

それは、たとえばクラスに操作があるというレベルでいいんですか。その操作が組み合わさってコラボレーションするとかいうダイナミックな部分はあまり相手にしないというスタンスですか。

ダイナミックな構造もあると思います。ダイナミックな構造自体も、状態遷移図のように階層的に分解できるじゃないですか。そういうのを2つ並べてみたときに、同じなのか違うのかを相対化できるし、違うならそれを統合するためにどうすればよいか、というように、振る舞いの構造化や相対化ができます。それはとても重要なことで、誤りや欠陥分析をするときに、欠陥の伝播などが出てきますよね。それは振る舞いの伝播です。信頼性やディペンダビリティで、振る舞いの分析は重要になります。実際にAADLもエラーモデルが定義されていて、そのシミュレーションができます。

次はプロセスとモデリングというテーマで、要求のモデリングの方法論や他の技術との関係などについてお考えをお聞かせください。

要求のモデリングでは、さっきの価値モデルが重要だと思います。それからその下に運用モデル、つまりオペレーションモデルがあって、それからやっと普通のモデリング、つまり、要求開発などで出てくる機能と振る舞いがあります。後は環境ですね。どんなドメインなのかということがこれから重要になってくると思います。システムが乗っかる環境自体もモデリングしておかなければならないはずですね。

図18 要求モデルの多様性と工程 (ワークショップ資料18ページ)

分析から設計を作ったり、逆に設計から分析を作るとか、分析と設計の間でいろんな性質が保存されなきゃいけません。この1つのモデリングの手法がSysMLです。

図19 分析と設計の関係 (ワークショップ資料20ページ)

それから次のスライドは、要求とアーキテクチャと仕様とコードは一体管理しなきゃいけないという私の考え方です。こういったものをばらして見てしまうとシステムはうまく開発できません。今はそういった視点がまだ欠けていると思うので、SECではこういったことを整理したいと思っています。非機能要件とアーキテクチャのような活動がエンタープライズ系にありますね。ああいったものとも連携しなきゃいけないと思っています。

図20 要求 アーキテクチャ 仕様 コード (ワークショップ資料21ページ)

ITSS[IT skill stanard、ITスキル標準]もそうですけど、役割分担されすぎていて、トータルで見る人がいないですね。要求は要求の専門家、アーキテクチャはアーキテクトというように。

そうなんです。本当に面倒なことになっていますね。

それで、プロマネがこれを見るわけではありませんから、誰も動機付けされていないような気がするんです。

そういうことを『すりあわせの技術』に書いています。自分の縦穴ばかり掘っている人が多いんですね。ですから、つなぐ人が求められますね。

それはアーキテクトなんですか。

アーキテクトだけじゃなくて、皆がつなぐ意識を持たないとだめです。要求のことだけじゃなくて、要求とアーキテクチャを一緒に考えなくちゃならないこともある、という風に、お互いが相手に貢献することで自分自身が楽になるということに気付いてほしいです。意識改革活動になっちゃいそうですが。

そういう職種を経産省が定義しないと、やろうと思わないかもしれませんね。

すりあわせの本は2030年近い時代を想定して、テスト専門家やディレクターや、オペレーションなんとか士のような、勝手な職種を創造しちゃっています。これからオペレーションはすごく重要になってくると思います。所有するのではなく利用するだけ、という流れになってきていますから。自分自身で持っていないから、他人がオペレーションしたものを見るしかなくなる。つまり、オペレーションする人の存在感が高まってきます。オペレーションを先行させて要求分析しなければいけなくなるはずです。JAXA[宇宙航空研究開発機構]なんかはそうしようとしているらしいです。人工衛星もそうですが、ロケットは軌道に乗ったら終わりではなくて、軌道に乗ってから何年も動き続けるわけです。安定状態というのはオペレーションしている状態なので、オペレーション可能な機能しか作ってはいけないんです。機能を考えるのが楽しいといって開発者が衛星の中に詰め込んでも、その機能が使われなかったら無駄ですよね。オペレーションされるというのはどういうことかというオペレーション要求を先に明確にしなければいけません。

「つなぎ」という話がありましたが、18ページのオペレーションモデルというのは、要求モデルとはまた別のものと捉えればいいですか。

オペレーションはシステムの外側にあって、システムの使い方のモデルですから、システムの要求モデルではありません。つまり、システムを使う人間系のモデルです。でも実は運用体制も作らなければいけないので、運用のための要求モデルにはなっています。ただ、そのあたりはまだ全然整理されていないので、ちゃんと書き物にしなきゃいけません。

業務モデルではないのでしょうか。

業務モデルです。昔、まだ余裕がある頃は、業務とシステムの設計を同時にやっていた頃もあると思うんですが、最近は作ることの方が忙しいのでそうなっていません。でも、使われないシステムがあまりにも増えていますね。つまり、人工衛星の開発と同じなんです。そもそも運用されるビジネスとは何かを考えて、その中で初めてシステム化する範囲が決まるはずなのに、「できましたから業務設計してください」というような話になってしまうと困りますね。

UML周辺の様々な技術、OCL、MDA、SOA、DOAなど、あるいはもっと広い範囲で、例えばソーシャルエンジニアリングなども含めて、モデリングとの関係についてどのようにお考えになっているでしょうか。

横軸でモバイル型、M2M型、コンテクスト活用型として、SOAのユビキタス活用のように書いています。横軸には基本型と複合型とマネジメント型として、SOAの技術が発展するといいですね、というようなことを昔考えていたことがあります。

図21 ユビキタスサービスのためのSOA技術 (ワークショップ資料22ページ)

そして、こちらはBMMです。

図22 ビジネスモチベーションモデル (ワークショップ資料23ページ)

ソーシャルエンジニアリングについては、3段階あるんじゃないかと思います。一番下は今まで考えているモデルです。その上に、モデルはもう十分にあることを前提として、モデル間をつなぐ技術がいるんじゃないでしょうか。ここでソーシャルと言っているのは、モデル社会をどうやって構築するかの技術です。その上に、複数のモデルをうまく活用するようなコミュニティ環境があればいいんじゃないかと思っています。まだ妄想の段階ですが。でも、個人的に結構信憑性があるんじゃないかと個人的には思っています。つまり、モデリング用のツールが一番下のレイヤにあって、その上にWikiやSNSのようなモデル間の連携を扱うところがあって、さらにその上に実際にモデルを活用する個々の人たちがいる、ということです。

図23 ソーシャルエンジニアリング技術とモデリング技術 (ワークショップ資料24ページ)

異種と言われているのは、先ほどのボーイングのような話ではなく、そういうものを越えて、ボーイングのモデルを全然別の、たとえば銀行などで使えちゃうというようなイメージですか。

たとえばUMLコミュニティもあれば、DOAコミュニティもあります。そういう色んなモデリングコミュニティを全部1つのコミュニティとしてつなごうということです。

異種モデルというのは、モデルそのものが違うタイプのモデルだということですね。

はい。要するに、お互いに仲良くしてくださいということです。「俺が一番だ」というようなモデルが世界制覇するとはもはや思えないんです。たとえばUMLの世界でも、BMMをやっている人と、純粋なUMLをやっている人と、SysMLをやっている人は違うかもしれない。そういう人たちが仲良くできるようなコミュニティをどう作るかという、コミュニティビジョンです。広すぎて分かりにくいですが、そういう世界観を目指すのも1つかと思います。そんな壮大なことを言ってもしょうがないから、一番下のところでモデルだけをやっています、というのも悪くない。でも、ユーザーサイドからすると、こういう風になっていたほうが活用しやすいとは思います。

プログラミング言語のコミュニティでは、「他のプログラミング言語は使い物にならない」というように結構排他的なコミュニティが形成されているような気がするんですが、モデルの場合は大丈夫なんでしょうか。

知りません(笑)。人間の原始的な特性として排他的なところがあるのかもしれませんね。でも、大きなユーザー企業だと、様々なベンダーの製品がバラバラに入っています。それをつなぐことが今問題になっていることを考えると、こういうことが起きる可能性はあるんです。古いモデルで作られたものもあれば、オブジェクト指向のものもあり、さらにゴール指向のものも出てきたときにどうなるかと考えると、こういう世界観がいるんじゃないかと思います。

確かに、SIなどではやっているわけですものね。

実際にやっているでしょう。でも、それをこういう風に整理はしていませんよね。

それから次のスライドですが、最近、知識流通ネットワーク研究会で私が「仲介知」というものを提案しています。世の中は暗黙知と形式知だという関モデルがあるんですが、CMCメディア、つまりメールやSNSで流れている知識を見ると、そのどちらでもないようです。それを「仲介知」モデルと言っています。ソフトウェア開発知識とは何かを考えると、そんなに一般化されたものはありません。パターンなどのように一般化された知識がどれほどあるでしょうか。具体的な経験でしか語られていないし流通していないものがほとんどではないでしょうか。でも、仲介知として流通していたものの中で、あるものは形式知になるでしょう。それから、同じような開発をやっている人たちは、一般化された知識でなくても、それと同じようなことはこうすればいいんだ、ということは分かります。だから、生の知識を流通させればソフトウェア開発知識の流通が変わるんじゃないかな、ということです。これも妄想ですが。

図24 仲介知によるジャストインタイム知識共有 (ワークショップ資料25ページ)

社内事例のようなものですか。

社内事例ですね。下手に一般化しようとすると、一般化されすぎて、どうやって使えばいいか分からなくなって、結局は誰も使わなくなります。それを僕は「不良知識在庫」と呼んでいます。そうでなくて、SNSやWikiで直接流通させなさい、そしてそれをJust In-Time Knowledge Managementしろ、と。そう言って嫌な顔をされているんですけど。

この話は、どの質問に対する答えですか。

これは、ここのソーシャルエンジニアリング技術で何を流通させるかという話です。目指すのは、一般化された知識ではなく、具体的な経験に基づいた知識を流通させることです。パターンのレベルもいくつかあるんですが、あまりにも具体的なものは流通させられません。そこをうまく考えないといけません。

オフショア開発とモデリングに関してはいかがでしょうか。

モデリング技術だけでなく、開発プロセスやオフショアの要員のスキルや、発注サイドの仕様定義能力、オフショア開発するマネージャの意識などが関係してきます。モデリングだけではありません。

図25 オフショア開発とモデリング技術の関係は? (ワークショップ資料26ページ)