はじめに
ソフトウェア工学とそれがもたらしたライフサイクルモデル、及びアジャイル開発についての学習を進めています。
参考：ソフトウェア開発プロセスを学んで健康的なエンジニアライフを送ろう
その学習と並行して、要求工学というものも学習を進めているので、学んだことと私が吸収して噛み砕いたものをアウトプットしておきたいのです。
間違いや誤解、助言などがあればコメントや編集リクエストをいただけると大変助かります。
目次
-
要求工学
- 要望、要求、要件の違い
- 要望と要求の関係
参考資料まとめ
1. 要求工学
どのソフトウェア開発ライフサイクルモデルにも必ず存在するのが「要求定義/要件定義」というプロセスである。私にとって、いやおそらく多くのエンジニアにとって、これはプログラムを書くこと自体よりも非常に難しいプロセスである。
例えば顧客が「ごはんを食べたい」と言った時、私たちは何を明らかにし、何を考え、何をすべきなのか。
顧客が求めているものは"ごはんを食べる"という行為なのか、"お腹をいっぱいにしたい"ということなのか、それとも"外食に行きたい"、"ごはんでも食べながら人と話したい"ということなのか。また、求められているごはんとは何か。お米を炊いたものか、それともごはんはお米という意味ではなくてパスタかラーメンか、そのどれでもいいのか、どれでもダメなのか。今どれくらいごはんを食べたくて、いつまでにごはんを食べたいのか。また、いつまでごはんを食べたい状態は続きそうか。我々はごはんを作れば良いのか、ごはんを食べれる場所を作れば良いのか、ごはんを食べられるお店を紹介すれば良いのか、ごはんを一緒に食べてくれる人を紹介すればいいのか。そして、それはどこまでが顧客の決めるべきことで、どこから我々のすべきことなのか。
このような問いは書ききれないほどある。要求/要件定義がいかに奥深く難解な問題であるかということが、この例でわかる。
要求工学とは
要求工学とは、要望、要求について、あるいはそれを仕様化するプロセスについての技術、あるいは研究と言える。
プロジェクトの失敗原因の多くは要求に起因する
要求工学知識体系(REBOK)概説 - 独立行政法人情報処理推進機構
システム開発において、手戻りやスケジュールの遅延、重大なバグが発生した時点で少なからず開発プロセスに失敗、欠陥があったと言える。
そして上記引用の通り、IPAはプロジェクト失敗の多くの原因は要求/要件定義にあるとしている。
これは私を含む多くのエンジニアが肌で感じ取っていることでもあると思う。
要求定義/要件定義に関する書物は現在確認できるだけで100冊を超えており、それは要求/要件定義の難しさを多くの人間が感じている証左である。
上掲IPA資料、ソフトウェア工学 - 玉井 2003年にも要求獲得、要件定義の難しさやそれに対するアプローチ技術の重要性が説かれており、これらは昨今ソフトウェア開発における一つの大きな課題として工学と呼ばれるにまで至っている領域である。
要求獲得、要求定義、要件定義、仕様化のプロセスについてはまだ未成熟な領域である。つまり、ベストプラクティスは未だ確立されていない難解な課題であるということは前提として認識しておく。
1-1. 要望、要求、要件の違い
重要：この三つはそもそも人によって解釈が違うものである
- 要望：demands
- 要求：requirements
- 要件：requirements
“requirement”は，通常“要求”又は“要件”と訳される。
(引用元：JIS規格X0166)
今回は、抽象度の違いという観点から特に要望/要求について定義し、要件定義に至る前段階に必要なプロセスを明らかにしたい。
抽象度の高い順に並べると要望>要求>要件(>仕様)であるという前提で話を進める。
1-2. 要望と要求の関係
通常、要望は英語でDemandsという。要求はRequirementsということから、この二つには明確な違いがありそうだということがわかる。
その前提の上で、まずは私なりの要望と要求の関係を定義したい。
- 要望 = 顕在化してない要求(潜在的要求)
- 要求 = 顕在化し、具体性を得た要望
私はこのように要望と要求を区別し、またその関係性を定義する。
そして、要求工学の力を借りつつ、私自身の経験から要求に関するプロセスをさらに細分化していく。
システム開発にまつわる"要求"というものは、下記のような段階的プロセスを経て作られていくものであると私は考える。
- 要望の発露
- 要求の認識
- 要求の分析
- 要求の定義
- 要求分析結果の合意
- 要求の検証
- 反復
まず、要望が何らかのプロセスを経て1.顕在化(発露)する。そして、それは要望保持者と要求獲得者(要求定義をしたい者)の両名に"未成熟な要求"として2.認識される。次に、認識された"未成熟な要求"を"成熟した要求"へと進化させるプロセスを経る。このプロセスを3.要求分析と呼ぶ。最後に、成熟した要求を文書化して明示(4.要求の定義)し、要望保持者と要求獲得者の間で5.要求分析結果の合意を得る。そして、成熟した要求が両者に共有された後、6.要求の検証を行う。
IPAのREBOKに基づく定義に当てはめると、1,2が要求獲得、3が要求分析、4,5が要求の仕様化、6が要求の検証・妥当性確認・評価に当たる。
同IPA資料にもあるように、このプロセスは決して直線的なものではなく、上で紹介したいくつかの反復型ソフトウェア開発ライフサイクルモデル、アジャイル開発の思想のように反復による改善を必要とするものである。
1-2-1. 要望の発露(顕在化)プロセス
先ほど"要求 = 顕在化し、具体性を得た要望"と定義した。
では、どういった経緯を経て要望は顕在化するのか。
要望が顕在化し"未成熟な要求"へと変化するプロセスには少なくとも2つの種類がある。
- コミュニケーション型要求発露
- 自己完結型要求発露
これらはあくまで私個人が名付けたものであり、一般的な用語ではない。それぞれ図を用いて説明する。
1-2-1-1. コミュニケーション型要求発露
上図に示したように、要望は要求獲得者(例えば要求獲得をしようとしているSIer)と顧客(ユーザ)間のコミュニケーションによって顕在化し、まず"未成熟な要求"へと変化する。
この場合、作業を楽にしたい、しかし"どうすればできるのかわからない"というわからなさや、そもそもこれは課題なのかというわからなさがコミュニケーションによって解消されたことにより要望が顕在化される。その"わからなさ"が要望を要望として留まらせていた原因と言える。
このプロセスを要求獲得者側として行う際に注意するべき点は正にそこであり、医療現場や社会学、心理学などにおけるインタビューの手法を取り入れるなどして、"わからなさ"の障壁と原因を理解した上で可能な限り適切にコミュニケーションを図る必要がある。適切でないコミュニケーションがもたらす結果は、要求獲得者のバイアスによる誘導、つまり"本当に顧客が要望していること"からの乖離といえる。
妻木によれば、この段階で具体的に取られる調査手法には以下のようなものがある。
- 情報の収集
- ステークホルダ分析
- 構造化インタビュー
- 観察
- 文献調査
- プロトタイピング
- 問題の定義
- 情報の整理
- 合意形成
- モデリング
1-2-1-2. 自己完結型要求発露
一方で、要望の顕在化までは顧客自身が行なっている場合がある。
顧客が要望を顕在化している状態では、SIerやソフトウェア開発をする側はほとんどの場合その要求を聞き取ることしか行わない。
上に挙げた妻木による調査をすでに顧客側が済ませており、ある程度整理された要求が提示されるという期待からである。しかし要求を獲得するという本質的な目的に対しては、この期待は危険を孕んでいる。
自己完結型要求発露によって顕在化した要求は"最も未成熟な要求"である可能性が高い。顧客自身が行った要望の顕在化は(顧客が社内調査をした結果だとしても)第三者とのやりとりを介して発露した要求ではない。提示される要求はコミュニケーション型要求発露プロセスを経た場合よりもあいまいさが強く、主観によるバイアスの影響も多大に受けている可能性がある。
しかし一方で、自己完結型要求発露によって顕在化された要求は、コミュニケーション型要求発露にはない当事者であるからこその業務知識、背景、課題感が含まれている可能性も高い。後のプロセスである"要求の分析"、"要求の検証"プロセスを経る際に鍵となる何かしらの要素がこの段階で露見することもある。
1-2-2. 要求の認識プロセス
要望の顕在化プロセスを経て、要求は初めて両者に認識される。
時には、顧客本人にとってもこの段階で初めて発見される要求及び要望がある。
(例) 「この作業を楽にしたい」 -> 「こういうシステムがあれば楽になるんだ」 -> 「じゃあそれが欲しい」
(例)「気づいていなかったけれど、実はこんなことにも困っていたんだ」 -> 「じゃあそれもどうにかしたい」
特にコミュニケーション型要求発露においてこの発見は顕著である。この場合においては、顧客自身も要求獲得を為したと言え、顧客ベンダ双方が要求獲得者としての性質を得る。
要望の発露と要求の認識プロセスを分けた理由はここにある。要望が発露した時点で要求として認識されたと捉えることもできる。しかし顧客自身が気づいていない要望/要求の発見という要求獲得における重要な課題の鍵を握るのはこのプロセスであると私は考える。
1-2-3. 要求の分析
1-2-1,1-2-2のプロセスを経ることで"未成熟な要求"を獲得した。
次の要求の分析というプロセスは、獲得した要求を成熟させる重要なプロセスである。
要求工学の領域ではない一般的な「要求定義」と呼ばれる工程で行われることとほぼ同様である。
分析の手法は多々ある。この分析こそが要求定義のコアであり、シナリオベースモデル、領域分割モデル、ゴール指向モデルなど様々な分析フレームワークが開発され、この難題をいかに解決するか日々研究がなされている。
ここでは、私の経験から最低限分析しておきたい3つの項目を挙げる。
-
要求の背景調査
- なぜその要求が生まれたのか？
- 誰が
- いつ
- どこで
- どのように
- なぜ、その要求は"今"要求として顕在化したのか
- なぜその要求が生まれたのか？
-
要求の正当性の明確化
- その要求は本当に必要とされている要求なのか？
- 誰に、どのくらい必要とされているのか
- その要求は何を解決し、何をもたらすのか
- 例えば業務効率の改善に関する要求であった場合、解決により何が顧客にもたらされるのか
- 新しい価値の創造リソース
- 人員コストの削減
- etc...
- もたらされるものは、本当に求められているものと同じなのか？
- 例えば業務効率の改善に関する要求であった場合、解決により何が顧客にもたらされるのか
- システムやツールが欲しい、という要求は正当なものなのか？
- 要望保持者、要求獲得者の適切でないバイアスが含まれていないか？
- それは「本当に欲しい」のか？
- "楽になるシステム"ではなく"楽になるオペレーションフロー"では解決できないのか？
- ここで、オペレーションフローを変更できない等の背景が発見されることもある
- システムと併用してより効率的な解決ができる方策はないか？
- システム利用権限保持者を拡大すれば、より効率が上がるのではないか？
- システム導入と同時に保守/運用が別途必要になるのか？
- 要望保持者、要求獲得者の適切でないバイアスが含まれていないか？
- その要求は本当に必要とされている要求なのか？
-
要求の具体化
- 要求が解決されるとは、どういうことなのか
- 先の図の例で言えば"楽になる"、"使いやすい"とはどういうことか
- 何が解消されていれば要求の解決に至れるのか
- 要求が解決されるとは、どういうことなのか
問いの例として、いくつか具体的な問いを掲載した。要求分析というプロセスは、何度も何度も立ち返り問いを発することで改めて要求の意義、要求の本質と詳細を明らかにしていくことが目的である為、重複した問いも時には必要であると私は考えている。
より根本的な課題背景を知ることで、必要とされているシステムが変わってくることはザラにある。
そもそも要求が正当でなく、作った後に「使ってない」と言われることもまたザラであると言える。1990年代に行われたスタンディッシュ・グループのレポートによれば、システムに搭載した6割以上の機能が使われていないという。
(参考：アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント 2013 平鍋健児、野中郁次郎)
1990年代の調査が現代に通用するのかどうかは別として、そうした非効率的な状況を回避するために、背景の認識、正当性の検証、具体化というこのプロセスが必要なのである。
要求の分析は決して開発者のみに利益があるものではなく、両者にとって利益のあるプロセスである。
要求の分析プロセスを経ることによって、顧客にとっても開発者にとっても気づきが与えられる。本当に必要とされている解決は何か、それはどれくらい致命的な問題で、解決することで何が起こるのか。
しかし一方で、開発側が敢えてこの要求の分析プロセスを回避している場合もある。例えば開発会社にとっては顧客にとって無駄なものであったとしても、案件として受注をして言われた通り納品してしまえば報酬がもらえる。この問題は受注/発注双方の課題でもあり、システムインテグレーション、システムコンサルティングの領域に波及する。
1-2-4. 要求の定義
前プロセスである"要求の分析"で明らかになった"要求の本質と詳細"を書面化するプロセスが本プロセスである。
一般的には、この時点で要求仕様書という要求をシステム仕様にまで落とし込んだ書面を作成する場合もある。
しかし今回は先述した通り、要求と要件を明確に区別し話を進める。その上で、要求の分析プロセスで明らかにしたものはビジネスの要件であり、決してシステム要件ではないということを断言しておく必要がある。
即ち、このプロセスで作るべき書面は、"ビジネス要件"を明示したものである。
1-2-5. 要求の合意
1-2-4. 要求の定義で作成したビジネス要件をまとめた書面は、両者によって分析結果に齟齬がないか検証合意される必要がある。
このプロセスでは分析の結果の正当性を問う。ここで注意しなくてはならない点は、そもそもの要求の正当性ではなく分析の結果の正当性を合意するという点である。
要求の正当性を問うプロセスは別にある。次のプロセス要求の検証である。
1-2-6. 要求の検証
ここまでで、ある程度成熟した要求が定義された。要求の分析結果は書面化され、ビジネス要件の具体的な姿が見えるところまできた。
その要求は本当に必要なものだったか、本質的な問題は別のものではなかったか、当初持っていた要望とは別の要望が生まれてはこなかったか。ここでようやく、顧客と要求分析者の間で要求の正当性を改めて問うことができるようになる。
1-2-7. 反復
先述した通り、これらのプロセスは反復型ライフサイクルモデルやアジャイル開発の思想のように、反復して行わなければならない。
その理由は以下2点である。
- 分析結果を受けて、要求が変化し得ること
- これまでのプロセスで得た"気づき"による新たな要求がまだ一連のプロセスを経ていないこと
例えば先の図で"本当は別のものが欲しいのかも"という新たな要求が顕在化した。その原因は何か。それは潜在的な要望が新たに発見されたことに他ならない。
はじめに、要望を以下のように定義した。
要望 = 顕在化してない要求(潜在的要求)
要望が潜在的な要求であるように、要望にもまた顕在化しているものとしていないものがある。顕在化した要望は新たな要求となり、再度一連のプロセスを経てその正当性、必要性が議論されて然るべきものである。また、要望は一度洗い出したらそれが全てというものではない。常に新しい要望が生まれ、それは潜在的であることもあるし、顕在化している場合もある。
この流動性、複雑性こそが要求工学という技術を生んだ要因であると私は理解している。
2. 参考資料まとめ
- 要求工学知識体系(REBOK)概説 - 独立行政法人情報処理推進機構
- ソフトウェア工学 - 玉井 2003年
- 要望・要求・要件・仕様・制約・前提の違いは？ - Qiita
- 要望、要求、要件 - たまゆら雑記
- JIS規格X0166
- 要求工学：現実と仮想をつなぐために - 妻木俊彦
- アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント 2013 平鍋健児、野中郁次郎
とりあえずここまで！！！！！！！！！