山修の開発文書品質入門（6） ―― 開発文書と対話
山本 修一郎
| この連載コラム「山修の開発文書品質入門」では，開発文書に携わる皆さんに役立ちそうな開発文書の品質につながる知識を分かりやすく解説します． バック・ナンバ |
ソフトウェア開発における知識の流通形態として，文書化と対話を考えることができる．文書化を徹底すれば対話量を削減できる．逆に，文書量を削減すれば，必要な知識を獲得するために，多くの対話が必要になる．
アジャイル型開発では，文書化量は削減する代わりに，濃密な対話によって開発に必要な知識を補完することになる．
たとえば，アジャイル型開発では，「①プロセスとツール，②理解しやすい文書，③契約交渉，④計画順守」よりも，「⑤個人と対話，⑥動くソフトウェア，⑦顧客連携，⑧変化対応を優先すること」に価値をおいている[1]．これによって，ソフトウェア開発のさまざまな無駄を省くことを目的としている．無駄な文書やコードを作らないことと，逐次的にソフトウェアをリリースして開発期間を短縮することなどの特徴がアジャイル型開発にはある．
これに対して，ウォータフォール型開発では，工程を明確に定めて工程生産物としての開発文書を作成する．曖昧さや抜け漏れのない開発文書を作成することにより，手戻りのない開発を目的としている．
以上の議論から，文書化量を横軸，対話量を縦軸として，アジャイル型とウォータフォール型の開発をプロットすると，図1のようになる．
図1 文書化と対話からみたアジャイル型とウォータフォール型の開発
アジャイル型開発を進めるためには，対話能力が開発者に要求される．しかし，現場の開発者は十分な対話能力を持っていないことも多い．そこで考えられるのが，対話能力不足を文書で補うことである．実際，ある研究会で筆者がこの図を紹介した際に，アジャイル開発の現場でウォータフォール型の手法が見直されているという話を聞いた．図1でいえば，曲線の中間に位置づけられるような開発手法が現場で求められているということであろう．
そのような中間的な手法として，エレン・ゴッテスディーナーとメアリー・ゴーマンによる発見から納品へ（Discovery to Delivery, D2D）がある．
D2Dでは，文書に基づいて対話を構造化する「構造化会話(Structured Conversation)」を提案している．D2D型開発を図1に付加すると，図2のようになる
図2 文書化と対話からみたD2D型の開発
D2Dでは，対話を構造化できるように適応した文書を提案している．すなわち，表1に示すように，D2Dでは，開発プロダクトの７側面に対して，対話で活用すべき文書を提示している．
| 側面（dimension） | 説明 | 文書 |
| ユーザ(user) | プロダクトと相互作用する主体 | ロールマップ，ペルソナ |
| インタフェース(interface) | ユーザ，システム，デバイスとプロダクトとの接続関係 | コンテクスト図 |
| アクション(action) | プロダクトがユーザに対して提供する能力 | ビジネスプロセス図，シナリオ(Given-When-Then)，機能マップ，依存性グラフ，バリューストリームマップ，ストーリーマップ，能力マップ，フィーチャ，ユースケース |
| データ(data) | プロダクトが操作するデータと有用な情報 | 状態図，データモデル，データ辞書，用語集 |
| 制御(control) | プロダクトが満たすべき制約 | 決定表，決定木 |
| 環境(environment) | プロダクトが適応する物理的特性と技術基盤 | 場所，物理条件，構成，使用形態，技術基盤比較表 |
| 品質特性(quality attribute) | プロダクトが持つ運用と開発の基準を示す特性 | プランゲージ(Planguage)，品質特性シナリオ |
ここで，プランゲージ(Planguage)[3]は品質特性を可視化するためにGilbが提案したテンプレート形式の表記法である．Baasらが提案した品質特性シナリオ[4]は，①発生源，②刺激，③環境，④シナリオ，⑤システム，⑥成果物，⑦応答，⑧評価基準を記述することによって，品質特性を明らかにできる．
参考文献
[1] アジャイルソフトウェア開発宣言, http://agilemanifesto.org/iso/ja/manifesto.html
[2] Ellen Gottesdiener, Mary Gorman, Discover To Deliver: agile product planning and analysis, EBG Consulting, Inc., 2012.
(エレン・ゴッテスディーナー，メアリー・ゴーマン，発見から納品へ- アジャイルなプロダクトの計画策定と分析，株式会社オージス総研訳，ブックウェイ，2014.)
[3] Gilb, Thomas, Competitive Engineering: A Handbool for Systems Engineering, Requirements Engineering and Software Engineering Using Planguage, Butterworth-Heinemann, 2005.
[4] Baas, Len, Paul Clements, and Rick Kazman, Software Architecture in Practice, second edition, Addison-Wesley, 2003.
（前田他訳，実践ソフトウェアアーキテクチャ, 日刊工業新聞社，2005.)
