学習の内容と経緯

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

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

ユーザークラスの定義

プロダクトに対してすべてのユーザーが同じ期待値を持っているわけではない。例えば、管理者がユーザーの監査ログを見たいといった期待値がある一方で、一般ユーザーにはその期待値はないケースがあると思う。 こういった期待値の違うユーザーに対して不要な機能を提供しないようにするために、事前にユーザークラスを定義しておくことが大事だと感じた。
そして、そのユーザークラスを定義するために実際の業務フローを体験または観察することが大事だと思う。業務フローの知識がつくことによって、価値を提供したいユーザークラスや価値を提供する必要のないまたは想定していないユーザークラスに対して対処ができると思う。
ここで注意するのは、純粋なユーザークラスのみではなく間接的なユーザークラスを捉え逃さないようにする必要がある。例えば子供向けのシステムでは、親向けの見守りシステムが必要だったりするケースがあるだろう。

要求開発の核心は要求の引き出し

要求の引き出しは単純に要求を集めるだけとは異なる。おそらくステークホルダーから出た要求が必ずしも本質ではないということだろう。ステークホルダー自身も自身の要求を正確に言語化できるとは限らないと思う。
こうした理由から下記のように記載されているのは理解できた。

要求開発の核心は、要求の引き出し、つまりソフトウェアシステムに対するさまざまなステークホルダーのニーズと制約条件を識別するプロセスである。

要求に向き合うためには、効果的なユーザーヒアリングや業務フローの観察のプロセスを経て収集した情報をもとに、ビジネス要求、ユーザー要求、機能要求の視点で段階的に分類することが大事だと感じた。個人的な意見としては、ビジネス要求とユーザー要求が最上位にあり、その期待値を満たすための機能要求が存在するといったようなイメージを持った。

コンテキスト図による外部エンティティの発見

作成するソフトウェアに何らかの要求を提示してくる外部エンティティを発見するためには、コンテキスト図が有効だと感じた。ここでいう外部エンティティには、ステークホルダーや外部サービスが存在する。
外部エンティティを発見することでどんな良いことがあるかというと、下記が挙げられると考えている。

• ユーザークラスごとに、要求に対して適切な機能を提供できる(逆に特定にユーザークラスに提供してはいけない機能を判断できる)
• 外部サービスとの連携が必要な場合、その外部サービスの要求(例えば制限事項など)の対策ができる

外部エンティティを事前に発見しておいてソフトウェアのアーキテクチャに反映させることで、容易に変更可能（要求への迅速な対応ができる）なシステムを作成できると感じた。

ユースケース図とプロセスフロー図によるユーザー要求の引き出し

ユーザー要求を効果的に引き出すためには、ユースケース図やプロセスフロー図が有効だと感じた。
ユースケース図では、ユーザーがどのような操作を行うか発見することができる。システムに対してユーザーができることを洗い出し、機能要求の発見につなげることができる。
プロセスフロー図では、ユーザーの業務プロセスに対してシステムがどのように関わるかを発見することができる。ユーザーの行動からシステムがユーザーの期待値に沿えているかを分析することができる。
ビジョンスコープ記述書、コンテキスト図の順番でステークホルダーを発見し、ステークホルダーとの関係性をユースケース図やプロセスフロー図を通して考察することで、要求が満たせないシステムが出来上がってしまうリスクを軽減できると感じた。
また、これらの図を実際にステークホルダーに確認してもらってブラッシュアップを重ねていくなど、ユーザーヒアリングのプロセスでも活用できると感じた。

Next Action

• コンテキスト図を作成してみる
• プロセスフロー図を作成してみる
• ユースケース図を作成してみる

参考文献

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