JEITA ソフトウェアエンジニアリング技術分科会
2007/10/22 S.Otuki

ソフトウェアエンジニアリング技術分科会 2007 年度報告書作成に向けて、ヒア
リングを行った事項について、あらかじめ委員会の場で議論をすることによって、委員会としての解釈や見解をまとめることとしました。本資料は、そのための議論用の資料です。大槻がまとめを担当している以下の２件について、報告書掲載の原型を兼ねて編集したものです。
z 2007 年 7 月 6 日 岩野和生氏（日本 IBM）
「IBM から見た情報技術動向と SOA」
z 2007 年 8 月 31 日 吉田尚志氏（NTT データ）
「アーキテクチャ設計のための非機能要求記述」

第1章

技術調査 ............................................................................................................................... 3

1.1

情報技術動向と SOA ............................................................................................................... 3

1.1.1

はじめに ........................................................................................................................... 3

1.1.2

全体的潮流と世界戦略 ..................................................................................................... 3(1)

全体戦略 ........................................................................................................................... 3(2)

グローバル化の波............................................................................................................. 3(3)

イノベーション ................................................................................................................ 4(4)

オープンイノベーション.................................................................................................. 4

1.1.3

技術動向 ........................................................................................................................... 5(1)

仮想化............................................................................................................................... 6(2)モジュール化 .................................................................................................................... 6(3)

スーパコンピューティング .............................................................................................. 6(4)

データの増加と連邦化 ..................................................................................................... 6(5)

企業トランスフォーメーション....................................................................................... 6(6)

サービス化........................................................................................................................ 7

1.1.4

ソフトウェア戦略............................................................................................................. 7(1)

SOA 台頭の背景............................................................................................................... 7(2)

データの SOA................................................................................................................... 8(3)運用の SOA ...................................................................................................................... 9

1.1.5

情報技術動向に関する考察 .............................................................................................. 9
-1-

1.2

アーキテクチャ設計のための非機能要求記述....................................................................... 10

1.2.1

はじめに ......................................................................................................................... 10

1.2.2

非機能要求のニーズと課題 ............................................................................................ 10(1)ニーズ............................................................................................................................. 10(2)

非機能要求の難しさ ....................................................................................................... 11(3)

非機能要求を定義していく場面での課題 ...................................................................... 11

1.2.3

アーキテクチャ設計のための非機能要求 ...................................................................... 11(1)

非機能要求検討のスコープ ............................................................................................ 11(2)

SEI の手法群.................................................................................................................. 12(3)

非機能要求をアーキテクチャ設計にしていくプロセス ................................................ 13

1.2.4

非機能要求検討で活用される方法論.............................................................................. 14(1)

Planguage ...................................................................................................................... 14(2)

NFR フレームワーク ..................................................................................................... 15

1.2.5

SEC の活動 .................................................................................................................... 16

1.2.6

非機能要求に関する考察................................................................................................ 16-2-

第1章 技術調査
1.1 情報技術動向と SOA
1.1.1 はじめに
2007 年 7 月 6 日に、日本 IBM の岩野和生氏（ソフトウェア開発研究所 所長、執行役員）による「IBM から見た情報技術動向と SOA:Service Oriented Architecture」と題するヒアリング講演があり、以下講演内容を概観し、技術動向としてまとめる。岩野氏は、日本 IBM の基礎研究所所長を経て、現在大和研究所（ソフトウェア開発研究所）所長で、執行役員でもあります。SOA、オートノミ
ックコンピューティング、IT 人材育成等多方面で活躍してきており、その経験を生かした大局的な動向を講演していただいた。
IBM 社は、1914 年設立、総売上高 10 兆円、従業員数数 30 万人の巨大企業。日本 IBM の従業員
数 1 万 7 千人（関連会社を入れるとこの 2 倍程度）で IBM 全体の 12%を占める従業員数で世界で 2番目の事業所と位置づけられる。IBM の歴史は決して順風満帆ではなく、メインフレーム中心の事業展開をしていた 1980 年代の好調期から、1990 年代に大赤字に転落、ガースナー（マッキンゼー、ナビスコ会長を経て、1993 年に IBM の CEO に就任、2002 年に退任）が大鉈（なた）をふるって、当時 40 万人いた従業員を 16 万人にまで削減、株価も 10 ドル（現在 100 ドルを超えている）まで下がったこともある。

1.1.2 全体的潮流と世界戦略(1) 全体戦略
IBM が長期的にみて成功している理由は、ビジネスバリュー、インフラバリュー、コンポーネント
バリューから構成される適確なビジネスポートフォリオを組んできたからといえる。ディスプレイ、
ハードディスク、パソコン等のコンポーネントは巨大投資をしなくてならない割に変動も大きいため相当のリスクがあると判断される。
一方、ソフトウェアやサービスといった上部レイヤーが伸びてきている。PWC(Price Waterhouse
Coopers)を買収したのも、上部レイヤーの伸びを見越してのことである。サービスの売上げは全体の60%、日本 IBM でも 75%に達している。人手をかけないサービスをどのように構築できるかがこれからの課題といえる。

(2) グローバル化の波
グローバル化の潮流も見逃すことができない。フリードマンの著作『フラット化する世界』（日本経済出版社, 2006 年）にも述べられているように、企業は世界規模でグローバル化した水平的に恊働する新しいプロセスを構築していかなくてはならない。グローバルなインフラを構築するには、それを可能にする文化や法制度が必要である。それによってはじめてグローバルな労働力が獲得でき、グローバルな生産可能がになる。この流れの中では組織や個人もコンポーネント化（経済的に流通する単位）の対象になりつつある。
-3-

グローバル化のポイントは、各文化をいかにマネージできるかというところにある。例えば、日本だとレイオフができないという制約があるし、ドイツでは百人雇ったら百人分の仕事を作らなくてはならないといったことである。こういった制約に対するマネージ力が今後の競争力に影響を与えることになる。レイバーコストという観点では、日本や米国は成熟してしまっている反面、インドや中国の伸びはすさまじいものがある。

(3) イノベーション「米国が、21 世紀も引き続き発展・成長を遂げるためには『イノベーション（革新）』こそ、唯一最大の原動力。米国を丸ごと革新すべきである」と宣言した報告書が、2004 年末に発表された。その議長が IBM の CEO のパルミサーノであることから、パルミサーノ・レポートと呼ばれている。
イノベーションにはパターンがあって、発明があって、その後、バブル崩壊やパニック等のクラッシュが置き、その後、数十年かけて法整備や国際間協調が進み社会的に安定していくということが繰り返されている。

図 1.1.2-1 イノベーションの歴史的パターン
情報技術に関しては、1971 年（マイクロコンピュータができた）が発祥で、2000 年に.com バブルの崩壊が起きて、今後数十年かけて税制や社会インフラが整備される調和の時代に入っているので、将来は明るいといえる。

(4) オープンイノベーション
グローバル化の観点というからは、競争が激化していること、オープンスタンダードとコンポーネント化が進んでいること、数多くの協調ツールと組織モデルがでてきていること、そして、個人の力-4-

が増大していること等を考えると、ビジネスモデルが重要になってきているといえる。

IBM で戦略上意識していることは、発明だけでは社会的インパクトは起こせない、これに、オープ
ンなインフラが加わるっことによって大改革が起こるということである。一方、グリッドコンピュー
ティング、オートノミー、LINUX 等の経験からいうと、オープンイノベーションだけでも投資が起こらない。つまり、独自のイノベーションで差別化を図り、他方オープンイノベーションで標準化を推進するという総合的な戦略が必要である。

図 1.1.2-2 オープンスタンダードに対する IBM リーダシップ
オープンスタンダードに対する IBM の取組みは、OGSA, Linux, Eclips 等多岐にわたっている。
Linux については、500 件の特許を開放し、カーネルに関する訴訟はしないことを唄っているし、
Eclipse については 4000M ドルの初期投資、年間で 900〜1400M ドルの投資を行っている。こういった活動によっていかに追随者を作り出すかが戦略上のポイントになる。

1.1.3 技術動向
Global Innovation Outlook（技術動向の調査機関）によると、2010 年にはコード化された情報件
数鵜が 11 時間ごとに倍増、自動車に搭載されるコード行数は 1 億行程度になると予測している。これからの技術動向を読み解くキーワードとしては、サービス化、オープン化、スタンダード、グロー
バル化、仮想化、コンポーネント化、コモディティ化（低価格・普及化）、連邦化(Federation)等がある。

-5-(1) 仮想化
仮想化に関しては、下のレイヤーから上位に移行してきている。仮想エンジン→仮想 OS→仮想ミ
ドル→次世代アプリ→次世代インタフェースといった具合である。オープンな世界での SLA（Service
Level Agreement）をどのように補償するかといった事項が今後、クローズアップされてくると予想される。2001 年にオートノミックというコンセプト（HP のアダプティブエンタプライズも同様）を提唱したが、これについてもどんどん仮想化の波は上位に移行していく。仮想化については最終的に
は、個人のスキル等を扱う組織レベルまで達するであろうと考えている。

(2) モジュール化
モジュール化の観点でも、チップ、サブシステム、システム、ビジネスレベルへと上位移行している。このようにモジュール化されていくということは、管理もしやすくなるということであり、さらには、管理自身もモジュール化が促進されるということを意味している。モジュール化の延長線上に
SOA が位置づけられ、SOA には、ビジネスプロセス、データ、運用の観点がある。

(3) スーパコンピューティング
スーパコンピューティングの進歩では、IBM BlueGenL では、1000 ペタフロップスを達成している。
今後、ムーアの法則は 10 年は続くと言われている。
(ASCI Roadmap http://www.llnl.gov/asc/alliances/index_alliances.html)(4) データの増加と連邦化
データに関する観点では、機械生成データが爆発的に増加している状況がある。医療や各種モニタリング等で個人ごとに年間 CD2000 枚分のデータがとられている。データには機械生成データ、個人
生成データ、ありとあらゆるものがある。これに対処していくためのキーワードが連邦化(DataFederation)である。
ありとあらゆるデータが生成され、分散し、検索されるようになる。Websphere Information
Integrator, Google タイプの検索（OMNI Find）、コンプライアンス（法令遵守）、検索インデクス等の技術が重要である。とりわけ、IBM ではメタデータに関する技術が重要になると考えている。生成と増殖が繰り返される世界での世界知識を把握し、アルゴリズム的なメタデータ、インタラクションを行い、データの世界をとりだしてメタデータとして構成する方法が必要である。

(5) 企業トランスフォーメーション
今後は、企業の分解が促進され、新しいバリューネットの中でビジネスが再構成されていく。技術革新が継続的に起こり、オープンな標準、グローバル化も進んでいく。バリューネットの接続方法がダイナミックになり、要素構成が小さくなっていく。こういったコンポーネント間のデータの受け渡しや規則が重要になっていく。
-6-

ビジネスをコンポーネントに分解することも必要である。今後は競争戦略をたてるためのツール、製造、サプライチェーン、ビジネス管理、アカウント、顧客レイヤーを扱うもの等が整備されていくであろうし、こういったコンポーネントから構成されるバーチャルエンタプライズをどのように作る
かがポイントになるであろう。

(6) サービス化
SaaS（Software as a service）についても、今後は、ソフトウェアサービス、インテグレータ、サービスプロバイダといった組織の役割が明確になっていくと予想される。このような路線の中でホス
ティングサービスでも SLA を保証するようになっていくものと思われる。この領域は、年率 26%、
2008 年には 91 億ドル（1 兆円）産業に成長すると見込まれている。
日本での SOA は相当おくれているようで、企業内で試行している段階である。CRM の分野でのSalesforce.com はブレークしているようでもあり、日本でも待った無しの状況に追い込まれている。
日本は、ソフトウェア、ミドルウェアが非常に弱いのが現状で、何かやろうとする場合には海外企業と手を組む必要がある。東証システムのダウンなんかもこういった背景があると推察されている。

1.1.4 ソフトウェア戦略
昨年の BARRONS という業界誌での記事によると、IBM は 2002 年から 51 社買収しており、非常にうまいポートフォリオを組んでいて、そのキープロフィットドライバがソフトウェアであるとのことである。IBM がよみがえりつつあるということが、各方面でいわれてきている。
IBM Global CEO Survey(March, 2006)によると、ソフトウェア戦略では、多くの CEO が、2 年以内に根本的な改革を起こしたいと考えていること、一方でマネジメント改革は今までうまくいっていないと感じていること、そして、ビジネスとテクノロジーとを統合することがイノベーションの基本であると信じていることと紹介されている。

(1) SOA 台頭の背景
ビジネスの現場では何千もの既存アプリケーションが使われている。IT 投資の 80%がメンテナン
ス、20%が新規開発という比率である。リリースまでの時間もどんどん時間がかかるようになってきている。複雑性をマネジメントする必要がある。バグがあった時の対策、TCO(Total Cost of
Ownership)も大きくなっている。ビジネスプロセスの標準がないことも問題でである。
ユーザの世界での複雑性も限界にきている。メールの処理が追いつかないことや、情報がどこにあるかもわからなくなっている。こういった課題に対処できるのが SOA ということになる。
SOA は複雑性に対応することができる。SOA もライフサイクルの観点で考えなくてはならない。
つまり、開発から運用、さらには、ガバナンス、分析、ビジネスプロセスモニタリング等がある。SOAの参照アーキテクチャは、ビジネス、データ、運用の三階層から構成される。
-7-

図 1.1.4-1 SOA リファレンスアーキテクチャ(2) データの SOA
IOD(Information On Demand)というコンセプトを提唱している。正しい情報を正しい人に正しいタイミングでということである。産業としては、Data（データウェアハウス）が 5%、コンテンツが8.2%、情報（情報の価値を高めること）が 12% の伸び率である。市場規模としてはそれぞれ 190 億ドル、30 億ドル、53 億ドルである。

図 1.1.4-2 IOD と物理統合・仮想統合
人間の頭の中の 4%程度しか顕在化されていないといわれている。COMPUTER WORLD 誌 2006
年 2 月号よると、IBM は 1B$ をデータの領域に投資をすると発表されている。これによて、
ETL(Extract Transform Load)クレンジング、EII(Enterprise Information Integration)、メタデータ
管理、プロファイリングの技術、データの整理から配布までの情報統合基盤の整備、協調型
MDM(Mobile Data Management)、オペレーション、エラーデータ処理（データの 30%に誤りがある）、プロダクトライフサイクル WPC、インターネット、ERP、コールセンター等の進展が図られていくものと予想される。
-8-

(3) 運用の SOA
組織の複雑さが問題を複雑よりにしている。インフラも多種多様である。ITIL の IBM 版では、テクノロジから人、プロセスまでを統合的に進めること、また、オートオノミックのパラダイムと IT
プロセスとの統合も視野に入れている。

図 1.1.4-3 オートノミックのパラダイムと IT プロセス

1.1.5 情報技術動向に関する考察
歴史を概観し、産業論の観点から大局を論じた講演は、大変興味深いものであった。アルビン・ト
フラー＆ハイジ・トフラーの『富の未来』（講談社,2006 年）やピータ・ドラッカーの『ネクスト・ソ
サイエティ』（ダイヤモンド社, 2002 年）等で予見されている知識主導社会へ向けて、グローバル企業が着々と戦略をたてていることが伝わってきた。非金銭価値や経済面から観測されにくい生産消費活動も視野に入れている。特に、オープンイノベーションの戦略では、コミュニティのオープンイノ
ベーションという生産消費活動と、これを独自のイノベーションによって金銭的価値を獲得しようという形になっているのは印象的であった。
トフラーの言う第１の波（農業）、第２の波（工業）、第３の波（知識）という観点からいうと、IBMは第３の波に徹底的にシフトしようとしている。また、一方で、CEO のパルミサーノのいうイノベーションによる強い米国という路線の中で、グローバル化しつつ米国主導という当たり前の外資系企業としての局面も顕在化している。

-9-

1.2 アーキテクチャ設計のための非機能要求記述
1.2.1 はじめに
2007 年 8 月 27 日にヒアリング講演として NTT データの吉田尚志氏に「アーキテクチャ設計のための非機能要求記述」の概要の話をしていただいた。吉田氏は SEC の研究員として昨年度まで活動していた方で、米国カーネギーメロン大学(CMU)に留学していた経験もあり、SEI(Software
Engineering Institute)の動向等もよく押さえた講演をしていただいた。非機能要求に関する検討グル
ープは SEC のエンタプライズ系部会の中で活動しており、IBM の榊原彰氏や豆蔵の羽生田英一氏等も参加しており、アーキテクチャの専門家が多く参加している。

図 1.2.1-1 非機能要求をとりまく活動
1.2.2 非機能要求のニーズと課題(1) ニーズ
非機能要求に対するニーズは、要求の高度化・複雑化、情報システムの社会的基盤化にともない高
まってきている。M.Lehman（英国インペリアルカレッジ）の E（Evolutional）-Type, S（Specification）-Type というソフトウェアの種別でいうと、今後は E-Type（進化型）のソフトウェアが重要で、機能そのものが環境とともに変化、対応が要求されるし、機能以外の要求も複雑化していくと考えられる。
業務要求を中心とした開発計画、方式も見ると…
要求
分析
業務系

RFP
RFP

方式
設計

詳細
設計

コード作成
テスト

業務が固まらず、仕様確定のタイミングがズレる

結合

開発開始
本番環境
APや環境が組み上がって、・性能がでない
・信頼性不十分などがわかる、問題解析

方式系

発注

開発機
到着

十分に要求がわからないながらも、機器を発注

機器等の発注があるので、この時点で仕様確定???

システム開発

導入

開発環境

仕様
仕様

仕様
仕様

適格性
確認テスト

本番機
到着

曖昧な状況で確定、結果は最後の方でやっとわかる

運用性に問題判明
・運用者手配・サーバ機器のアップグレード

C/O

システム運用・保守
導入
サービス開始保守方法を考慮してなかったため、莫大な保守コストが発生セキュリティを考慮していなかったため情報漏洩

次期システム開発開始
運用方法が定まっていなかったため、運用に失敗してサービス停止

性能が足らず、性能向上のための追加コストが発生

図 1.2.2-1 非機能要求とシステム開発、および、システム運用- 10 -

次期システムへの移行を考えていなかったため莫
大なコストが発生

(2) 非機能要求の難しさ
非機能要求は以前からテーマとしては存在しているものの、なかなか解決に至ってはいない。その理由は、人によって解釈と評価が異なるという「主観性」、対象となるシステムの種類によって観点が頃なるという「相対性」、一方の性質を満たすと他方が損なわれるといった「相互干渉性」等があって、本質的に難しいテーマである。
その一方で、システムへの要求が高度化・複雑化し、社会基盤として位置づけられてきており、各方面で国内外の標準化、ガイドラインも整備されてきている。上記のような本質的困難があるとはいえ、システム開発や運用で社会・経済的なリスクも負うため継続的に取組んでいく必要がある。

(3) 非機能要求を定義していく場面での課題
要求定義や提案の「初期」の状態

要求定義や提案活動後の状況

ユーザに

ベンダに

認識できる 認識しにくい

認識できる

認識しにくい

Ⅰ
共通認識

Ⅱ
残された
非機能要求

Ⅰ
共通認識
Ⅳ
未知の要求
伝え忘れや
聞き出し不足

Ⅲ
残された
業務要求

Ⅳ
未知の要求
Ⅰ
共通認識

ヒアリングなどからの共通認識に加えて、不明瞭だった非機能要求について合意できるようにする手段
が必要。

Ⅳ
未知の要求
伝え忘れや
聞き出し不足図 1.2.2-2 ユーザ・ベンダとの共通認識拡大の課題
非機能要求を明確にしなくてはならない場面の代表的なものは、ユーザとベンダとの関係である。
取引価格や契約にも影響を与えることになる。ユーザの世界とベンダの世界とは文化も異なるし、認識できる事項も異なる。この中で非機能要求に関する両者の共通認識可能は範囲を広げていくことが重要であると吉田氏は主張している。

1.2.3 アーキテクチャ設計のための非機能要求(1) 非機能要求検討のスコープ
SWEBOK（ソフトウェアエンジニアリング知識体系）によると、非機能要求とは、「時として，制約条件(constraints)もしくは品質要求(quality requirements)」として知られている。また，この要求はさらに、性能要求，保守容易性要求，安全性要求，信頼性要求，電磁気互換性要求，その他の様々なタイプの要求であると定義されている。ソフトウェア製品の品質については、JIS X 0129（ISO/IEC- 11 -

9126）で品質特性、副特性が定義されている。非機能要求には、ビジネス要求、システム要求、プロ
ジェクト要求等多岐にわたっており、現在注力しているのは、アーキテクチャ設計のための非機能要求である。
プロジェクト管理
IT企画

今回のターゲット

テスト
アーキテクチャ設計

ビジネス要求システム要求プロジェクト要求

移行方法

投資コスト
信頼性

得られる利益

開発スキル

運用方法

性能

リリース時期社内インフラセキュリティ

法令遵守

納期

コスト
契約

図 1.2.3-1 アーキテクチャ設計のための非機能要求(2) SEI の手法群
SEI(Software Engineering Institute)では、アーキテクチャ設計、ライフサイクルの観点での各種の手法が提唱されている。品質要求とアーキテクチャ設計を“対”で分析・設計・評価をするために、
品質要求の記述には「品質特性シナリオ」、「ユーティリティツリー」という方法を利用している。

手法 QAW
名称 Quality Attribute
Workshop

ADD

ARID

Attribute Driven
DesignActive Review forIntermediate Designs

ATAM

CBAM

Architecture
Cost Benefit
Tradeoff Analysis Analysis Method
Method
利用 主な品質特性要求を 要求を満たすアーキテ アーキテクチャ設計のレ アーキテクチャ設計 アーキテクチャ設計で目的 発見し、洗練・具体化 クチャの初期設計を ビューを行い、設計を洗練 の妥当性を確認す の選択を費用・便益
する
行う
させる
る
の視点で選別する
適用 アーキテクチャが設計 主な機能要求、品質 初期のアーキテクチャ設 アーキテクチャの設 アーキテクチャの分計方針がある程度 析・評価が終わり、設段階 される前に要求を具 特性要求が定義され 計がなされた段階
体化する段階た段階決まった段階計を決定する段階
利害関係者に対し、 開発、および、保守・
手法 粗い機能要求、非機 品質特性シナリオを基 ADR（Active Design※
概要 能要求、制約、ビジネ に、システムの構成を Review） とATAMをあわ アーキテクチャ設計 運用に関わるコストやスゴールなどを元に品 段階的に検討してい せたような手法。アーキテ が彼らの望む特性 特定の選択による便質特性シナリオを記 く手法。検討に際して クチャ設計の詳細化を実 を備えているか検証 益を加味して費用対述・構成し品質特性 は、典型的な実現手 際に行うソフトウェア開発 し、リスク要因やト 効果を検討するため要求を洗練・具現化さ 段やパターンを活用し 者にとってアーキテクチャ レードオフとなる箇 の分析手法。
せていく手法てシステムを構成要 設計が実用的か、利用可 所を検出する。
素に分解していく。 能かを調べ課題を探る。

図 1.2.3-2 SEI の手法- 12 -

(3) 非機能要求をアーキテクチャ設計にしていくプロセス
目標・目的
関心事の列挙• 品質特性の目標• 特定視点での具体的課
題や関心事
事前に準備可能

品質要求
品質要求
分類・モデル
分類・モデル

ケースごとの
具体化

実現手段の
選択

評価

• 状況説明• 具体化された目標の実現 • 品質特性目標に対して実• 目標等の評価/検証のた方法の選択や検討
現手段の評価
めの定量化

個別の品質要求
個別の品質要求“テンプレート”“テンプレート”（記述項目）（記述項目）

開発単位ごとに準備

個別の品質要求⑤
個別の品質要求⑤⑤
仕様記述⑤
個別の品質要求
仕様記述
個別の品質要求
個別の品質要求（ケース、シナリオ）
個別の品質要求
仕様記述（ケース、シナリオ）
仕様記述
仕様記述
仕様記述
（ケース、シナリオ）（ケース、シナリオ）（ケース、シナリオ）（ケース、シナリオ）

個別の品質要求
個別の品質要求
記述例
記述例

品質要求
品質要求
に対する実現手段に対する実現手段

品質要求の関係性
品質要求の関係性
仕様記述
仕様記述（ゴールツリー、優先度）（ゴールツリー、優先度）

品質要求に対する品質要求に対する実現手段の影響
実現手段の影響アーキテクチャアーキテクチャ設計
設計

図 1.2.3-3 アーキテクチャ設計のプロセス
品質特性シナリオとは、6 部位（刺激の発生源、刺激、成果物、環境、応答、応答測定）からなる構成要素をガイドとして具体的な場面（ユースケース、フェイルケース、チェンジケースなど）についてシナリオ形式で品質要求を記述するための方法である。例えば、可用性に関する「予期しない外部メッセージを通常状態で運用中のプロセスが受け取ったときに、プロセスはオペレータにメッセージを受け取ったことを通知し、ダウンすることなしに運用を続ける」という情況は、以下のような品
質特性シナリオとなる。

成果物：
刺激：
予期しない
外部メッセージ
刺激の発生源：システムの外部プロセス

応答：
メッセージ受取りをオペレータに通知

環境：
通常状態で運用中

応答測定：
ダウンタイムなし

図 1.2.3-4 可用性に関する品質特性シナリオ
ユーティリティ・ツリー作成ステップでは、システム目的やビジネス上での目標を元に重要な品質特性を選別する。初期段階では特に、ハイレベルな機能要求、品質要求、制約条件に注目する。次にユーティリティ・ツリーを構成する品質特性を列挙し、詳細化の対象とする。そして、個々の品質特性ごとにより具体的な「関心事」を記述する。
「関心事」を具体的にシナリオ形式の記述（あるいは記述群）によって具体化する。

- 13 -

性能

Utility
セキュリティ

トランザクションの応答時間

システムピーク時でも、ユーザの利用する処理Aのトランザクションが0.5秒以内に完了する。(H,M)

スループット

ピーク負荷時にも毎秒150件の処理Aのトランザクションを処理できる。(M, M)
指定ユーザ以外の権限のないユーザが権限を必要とする情報にアクセスするとシステ
ムはアクセスを拒否し、ログを残す。
(H, M)

機密性
完全性

技能トレーニング受講により、２年以上就業経験のある社員が、１週間未満でシステム機能を習得可能である。(M, L)

技能トレーニング
使いやすさ
通常業務

図 1.2.3-5 ユーティリティ・ツリー作成
分析をより効率的に進めるために汎用のシナリオや、それを達成する実現方法（Tactics）を整備していく。
シナリオの部位シナリオにあてはまる可能性のある値

刺激の発生源システムの内部、システムの外部刺激

障害：欠落、クラッシュ、タイミング、反応・応答

成果物

システムのプロセッサ、通信チャネル、永続ストレージ、プロセス

環境

通常運転中、デグレードモード運転中（例：少ない機能、縮退運転）

応答

システムはイベントを検出し、下記の1つ以上のことを行う：• 記録する。
• 適切な相手へ通知する。ユーザや他のシステムを含む。
• イベントの原因を定義されたルールに従って無効化する。
• 事前に明記した期間、使用不可の状態になる。
（期間の長さはシステムの重要度によって異なる。）• 通常モード、あるいは、デグレードモードで継続運転する。

応答測定

システム復旧までの時間間隔（MTTR）
稼動時間
システムがデグレードモードで運転していることができる時間間隔
修復時間

可用性

障害検出
障害

回復準備
及び修復

障害回復と再開始

予防措置

障害の
遮断
あるいは
修復

• シャドーオペレーション • サービスからの• Ping/Echo • 多数決
除去• ハートビート • 動作中の冗長性 • 状態の再同期• 受動的な冗長性 • ロールバック• トランザクション
• 例外
• 予備
• プロセス監視

図 1.2.3-6 可用性の汎用シナリオと実現方法

1.2.4 非機能要求検討で活用される方法論(1) Planguage「 ソ フ ト ウ ェ ア イ ン ス ペ ク シ ョ ン 」 で 著 名 な Tom Gilb に よ っ て 提 唱 さ れ た も の で 、“Plan+Language”（計画＋言語）から合成された造語である。仕様言語(Planguage Specification
Language)とプロセス記述(Planguage Process Descriptions)とから構成される。前者は、要求・設計
およびプロジェクト計画を記述するための仕様言語で、Planguage 内で使用するコンセプトのマスタ
ー定義のセット（Planguage Glossary）、パラメータと文法のセット、アイコンのセットからなる。
後者は、特定タスク実施のための推奨ベストプラクティスを提供するプロセス記述である。
仕様記述言語は、個々の要求を構造的に記述するために詳細なパラメータを定義した記述言語としても使用可能である。

- 14 -

Evolutionary Project Management
Process.EVO

Strategic Management
Cycle
Process.SM

要求仕様化についてのプロセス

Requirement
Specification
Process.RS andsub-processes
Design Engineering
ImpactEstimation

Development
Cycle

定量化、評価可能な要求を元に、設計を評価する手法など含む

Process.IE

Production
Cycle
Delivery
Cycle
Process.DC

Specification
Quality Control

Implementation Cycle

Process.SQC

Result Cycle

図 1.2.4-1 Planguage による要求構造記述(2) NFR フレームワーク
SIG(Softgoal Interdependency Graph)による要求定義を行う。これによって非機能要求を実現する操作を明確にすることができる。
一般的な手段を上位に、下位に個別手段を整理することができる。
凡例
セキュアな
システム
AND貢献

システムの
完全性

システムの
可用性
システムの
機密性

NFR
ソフトゴール

実現手段

OR 貢献

AND 貢献

OR貢献
実現
手段

Is-A
（サブタイプ)
関係

選択された
実現手段
あるいは、
根拠

ユーザの
識別

＋/－

!

正の/負の
貢献

優先される
ソフトゴール

?

?

ユーザ
認証

根拠

選択しなかった
実現手段
発見された
あるいは
貢献
根拠

図 1.2.4-2 SIG による非機能要求記述
相関関係をマトリクスで示すことによって、間接的に相互依存性を発見、整理し、実現手段が非機
能要求に与える影響（好影響・悪影響）を記述することができる。

- 15 -

NFRソフトゴール
手段

正確性

機密性

応答性

＋

＋

－

妥当性評価
圧縮

－

索引

＋

認証

＋

追加ID

＋

資源効率性

使用性

＋

図 1.2.4-3 相関カタログ
1.2.5 SEC の活動
システム要求記述については、Planguage 等を参考に「キーワード」による記述項目の洗い出している。詳細化・関係分析については、 NFR フレームワークの「カタログ」の利用を参考にカタログの検討を行っている。狙いとしては、システムテストで判明する非機能要求の検証を早め、レビューなどで使えるようにすることや、開発工程の途中での目標変更などによる修正で非機能要求も検討・判断の要素としてきちんと加えられるようにすることを考えている。
要求
シナリオ

ソリューション要素
E1

E2

信頼性

効率性

コスト

S1

U

U

＋

＋/－

－－

＋

－

S2

品質

U

要求シナリオ（タグ埋め込み）
アーキテクチャ設計
アーキテクチャ
パターン

アーキテクチャ
評価
品質/手段ツリー（個別開発）
効率性

信頼性
品質/手段ツリー（カタログ）

－

＋

＋

E1

－

コスト
－

E2

図 1.2.5-1 非機能要求記述の利用イメージ
1.2.6 非機能要求に関する考察
講演者の吉田氏は、NTT データという大手 SI 企業として、システムの初期構築から運用、セキュ
リティといった広範なマネジメントをしていく必要があることもあって、かなり真剣にビジネスをにらんで取組んでいるという印象である。SEC の活動の方は、現状では、いくつかのケーススタディ検討や記述方法についてまとまるところまではきているようである。
ITIL や COBIT 等の運用やガバナンス系の話と、標準化含めて総合的に世の中の知見をまとめていくということと、ATAM 等の評価手法についても、ソフトウェア価値評価の観点からもうまく整合性- 16 -

がとれるように進むとよいと考えている。ISO/IEC 9126(JIS X 0129)の品質体系もそろそろ古くなってきているし、このあたりについても国際的な視点でも再編成が進んでいくものと予想される。
planguage から NFR フレームワークという木構造でカタログを示す方法の説明があったが、これはアーキテクチャやこれをとりまく非機能要求を分析・設計する方法論としては原理的な限界があるように思える。無論、出来上がった設計結果を人に説明するためには有効である。このあたりは、具体的ドメインからの構成的方法(constructive approach)でなくてはならない。また、運用系の実務からのアプローチがほとんどなされていないのも課題のように思える。
非機能要求を対象とした分析方法論が熱望されているため、研究アプローチとして「原理」の究明が必須に思える。本質的な困難もあり難しいとは思うが、分析方法論を提示し、それを世に問うことによって進歩していくのではないだろうか。また、いわゆるエンタプライズ系の大規模システムの場
合には、システム開発やアーキテクチャ設計の現場でもさまざまなステークホールダが存在するために、このあたりの役割分担やモジュール化の視点もあると、より実践的な方法論になるであろう。また運用系からのアプローチとして、オートノミックや進化の考え方も取り入れると、新しい時代へ向けての方法論として発展させていけそうに思える。

- 17 -