サマリ
想定読者：設計業務に興味がある方 / 想定時間：20分～25分程度
第14回目のテーマは、要件定義について取り上げます。
#1 要求をどのように満たすかの定義を実施
前回の記事で全体のプロセスをご紹介しています。要件定義の建付けは、要求フェーズからのインプット情報を元に、業務要件から機能・非機能要件を定義し、後段の基本設計に成果物としてアウトプットすることです。
本フェーズに入ると、まずはインプット情報が不足していないかをチェックします。例えば、ゴールや現状の課題、制約事項などプロジェクトの背景をヒアリングで吸い上げていくと共に、ラフでも構わないので動作に関するイメージ（このぐらいのサイズで、こういったボタン操作で、、、など）をヒアリングしていきます。
ある程度経験を積んでいる顧客からだと、要求仕様書や要件定義書などドキュメントの形で提示されることもあるため、しっかりと読み込んでヒアリングを重ねます。余談ですが、QCDのどこに比重を置いているかなど顧客の文化をこの時点で聞けていると、今後のトラブル防止に役立つのでお勧めです。
#2 機能/非機能の両観点から定義
ヒアリングやインプット情報の整理が終了したら、次に、このシステムをどのように使うか（使いたいのか）の業務要件を定めていきます。最終的には、このヒアリングを通じて得た内容を元に検証プロセスに入るため、最初の段階で詳細にヒアリングしたほうが効率的です。今回はシステム開発に着目しているので、システムを通じて業務（動作全体）がどのように変化するかを中心に、業務の流れをヒアリングしていきます。
例として、簡単に電卓の開発を想定してみましょう。元々の業務の流れ（AsIs）で、当月の支出金額をまとめる作業があったとします。以下がヒアリングで聞けた５ステップの作業です。
- 今月の支出金額合計を計算したいため、領収書を手元に準備する
- 必要な情報を元に、紙に計算したい数値を上から順に記載する
- 筆算で計算する
- 検算する
- その結果を元に社内の登録用紙に記載して回覧する
こちらを聞き出せていれば、電卓が関与する業務を②～④とし、領収書の金額や計算結果の自動連係などは対象外とするなど、開発対象のスコープの定義に役立たせます。
次に電卓という新たなシステムが寄与してどのように業務が変わるか（ToBe）を顧客と合意していきます。 上記の②～④が電卓により、
- 今月の支出金額合計を計算したいため、領収書を手元に準備する
- 必要な情報を元に電卓に一つ一つ数値を打ち込んでいく
- （自動で計算されるためこの業務はスキップ）
- 検算する（もう一度打ち込む）
- その結果を元に社内の登録用紙に記載して回覧する
となり、特に③の部分での時間短縮やヒューマンエラー防止に寄与するシステムと定義する感じになります。ここでの重要なポイントは②で、”電卓に一つ一つ数値を打ち込んでいく”という動作の合意が取れるかが鍵になります。顧客から、それはめんどくさいから一気にレシートを取り込んで自動計算してよ、と言われた際に受け入れてしまうと、今日私たちが使う電卓では達成できないですよね。すると、新たにスキャナの概念を盛り込んだ、かなり大掛かりな装置を開発する事になってしまうため、顧客と自身のお互いが不幸になりかねません。ですので、この段階でハンドリングを如何にできるかが非常に重要になってくるわけです。
さて、上記のように大体の業務要件定義が完了したら、次にシステムを対象（主語）として、要件定義を実施していきます。上記の例において、このシステムはどのような機能があると実現できそうでしょうか？ 既に私たちは電卓を知っているのでイメージがつくと思いますが、実務ではこれを一から検討していく作業になります。
例えば、右のような電卓があったとします。
・入力や計算結果を表示する機能
・数値を入力する機能
・計算途中の結果を記録する機能
・実際に演算する機能
の４つは最低限構成されているイメージですね。ここで、右の絵には顧客の業務の中で定義していない機能が一つ含まれています。
・充電機能 (太陽光パネルを経由)
こちらも本当に顧客が必要としているのか、付加価値に感じるかなどは顧客に確認していく必要があります（過剰な機能を搭載させては工数・機材の単価がかかるだけですので）
CASIOの電卓より引用
合わせて検討すべきことは非機能要件になります。そもそも非機能要件とは何かですが、上記の実現業務を満たす機能以外の機能となります。この文言だけではよくわからないと思いますので、電卓を元に具体的な例から先に示します。左側２列が非機能要求のフレームワークからの要素で、一番右が今回の非機能要件の定義例になります。
| 非機能要求（IPAベース） | 概略（IPAベース） | 電卓での例（非機能要件） |
|---|---|---|
| 可用性 | システムサービスを継続的に利用可能とするための要求 | 電池を入れたら１か月は持つなど |
| 性能・拡張性 | システムの性能、および将来のシステム拡張に関する要求 | 電源投入後１秒でロゴマークが出て、その１秒後に利用できることなど |
| 運用・保守性 | システムの運用と保守のサービスに関する要求 | サポートセンターに問い合わせればトラブル対応してくれるなど |
| 移行性 | 現行システム資産の移行に関する要求 | （本製品では該当せず。システム導入時に移行期間の要件を決める際に活用） |
| セキュリティ | 情報システムの安全性の確保に関する要求 | ネットワークには接続せずスタンドアロンで動作させるなど |
| システム環境・エコロジー | システムの設置環境やエコロジーに関する要求 | X人の利用を想定し、言語はXXなど |
例えば処理スピードなどは業務の流れ上には出てきませんので、このような内容を定めていきます。業務以外の機能と言われたらなんでもありのようなことを想定されるかもしれません。まさにそこが鍵で、後から実はこういった内容が欲しかった、、、などの要件漏れが無いように、この非機能要件についても各種のフレームワークが存在します。上記ではIPA（独立行政法人 情報処理機構）が定義する非機能要求グレード（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html）を参照しましたが、こちらは比較的サーバーなど大掛かりなシステムに対して有効なフレームワークです。他にもJUAS（一般社団法人 日本情報システム・ユーザー協会）がもう少し単独のシステム開発に向いているような資料を出していますし、それ以外にも様々なフレームワークが存在しますので、気になる方は調べてみてください。
重要なのは、ここが検討の抜け漏れや認識齟齬が多く発生する箇所でもあり、また、品質を決めるうえでも非常に大切な箇所ということです。プロジェクトが燃える原因の一つでもあり、手間暇かけてここをしっかり押さえることで将来燃えるリスクを最小限にできますので、しっかりと定義しましょう。
ここまでつらつらと実際に要件を定義する作業内容を書いてきましたが、人によって検討の仕方が違うと共同作業や引継ぎの際に、フォーマットそのものの一から理解しなければならなくなってしまいますよね。その対策として、プロジェクト着手前にＵＭＬ（Unified Modeling Language：統一モデリング言語）などの開発プロセスのどれを使うかを決めてから、そのフレームワークを元に実際は業務していますので、未然に混乱を防止しています。（こちらは細かくなるのでまた別の機会に記載します）
#3 実務上では要件定義フェーズが非常に重要
さて、ここまで要件定義の業務についてみてきたわけですが、私の経験として、この要件定義フェーズを如何にハンドリングして抑えられるかが非常に重要であり、プロジェクトマネージャや設計者の力量が問われることになります。
なぜかというと、一番情報が不確定な時期なのに、後段のフェーズに一番影響するためです。顧客の立場としては、自分で実現できないからこそ、他のベンダなどに開発依頼をしているため、開始直後に全ての要求・要件が定まっていることは少なく、検討しながら定めることも多々あります。一方、請け負った身としてもすべての要求に対してその場で解答を出すことも難しく、また、上記のように顧客の要求自体が定まっていないため空白状態の要求も多々あります。
このため、大抵の場合には初回の要件定義フェーズの進行に際しては前提条件を置き、次フェーズ以降の基本設計や詳細設計フェーズ時で定まり次第、適宜フィードバックがかかることになります。ここが非常に重要なポイントになります。つまり、何がわかっており、何がわかっていない状態かを整理しないと検討漏れが発生する可能性もあり、また、曖昧な状態で進めると顧客が思っている要求・要件と一致していない場合にはその部分を一から検討し、設計しなければならないため、このフィードバックによる手戻りの工数が結構かかります。
これを回避するためには、議事録やドキュメントの整備が有効です。これらの情報整理はプロジェクト進行上一見無駄な時間に思えることもあるのですが、ここをしっかりと抑えることが出来るかで将来が変わってきますので、時間を捻出すべきです。当然ながら、このドキュメントなどを元に、顧客と合意形成も重要になります。