ICTソリューション総合誌　月刊ビジネスコミュニケーション

ホーム >  要求工学 >  2008年8号 >  第47回：要求エンジニア

今回は、要求エンジニアが持つべき基本的なスキルとしての抽象化能力と要求工学知識について考えてみたい。

抽象思考

Kramerは自身の教育経験から、システムをよく分析し問題解決できる学生と、そうでない学生の能力差の鍵は抽象化にあると述べている[1]。良いエンジニアとそうでないエンジニアの差は、抽象化能力の有無によるのだというのである。要求工学では、対象システムとその環境について重要な事象や情報を要求モデルとして抽出し、そうでないものを要求モデルから除外する必要がある。抽象的に思考した結果を抽象的に要求モデルとして提示できる能力が、要求エンジニアに求められるのである。

同じことだが、「モデル化の鍵は対象の抽象化である」とも言われる[2]。抽象化できなければ良いモデルが作成できないという訳である。それでは抽象化とは何かといえば、本質的な内容だけを残し、それ以外を除外することだ。よく日本人には抽象化能力がないと言う人がいる。面白いことにKramerは、葛飾北斎の赤富士を記事の中で抽象化の例として示している。この浮世絵では、「色彩と構図が完璧に調和して富士山の本質を捉える抽象形式を表現している」という批評を紹介している。このように浮世絵は、抽象化能力を日本人が持っていることの優れた証跡なのである。さらに歴史を遡れば、鳥獣戯画に行き着くのではないか？アニメも非常に抽象化された芸術の例であろう。

このように、日本人には抽象化能力を持つ人がいることは明らかだが、それを持たない人がいることも事実ではある。最近耳にした話だが、ある外資系のベンダでこんなことがあったそうだ。とある金融系のシステムを、全面的にオブジェクト指向を用いて日本で開発することになった。ところが、設計したクラスの数は全部で3000にもなった。通常であれば300程度のクラスの個数で済むはずだったのに、である。この案件以降、この外資系企業では日本ではシステムをオブジェクト指向で設計することを止め、インドで設計するようになったということだ。抽象化思考ができない現場のエンジニアの将来はどうなるかを、予見させるような厳しい事例ではある。

モデルの選択と組合せ

ところで要求抽出では、前回紹介したように数多くの要求モデルが用いられる。必ずしもすべてのモデルを用いる必要はない。ということは、要求モデルもまた選択する必要があるということだ。要求モデルもまた、対象システムとその環境に合わせて取捨選択する抽象化能力が求められるということになる。いまのところ、どれか一つの要求モデルだけを知れば、全ての問題に適用できるという万能な要求モデルはないと考えた方がいいからだ。つまり、要求エンジニアにとっても特定の要求モデルを使いこなすだけではなく、複数の要求モデルを比較選択する能力が求められるということだ。

実際に1980年代は構造化手法が標準的な要求モデルだったが、最近はオブジェクト指向手法が要求モデルとして主流になってきた。オブジェクト指向が提案され始めた初期のころは、構造化手法は機能指向だからだめで、オブジェクト指向でないとうまくいかないという研究者やコンサルタントたちがいた。しかし、Jacobsonのユースケース図はオブジェクト指向手法であるにもかかわらず、その構成要素は機能としてのユースケースと外部アクタとの相互作用関係だったのである。機能指向が、オブジェクト指向でも最初のモデルで必要だったのである。またRobertsonの要件ローリング手法[3]などでは、データフロー図とユースケースやクラス図を併用していたりする。これらは、適切な要求モデルを柔軟に組み合わせればいいという例である。要求エンジニアは誰かが開発した要求モデルを使うだけではなく、自ら必要に応じて要求モデルを組み合わせる能力が求められる。読者の皆さんには、ぜひそういう要求エンジニアを目指していただきたい。

構造化・相対化・最適化

筆者も、数多くの大学や大学院で要求工学を教えてきたし、今も授業を持っている。そこでは、多様な要求モデルを紹介するだけでなく、要求モデルの構成要素と、それらの関係の観点から比較することの重要性について触れている。この理由は、システム開発で求められる最も基本的な思考法として、次の３点が重要だと思うようになったからだ。

構造化：

構成要素とその関係を明らかにすること

相対化：

異なる対象を構造の観点から比較すること

最適化：

比較結果に基づいて最適な対象を選択もしくは必要に応じて再構成すること

この考え方はシステム分析やシステム設計で役に立つだけでなく、モデルを比較選択するときにも有効である。たとえば、筆者の「ゴール指向によるシステム要求管理」[4]では、各種のゴール指向手法をこの考え方で構成要素に分解し比較している。この本の最終章で比較結果を示していることの意味は、もし抽象思考を身に付けた現場のエンジニアであれば、最適なゴール指向手法を現場に合わせて自ら構築できると信じているからである。

各種の手法を構造化し相対化することができなければ、適切な手法を選択できない。この本は、ゴール指向手法の構造化と相対化の実践の書なのである。これを見てもらえれば、だれでも各種の手法を選択する上でどんなことが必要になるかがわかるはずだ。もちろん、「そんな面倒なことなどいいから一番役に立つ技術を早く教えてくれ」という人には「もったいぶっている」ことになるかもしれない。しかし、現場は千差万別だろう。どのような現場なのかが分からなければ、その現場にとって最適な手法を選択することはできない。同書の最後にも述べたように、それは現場の皆さんが選択するより仕方がないのである。ということで、どれかを選ぶところはみなさんの演習問題になっている。つまり、どれが現場にとって最適なのかという答えが書いてない訳だ。

また、なぜあれだけたくさんの手法を比較検討しているかというと、多くの例を提示することで比較のやり方をパターン化できるからだ。読者の皆さんが新たな手法を選択するときに、手法を構造化し相対化する上で「具体的に」役立つはずである。もし事前にどれが良いかを判断できない場合には、有効そうだと思える手法を部分的に適用してみて、その結果を現場にフィードバックしていくこともできるのではないだろうか。本連載の第45回「要求工学プロセス改善」の記事でも紹介したように、現状のプロセスを一気に変えることは現実的ではない場合もあるからだ。

アクタ関係分析

2008年１月の連載第39回で紹介した我々のオリジナルな方法であるアクタ関係分析は、現場でもすぐ使えてかなり役に立つということが分かってきたのも事実である。残念ながら、アクタ関係分析[5]は、前掲書には出てこない。実は、前掲書を執筆してから同書で紹介しているゴール指向手法を実際に現場で使うためには、まず、アクタ関係を抽出するための補助的手法が必要だと気づいて、この手法を考案したからだ。ところがアクタ関係が抽出できれば、それをゴール図に翻訳する作業は必ずしも必要ないのではないかと考えるようになった。

これはある大学の大学院でゴール指向を教えていたときに、ある学生から「先生、アクタ関係表を定義するだけでいいじゃないですか？それをまたわざわざゴール図にする必要はないのではありませんか？」と教えられたからだ。なるほど学生の言うとおりだ。図や表の配置などの空間的な情報を除けば、アクタ間の関係についての本質的な情報としては図と表の差はない。むしろ、表の方が余分な情報がないだけ抽象的で分かり易いだけでなく、図の構成要素や表記法を学習する必要もない。つまり、だれでもすぐに記法に煩わされることなく使えるというわけだ。そういう意味では、アクタ関係分析は従来の図式を用いたゴール指向手法に対する、破壊的な表形式ゴール指向手法だとも言える。

今後もし機会があれば、アクタ関係分析法をぜひ書籍化したいと考えている。それまでに、より多くの事例に適用して評価していく予定である。

要求エンジニアに求められるスキルとは

さて、本連載の第１回では要求エンジニアについて次の２つの問いを挙げた。

• 要求エンジニアとステークホルダや開発者がどのようにして協調作業をするのか？
• 要求エンジニアにはどのようなスキルが必要になるのか？

前掲書56ページではこれらの問いに対して次のように答えている。

要求エンジニアとステークホルダや開発者がどのようにして協調作業をするのか？

システム開発のゴールを見失わないようにして、相互理解のためのコミュニケーションを実施する必要がある。このため、用語集を作成して語彙を共有することや、課題票を作成して課題を共有する必要がある。

要求エンジニアにはどのようなスキルが必要になるのか？

要求エンジニアで必要とされるスキルには、技術的スキルと個人的スキルがある。技術スキルでは、要求工学、システム工学、マネジメントの３つが大切だ。システム工学スキルが必要とされる理由は、ソフトウェアだけでなくハードウェアやビジネスプロセスも含めたシステム全体の理解が必要になるからだ。またソフトウェアシステムの戦略立案やマーケティング、財務、プロジェクト管理についてのマネジメントスキルが必要となる。

個人的スキルでは、コミュニケーション能力、認識能力、社会的能力の３つが大切だ。相互理解のためにはコミュニケーション能力が必要だし、良いコミュニケーションをするためには相手の言葉に耳を傾け、理解する認識能力が必要である。また、顧客や開発者とチームによる活動を実践して、その中で交渉したり妥協するというような社会的能力も必要だ。

IREB
（International Requirements Engineering Board）[6]

国際要求工学委員会IREBという組織がドイツ語圏で設立されているようだ。IREBでは表１に示しているように要求獲得と確認、仕様化、要求管理などの主要な要求定義タスクに対応して教程を用意しているようである。

◆認定の効果

2007年にIREBを設立して契約会社が、ドイツ語圏でこれまでに約500回の試験を実施したそうだ。この結果、実践的な有効性の評価は実施していないが、良い感触を得ているようである。

メリットとして、試験の結果与えられる認定証によって、要求定義タスクがプロジェクトの同僚から好意的な評価をもらえるようになったことを指摘している。また要求エンジニアの検定試験は、要求工学に関する共通の語彙を業界で確立する上で役立つとしている。

◆留意点

要求定義タスクに対応付けて、詳細なチェックリストに基づいて要求エンジニアの役割を定義することの問題点は、要求エンジニア以外の役割を持つ開発者と同じ成果物を作成するときに、関連するタスクが多くなることだ。たとえばユーザビリティエンジニアと要求エンジニアがプロトタイプについて共同作業するとき、利用し易いインタフェースを設計するためのタスクだけでなく、新しい機能を抽出するタスクでも協力を必要とする。これらのプロトタイプ開発の責任を誰が取るのか、プロトタイプを何回作成するのか、その品質はどうなのかといようなことを、要求工学エンジニアはユーザビリティエンジニアと役割分担を取り決める必要がある。通常はプロジェクトマネージャがその責任を持つ。このように要求エンジニアのタスクは定義できても、責任範囲についての一般的な標準を定義することは必ずしもできない場合がある。

また問題領域が非常に複雑な場合、分析スキルだけでなく問題領域を構造化できるスキルが求められる。その他にも、要求エンジニアには文書化の責任があるので、ライティングスキルも必要になる。さらに関係者と開発者の間で議論し検討することから、関係者への同情心、司会、矛盾の解消などのコミュニケーションスキルも必要となる。

既に述べている通り抽象化能力などのように、個性には個人差があるので、スキルを持つ人とそうでない人がいる。また経験によって個人が獲得するスキルも重要だ。要求工学プロセスの複雑性のために、ベストプラクティスやパターンなどの経験に学ぶヒューリスティクスがなくてはならない知識である。

要求エンジニアは、前述した基礎を知り、経験に学んだ上で初めて要求定義に関する責任を負うことができる。

IREBの要求エンジニア検定試験の上級編については、発展知識と一定のスキルを認定していく必要があり、そのための十分な議論が必要だとしている。

また、重要な課題として多肢選択問題の限界があるとしている。たとえば、十分具体的なユースケースを記述するなどの工夫が必要になるようである。

さらに、経験を試験することも難しい。Certified Software Development Professional (CSDP, available through www.computer.org）では経験を証明することが義務付けられている。また経験するだけでなく、フィードバックを得られる徒弟制度のようなしくみが必要だとしている。IREBでは、今後これらの課題について対策を用意していく必要があるだろう。

情報専門学科カリキュラム標準J07[7]

米国で2001年に策定されたIT標準カリキュラムに対応して、情報処理学会の情報処理教育委員会で策定されたのが情報専門学科カリキュラム標準J07である。このJ07では、コンピュータ科学領域CS、情報システム領域IS、ソフトウェアエンジニアリング領域SE、コンピュータエンジニアリング領域CE、インフォメーションテクノロジ領域ITからなる５領域に分けてカリキュラム標準を示している。この中で、要求工学に関連するカリキュラムが明記されているのはCSとSEの２つである。CS科目の中にソフトウェア工学があり、その中にSE5として「ソフトウェア要求および仕様」が入っている。そのトピックスは、次の５つである。

• ステークホルダ分析と要求獲得
• 要求分析モデル化技法
• 機能要求および非機能要求
• プロトタイピング
• 形式仕様技法の基礎的な概念

SE科目の中では、「モデル化と要求開発」と「開発マネジメント」がある。「モデル化と要求開発」のトピックスは以下のようである。

• モデリングの基礎
• モデリングの種類
• 要求の評価

「開発マネジメント」のトピックスは以下のようである。

• モデルの分析の基礎
• 要求分析の基礎
• 要求の獲得
• 要求の仕様化と文書化

なお、情報システム領域でもIS07に「情報システムの分析と論理設計」という科目がある。これらのトッピックスを見ると、学部で学ぶこともあり基礎的な内容になっていることが分かる。このようにCS、 SE、ISの中で要求工学に関するトピックスが共通する一方で、用語や知識について共通化されているかどうかが気になるところではある。J07でも、要求エンジニアが持つべき要求知識について領域横断的な一貫した教育が求められている。

まとめ

今回は、要求エンジニアのスキルについて抽象化スキルと欧州におけるIREBの活動事例や、日本における情報専門学科カリキュラムにおける要求工学教育科目の事例を紹介した。わが国においてもJ07のような大学教育だけでなく、現場の要求エンジニア教育のための実践的なカリキュラムの策定が望まれる。今後、要求エンジニアがスキルを獲得するための要求工学カリキュラムと、その教育コースや検定制度が提供されることを期待したい。

---

■参考文献

• [1] Jeff Kramer, Is abstraction the key to computing? , CACM, vol.50, No.1, pp.37-42, 2007
• [2] 玉井哲雄，ソフトウェア工学の基礎，岩波書店，2004
• [3] Robertson, S. and Robertson, J., 要件プロセス完全修得法，三元社, 2002
• [4] 山本修一郎，「ゴール指向による～システム要求管理技法」,ソフトリサーチセンタ，2007
• [5] 山本修一郎，要求工学，アクタ関係分析，http://www.bcm.co.jp/site/youkyu/youkyu39.html
• [6] Paech, B., What is a Requirements Engineer?, IEEE Software, July/August, pp.16-17, 2008
• [7] 情報専門学科カリキュラム標準J07, www.ipa.go.jp/jinzai/sangaku/pdf/03/shiryo3.pdf