前回の記事の続きです。

今回は具体的な要求抽出の説明に入ります。

要求抽出

まずは相手の要求を抽出していく必要があります。
要求を抽出する際に、必要な観点として、以下が挙げられます。

• システムの限界を定義する

• 組織や環境、期限、予算といった制約を考慮する

• システムの機能を定義する

「要求を引き出す」と言った時に勘違いしがちなのが「全部の情報を引き出すことが大切」と思ってしまう事です。「必要な」要求は当然引き出す必要はありますが、目的は「全ての」要求を引き出しても意味がありません。
例えばスマホアプリを作ろうとしているのに、「明日は晴れがいいんだよね」という要求を引き出したところで意味はないでしょう。
ここまで極端ですと誰でもわかるかと思いますが、要求を引き出すときに、「引き出すべき要求」と「不要な要求」が混在していることがあることが多いです。後者はノイズになります。

「引き出すべき要求」と「不要な要求」の境目は「システムの限界を定義する」ことで決まります。何ができるのか、何ができないのか、その範囲を超えての要求をいくら集めても意味がありません。ここでしっかりと双方で誤解が無いように、定義しておくとよいでしょう。

システムで実現可能な場合であっても、すべての機能が実現できるとは限りません。必ず制限があります。例えば予算。100万円で作れることと1000万円で作れる事、1億で作れる事は異なります。いつまでに作らなければならないのか、と言ったことも制約として大きく影響します。
「予算はいくらでもいいから理想のアプリを作りたい」という方がいる場合「では予算を100億円用意してください。」というと当然「いや、それはちょっと…」となるでしょう。
「まぁ大体常識的な金額で」と言った場合も「アプリは10万円位で作れる」と思っている人と「アプリは1000万円位は必要」と思っている人では後で大きな問題につながりかねません。こういった制約については初めの時点で考慮しておく必要があります。

そうして、システムとして、どういった機能を作っていくかの定義をしていきます。

そこまで違和感はないかと思います。どれも「まぁそうだよね」という内容でしょうか。しかし、この「まぁそうだよね」と思う内容であっても、なかなかうまくいかないのが実情です。
この時に次の内容が要求定義の阻害要因になりえます。

要求を抽出する際の阻害要因

• 問題の範囲の定義

• 双方の理解度の問題

• 時代は変化するという事実

それぞれ簡単に説明します。

• 問題の範囲の定義
  先ほど「明日は晴れがいいんだよね」という要求は、アプリ開発を行う目的としては抽出しても仕方がない問題として挙げました。これくらいはっきりとしていればよいのですが、現実はそうシンプルではありません。どこまでができて、どこからは違うのか。「それはアプリではできないんですよね」と繰り返され続けたら「じゃあ何ならできるのさ！」と言いたくなってしまうか、委縮して言いたいことも言えなくなってしまう、そんなこともありそうです。

• 双方の理解度の問題
  上の問題にもかかわってくるのですが、お互いの得意領域が異なる場合が多いです。お互いアプリ開発者であればある程度共通のプロトコルがあるので話はスムーズに進みますが、多くはそうではないでしょう。
  また、一方が当たり前としていることもそうではない場合が多いです。「毎日「てっぺん」にアラームが鳴るようにしておいてよ」と言われても、「てっぺん…？」となってしまいます(深夜0時（24時）のを指す業界用語とのこと)。

• 時代は変化するという事実
  これもとても厄介な問題です。昨今時代の移り変わりが早いのは言うまでもないでしょう。ビジネスや技術は刻刻と変化していきます。今から10年ほど前に設計した「映画を視聴できるアプリ」であれば「レンタル」という形式が常識でしたが、いま「サブスク」という形式が無いのはありえない気もしますよね。

そう難しいといっても、要求自体を定義していかないことにはシステム化をしていくことができません。
要求を定義していくにあたり、要求の分類を把握していくと、定義する際に役にたつかもしれません。

• 組織活動の目的を達成するための要求・ビジネスプロセス
  戦略とか大きな範囲での要求です。抽象的になることが多く、何かに落とし込むことが難しい傾向にあります。また例えばシステム化と言った具体的な手段で定義できるものでもない場合が多いです。この要求を定義していく場合は都度確認し、修正していく必要があるかも知れません。

• 機能要求
  上に書いた要求をシステムで実行する際の要求になります。具体的な内容に落とし込んで、どう実行するかというところまで明確にする必要がある内容になります。

• 制約要求
  要求というと「やりたいこと」だけに目を向けがちですが、何かを行うときには必ず制約があります。性能だったり、予算だったり、アプリケーションを開発する場合セキュリティレベルのようなものも挙げられます。また、必須条件と言った、必ず満たさなければならないというモノもこの制限要求の一部となります。

要求抽出方法

要求を抽出するための手法は様々あります。ここで簡単に整理したいと思います。

• 直接聞く
  インタビューやアンケートといった形式で、要求を持っている人から拾い上げるという方法です。ただなんでもよいから聞きたいわけではありません。沢山アンケートは集計で来たけど、先に挙げた「不要な要求」ばかり集まってしまっても意味がありません。
  この時に「誰に」「どういった項目を」「どのように聞くか」で聞き出せる要求が変わってきてしまうので注意が必要です。

• 要求を想像する
  ペルソナシナリオ法などでユーザーを想定し、ブレインストーミングやマインドマップなどで要求をイメージしていく手法です。当然ユーザー想定が恣意的になりすぎてもいけませんし、要求のイメージも参加者の想像の域を出ない事もあります。一生懸命ユーザーを想定して要求を考えたが、そもそも現実世界にはそんなユーザーが居なかったといったといったことも起こりがちなので様々な人にレビューしてもらいながら進める必要があるでしょう。

• 観察する
  実際にユーザーを観察して、「こういったところに困っていそうだな」と現場の情報から要求を抽出するのも有効です。何か既にあるものに対しての改善要求を抽出するときには特に有効でしょう。アプリを実際に触ってもらい、使いづらそうにしている個所を確認する、と言った事が可能です。ただその反面、この観察からは潜在的な要求は抽出できないことがおおいです。また、まだ観察対象が存在しない場合、そもそも観察できないという事もあります。

このような手法を用い要求を抽出し、その要求が必要な要求なのか・不要な要求なのか、要求の程度に齟齬がないかと言ったことを双方すり合わせながら要求を抽出していく必要があります。

参考：
・要求工学知識体系(REBOK)概説
　https://www.ipa.go.jp/files/000005375.pdf
・要求開発の基礎知識　要求プロセスと技法入門
　https://nextpublishing.jp/book/10544.html