KAOS (28) 文書を用いた情報入手方法 (2.2.1~3)

この手法(背景調査)の明らかな強みは,後に必要となる基礎的な情報を得られることにある.用いている用語,考慮すべき目的・方針,利害関係者の責任分担状況などである (p. 64)

本節では,情報を入手する対象は文書である.必ずしも,既にあるものには限定されない.必要に応じて新たに取得するものも含んでいる.というより,ほとんどは新たに取得することになる.

様々な方法が提示されているが,一般的な三つの方法の紹介である.

背景調査(2.2.1)

  • 組織について,学習する

対象文書例:組織図,ビジネス計画・方針マニュアル・会計報告・重要な会議の議事録,職務分掌等

  • 問題領域について,学習する

対象文書例:書籍,調査報告,出版された記事

  • 現状システムについて学習する

対象文書例:情報の流れ,作業手順,ビジネスルール,部署間でやりとりするフォームなど

データ収集(2.2.2)

既存文書で不足する情報を集める.例えば,市場に関する情報,システム利用に関する統計情報,性能値,平均的な運用コストなどである.

質問票(2.2.3)

対象者を限定して,質問票に回答してもらう.質問票は,適切な設計が必要で,回答に負荷が掛からないようにする.また,バイアスが発生する可能性があり(回答したい人は回答するが,本当に知りたいと思う人は回答してくれないかもしれない),データの解釈にも注意が必要である.

のちにでてくる概念ラダリングが参考になる.

(nil)

KAOS (27) 利害関係者の識別とコミュニケーション (2.1)

要求工学のスパイラルモデルにおける最初フェーズを扱う.即ち,「問題領域の理解と要求を引き出す」という絡み合ったプロセスである.(p.61)

いよいよ(ようやく)2章である.ここからは,以前にみたスパイラルモデルの各象限毎に,章が与えられ,詳しい考察を行う.最初は,冒頭にある,「問題領域の理解と要求を引き出す」ことである.その中でも,今回は,誰もがそうするであろう,「人に聞く」である.

人といっても,多くの場合は,窓口として特定の担当者かもしれない.その人から,要求を単に聞き出せば済むのかもしれない.

ここでは,比較的大きなプロジェクトを想定する.要求分析も仕事と考えているベンダや,社内で要求をまとめる担当者を考える(そうしないと,話は半分くらい終わってしまう).

最初にすることは,利害関係者を見つけることである.利害関係者が,誰かというのは,重要である.

基本的には,システムに直接,関わる人々.例えば,新システムの開発責任を持つ人,検査する人.教育する人.ユーザ.現行システムがある場合は,そこから類推することも可能である.

将来システムでは,より広い範囲に影響を及ぼし,新たな利害関係者がいるかもしれない.現状から類推することは容易だが,新しいシステムが動いたときに,人々の振るまいがどう変化するかを想像することは難しい.

利害関係者を代表する人が誰かということも,大事である.

窓口として要求を伝える人が一人だとしても,どこまで彼の言葉に依存するかで,プロジェクトの成否が決まるかもしれない.例えば,彼は他の利害関係者の言葉を(意図的に?)間違って伝えるかもしれない,或いは,そもそも重要な利害関係者であるユーザの存在に気がついていないかもしれない.

窓口の人は,正しく要求を伝えてくれている,と思う人は幸せである.

どのような障害があるかについて,幾つか項目を挙げている.

  • 分散し衝突している知識源

大きなプロジェクトでは,多くの知識源としての利害関係者がいる.利害が衝突している可能性が高い.

  • 情報源への近づきにくさ

多くを知っている人は,忙しい人でもある.話を聞く機会は限られる.

  • 良いコミュニケーションの難しさ

異なった背景・用語や文化の違いがある.これらは,コミュニケーションを難しくする.

  • 暗黙知と隠された必要性

大事なことは,情報源にとって当たり前のことであり,それは語られないことが多い.

  • 社会政治学的要因

情報源は,情報を持つので,現状において力があるのかもしれない.だとすると,変化は望ましくないと考えるかもしれない.

  • 不安定な状態

世の中は,変化する.また,聞くべき人も変える必要があるかもしれない.

上記を踏まえての対応が必要がある.しかし,簡単ではない.

(nil) 

KAOS (26) 素早さと前提 (1.4)

要求工学プロセスにおけるよりよい素早さ(Agility)は,前述のソフトウェアプロジェクトにおける障害に対処できるかもしれない.(p.53)

この節は,いわゆるアジャイルプロセスの話である.アジャイルプロセスとは,早い段階で,かつ継続的に顧客に機能を示すことで,要求工学に関わる労力と,要求からコードまでの距離を減らすることを目的としている.これは以前のスパイラル図をより早く回転させることを意味する.

しかし,このアジャイルプロセスを可能とするには,下記に示す前提があるとしている(ちなみに,アジャイルプロセスといっても様々な方法があり,ここで筆者がイメージしているのは,XP(eXtream Programming)だと思う 1).

  • 全ての利害関係者の役割は(顧客やユーザの役割も含む),一つの役割に集約できる
  • プロジェクトは,十分に小さい.そこでは,小さなサイズで同じ場所にいるたった一つの開発チームを割り当てることができる
  • ユーザは,開発場所にいることが可能である.或いは,素早くかつ効果的に開発メンバーとコミュニケーションがとれる
  • プロジェクトは,十分に単純である.また,クリティカルなシステムを対象としない.そこでは,非機能的側面・環境における前提・重要な目的・代替策・リスクをムシできるか,重視しないで済む
  • ユーザーは,次の追加機能をどうするかを,素早く・一貫した内容として,示すことができる(従って,コンフリクト管理は不要である).かつ,重要なものから,そうでないものへと順序立てて示すことができる(従って,優先度付けは不要である).
  • プロジェクト管理では,作業の調整や製品の保守のための文書を必要としない.コーディング前の正確な要求仕様書など,問題ではない
  • コーディング前の妥当性確認は,早くリリースするためには,さほど重要ではない
  • 新しい,ないしは変化する要求は,コードのリファクタリング・書き換えを必要とせず,製品保守を担当するのは,開発した人間で良い.

もちろん,これは極端な場合であり,実際には通常の開発とアジャイルプロセスの間にはスペクトルがある.しかし,素早さを求めるのであれば,他のアプローチもあるというのが,Lamsweerdeさんの主張である.

  • ユーザにとっての価値としての機能的なゴールとシナリオを用いる
  • 必要な場面では,漸次的な精緻化と分析に対する規範的な形式化に注目する
  • 種々の経験的知識とパターンを用いて,モデルベースの要求工学におけるガイダンスを提供する
  • 事務作業を減らすことができる統合的なツールサポートを行う

これが,KAOSを通じて,Lamsweerdeさんが,提案する方法ということになる.

(nil)

Notes:

  1. この話題は,これまでもかなり議論されてきて,いわば宗教にまつわる問題のように相互理解が困難な問題でもある.クリスタル法(crystal methodolies,複数形であることに注目!)のCockburnさんの主張のように,全ての方法には規模や特性に応じたスペクトル上の適正な位置がある.どう選択するかの問題であるということに同意する.その上で,もちろんどう選択するかが重要であり,ここでの議論は,その選択の役に立つ