学習の内容と経緯

読書感想文：「ソフトウェア要求」2, 3 章の続き。

面白かったポイントと考察

ビジョン/スコープ記述書

ビジネス要求を１つの文書にまとめたものとして「ビジョン/スコープ記述書」というものが存在する。 この文書には、ビジネス要求の発生経緯、目標、責任者、スコープなどの情報が含まれており、これを唯一のベースラインとして全員が作業を進めていくことになる。
イテレーション型の開発プロセスにおいて、要求が進化する場合は別のビジョン/スコープ記述書を作成するのではなく既存のものを更新することになる。

ビジョン/スコープ記述書の責任者をはっきりさせておく

衝突しがちなビジネス要求とその他の要求との折衝を図るために誰に対して相談すれば良いかははっきりさせておき必要がありそうだと感じた。 基本的にビジネス要求の大元の情報をインプットした人がいるはずで、ビジョン/スコープ記述書を作成する前にその要求は誰から発生したものかを明確に記述しておくことで責任を持つ人にたどり着きやすくなるのではないかと考えた。

スコープをコントロールするためにスコープを定義する

プロジェクトに機能を詰め込み過ぎてスコープが拡大していことをスコープクリープと呼ぶ。 このスコープクリープをコントロールするためには、事前に「何をするか」「何をしないか」を明確にしておく必要がある。 あらかじめスコープを合意できていれば、スコープ外の要求が降りてきた場合に冷静に折衝することができ、狙ったソフトウェアが開発できると考えた。

プロジェクトのスコープを表現するためのモデル

スコープを表現するためのモデルとして、下記のようなものがある。

• コンテキスト図
• エコシステムマップ
• フィーチャーツリー
• イベントリスト

上記のモデルを使用することで明快かつ正確なコミュニケーションをステークホルダー間で行うことができる。

ビジネス目標は明確にする

まずビジネス目標がないと下記のリスクがある。

• 目的が達成できたかわからずに無駄な努力をしてしまう
• 目標がないビジネスには投資が集まりにくい

このリスクを取り払うためには、ビジョン/スコープ記述書にビジネス目標や成功判定のメトリクスを可能な限り定量的に定義するのが大事だと感じた。 もちろん、すべてのビジネス目標を定量的に定義することは難しいが、そこをどうにかするために時間をかけてでも定量化するのは無駄な努力ではないと思う。 ただ、定性的なメトリクスも必要だと感じていて、どのようにして成功判定のメトリクスを達成したかも考慮することで、プロダクトを成長させたいのに「従業員の給料を削減することでコストカットを達成した」のような本来の目的と異なった結果を達成してしまうことを防ぐことができると考えた。

Next Action

• ビジョン/スコープ記述書を作成してみる

参考文献

(1) カール ウィーガーズ；ジョイ ビーティ. ソフトウェア要求　第 3 版 (Japanese Edition), 日経 BP 社. Kindle Edition.