ここ数年、都内のある大学院の前期課程で「要求工学」の講義を実施している。今年も4月からこの講義を始めた。今年から学生のクラス参加を目的として、質問することを合否の判断基準に加えることにしたところ、いろいろな質問を受けることになった。
今回はこれまでに受けた質問と、それに対する回答例を紹介する。
質問 システムが要求を満たしているか否かということは、どうやって確認するのでしょうか?
回答 システム仕様を文書化することによって顧客の要求をシステム仕様が満足することを確認します。このため要求もまた文書化することになります。
質問 実際に顧客から要求を引き出す際には、何か工学的な手法を用いているのでしょうか?
回答 要求抽出には、システム化対象の世界の理解段階とシステム要求の獲得段階があります。各段階で次に示すような手法を活用することができます[1]。
・対象世界の理解異なるステークホルダが持つ価値観を理解するためにCATWOE分析が利用できます。C:システムの顧客、A:システムの運用主体、T:システムが実施する変換、W:世界観、O:システムの所有者、E:システムの外部環境のことです[2]。また構造化分析で用いられるコンテクスト図やUMLで用いられるユースケース図、状態遷移図、クラス図を利用することもできます。
マインドマップも階層的な事柄の依存関係を表現できるので、対象世界の理解に有効だと考えられています。
・システム要求獲得シナリオ分析やビジネスユースケース分析により、システムと外部との相互作用を明らかにすることができます。また実際にシステムをプロトタイピングすることで、システム要求を具体的な動作を見た上で獲得することもできます。
質問 システムにおけるブレークスルーはどこで生まれるのでしょうか?
回答 新しいビジネスモデルを考案し、それをITによって実現することでシステムのブレークスルーが生まれると考えています。たとえば、前回の連載で紹介したサービス指向要求工学では、アクタ間の隙間を見つけ、そこからアクタの分解と再結合によって隙間のないサービスをすりあわせることができます。ですから、初めに隙間を認識するところから新たなブレークスルーが生まれるのではないでしょうか?
質問 自分から発想を生み出し、それが世の中に受け入れられるには、何が必要になりますか?
回答 まず、現実を見ることで、そこにある課題としての隙間を埋めることが必要だということについて周囲のコンセンサスを得ることが大切です。また発想が世の中に受け入れられるためには、社会的な受容性を高める必要があります。このためには試行錯誤が必要になると思います。第43回のイノベーションと要求工学の連載で解説したように、市場に対して謙虚に意見を聞きながらシステムを洗練していくことが大切です。
また、システムを使ってもらうために何が必要になるかという点については、次に示したようにシステムが使われない原因を考えると分かり易いと思います。
【原因1】認知性の欠如
【対策1】広報活動を展開してシステムを広く知ってもらう
【原因2】理解性の欠如
【対策2】説明会などでシステムを分かり易く紹介する
【原因3】操作性の欠如
【対策3】ユニバーサルデザインガイドラインを参考に改善する
【原因4】受容性の欠如
【対策4】システムの合目的性と活用性をユーザーを巻き込んで確認する
【原因5】評価の不足
【対策5】試行運用による課題抽出と解決
質問 システム開発で仮説のマネジメントがなぜ必要になるのでしょうか?
回答 たとえば、上述した5つの要件を考えることは必要条件ですが、仮説の部分がどうしても残りますから、仮説が外れることを認めたうえで、仮説をマネジメントする必要があります。たとえば図1に示すように、ポラニーはあらゆる人工物には境界条件があると指摘しています[3]。この理由は、自然法則や人間行動を完全に我々が理解することはできないからです。図1に示すように人工システムは目的を持ち、それを実現する機能と構造を持つわけですが、機能と構造は自然や人間に対する理解の範囲でしか定義できません。もし理解の範囲を越えた自然現象や人間行動が発生した場合には、機能や構造を見直すことになります。
またレーマンは、システムには3つの種類があると述べています[4]。
◆問題とその答えが数学的に厳密できるシステムたとえば方程式の解を求めるようなシステムです。
◆問題を厳密に定義できるが、答えを厳密に定義できないシステムたとえば将棋や囲碁のようなゲームではルールを厳密に定義することはできますが、ゲーム途中の進行状態が多様すぎて現在でもまだゲームの答えを見つけることはできていません。
◆問題も答えも厳密に定義できないシステムたとえば予測問題を含むような需要予測システムなどは問題を厳密に定義できません。したがって、ある仮定の下でシステムを開発することがどうしても必要になります。
質問 なぜ世の中に存在しないシステムを考案することができるのでしょうか?
回答 技術的な可能性を素早く認識することが必要になります。新しい技術を使って社会や産業をどのように変革できるか、なぜ変革すべきなのかという問を持つことが大切だと思います。しかし、同時に考案したシステムが社会的に受容されるためには、上述したように社会とシステムの相互作用が必要です。市場に受け入れられないシステムはマーケティングに問題があったことになるのではないでしょうか?技術サイドからシステムを提案するだけでは不十分です。顧客にどんな価値を提供できるのかを問う必要があります。
質問 完全に倫理を順守している人工システムはあるのでしょうか?
回答 システムが倫理感を持つのではなく、システムを開発する人間が倫理感を持つ必要があります[5]。たとえば、図2に示したような職業人倫理が必要になります。倫理観のない人によって開発されたシステムが他人に甚大な被害を及ぼすことが、セキュリティ問題やプライバシー問題を見ればよく分かります。
技術的に可能だからといって、何をしてもよいということにはならないことを肝に銘じる必要があります。
質問 Web上での参加型アプローチについて、企業ではどのように取り扱っていますか?
回答 日本でも消費者がWeb上の投票で、製品開発に直接参加できる例があります[6]。このテーマは欧米でも注目され始めていて、国際会議が始まっています[7]。この理由は、社会的ソフトウェア(social software)や社会的生産(social production)をビジネスプロセスやビジネスモデルを進化させる手段であると考えることができるからです。これによって次のような効果を期待できます。
- 顧客とともに製品を開発するために、ブログで製品や特性のアイデアを獲得する。
- 顧客と企業の新しいコミュニケーションパターンに適応したビジネスプロセスになる。
- 特定の顧客や顧客コミュニティとの双方向にコミュニケーションが変化する。
- ビジネスプロセスを知識や情報の流通を改善して意志決定を加速することで、社会的ソフトウェアがビジネスのしくみを提供できる。
質問 システム開発が納期に間に合わないのはなぜでしょうか?
回答 システム開発が納期に間に合わない一番の原因は要求変更にあると思います。要求がたとえ、定義され正しく実現されていても望ましい要求でなければ意味がありませんから、変更されることになります。また要求が定義されていても、テストによって確認するまでその正しさは確認できません。このためシステム開発の最終段階になって要求変更が発生することも多いのです。したがって、要求変更によってシステム開発が納期に間に合わなくなることが多いのです。
質問 システム開発では、開発工程とコストの関係はどうなっているのでしょうか?
回答 システム開発ではおおまかにいうと要件定義、設計、製造という上流工程と試験工程がほぼ同じコストになると言われています[8]。しかし上流で埋め込まれた欠陥の9割が下流工程で検出されていることを見ると、上流工程で下流に持ち越される欠陥を検出することができれば、下流工程のコストを低減できる可能性があります。このことも、要求工学が重要になってきた理由の一つだと考えています。
質問 モジュール化が進んでいると、ソフトの変更が比較的簡単になるのではないでしょうか?
回答 そのとおりですね。たとえば、モジュールAがモジュールBをインタフェースIで利用しているとします。このときAとのインタフェースIを変更しない限り、Bの内容をどのように変更してもAには影響がありません。
この考えを、システムとその利用環境に当てはめてみるとどうなるでしょうか?Aを利用環境、Bをシステムだと考えます。要求仕様がインタフェースIになりますね。したがって、インタフェースを変えない限りシステムをどのように変更しても良いのです。ところが、インタフェースとしての要求仕様が明確に定義できていないとどうなるでしょうか?システムの変更が利用環境に大きな影響を与えてしまうことは明らかですね。
質問 変更する必要のないシステムを作ることができますか?
回答 もし要求仕様を変更する必要がなければ、上述したことからも分かるようにできますね。この場合、要求仕様が正しくかつ望ましいことを確認するための作業が必要になります。システム仕様を正確に定義できればテスト工数を削減できるとは思いますが、システムが要求を正しく実装できているかを確認するためのコストを正確に見積もることは、開発対象やプロジェクト構成に依存しているのでまだ技術的に易しくはありません。
また実際には、システムが利用するOSやミドルウェアなどの外部システムやビジネス環境が変化するので、一度開発したシステムが変更されることも多いのです。
質問 モジュール化に関する共通のレベルや基準がありますか?
回答 よく知られた基準としてモジュールの結合度(Coupling)と凝集度(Cohesion)があります[9]。モジュール内にはできるだけ強く関係する要素だけを集め、モジュール間ではできるだけ関係を弱くするという考え方です。この考え方では、モジュール内部の情報を操作によって隠蔽する情報隠蔽はデータ結合であり、パラメータの値を変更してもモジュール内部の制御論理を変えないという意味で最も弱い結合度である、つまり最も良いモジュール化になっていると言えます。
質問 システムはどういった年齢層をターゲットにして作られているのでしょうか?
回答 システムの利用者をどのように想定するかというのはいい質問です。たとえば、ある機能に対して想定利用者によるシステムの利用シナリオを定義します。この利用シナリオに対して操作性や理解容易性などをゴールとして定義します。次に、それらのゴールを達成したかどうかの判断基準となる測定項目と、達成条件としての基準値を定量的な指標で定義します。このような手法によって想定する年齢層の利用者が、システムの機能を受容できるかどうかを評価できると思います。一般の消費者向けのシステム開発では、あらゆる年齢層を対象にする場合もあれば、特定の範囲に限定する場合もあると思いますから、それぞれの場合に応じて上述したような手法によって予めシステムの受容性を評価しておくことが求められます。
質問 よりわかりやすいインタフェースやシステムを作るための方法論などはありますか?
回答 まず、システムの分かり易さを定義する必要がありますね。分かり易さを構成する非機能要求を列挙できれば、それを測定する定量的な基準とその基準値を定義することで上述したように分かり易さを評価できます。この手法はGQM(Goal-Question-Metric)と呼ばれています。
質問 わざと手続きを煩雑にするシステムというのも存在するのでしょうか?
回答 たとえばセキュリティを考慮すると、システムの利用手続きが複雑化して操作性が低下します。通常はパスワードを要求される程度ですが、それでもあらゆるシステムのパスワードを記憶することが、先生のような年齢になってくると難しいものです。おかげで、いくつものシステムをパスワードを忘れたために使えなくなってしまって困っています。このように操作性とセキュリティというように互いに競合する要求もあります。
質問 要求の派生的な影響の解釈は分析者に依存するのでしょうか?
回答 まず派生的な要求とは何かを定義する必要がありますね。たとえば次の2つが考えられます。
- 構造的派生要求:要求Aのある構造を特定することから派生する要求B
- 操作的派生要求:要求Aを達成するための操作要求X
こうしてみると、いずれもある要求を具体化するときに新たな要求が派生すると考えられます。このような要求の具体化は分析者に依存すると思います。そこで、ゴール指向の考え方を用いて派生要求の具体化関係を明確にすることで、客観的に評価できるようにすることができます。
たとえば、「分かり易く使い易い」というゴールを「視認性」と「操作性」に分解できます。また「タッチパネル」には表示面と操作面という構造があるので、それぞれについて素材や操作についての要求を具体化することで派生要求間の関係を分析できます。
質問 ソフトウェア開発手法によって、抽出すべき要求や抽出方法が変化するのでしょうか?
回答 はいそのとおりです。
ゴール指向では、なぜソフトウェアを開発するのかというWHYに着目して要求を抽出します。これに対して、どんなソフトウェアを開発するのかというWHATに着目して要求を抽出する手法としてデータ指向手法、オブジェクト指向手法などがあります。さらに、HOWに着目してソフトウェアがどのように振舞うのかを明らかにする手法として状態モデル、制御フローモデル、シナリオモデルなどがあります。
もちろん、これらの手法を組み合わせることで要求をより完全に抽出することができます。いずれにしても要求抽出の完了基準を予め定義しておく必要があります。そうでないと抽出した要求が十分であり、漏れがないことを確認することができません。
質問 様々な概念モデリング手法がありますが、一つの手法に絞るのでしょうか?それともすべての手法を使うのでしょうか?あるいは必要に応じて選択するのでしょうか?
もし選択するのだとすれば、どのようにして選択するのでしょうか?
回答 一つの手法が他の手法に比べて、より優れているという実証的な証拠はほとんどないといわれています[10]。したがって、どの概念モデリングを使うか、あるいは複数の概念モデリングを組み合わせるかについては、開発対象システムやプロジェクトごとに選択する必要があります。この場合、手法ごとにどのような概念とその関係を表現できるかを整理しておき、開発対象システムのモデルで必要となる概念とその関係と比較することになります。さらに、プロジェクトメンバーが使いこなすことができる手法であることが必要条件になります。また、発注元から使用すべき手法を指定される場合もあります。逆に発注元の理解が得られない手法を使っているときには、概念モデルを発注元に分かり易く提示するためのコミュニケーション手段を考える必要がでてきます。
まとめ
今回はこれまでに学生から寄せられた質問の一部を紹介した。お分かりいただけたと思うが、いろんな質問が集まっているところを見ると、学生の反応は例年よりもいいようである。
学生が疑問や好奇心を持つこと、それを文字にすることで考えること、それによってできるという自信をもつこと、この考えるプロセスを一緒に考えているところである。
細かな要求工学の技法を教えることよりも、大切なことがあるのではないだろうか?
■参考文献
- [1]中谷多哉子、要求獲得技術、情報処理、vol.49, No.4, 2008, pp.357-363
- [2] 連載第20回 ソフトシステム方法論再考(その1)
- [3] ポラニー、暗黙知の次元,1966
- [4] M.M. Lehman and L.A. Belady, Program Evolution -Process of Software Change, Academic Press, 1985
- [5] Berebbach, B and Broy, M., Professional and Ethical Dilemmas in Software Engineering, IEEE Computer, Jan.,2009
- [6]無印良品計画の「ものづくりコミュニティ」,http://www.muji.net/community/
- [7]The Second Workshop on Business Process Management and Social Software
http://crinfo.univ-paris1.fr/users/nurcan/BPMS2_2009/ - [8]山本修一郎他、誰も語らなかったIT~9つの秘密~、ダイヤモンド社、2004
- [9]国友義久、効果的プログラム開発技法、近代科学社、1983
- [10]山本修一郎 「~要求を可視化するための~要求定義・要求仕様書の作り方」
4.2.6概念モデリングの留意点(1)概念モデリングの選択、P86
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要