Wikipediaで有名になったWikiは、もともとは米国のWard Cunninghamがインターネット上でソフトウェア設計のデザインパターンの収集と共有を目的にして1995年に開発した技術だ[1][2][3][4]。Cunningham がWikiで公開しているPatternsListには、毎日10前後のページが追加され続け、10年後の2005年には30690ページに達したそうだ。
今回は、このWikiを取り上げて要求工学やソフトウェア開発との関係を考える。
Wiki
Wikiは、インターネットでみんなが協働して簡単にWebのページを作成して編集できることを目的にして開発されている。この目的に合わせて、表1に示したようなWikiの設計方針が設定されている[5]。Wikiではコンテンツをカード形式にしてカードの名前、内容、関連リンクで構成する。Wikiのこの着想はアップル社が1987年に販売を開始したHyperCardから得たとCunningham が書いている[1]。
方針 | 説明 |
---|---|
開放性 |
不十分であったり貧弱なページを発見でき,誰でも簡単に編集して修正できる |
漸増性 |
まだ書かれていないページも含めて他のページを引用できる |
組織性 |
文書の構造と内容を編集して更新できる |
日常性 |
ページマークアップのための少数の有用な規約を提供する |
普遍性 |
編集と構成のための仕組みをページ作成と統一することでページ作成者が編集と構成もできる |
顕在性 |
書式付出力では再出力すべき入力を識別する |
統一性 |
余分な解釈を必要としないように理解し易いページ名を付ける |
正確性 |
名前の衝突が起きないようにして名詞句のページ名をつける |
寛容性 |
エラーメッセージを出するよりも振る舞いを予測することを優先する |
観測性 |
サイト内の行動を監視して他の訪問者がレビュできる |
収束性 |
類似したり関連する内容を発見・引用することによって内容の重複を予防・削除する |
カード形式にしたことで、Webページの構成と内容を誰でも編集できるようになった。また名前の中に英語の大文字が2つ以上あると、カードの名前だと自動的に認識してリンク関係を生成する。もしその名前のカードがないときは、新たに対応するカードを生成してくれる。日本語のWikiの場合には大文字と小文字の区別がないので[[カード名]]のようにしてカードを指定している。
さらにWikiでは、HTMLを知らなくてもWikiのページを作成編集できるように括弧などを用いて簡単な編集規則を提供している。たとえば文字を強調するときは、‘‘‘要求工学’’’(‘‘‘Requirements Engineering’’’)のようにして、要求工学(Requirements Engineering)を表示できる。
このようにWikiには簡単に誰でも参加できて情報共有できるという特徴があり、最近では企業内の知識共有でもWikiの価値が認められてきており、「企業内Wiki」が企業内SNSと並んで注目されるようになった。
ソフトウェア開発におけるWikiの利用
良いドキュメンテーションがソフトウェア開発プロジェクトに役立つことは明らかだが、ドキュメントを作成して保守することは容易ではない。そこで、Wikiをソフトウェア開発のドキュメンテーションに活用するという着想が出てきた。ソフトウェアの再利用のためのデザインパターンを公開することがWikiの当初の目的だったことから見ても、筋のよい着想だ。
ソフトウェア開発のドキュメントには、要件定義書、設計書、テスト仕様書、ユーザーマニュアル、進捗報告、問題管理票、バグ票、変更管理票などがある。ソフトウェア開発の過程で発生する、これらの生産物についての誤りを検出し記録し訂正することでプロジェクトを成功に導くことができる。
協調型コミュニケーションツールであるWikiには簡単な言語規約、強力なリンク機構、誰でも編集できる適応型Webページという特徴がある。Wikiの機能的特長がソフトウェア開発のドキュメンテーションでどのように活用できるかを表2に示した。
Wikiの機能 | 特徴 | ドキュメンテーション |
---|---|---|
ページ |
断片的な文書作成が容易 | 必要な部分や関係者ごとに文書を作成できる 未定義ページによる課題管理が出来る |
ページリンク |
内容の重複を予防 | 関連ページをまとめて文書化できる 文書作成の管理尺度を定義できる |
ページ履歴 |
変更履歴の管理が容易 | 意見収集 頻繁な変更や更新のないページを点検することで文書品質を向上できる |
ページ検索 |
内容の検査や修正が容易 |
仕様書記述要領 文書テンプレート レビュ規約 ノウハウ集 |
タグ |
内容の不一致を強調 | 矛盾点を明示できる |
2005年から始まっているWikiの国際シンポジウムWikisymでも、ソフトウェア設計ドキュメントの草稿や設計検討だけでなく要求獲得についてもWikiが提供する協調型コミュニケーションが有益だと認められている[6]。また{code}タグで囲むことでコードの断片をWikiの文章に埋め込む方法やEclipse Wikiなどの開発環境なども提案されている[7]。
ところで、我々も実は約20年前にハイパーテキストに着目してカード型のソフトウェア開発環境SoftDAを研究開発していた[8]。SoftDAの目的はソフトウェア開発に関する要求、設計、コード、試験を含む全情報を互いに関係付けて管理して活用することによってソフトウェアの開発や再利用の効率向上だった。したがって、Wikiを用いることで同様のことが実現できる可能性が高いことはよく理解できる。
HyperCardにはマルチメディアコンテンツの開発環境としてのHyperTalkがあるように、WikiTalkというオブジェクト指向言語も既にある。またWikiは教材作成にも適しているので、ソフトウェア工学の教育にも使えそうである。
ソフトウェア開発へのWikiの適用事例
以下では、ソフトウェア開発におけるWikiの利用例を紹介しよう。
◆SOP-Wiki[9]
これまでも要求獲得では発注者、運用者、利用者、開発者などソフトウェア開発に係る多様な関係者から要求を抽出するために様々な手法が研究されている。Fraunhofer財団の実証的ソフトウェア工学研究機関(Fraunhofer Institute for Exper- imental Software Engineering)が開発したSOP-Wiki(Software Organization Platform)では、表3に示したようなWikiによる要求文書の構成方法を提案している。
種類 | 要求工学 | |
---|---|---|
ホームページ |
プロジェクト |
要求の入口ページ ミッション、要求概要へのリンク,参加者への周知情報 |
関係者 |
参加者情報 プロジェクト内での役割 関係者ページへのリンクによって要求に対する責任者 であることを定義 |
|
概要ページ |
要求文書のリスト 完成要求、未完成要求 矛盾要求、誤解事項などを示し議論の起点を与える |
|
要求ページ |
ユーザ物語 |
システムの相互作用についてユーザ関係者が要求を簡潔に仕様化する |
アクタ |
ユーザ物語とユースケースに出てくる役割をアクタとして定義する | |
ユースケース |
ユーザ物語を要求として明確に定義する アクタによるアクションの系列をユースケースで記述する |
・ホームページ
プロジェクトホームページは要求の入口ページである。ミッション、要求概要へのリンク、参加者への周知情報などを記述する。
・関係者ホームページ
要求獲得に参加する参加者の情報を記述する。また、プロジェクト内での役割や関係者ページへのリンクによって、要求に対する責任者であることを定義する。
・概要ページ
要求文書のリストを記述することにより、関係者ページと要求ページとの関係を定義する。また完成要求と未完成要求を識別したり、矛盾要求や誤解事項などを示すことで議論の出発点を示すことができる。
・要求ページ
要求ページには、ユーザー物語、アクタ、ユースケースという3種類のページがある。
ユーザー物語ページではシステムの相互作用についてユーザー関係者が要求を簡潔に仕様化する。
アクタページではユーザー物語とユースケースに出てくる役割をアクタとして定義する。
ユースケースページではユーザー物語を要求として明確に定義する。またアクタによるアクションの系列をユースケースで記述する。
◆WikiWinWin system[10]
南カリフォルニア大学のBoehmらが開発したEasyWinWinシステムの後継版がWikiWinWinシステムである。EasyWinWinは顧客と開発者という異なる関係者が持つ要求に対する価値観の矛盾を交渉によって解決することを支援するシステムであり、約150のプロジェクトへの適用実績がある。しかし、操作の習熟の点で課題があったため、Wikiを用いて要求に関するEasyWinWinの合意形成モデルを定義している。これにより、関係者間で要求の合意条件についてブレインストーミングができるので協調作業型要求交渉プロセスを実現している。
◆Galaxy Wiki[11]
Wikiは、ドキュメンテーションで用いられてきたがプログラミングにはまだあまり使われていなかった。XioらはWikiによるプログラミング方式「writing wiki page is wring source code」を提案している。Galaxy Wikiではプログラムを書くだけでなくコンパイル、実行、デバッグもできるオンライン協調参加型ソフトウェア開発環境の試作版だ。
Wikiとイノベーション
Wikiの起源は、Apple社のBill Atkinsonが開発したHyperCardである。1987年にMacintoshにHyperCardがバンドルされて成功した。
ところで、HyperCardの起源は、VannevarBush が1940年代に着想したハイパーテキストにまで遡る。ハイパーテキストといえば、Webもそうである。HTMLは、Hyper Text Mark up Languageのことである。
WikiWikiHyperCardのページ[12]には次のような言葉が記されている。
「ほとんどの新しい着想は、実のところ、互いをつなぐ洞察を必要としていた過去の着想の集まりである」
この言葉を見て、Einsteinが発見した世界でも最も短い有名な式 e=mc2のことを思い出した。エネルギーeも質量mも光の速度cも既知の概念だったのであり、Einsteinの洞察がそれらをつないだのである。前回も述べたがイノベーションとはそういうものである。
Wikiによる協調作業の成功要因
Wikiの成功要因 | 説明 |
---|---|
理解 |
社会的側面:コンテンツの執筆責任の分散協調管理のしくみの確立により信頼が向上する 技術的側面:Wikiの習得 |
信頼 |
技術への信頼:操作することで判断できる コンテンツへの信頼:内容で判断できる コミュニティへの信頼:社会的側面での信頼関係の醸成には時間が必要 |
価値 |
Wiki導入の目的が参加者の満足に繋がることが必要 既存技術の連携による価値向上も必要 |
企業内Wikiは、企業内SNSと同じように情報共有の場として期待されているが、必ずしも活性化していないという声を良く聞くことがある。
Wikiを使ったブレインストーミングの研究[13]では、共通の目的を持つことが確立され継続すると、参加者の関心を高めることができ、Wikiがただの情報共有空間ではなくなるWikiサイクルが成立するといわれている。この考えを整理すると、図1に示すように場と参加者の間に次のような循環構造があることに気づくだろう。
図1 場と参加者の循環構造
◆目的-満足-貢献
- 貢献するためには適切な目的が必要
- 満足するためには貢献することが必要
- 目的を達成するためには相応しい満足感が必要
逆に言えば、場に適切な目的が設定されなければ、満足も貢献もない場になるのである。
◆信頼-満足-貢献
- 貢献するためには信頼感が必要
- 信頼感を醸成するためには参加者の満足感が必要
- 目的を達成するためには信頼感が必要
逆に言えば、場を信頼できなければ、満足も貢献もない場になるのである。
したがって、適切な目的の定義が場への参加者の信頼感を醸成し、場に参加することによる満足と貢献を促進することで、目的が達成するという大きな好循環へとつながるのである。もし、このような好循環を実現できれば、Wikiが満足という参加者の価値交換の場になるだけでなく、目的に向けた具体的な成果への貢献が持続すると思われる。
まとめ
今回はWikiを事例として要求工学やソフトウェア開発への適用例を紹介した。この記事を書きながら、ソフトウェアの関係者や利用環境とソフトウェア開発がWikiによって一体化されて、継続的にかつ多面的に進化していく可能性が出てきていることを再認識した。
今後、Wikiを用いた要求工学手法が活発に研究開発されることを期待したい。
■参考文献
- [1] http://c2.com/cgi/wiki?WikiHistory
- [2] Ward Cunningham, http://c2.com/cgi/wiki?WardCunningham
- [3] http://c2.com/cgi/wiki?InvitationToThePatternsList
- [4] http://c2.com/cgi/wiki?WikiWikiWeb
- [5] http://c2.com/cgi/wiki?WikiDesignPrinciples
- [6] Workshop2WikiExamples, http://www.wikisym.org/ws2005/wiki/space/
Workshop2WikiExamples - [7] Workshop2WikiExamples, http://www.wikisym.org/ws2005/wiki/space/
Workshop2WikiExamples - [8] 磯田 定宏, 山本 修一郎, 下村隆夫, 黒木 宏明 : 設計情報とコードの一体管理方式に基づくソフトウェア開発支援システムSoftDA, NTT R&D, Vol.38, No.11, pp.1239-1248, 1989.
- [9] B. Decker, E. Ras, J. Rech, P. Jaubert, and M. Rieth, "Wiki-Based Stakeholder Participation in Requirements Engineering", IEEE Software, Vol. 24, No. 2, March/April 2007, pp. 28-35
- [10] Da Yang1,3, Di Wu2, Supannika Koolmanojwong2, A. Winsor Brown2, Barry W. Boehm2, WikiWinWin: A Wiki Based System for Collaborative Requirements Negotiation, Proceedings of the 41st Hawaii International Conference on System Sciences-2008,sunset.usc.edu/csse/TECHRPTS/2008/
usc-csse-2008-805/usc-csse-2008-805.pdf - [11] WenPeng Xiao他, On-line Collaborative Software Development via Wiki, www.wikisym.org/ws2007/
- [12] http://c2.com/cgi/wiki?WikiWikiHyperCard
- [13] Jonathan Davies, Wiki Brainstorming and Problems with Wiki Based Collaboration, http://www-users.cs.york.ac.uk/~kimble/teaching/students/
Jonathan_Davies/Jonathan_Davies.html - [14] P. Louridas, “Using Wikis in Software Development”, IEEE Software, vol. 23, no. 2, 2006, pp. 88-91
- 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:保証ケース作成支援ツールの概要