読書感想文：「ソフトウェア要求」まとめ

作成日：2024/09/29

学習の内容と経緯

読書感想文：「ソフトウェア要求」を読んでみて、自分が解釈した理解に対して備忘録としてまとめていきたい。おおもとの経緯は下記を参照。

実践し続けたいこと

この書籍から自身が解釈したことのうち、特に実践し続けたいと感じたことを以下に記載する。

ビジネス要求、ユーザー要求、機能要求の観点で要求開発を行う

まず、ユーザーの期待値を満たすための仕様や活動として「要求」という言葉があり、それぞれ①ビジネス側からの要求（ビジネス要求）、②ユーザー側からの要求（ユーザー要求）、③機能として実装するための要求（機能要求）に分類できると考えている。この3つの観点を意識することによって、ステークホルダーとの期待値のずれを防いでいくことができると感じた。

要求の優先順位は必須

開発活動の中で基本的に要求は常に変化するものだと考えている。そのため、すべての要求に完璧に答えられるわけではないと考える。要求の変化に対応するために、優先順位を合意しておいて常にその時の最善手をステークホルダー全員が選択できるようにあらかじめベースラインを揃えておくことが重要だと感じた。

スコープを定義し、スコープクリープを防ぐ（特にやらないことを決める）

あらかじめスコープを合意しておけば、特定のリリースに詰め込みすぎて開発が意図したとおりに進まずにずるずる行ってしまうことを防ぐことができる。ただ、活動をしているとやりたいことが増えてしまうことが多いので、特にやらないことを決めておくのが重要だと感じた。

ビジネス目標の成功判定メトリクスを定量的に定義する

難しいが、どうにか定量的な目標を定義するのは大事だと感じている。客観的な目標がないと活動が成功したかもわからずに無駄な努力をしてしまうかと思う。また、振り返りもやりづらく次の活動にも活かしづらいと思う。

モデリングの手段はツールとして覚えておきたい

機能要求の開発を行う際に、ビジネス要求とユーザー要求が満たせるかを検証するためにコミュニケーションを取ることがある。その際に、ステークホルダーが理解しやすいように図で表現することができると、理解不足による期待値が満たせない機会を減らすことができると感じた。個人的にはまず下記を意識して使いたい。

ユースケース図
プロセスフロー図
コンテキスト図
ユーザークラスの抽出

各要求でトレーサビリティを持つこと

チームが目的どおりに各要求間でトレーサビリティが必要だと感じた。ビジネス要求とユーザー要求を満たすための機能要求が定義されているか検証するためには、機能要求からビジネス要求、ユーザー要求へ辿れる必要がある。

参考文献

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