ソフトウェアが社会に浸透するようになると大企業だけではなく、中小企業でもソフトウェア要求を検討する必要が出てくる。欧州でも大企業と異なり、中小企業では要求定義工程を十分に確立しているとは言えないようある。
今回は、ドイツにおける中小企業の現場で実施された要求工学プロセスの改善手法を紹介する。
中小企業の要求プロセス改善
中小企業における要求プロセスの課題は、
- (1)最先端のソフトウェア開発技術に詳しい経験者がいない
- (2)いたとしても改善活動のための時間や経費がない
ことである。
中小企業で受け入れられる要求定義プロセス改善活動では、中小企業の個別要望を考慮する必要がある。一方で、中小企業は規模が小さいから、ビジネスドメインやビジネス環境については熟知していると思われる。ただし、これらを暗黙知として熟知はしていても、形式知としてドキュメントが整理されているとは言えないだろう。
もし、これらの暗黙知をすべて形式知化しようとすると時間と経費がかかりすぎて現実的な要求定義プロセスを構築することは難しい。ではどうするか?
中小企業の従業員がプロセス改善についての意志決定を自らできるように、従業員を巻き込んだ改善プロセスを構築したのである。
これによってやむを得ず従業員を組み込んだことで、通常は新しい開発施策の導入に対して疑り深い従業員たちも、プロセス改善のための議論に積極的に参画するようになり、多くの改善案が受け入れられることになった。
中小企業における要求プロセス改善の留意点
中小企業は多様であるから、中小企業の置かれた環境について一般的な仮定をおくことはできない。要求工学を熟知した専門家が一人でもいれば、むしろ企業規模が小さい方が要求プロセスの成熟度を高めることができるだろう。しかし、このような専門家を擁することはまれであろう。また、要求工学の知識を習得する十分な時間を確保することも難しいかもしれない。したがって、少しずつ必要な要求工学知識を段階的に実際のプロジェクトの中で獲得していくことが現実的であると思われる。
Dorrらは数多くの中小企業と協働活動した結果に基づいて、中小企業におけるプロセス改善施策を適用する上で次の5点が重要だと述べている(表1)。
留意点 | 説明 | 理由 | |
---|---|---|---|
1 |
容易性と経済性 |
迅速活経済的に改善策を実施できること 識別した施策を1回の手順で短期間に導入できること |
改善策を複数回に分けて実施すると効果や課題を特定できない また経費が大きくなる |
2 |
理解性と予測性 |
改善の背景にある課題と根拠を関係者が容易に理解できること | 不適切な改善をしてしまうと大きなリスクになる 効果が予測可能な施策に限定する必要がある |
3 |
柔軟性 |
組織の環境、文化、要求プロセスに適応できる柔軟性が改善策にあること | 組織に適応できない改善策を導入することは出来ない |
4 |
参画性 |
改善策の選定と実施に適切な関係者が参画できること | 関係者の知識を活用する必要がある |
5 |
具体性 |
改善活動に必要となる具体的な情報を提供すること | 不十分な知識では改善策の実施で問題が発生する |
◆容易性と経済性
迅速かつ経済的に改善策を実施できること。
識別した施策を1回の手順で短期間に導入できること。
【理由】改善策を複数回に分けて実施すると効果や課題を特定できないだけでなく経費も大きくなる。
◆理解性と予測性
改善の背景にある課題と根拠を関係者が容易に理解できること。
【理由】不適切な改善をしてしまうと大きなリスクになる。
◆柔軟性
組織の環境、文化、要求プロセスに適応できる柔軟性が改善策にあること。
【理由】組織に適応できない改善策を導入することはできない。
◆参画性
改善策の選定と実施に適切な関係者が参画できること。
【理由】関係者の知識を活用する必要がある。
◆具体性
改善活動に必要となる具体的な情報を提供すること。
【理由】不十分な知識では改善策の実施で問題が発生する。
協調型自己査定改善手法
以下ではDorrらによる協調型自己査定改善手法(Cooperative Self-Assessment and Improvement)の概要を紹介しよう。まず要求改善施策の36類型を示し、次に3つのワークショップからなる手順を述べる。
要求プロセス改善施策の類型
協調型自己査定改善手法では、要求プロセスを改善するための施策を5つの適用プロセスと4つの施策レベルという2つの側面から分類する(表2)。要求プロセスについては、要求管理、要求抽出、要求分析、要求仕様化、要求検証に分類する。また施策レベルについては、基本施策、発展施策、最適化施策、状況依存施策に分類する。
たとえば、要求管理についてみていくと、次のようになる。
- 基本施策には要求変更管理がある。
- 発展施策には優先順位と合意形成、経費と期間の見積り、役割と責任の定義、リスク評価がある。
- 最適化施策にはプロセス改善、製品計画、技術選択がある。
- 状況依存施策には要求再利用と変動性管理がある。
これらの改善施策の具体的な内容は論文には記述されていないので不明であるが、要求工学の教科書などから抽出したとしているので、これらの改善差施策を具体化することはできるだろう。ただし、発展施策として挙げられている施策が確立しているというわけではなさそうである。たとえば、要求に対して必要となる経費や期間を正確に見積もるのは簡単ではない。またリスク評価についてもまだ十分に解明されているとはいえない面がある。
要求管理プロセス自体を改善することが最適化施策として挙げられているのは、要求管理が要求プロセスの中心だと考えているためであろう。
状況依存施策として要求再利用と変動性管理が示されている。この理由は企業の状況に応じて要求が再利用できるかどうかや、要求がどの程度変化するかが異なるためであろう。
また、要求レビュのように基本施策となっている項目についても、本連載でも取り上げているように、属人性を排除して要求レビュを実施し、要求の正しさをきちんと確認するのは意外に難しいことである。おそらくここで要求レビュを基本施策としているのは、標準的な要求レビュの仕方を提示してそれを実践することを求めているのだと思われる。
要求分析プロセスには基本施策がなく、発展施策として実現性評価や各種のモデル化が位置づけられている点も興味深い。中小企業では、これらのモデル化施策を導入することはまだ敷居が高いという判断なのだろう。
また、形式手法が状況依存のところで上がっている理由を考えてみる。たとえばICカードや組込みソフトウェア開発では、信頼性を保証するためにどんなに小さな企業であっても形式的な検証が必要になることがあるだろう。したがって、企業が置かれた状況によっては形式手法を活用することが当然考えられる。ただし、形式手法の具体的な適用方法については様々なやり方があるので注意が必要である。最近、公開された「高信頼ソフトウェア構築技術に関する動向調査」(http://sec.ipa.go.jp/reports/20080606.html)に形式手法の適用事例が紹介されているので参考になるだろう。
いずれにしても、この類型が重要な点は、改善施策を詳細化して、容易に適用できる部分に分解していることである。改善施策がこのように細分化されていればいるほど、効果は限定的にはなるけれども、その代わり改善施策の適用コストを小さくできるだけでなく、効果を測定し易くなるということである。大きな改善を計画すればするほど、計画策定の時間が必要になり、実施コストも大きくなり、適用した後でどの改善項目がどのように影響したかを判断することも困難になる。さらに、計画を策定している間に外部環境が変化して解決対象課題が変化してしまっている可能性もあり、改善計画自体の効力が失われるというリスクもあるかもしれない。
プロセス改善サイクル
要求プロセス改善手順を表3に示す。
手順 | 概要 | ワーク ショップ |
|
---|---|---|---|
1 | 分析と検討 | 現状を把握し問題点を抽出することで改善施策の適用可能性を検討する 改善専門家がモデレータになり、ドメイン専門家の知識と実現している改善試作についての意見を共有する。基礎、発展、最適化の順に改善施策を検討する |
1 |
2 | 結果の文書化と改善施策の識別 | 改善専門家が評価結果を文書化する 適用可能な改善施策の候補を用意する |
|
3 | 改善施策の選択 | 手順1,2の結果に基づいて議論し現状プロセスの改善点の抽出と解決策を考案する すべての関係者が参加してどの改善施策を導入するか発言 1~4個の改善施策を抽出する |
2 |
4 | 改善施策導入 | ドメイン専門家と導入者がどの候補を最初に導入するかを判断する |
|
5 | 評価基準策定 | 改善専門家が改善施策の有効性の評価基準を策定する |
|
6 | データ収集 | 関係者が改善施策を適用する過程で有効性を評価するためのデータを収集する |
改善実施 |
7 | 評価実施と反復 | 約半年後に第3回なワークショップを開催 関係者が改善施策の有効性について議論し、次の改善サイクルを開始する |
3 |
◆ワークショップ1
最初のワークショップでは分析、文書化という2段階でドメイン専門家と改善専門家が協力して要求プロセスの課題を抽出し適用すべき改善策を選択する。
【分析】現状を把握し問題点を抽出することで改善施策の適用可能性を検討する。
【文書化】まず改善専門家が評価結果を文書化する。次いで適用可能な改善施策の候補を用意する。
◆ワークショップ2
第2回目のワークショップでは、前回の結果に基づいて、選択、順序付け、評価基準策定という3段階で改善策の導入を準備する。
【選択】ワークショップ1の結果に基づいて議論し、現行プロセスの課題を抽出し改善施策を選択する。すべての関係者が参加してどの改善施策を導入するか議論する。この過程で1個から最大4個までの改善施策を抽出する。
【順序付け】ドメイン専門家と導入者がどの候補を最初に導入するかについて決定する。
【評価基準策定】改善専門家が改善策の有効性の評価基準を策定する。
ワークショップ2が完了した後で、選択された改善施策を実施する。関係者が改善施策を適用する過程で有効性を評価するためのデータを収集する。
◆ワークショップ3
改善施策を実施して約半年後に第3回のワークショップを開催する。ワークショップ3では関係者が改善策の有効性について議論し、次の改善サイクルを開始する。
プロセス改善手法の比較
図1 工程改善手法の比較
従来のプロセス改善手法(a)とDorrらの手法(b)を比較すると図1に示すようになる。
この図のポイントは、ドメイン専門家に予め、どのような改善施策があるかを分類してメニュとして提示し、その中からドメイン専門家自身が望ましいと思う改善施策を選択できるようにしたことである。このためドメイン専門家の参画意識が高まり、満足度も向上するのである。
これに対して従来は改善専門家がドメイン専門家からドメインの特徴を聞き出して改善専門家の視点で改善施策をドメイン専門家に提示していたので、必ずしもドメイン専門家の満足を得にくかったということである。
このような協働参加型によるプロセス改善の考え方は、要求プロセス改善だけでなく、他の新技術の導入にも適用できそうである。
適用経験
顧客向けソフトウェア開発企業6社の実プロジェクトに適用したところ、良好な結果が得られたという。企業規模は20名から200名だ。金融や自動車など事業分野も異なる。プロセス成熟度や開発プロセスの柔軟性にも差があったということである。
Dorrらは、5つの留意点についての教訓を次のようにまとめている。
◆容易性と経済性
プロセス改善を識別して実施するための迅速で経済的なアセスメントが必要である。限定的な努力と資金で繰り返し実施できる改善策を見つけることが重要である。大規模な改善を実施しようとすると、どのような結果になるか予測できないからである。
◆理解性と予測性
問題とその改善策の根拠を関係者がだれでも理解できるようにしておく。中小企業は不適切な変更に対するリスクが大きいので、改善効果を可能な限り予測できるようにする必要がある。
◆柔軟性
改善策は、組織の置かれた環境や方針に対して容易に受け入れ可能な推奨策を提供することで、改善策の現場に合わせた変更を抑えることができる。
◆参画性
適切な関係者がすべて参画できないといけない。改善に対して関係者を動機付けて関係者のドメイン知識を活用できるようにする。関係者が参画することで動機付けられる。
類型化された改善施策が提示されることで、有益な意見交換を導くことができる。
◆具体性
改善策は具体的でないといけない。改善施策についての限定的な知識しかない組織では、具体的な情報がないために実行段階で問題が発生する。したがって、要求工学手法に関する外部からの適切な支援が必要になる。
まとめ
今回はドイツのFraunhofer研究所で開発された、中小企業における要求プロセス改善手法を紹介した。この手法の良い点はプロセス改善を一気にまとめてやろうとするのではなく、短期間で実施できるピンポイント的な改善施策を何回も段階的に繰り返す点にある。
今後、既存の要求定義プロセスを改善するための要求工学手法が活発に研究開発されることを期待したい。
■参考文献
- 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:保証ケース作成支援ツールの概要