要求分析

要求分析（ようきゅうぶんせき、Requirements Analysis）とは、システム工学やソフトウェア工学において新たなシステムやシステム更新に際しての調査/定義に関わる工程を指す。要求分析はシステム設計工程でも重要な部分であり、アナリストやシステムエンジニア/ソフトウェア開発者が顧客の必要性や要求を特定する工程である。顧客の要求が特定されたら、システム設計者がその解決策を設計することになる。

主な技法

概念上、要求分析には以下の3つの活動が含まれる:

要求を聞きだす: 顧客やユーザーとの対話によってその要求を聞きだす。
要求を分析する: 要求を必要に応じて明確化し、補い、矛盾点や問題点を明らかにする。
要求を記録する: 要求を文書化する。文書形式には通常の自然言語の文書以外にユースケース、ユーザーストーリーなどがある。

要求分析は時間のかかる忍耐を要するものとなる場合もあり、微妙な心理学的スキルを要することもある。新たなシステムは人間関係や環境を変えることもあるので、関係者全てを特定しておくことも重要であり、関係者全員のニーズを聞き出すと共に、彼らがシステムとどう関わるかを理解していることを確認する必要がある。アナリストは顧客から要求を聞きだすためにいくつかの技法を活用する。インタビューやフォーカスグループ（要求ワークショップ）から要求リストを作成するのは古くからある技法である。やや新しい技法としてプロトタイピングとユースケースがある。必要に応じてアナリストはこれらの手法を駆使し、関係者の要求を正確に把握する。それによってビジネスの必要性に合ったシステムが開発される。

関係者インタビュー

関係者インタビューは要求分析の典型的な手法である。工数との兼ね合いで関係者の選択が一般に必要とされる。インタビューによってプロジェクトの開始時点で想定していなかった要求が明らかとなり、個々の要求の間で矛盾が生じることがある。

要求ワークショップ

場合によっては関係者を集めた「要求ワークショップ」を開くのが有効である。ワークショップは関係者が集中できる環境で行うのが望ましい。司会役は議論が逸れないよう注意する。また、書記役が議論を記録しておくのがよい。司会役はプロジェクターと図作成ソフトウェアを使ったり、紙とマーカーによる資料を使ったりする。司会役の重要な仕事として、個々の要求の優先順位付けが参加者の個性にあまり依存しすぎないように注意しなければならない。

契約型要求リスト

要求を文書化する方法として契約型要求リストがある。複雑なシステムでは、この要求リストが数百ページにもなることがある。

検証可能な目標

最善のプロジェクトでは、要求リストを単なる手掛かりとして扱い、繰り返し「何故このような要求が出てきたか」を問いかけて真のビジネスの目的を明らかにする。そして関係者と開発者で各目標の達成状況を測るための基準を設ける。これら目標は個別の（基準のない）要求リストよりも変化しない。重要な目標が達成されたとき、手早いプロトタイピングと開発によってプロジェクトの途中であっても関係者に成果として提供することがある。

プロトタイプ

1980年代中ごろ、要求分析問題の解決策として「プロトタイピング」が注目された。プロトタイプとは、開発前にユーザーに対してアプリケーションを視覚化してみせるための画面表示などである。プロトタイプによってユーザーはシステムがどのようなものかを具体的に描くことができるようになり、開発前に設計上の決定を行うことが容易になる。プロトタイプの導入によってユーザーと開発者の対話が大いに改善された。最初に画面の見え方を示しておけば後工程での変更が少なくなり、全体としてコスト削減につながる。

しかしその後、次のような問題は解決できないことがわかってきた:

マネージャから見れば、プロトタイプが即座に出来てきたのに、実際の開発に時間がかかる理由が理解できない。
設計者は実際の開発にあたって一からやり直すことになるのを恐れて、プロトタイプのコードをつぎはぎして実システムを作ることを強制されているように感じる。
プロトタイプはユーザーインターフェイスの設計などには有効である。しかし、本来の要求が何だったのかということとは無関係である。
設計者とユーザーがユーザーインターフェイスの設計に重点を置きすぎて、実際にビジネスを行うシステムがおろそかになる。

プロトタイプは、実際に動作する簡単なアプリケーションの場合もあるが、線画（ワイヤフレーム）の場合もある。線画では色をつけないようにして、最終的なシステムの見た目と混同させないようにするのがよいとされる。

ユースケース

詳細は「ユースケース」を参照

ユースケースは、新システムやシステムの改善にあたっての要求を文書化する技法である。各ユースケースは1つ以上の「シナリオ」を提供し、その中でシステムやエンドユーザーや他のシステムがどのように相互作用を行ってビジネスの目標を達成するかを描く。ユースケースでは技術的な専門用語を排し、エンドユーザーやその分野の専門家にわかる用語を使うのが望ましい。ユースケースはソフトウェア開発者とエンドユーザーが共同で執筆することも多い。

ユースケースはソフトウェアの挙動を説明する単純なツールである。ユースケースにはユーザーがインターフェイスを通してソフトウェアを動作させる全ての方法に関する文章による記述が含まれる。ユースケースはソフトウェア内部の動きは記述されないし、どう実装されるかも説明されない。単にユーザーが何かをソフトウェアにさせる際の手順を示すだけである。このような形で全てのユーザーとシステムのやり取りが記述されている。

1990年代、ユースケースは機能的要求仕様を捉える手法として急速に広まった。特にその起源となったオブジェクト指向の世界で顕著であるが、その利用はオブジェクト指向システムに限られたものではなく、ユースケース自体はオブジェクト指向に縛られた手法ではない。

各ユースケースは1つのビジネス目標/タスクを達成する方法を描いている。従来からのソフトウェア工学の観点からすれば、1つのユースケースはシステムの1つの機能を描いていると言える。多くのソフトウェアプロジェクトでは、システム全体を記述するのに数十から数百のユースケースが必要であることを意味する。特定のソフトウェアプロジェクトの形式化の度合いやそのプロジェクトの工程によってユースケースをどこまで詳細に記述すべきかが決まる。

ユースケースは、あるビジネス目標を達成する際の外部のアクターと対象システムの相互作用を定義する。アクターとはシステムの外にあってシステムとやり取りをするものであり、ユーザーだったり、別のシステムだったりする。

ユースケースではシステムを「ブラックボックス」として扱い、システム外から観測できるやり取りを扱う。これは意図的な方針であり、この方針によって要求仕様の記述が簡略化され、その機能がどのように実装されるかという前提（先入観）を排除することができる。

ユースケースは以下のように記述されるべきである。

ビジネスの目標を達成するためのビジネスタスクを記述する。
適切な詳細さで記述される。
ソフトウェア開発者が一回のリリースで実装出来る程度の量である。

ユースケースは機能的要求仕様にとってはよい手法だが、非機能的要求仕様には適さない。ただし、パフォーマンス・エンジニアリングでは、重要なユースケースにはそれに対応した非機能的要求が存在するとされる。

ソフトウェア要求仕様

ソフトウェア要求仕様は、開発対象システムの振る舞いを完全に記述したものである。これには、そのソフトウェアとユーザーとのやり取りを全て記述したユースケースも含まれる。ユースケースは機能要求仕様とも呼ばれる。ユースケース以外に非機能的要求仕様も含まれる。非機能的要求仕様は、設計や実装に対する何らかの制限（性能要求、品質要求、設計上の制約など）である。

ソフトウェア要求仕様の記述に関する推奨手法は IEEE 830-1998 で示されている。この標準はソフトウェア要求仕様の考えられる構造、望ましい目次、品質などについて記している。

関係者の特定

1990年代になって特に強調されるようになったのは、「関係者」の特定である。「関係者」とは単にそのシステムを発注した企業の社員だけに限られない点に注意されたい。他に考えられる「関係者」として次のような人々がいる:

その企業と対等な関係で密に連携している（あるいはこれから連携が予定されている）企業
何らかの事務処理部門
組織上上位にある者

要求定義工程に対する世間一般の誤解

要求定義工程における素人が持ちやすい誤解とは、理解の対象となるシステムの規模が概ね法人向け大規模システム開発プロジェクトが対象となるが故に、要求定義工程を担当する人材自身が時として経営者クラスの人材である事から、要求定義工程を担当する事がそのまま担当する地位や職責の高さを明示的に周知するべきものであると誤解されやすいが、分析の対象となるコンピュータシステムの開発プロジェクトによって千差万別であり、必ずしも要求定義工程を担当する技術者がその地位や職責の高さを内外に知らしめるものではない。

以下に記述するように小規模システム開発プロジェクトであれば、要求定義工程は極めて小規模であるが故に責任の持つ範囲がある程度限定される事実を背景に、外部のエンジニアと営業担当という非常に限定された責任の範囲にて解決される場合があるが、大規模システムである場合は各社の経営陣を交えた高度な専門家チームによってコンサルティングを含めた分析が数年に渡って行われる事が多い。概ね一般的に要求定義とは大規模システムを対象とした後者の工程に対して言われる傾向があるが、日曜プログラマ（アマチュアプログラマ）がリリースの対象とするプラットフォーム（ウィンドウズなのか、リナックスなのか、iOSなのか、Androidoなのか等）や開発言語（VC＋＋なのか、Javaなのか等）を選定する工程そのものが要求定義工程の作業そのものであり、本来は大規模システム開発プロジェクトで見られる大がかりな要求定義の方がケースとしてはどちらかと言うと特殊である。

主に要求定義工程と基本設計工程以降の一番大きな違いとして、案件受注の対象として見積もりの対象とされるか否かの違いであり、基本設計工程以降に行われる見積もりがプロジェクト全体に与える影響は、要求定義工程に確定された見積もりに対して極めて微小な範囲に限定される。

世間一般の誤解として、建設やプラント開発になぞらえて、小規模開発プロジェクトが軽視され、大規模開発プロジェクトが高く持ち上げられる傾向もあるが、有名なソフトウェア作家が作品の制作を進めるソフトウェア開発プロジェクトや、Googleを始めとしたWeb2.0の時代に有名となった企業の多くは、専門性の高い少数精鋭の高度な技術者集団による小規模開発プロジェクトにて実現されており、必ずしもシステム開発プロジェクトの規模が与える社会的影響力について、その規模に比例しない事が素人の誤解や混乱を一層深くさせる要因の一つである。

小規模システム開発プロジェクト（1千万円以下）

マネージャの関わり方

役割として営業担当者と殆ど変わらない。受注した案件を自社に持ち帰って他のエンジニアと共に徹夜で残業するケースも多く見られる。

エンジニアの関わり方

システムエンジニアやプログラマやネットワークエンジニアを含めた殆ど全ての役割は、各個人や多くとも数名で対応が成され、専門分化された役割を主張した上で個々人が作業範囲を限定してしまう事がむしろプロジェクトにとって大きな弊害となる傾向がある。数名の凡庸たるプログラマよりも一部の特殊な才能のエンジニアによる少数精鋭の集団による開発が最も有効と言われる傾向にあるが、特殊な才能よりも一般的なビジネス知識や社会人としてのマナーの方が重視される傾向は、研究機関や教育訓練機関（知識偏重教育の舞台）と混同されやすい傾向を背景に、技術者である事が単にビジネスマンの一人であるにすぎないという当然の理解を前提とする。

その他(肩書や開発工程との相関関係)

全くの新人であってもプロジェクト全体のまとめ役や進捗管理を担当する場合があり、特に人材の活用方法が流動的な中小企業ではそのような機会が多い傾向もあり、必ずしも肩書や開発工程と、その人材の社会的地位や職務上の肩書と一致するものでは無い。

中規模システム開発プロジェクト（1千万円以上～1億円以下）

マネージャの関わり方

職責として要求定義の発注に関わる責任者クラスが担当する傾向があり、プロジェクト全体の進捗管理や工程管理についても責任者たる地位である場合が多い。サブリーダーやリーダーを含めた作業の専門分化もある程度見られ、分業の体制として設計・開発・試験が適宜分化の対象となり、設計・開発・試験の工程の一部を切り出した上でその全てを下請け会社に発注するケースや、試験専門のチームによって試験の工程だけが分化される場合等、その会社の方針や、その時その会社に所属する人材の質によって様々な形態が見られる。そのようなプロジェクトの体制の決定や、不足する人員や資材の調達や、法律上の問題の解決を含めた役割を主に担う傾向がある。

エンジニアの関わり方

ある程度専門分化されたチームによって、システムエンジニアやプログラマのような位置づけがある程度明示的な状況の中で、それぞれの分化された役割を対応する傾向にある。リーダーやサブリーダーであったとしても、管理的業務よりも設計や開発業務が主体であり、専門性が求められる対象としては技術者としての専門性である。

その他(肩書や開発工程との相関関係)

責任の大きさとしてマネージャ格の人物は社内のライン管理者であるケースが多いが故に、ライン管理者自身は技術者としての高度な専門性を保有しないケースが大半である。リーダー職やサブリーダー職については極めて流動的であり、肩書はあって無いような世界である。頻繁に上下関係の位置づけが混乱を続けながら切磋琢磨を期待される環境にあるのは、技術屋の世界ならではであろうが、それを良い事に足切り同然の不当人事や一方的な賃金の切り下げを含めた労働基準法違反を成立させる為の経営者側の口実となるケースも少なく無く、ヒューマンスキルが高いマネージャ格の人物の善政によるマネージメントが無ければ、プロジェクトが途中で壊れ精神病や内臓疾患を中心とした病人の大量生産や訴訟問題に発展するケースも少なくない。

大規模システム開発プロジェクト（1億円以上～）

マネージャの関わり方

責任の大きさとして企業の経営者クラスがマネージャ格を務めるケースが多い。組織の多くは縦割りとなり管理的役割の人員の規模も多くプロジェクト全体の効率性は極めて低いが故に、たった1日の工程遅延がそのまま永続的に回復しないぐらいに柔軟性を欠く。プロジェクトマネージメントに関わる高度な専門性を持ったエンジニアが多数関わる中で、半数以上は全くの素人や新人で構成されるプロジェクトも多く、突飛な能力を発揮できる一部の特殊な才能を持つエンジニアによる非定形的な活躍よりも凡庸たるエンジニアを多数まとめ上げながら極めて厳しい納期や予算の制約を乗り越える事を可能とする、熟練した経験を前提としたマネジメントにおける采配が必要とされる。

エンジニアの関わり方

極めて細分化された専門分化と、その役割に応じて詳細に決定された責任の範囲における肩書を含め、能力評価や進捗管理の殆ど全ては科学的評価手法によって数値による定量的な分析の対象とされた管理の下に、それぞれの細分化された役割をミス無く担当できるだけの能力の発揮を継続的に長期間に渡って求められ続ける。高度な資格を保有している実績や過去の経歴も重視される傾向にあるが、極めて限定的な技術的分野の特定の領域に対する専門分化に極めて特化している事が要求されるケースが多く、のれん分けのような徒弟制度によって脈々と古いエンジニアから新しいエンジニアにその地位が継承される職人気質の性格が強い。

その他(肩書や開発工程との相関関係)

極めて強固な縦割り組織であるが故に、官僚社会同然の厳しい縦社会の風土が強い傾向にある。肩書と職責の範囲の相関関係は極めて強固かつ（暗黙的ながらも）明示的であり、プロジェクトに関わる人材の大半は巨大なシステムのほんの一部分の歯車として正確に働く事を求められるにすぎない。このような大型案件特有の縦割り組織かつ非効率かつあまりにも細分化され限定される責任の範囲がもたらす、個々の技術者に対する閉塞感や将来性の低さが原動力となり、ベンチャー起業やフリーランスに転じる技術者も多いが、35歳定年説が多く論じられる最も大きな世界もこの環境である。

徒弟制度に基づくのれん分けを伴う人間関係を主体とした組織の形容はドッグイヤーと呼ばれるこの世界において極めて短期間に改廃が繰り返される傾向にあり、既得権益化しづらい環境がビジネスの新機軸を打ち出す為の機運を高める傾向にあり、新しい斬新かつ先進的なビジネスチャンスを梃子に多くのブームの火付け役として中心的な役割を担うのは、アイデアというモデルを発明の対象とした上で工学的に自在に実現を可能とするソフトウェアの特異性を根拠とする。

問題点

関係者の問題

Steve McConnell はその著書 Rapid Development の中で、ユーザーが要求を集める作業を妨げる可能性を以下のように示した:

ユーザーは自らが何を欲しているか理解していないことがある。
ユーザーは要求仕様書に関わりたがらないことがある。
ユーザーは既にスケジュールと費用が確定した状態で新たな要求を出してくる。
ユーザーとの対話には時間がかかる。
ユーザーはレビューに参加したがらないか、参加できないことがある。
ユーザーは技術に疎い。
ユーザーは開発工程を理解しない。

このような要因によって要求仕様は開発が開始されてからも変更され続けることになる。

技術者/開発者の問題

要求分析において技術者や開発者が次のような問題を引き起こすこともある:

技術者とエンドユーザーは語彙の違いによって話が通じないことがある。結果として意思疎通できていないにも関わらず、完全な合意に達したと勘違いしたまま開発を行うことがある。
技術者や開発者は要求を既存のシステムやモデルに当てはまるようにしようとする傾向があり、その顧客専用のシステムを開発するのを避けようとする。
分析を技術者やプログラマが行ってしまい、対象分野の専門家が参加しないためにユーザーのニーズが正しく反映されないことがある。

解決の試み

このような意思疎通問題の解決策としてそのビジネスの専門家やシステム分析の専門家が雇われることもある。

1990年代に登場したプロトタイピング、統一モデリング言語(UML)、ユースケース、アジャイルソフトウェア開発などの技法も従来の手法の問題点を解決するべく導入されてきた。

アプリケーションのシミュレーションツールや定義ツールも市場に出回るようになってきた。このようなツールはユーザーとIT組織の意思疎通問題を解決するよう設計されており、実際にコードを開発する前にアプリケーションを試してみることを可能にしている。これらツールの特徴は以下の通り:

電子ホワイトボードでアプリケーションの流れを図示したり代替案を検証する。
ビジネスロジックやデータの必要性を捉える能力
最終的なアプリケーションをかなりの精度で実現する高機能プロトタイプを生成する能力
対話性
文脈的な要求やコメントを追記できる機能
遠隔ユーザーや分散ユーザーがシミュレーションとやりとりする機能

参考文献

McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules (1st ed. ed.). Redmond, WA: Microsoft Press. ISBN 1-55615-900-5. http://www.stevemcconnell.com/
Wiegers, Karl E. (2003). Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle (2nd ed. ed.). Redmond: Microsoft Press. ISBN 0-7356-1879-8. http://www.processimpact.com
Andrew Stellman and Jennifer Greene (2005). Applied Software Project Management. Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8. http://www.stellman-greene.com

外部リンク

要求分析山本修一郎（NTTデータ）、月刊ビジネスコミュニケーション