学習の内容と経緯

経緯

開発したいソフトウェアに対して、より多くの仮説検証を繰り返したい。しかし、各開発フェーズごとにどのような仮説を立てて検証してよいかがわからない。 例えば、プロダクトオーナーに対してソフトウェアの仮説を検証してもらう場合はステークホルダーの期待値、開発者に対してソフトウェアの仮説を検証してもらう場合はソフトウェアの設計書などプロセスごとに検証する仮説が異なってくる（前述で上げた例はあくまで適当な想像）。 そしてこれらの仮説検証を行わずに開発するとどうなるかというと、自分たちが想像していた「素晴らしいソフトウェア」が作れずにプロダクトがうまくいかずに終わってしまう可能性がある。
この課題を解決するために、ソフトウェアの仮説検証を行うための開発プロセスにおけるフレームワークを自分の中で定義する。もちろんすべてのケースに当てはまるフレームワークを作ることはできないが、自分の中で型を定義することによって、それを派生、応用できるようにしていくことが出来るとは思っている。

目標

• ソフトウェア開発プロセスにおける型を知り、自分の中で定義すること(抽象度は高くて良い)

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

「要求」という言葉の定義

この本は「ソフトウェア要求」というタイトルがついている通り、「要求」について解釈をして置かなければいけないと思った。 「要求」という言葉の定義について、書籍の中ではいろいろな解釈があることについて述べられていた。 その中の一つとしてSommerville and Sawyer 1997を引用して下記のように記載されていた。

「要求とは、何を実装しなければならないかという仕様である。また、システムがどう振る舞わなければならないかという記述であり、システム特性や属性の記述でもある。システムの開発プロセスに対する制約条件のこともある。」(1)

ただ、「要求」については様々な解釈があり、ある一定の理解に収束させることが難しそうだった。このことから、「要求」における一般的な解釈を考えるよりも、自分の中で一旦「要求」について定義し、チームの中で「要求」という言葉の定義を共有できていることを目指すのが良いのではと考えた。
そして、今自分が「要求」という言葉の意味を定義づけるとしたら、「ユーザーの期待値を満たすための仕様や活動」かなと思った（1 年後の自分は全く違うことを言っているかもしれないが、、、）。

システム開発で出てくる「要求」の種類

下記の引用について、一旦自分の中でプロセスを整理したいと考えた。自分が普段行っている活動はどの要求のアウトプットであるか、書籍を読み進めてみてから整理したい。また、各要求に対して何らかのアウトプットがあるはずで、その典型的なパターンはなにかそのプロセスを検証するためにどういった手法を行うのが良いかを考えていきたい。

ソフトウェア要求には、ビジネス要求、ユーザー要求、機能要求という 3 つの異なるレベルがある。これに加えて、あらゆるシステムには、各種の非機能要求がある。(2)

1 章まで読み進めた中で必ず抑えておきたいと感じた要求に対するアウトプットは下記のとおりである。書籍を読み進めながら、下記のアウトプットをどう作成してどう検証するかを考えてみたいと感じた。

• ビジネス要求：「ビジョン／スコープ記述書」
• ユーザー要求：「ユーザー要求文書」
• 機能要求：「ソフトウェア要求仕様書」

「要求」をコントロールするための考え方

要求を満たすために、妥当性をを検証する「要求開発」と、要求を満たすことのできる確率を上げるための「要求管理」という活動があると自分は理解した。 この分類をどう活用していくかはあまりしっくり来ていないが、おそらく応用したり切り出して移譲しやすくなるのかなと考えた。

Next Action

• 「要求」という言葉の定義を自分の中で持ち続けられるようにする。

参考文献

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