SQuBOKと要求

SquBokアドベントカレンダー


※本稿をアップするにあたりブログソフトを作りました。ただ、作ったあとに気づいたのですが、基盤として使用しているPaaSは、無料で利用する場合の制約として1日6時間は停止するということなので、たまに停止しているかもしれません。
それだとたまに読めなくなってしまうので、このブログにも貼っておくことにします。だとしたらブログソフトなど要なかったわけですが、、せっかくなので、こちらからもご覧ください。

寒い日が続いていますが、いかがお過ごしでしょうか。私は、春夏のあたりは鎌倉やら、
二宮（湘南です）やらに出かけたりしていたのですが、ここ最近は家で本を読んだりパソコンをしたりとすっかりインドアになってしまいました。寒いと出かけたくなくなるものですね。

さて、SQuBOK V2読破会 Advent Carenderということで、SQuBOKについて書いてみたいと思います。これまでの方はSQuBOKそのものについて書かれているようですが、私はSQuBOKの内容そのもの、SQuBOKでは「3.5 要求分析の技法」の章であつかっている「要求」をテーマにします。

ソフトウェアの開発プロジェクトの失敗では、よく「要求がもれていた」「要求が曖昧だった」と言った原因が挙げられますが、どうすればこのようなことは避けられるのか、SQuBOKやKarl Wiegers、Joy Beatty著の「ソフトウェア要求」などを読みながら書いてみたいと思います。

要求をもれなく分析するために要求の「発生源」を確認する

SQuBOKでは、「3.5.1 要求抽出」の項目のすぐあとに「3.5.1.1 ステークホルダー識別」
の項目があります。これは私の経験になりますが、開発プロジェクトをやっていていちばん危険な状況は、「新しいステークホルダーが増えたとき」です。新しいといっても新たに加わったのではなく、それまで認識していなかった潜在的なステークホルダーが明らかになった、ということです。ステークホルダーは要求の「発生源」です。ですので、ステークホルダーが増えると、通常、要求も飛躍的に増えます。そしてその要求の中にはもともとの要求との衝突や矛盾が生じることもあります。こうしたことはソフトウェアの根幹に大きく影響を与えます。
このように危険が大きいこともありSQuBOKでもステークホルダー識別として大きく取り扱っています。なお、「ソフトウェア要求」では、ステークホルダーのサブセットであるユーザーをさらにユーザークラスとして詳細に識別しています。ソフトウェアを直接使用するユーザーは、要求にとってもっとも影響力を持ちます。このため、ステークホルダーという単位からさらに具体化して分析しているのです。

また、要求はソフトウェアを取り巻く環境のうち、「外界」にいけばいくほど強く、
変更が効きません。例えば、ソフトウェア利用者にとっての取引先が「請求書はこの形に
してほしい」といった要求を持っている場合、この要求は強く影響し、調整が効きません。
取引先はソフトウェア利用者にとってはお得意様にあたるため、自社の都合で変えるわけにはいかないのです。（ただし、何らかの利益がその取引先にもたらされるのなら調整の余地はあります）。さらに外側に目を向けると、政府が法改正をしたので帳票の集計方法をを変えなければならい、と言った場合があります。この場合は要求というよりは「制約条件」になります。調整したければ政治家を送り込む方法があるのでしょうが、１つのソフトウェアの都合で法律を変えることはできません（サマータイム導入ぐらいのレベルになると業界団体が動くかもしれません）。さらにさらに外界に目を向けてみます。太陽系の位置関係が変わって、全世界の気温が変化し、それがソフトウェアの仕様に影響するとしたらどうでしょうか。これはもう絶対に調整は効きません。ということなので、要求は「外から」しっかり押さえておく必要があります。

要求は多様な引き出し手法で引き出し、多様なモデルリング手法で表現する

要求をもれなく抽出するためには、ただユーザーの要求を聞いて資料に書いていくだけで
はうまくいきません。

これは自分自身でも実感できることです。例えば、私は先日、冷蔵庫を買ったのですが、事前に考えていたことは、「容量が大きくてたっぷり入り、部屋を圧迫しない程度の大きさ」といったものでした。しかし、実際に売り場に行ってみると要求はどんどん増えていきました。

・冷凍庫は長い期間保管するので、保管していることを忘れがち。
   だから奥のほうまで確認できるように、最下段にある引き出しに入れたい
・野菜はたいてい使い切れないし、重たいので、高い場所におきたくない。
  だから野菜室は真ん中より下にほしい
・扉の部分は、牛乳や麦茶を隣同士において選べるようにしたい。
  さらに500mlのビール缶をちょうど入れやすいぐらいの高さがほしい
・デザインはフラットなのがいい

といったことです。こうしたことを、会議の場で、資料を眺めながら出せと言われても至難の技です。
そこで、ただ要求を聞くのではなく、要求の引き出し技法を用います。たとえば、インタビューやアンケート、仕事中のユーザーの観察、ユーザー同士が話し合うワークショップ、各種文書の分析などです。

これらでの手法で引き出すことのできる要求は、少しずつ領域が異なります。インタビューでは、ユーザーが最初から持っている明らかな要求や、ビジネスの状況から論理的に導き出した要求を獲得できます。仕事中のユーザーの観察からは、ユーザーが無意識のうちにしている動作や、現場でないとわからないことなどを引き出せます。さらに観察中にユーザーに話しかけるか話しかけないかによっても引き出せる要求は違ってきます。話しかける場合はやっていることの理由などを明確に確認できるし、話しかけない場合はユーザーの自然な動きや考え方に気づきやすくなります。

このように引き出した要求は、ただ文書で羅列するだけでなく、多様なモデリング手法を用いて表現します。というのは、ソフトウェアは多岐にわたる複雑な空間を取り扱うので、これらを文書だで表現してもうまく把握できないのです。たとえば、業務フロー、ユーザーの操作シナリオ、外部システムとの連係といった「動的な関係」もあれば、ユーザーの組織の関係、取り扱うエンティティの関係、ソフトウェアの動作環境や構成といった「静的な関係」、さらに、ソフトウェアが確定処理中などで操作を受け付けない場合や、障害中である場合などの「状態」などです。

モデリングの手法としては、ソフトウェアとその他のすべてのものとの境界と関連を表現する「コンテキスト図」や、このソフトウェアが情報のやり取りをするすべてのソフトウェアを表現したエコシステムマップ、プロダクトのフィーチャーを表現したフィーチャーツリー、システムの振る舞いのトリガーとなるイベントリストなどがあります。SQuBOKでは、「3.2 モデル化の技法」として、要求仕様に限らずソフトウェア品質全体に関る技術として紹介されています。

要求の定義はどこまでやれば良いのか

要求の定義をしていると、どこまでやれば良いのかわからなくなることがあります。そのうちに、いつまでも検討が終わらなかったり、詳細な設計レベルまで作りたくなったりということがあります。

テクニックとしては、「要求の品質」を定義し、検証するというものがあります。完全性、正確性、曖昧さ、実現性、検証可能性などについて具体的な基準値を定め、実際の要求を検証します。

もう１つのテクニックは、モデル間の整合性を確認するというものです。例えば、業務フローに現れたエンティティがエンティティ定義に記載されいるか、といった確認です。こうした確認からエンティティの抜けが見つかった場合、それでは抜けていたエンティティはどの画面から入れるのか？エンティティのライフサイクルを考えた時、エンティティはいつ消滅するのか？というように派生的に不整合が見つかり、それらを解消していくことで、要求定義が洗練されていきます。

実際に詳細な設計まで進めてしまう、もしくは作ってしまうというのも手です。SWEBOK V3.0においても要求は「一発で終わるようなプロセスではない」としています。

「ソフトウェア要求」では、「リスクが受け入れ可能なレベルになったら終わり」と表現しています。そう言われればそうだけど、そのリスクが受けれ可能なレベルというのがわからないから苦労しているのだ、とも思ってしまいます。おそらくここで言いたいのは、あらかじめ教科書的に設定できるような答えはなく、どのようなアプローチをとるのか態度を定め、関係者と合意をとるのが最善だということなのだと思います。

例えば、複雑かつ厳密な計算ロジックのようなものがある場合は、事前に全てを明確にしてから作り込みに入らなければ完成しないでしょうし、逆に、ユーザーが軽妙に操作できるようなGUIを作るよう場合は、早めに作って見せてしまった方が良いと思います。また、これらの方法が１つのソフトウェアの開発中に混在する場合もありえます。

またプロジェクトに求められる要求（プロジェクト要求）によっても違います。納期、予算、スコープは死守だがプロジェクト期間は長いのか、逆に、スコープの調整はある程度弾力性があるが、かわりに早めに市場投入したいのか、といったことでも違います。

どのやり方を取るにせよ、たいていは開発中に要求の変更は避けられません。
そのため、要求定義を確定する段階では、「現時点でこの要求が我々の最大限の理解である」ということを全員が納得し、また、「将来変更が生じた場合は適切な変更プロセスを踏む」ことをお互いに約束することが重要になります。このような信頼関係を醸成しないと、要求を確定したくても確定できない、ということが生じてしまうのです。

おわりに

ということで、要求について書いてみました。SQuBOKは、要求に限らず様々な技術につながっています。品質というものは、そのように全方位的な性質を持っているのだと思います。そういった枠組みを最初に押さえてから、各分野の本を読むことで、ずいぶん理解が進むことがあったように思います。

さて、次は昨日に戻ってkazucocoaさんです！

参考文献

・ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版) (SQuBOK)
・ソフトウェア要求 第3版　Karl Wiegers、Joy Beatty
・ソフトウェアエンジニアリング基礎知識体系 ―SWEBOK V3.0