日本ソフトウェア科学会第 30 回大会 (2013 年度) 講演論文集

要求の集約と体系的な可視化を支援する環境の提案
濱登 強伊藤 恵

本研究の目的は引き出された要求の集約とその体系的可視化を支援することにより，システム開発プロジェクトを支援することである．現在日本のシステム開発で多く適用されているウォーターフォールモデルでは，手戻りが発生しやすい．上流工程の時間的な制約のため要求の整理ができず，要求漏れに気づかぬまま下流工程へと進行することがある．そのため手戻りが発生してしまう．そこで要求漏れを改善するために超上流，要求開発などの仕組みが提案され，ビジネスアナリシスを体系化した BABOK が整備された．しかし，時間的なコストを削減するには至っていな
い．本研究では開発依頼者に対し，BABOK を活用し要求の集約とその体系的可視化を支援することにより，要求漏れの把握と時間的コストの削減をできる環境を提案する．

The purpose of this study is to support the system development projects how to collect requirements drawnand to systematic visualization. Today, many system projects in Japan use the water fall model as thedevelopment process model. There is a greater risk that is easy to occur the rework in water fall model. Therequirements can not be collect by time constraints. The progress of a projects to lower process remains tobe drawn enough requirements. Rework is caused by it. To solve these problems, methods such as Cho-joryu
and Requirement Development were suggested and BABOK that is a guide to the business analysis body ofknowledge was prepared. But, they can not reduce the time of requirements definition. This study proposes
an environment for development client. As way of collecting requirements by using BABOK and supporting
systematic visualization. In this environment can perceive requirements that is overlooked and reduce thetime of requirements definition.

ここでいうプロジェクトの成功率とは「Q(Quality)，1 背景

C(Cost)，D(Delivery)」，すなわちシステムの「品ソフトウェア開発において要件定義はプロジェク

質」「コスト」「納期」の 3 点について当初の計画を順トの成功に大きく関わる重要な工程であり，システム守できたかどうかを尋ね，その回答を基に算出した値を発注する側のユーザ企業とシステムを受注する側となる． このように成功率はわずか 31 ％しかない．のベンダ企業の両視点からも欠かすことができない．
ユーザ企業視点では，ベンダ企業に何を実現するためにどのようなシステムが必要かという要求を伝えられる工程となっている．一方ベンダ企業視点では，システム開発でどのような機能が必要になり何をすべきか知ることができる工程となっている．ここで現在のIT プロジェクトの成功率を図 1 に表す．これは日経コンピュータ (2008 年 12 月 1 日号) のデータである．
Proposal of An Environment to Support Collecting
Requirements and Systematic Visualization
Tsuyoshi Hamato Kei Itou, 公立はこだて未来大学システ
ム情報科学部, Dept. of Systems Information Science,Future University Hakodate.

図1

プロジェクトの平均成功率

プロジェクトの失敗要因のひとつとしてあげられる納期の遅れに着目した際，要因の約 4 割が要件定義工60%(651 件中 392 件)

程の遅れという結果も日経コンピュータ (2008 年 123. 事前に発注先の体制，能力をよくチェックせず

月 1 日号) であげられている．要件定義は，システムに発注してしまった：32%(651 件中 209 件)

開発プロジェクトにおいて早期の工程になるため，ここのようにシステム開発プロジェクトを終えた後にの工程で要求を洗い出すことができなければ後の工システム仕様の定義をしきれなかったと答えるユー

程でも手戻りが発生しプロジェクトの納期が遅れるザ企業が多い．また，ユーザ企業，ベンダ企業の両方可能性があり，また，ユーザ企業が意図しないシステの問題としてシステム機能の利用率について図 2 にムが出来上がってしまう．そのため要件定義という工示す（Standish Group Study Report in 2000 Chaos

程はシステム開発プロジェクトにおいて重要である．

Report）． [3]

要件定義の現状を 1.1 節で記述する．

1. 1 要求定義の現状
現在行われている要求定義では，システム仕様が明確に定まらないまま次の工程に進んでしまっているプ
ロジェクトもある．ユーザ企業とベンダ企業の両方の問題を記述する．ユーザ企業では要求仕様書をベンダ企業に依存してしまっている．表 1 では要求仕様書作成におけるユーザ企業とベンダ企業の役割分担を図2示したもので，2004 年に行われた JUAS（日本シスシステム機能の利用率

テムユーザー協会）IT 動向調査の結果である．
ユーザ企業がビジネスを実現するために，システム図が示す通り利用されていない機能が 45%ある．こ化の要求を要求仕様書にまとめるが，現実にはユーザの結果はユーザ企業が何をシステム化したいのか明

企業自身で作成している割合は 16%と低く，それ以確にできていない事とベンダ企業のどのようなシス外の結果を見てもベンダ企業に依存している状況だ

テムを制作するのかを明確にできていない事が原因とわかる．要求仕様書の作成においてベンダ企業へので問題となっている．要件定義の現状では，発注者，依存が強くなると下記のような問題を引き起こす可受注者ともにシステム化要求を明確にできておらず，能性がある． [4]

納期が遅れてしまうという問題がある．

• 実際の業務とシステムの仕様が乖離し，システムを使い業務を遂行できない．

• システムに業務の遂行に必要な機能が不足し、システムの想定外の運用を強いられる．

2 関連研究2. 1 要求の獲得方法
要求をどのような手法で手に入れるかについて述• 開発環境では想定できなかった環境面の問題がべる．現在までの要件定義で主に使われ，今もなお使システムに発生し，業務が長時間停止する．

われている手法に「関係者インタビュー」，「プロトタまた，ユーザ企業の発注する立場としての反省を分析イプ」がある．また，ユーザ企業のビジネスそのものしたものを以下に記述する．データは JUAS IT 動向から考えてシステム開発をどのようにおこなっていく

調査 2005 年度のもので，システム発注者が反省としかを考えていくものとして「要求開発」，「BABOK」てあげる項目をまとめたものである．などもある．下記 2.1.1 から 2.1.4 でそれぞれについ1. システム仕様の定義が不十分のまま発注してしまった：93%(651 件中 606 件)

2. 委託先に要求仕様条件を明確に提示しなかった：て説明する．

表1

要求仕様書による役割分担

要求仕様書はユーザ企業が作成

16%

ベースはユーザ企業が作成し，細部の作成はベンダ企業に委託

33%

ラフな要求仕様書はユーザ企業が作成，あとはベンダ企業に委託

41%

すべてベンダ企業が担当

9%

2. 1. 1 関係者インタビュー

クなアプローチとともに以下の方法を提供している．

関係者インタビューは要求定義の典型的な手法であ[2]る．工数との兼ね合いで関係者の選択が一般に必要とされる．インタビューによってプロジェクトの開始• 戦略的 IT 化を推進するための組織形成やプロジェクトの構成方法

時点で想定していなかった要求が明らかとなり，個々• 経営課題やビジネス要求を構造的に分析する方法の要求の間で矛盾が生じる場合もある．

• ビジネスの構造やメカニズムを視覚化する方法

2. 1. 2 プロトタイプ
プロトタイプとは，開発前にユーザーに対してシステムを視覚化してみせるための画面表示などである．
プロトタイプによってユーザ企業はシステムがどのようなものかを具体的に描くことができるようになり，開発前に設計上の決定を行うことが容易になる．プロ• ステークホルダーの合意を形成しつつプロジェクトを推進する方法• 企画したシステムによるビジネス的価値・効果の検証方法• ビジネス要求とシステム要求のトレーサビリティの管理方法

トタイプの導入によってユーザ企業とベンダ企業の対要求開発では，ユーザ企業のビジネスモデルに基づ話が大いに改善された．最初に画面の見え方を示していた要求の引き出しが可能である．しかし，プロジェおけば後工程での変更が少なくなり，全体としてコスクト失敗の原因のひとつである，「納期の遅れ」を解決ト削減につながる．しかし，以下のような問題は解決するには至っていないと考える．そこで，本研究ではできない．

要求開発で行われている要求獲得方法を活用し，要求• プロトタイプはユーザーインターフェイスの設の引き出しを時間を短縮し行える環境の提案をする．

計などには有効である．しかし，本来の要求が何

2. 1. 4 BABOKだったのかということとは無関係である．

組織の目的達成に役立つ解決策を推進するため，ス• 設計者とユーザーがユーザーインターフェイステークホルダー間の橋渡しとなるタスクとテクニックの設計に重点を置きすぎて，実際にビジネスを行の集まりのことを「ビジネスアナリシス」という．このう機能システムがおろそかになる．

ビジネスアナリシスの知識体系が BABOK（Business2. 1. 3 要求開発

Analysis Body of Knowledge）である．カナダのト要求開発とは，経営分析 (ビジネス戦略) とシステ

ロントに本拠を置く NPO 法人，IIBA（Internationalム開発プロジェクトのギャップを埋め，ビジネスとシInstitute of Business Analysis）が BABOK を発刊

ステムの相互作用による『正しいシステム』の構築をしている．要求をまとめるにあたり，ビジネスアナリ目的とした手法のことである．要求を『要求開発アラ

ストは何から取り組めばよいのかの指針となるのが，イアンス』という団体によって考え方が提唱され，「要BABOK が示す知識エリアである．7 つのカテゴリ求は在るものではなく、開発するものである．
」と唱それぞれに，実行すべきタスクを定義している．以下えられている．つまり，ビジネスの視点から業務のあに各知識エリアについて記述する． [1]るべき姿や、問題課題を捉え、その中からシステム要• エンタープライズアナリシス

求を作り出すことを重視している．また，ビジネス的プロジェクトの投資対効果を考えながら，企業と要求をシステム要求に変換するためのシステマティッ

してのゴールや目標を決める．ビジネス上の置かれた状況を分析したり，ビジネスニーズを文書化

2. 2 要求の可視化したりする．

まとめられた要求を可視化する手段について述べ• 要求アナリシス

る．現状ではビジネスプロセスモデル，DFD（Data

候補に上がったソリューションがステークホル

Flow Diagram），状態モデル，イベントシーケンスダーのニーズを満たすためにどんな機能が必要

図，クラス図，概念オペレーショナルモデルなど 6 種なのかを定義する．価値や実装の難易度などに応類以上のモデル表記方法が使用されている．これらのじて優先順位を付け，重要な要求を確実に取り込

モデル表記はオブジェクト指向の考え方を使ってソフめるようにする．

トウェアを設計する際の設計図として用いられるほ• ソリューションのアセスメントと妥当性確認

か，ソフトウェアに要求される機能を分析する段階にソリューションが目標に対して正しいものである

おいて要求を分かりやすく図示し分析を助ける目的かを評価する．弱点を見極めるほか，そもそもシでも利用される．これらの可視化の手法は発注者側がステム化せずにプロセスの順番を変えるだけで見る際，IT に精通している人物でないと理解しにくよいのかなども勘案する．

い．そこで本研究では発注者側から，要求の可視化を• 引き出し支援する環境を提案する．

ステークホルダーのニーズと懸案事項を把握し，どのような状況に置かれているのかを定義する．

2. 3 要求の管理

本当に必要な要求を顕在化し，うわべだけの不要要求管理は，プロジェクトの要求を管理し，それらなニーズと振り分ける．

• 要求のマネジメントとコミュニケーション

要求とプロジェクトの計画および成果物との不整合を特定することを目的とする．要求管理には変更管理

プロジェクトが進むことで起こり得る要求変更と要求トレーサビリティが含まれる．要求管理では，を管理する．変更した理由，影響範囲などを明記

バランス，コミュニケーション，調整が重要である．

する．

ある種の要求が他の要求を無効化してしまうのを防• ビジネスアナリシスの計画とモニタリング

ぐには，開発メンバー間の一定のコミュニケーション

ステークホルダーの役割と責任，コミュニケーが必須である．例えば，内部アプリケーションのソフション方法を定義するほか，要求を満たすためのトウェア開発において，ユーザーの要求を無視させるアプローチについて誰に意見を求め，報告すべきような強い内部的ニーズがあったり，ユースケース作かを決める．

成時にそのような要求がユーザーの要求であるかの• 基礎コンピテンシように思い込むことがある． 要求トレーサビリティ

要求の整理について記述したものではなく，適応とは，要求のライフサイクルの文書化に関わる．それ力のある BA になるための資質や知識などをまとぞれの要求の起点にさかのぼることは可能なはずでめる．例えば問題を解決する発想力や，決断を下あり，従ってトレーザビリティを達成するために，そす際の判断基準を持つことが必要，などを記す．

れぞれの要求になされた変更が文書化される必要が

BABOK では要求獲得の手法を提供している．しかある．実装された機能が配備されて使われるようにし，それらの手法を使いこなすため前提としてビジネなった後でも，要求の使用状況はトレース可能である

スアナリシスに精通していることあげられる．そこべきである．

で，本研究ではビジネスアナリシスの経験がない人物であっても，BABOK の手法を使える環境を提案

3 提案する．

3. 1 本研究の目的
本研究の目的は，要求を引き出し集約し，体系的に可視化することにより管理を支援する環境を提案することである．要件定義における問題をここで整理すで得られた集約，可視化された要求をもとにユーザる．以下に記述する．

企業とベンダ企業間で要件定義を行う．そこで得られ1. システム化をおこなう全体像が見えない．

るシステム要求を環境に入力することでも，体系的

2. 要件定義においてユーザ企業がリードできない．に集約し両者に対して可視化を行う．環境下では要求

3. 要件定義工程で納期の遅れに繋がる遅延が生変更をする際，要求変更がシステム化の範疇なのかを判断し，要求変更を認めるかどうかの裁量を行う．

じる．
これらの原因についても以下に記述する．

また，要求変更があるたびに可視化をおこない，両者

1. ビジネス全体としての問題点や，システムの位が情報を共有できるよう支援する．

置づけが不明瞭なままであること．

2. ユーザ企業が要求をまとめきれていないことに

3. 2 研究のアプローチ加えて，効果的に伝える手段を有していないこと．

本研究は 3.1 で述べた問題点を解決できる手法を有3. 要求の範囲を明確にできていないこと．ベンする環境を提案する．問題の一つ目と三つ目であるダ企業がユーザ企業の鵜呑みにしてしまうこと， 「ビジネス全体としての問題点や，システムの位置づけが不明瞭なままであること．
」「ビジネス全体としてなど．
これらの問題を解決するために，提案する環境での問題点や，システムの位置づけが不明瞭なままであは，ユーザ側が要求を自身でまとめ，視覚的にまとめること．
」については，ユーザ企業の潜在的な要求や，らる環境を提供する．それにより，ベンダ企業へ要求システム化することにより効果が及ぶ範囲をユーザを伝わりやすくすることを助ける．また，ベンダ企業企業が自ら理解することにより防止する．具体的には，まとめられた要求を元手に開発者インタビューをは，BABOK に記載されている知識エリアのひとつ，おこなうことにより要求を漏れなくまとめ，要件定義

エンタープライズアナリシスでのタスクを使用する．

工程を円滑に進められる手助けをする．加えて現在のエンタープライズアナリシスで定義されているタスシステム化開発における要求は，競合他社の動向を視クは以下となる．

野に入れたものなど，要求が変更されることもある．

1. ビジネスニーズを定義する．

それらの変更された要求も要件定義で定められた要

ビジネスニーズは大きく分けて 2 種類あり，ビ求の範囲内で随時変更することができるようにし，シジネス機会とビジネス問題となる．ビジネス機会ステム化開発での要求管理も支援する．提供する環境（または問題）を明確にし，競合との差別化，理の概要を図 3 に示す．

想の製品・サービス（To Be）を明確にする．

2. 能力ギャップをアセスメントする．
理想の製品サービスを提供するために，組織の能力が備わっているかを診断する．

3. ソリューションアプローチを決定する．
ソリューションに対する方針を決めるタスク．

4. ソリューションスコープを定義する．
ソリューションにより実現される新しい能力を，ステークホルダーが理解できるように概念的に
図3

環境の概要説明する．そして，外部組織との依存関係も明確にする．

ユーザ企業は環境下で要求の入力を行う．その際，5. ビジネスケースを定義する．

その環境では要求を網羅的に入力できる支援を行う．

プロジェクトの正当性を記述し，ソリューション環境では，体系的にまとめた要求を可視化する．そこの投資効果を明確にし，スポンサーが投資の判断ができるようにする．

はベンダ企業に効果的に要求を伝えることが出来る．

これらのタスクをユーザ企業自身でおこなえる環

また，要件定義よりも下流工程で要求の変更があった境があることにより，ビジネスの問題点，ビジネスの際もスプレットシートを通すことによりユーザ企業，中でのシステムの位置づけ，要求の範囲を明確にする

ベンダ企業ともに視認することができるようにする．

ことができる．どのようにユーザ企業は自身でこれらの要求をまとめていくかについて記述する．対話形

4 実験

式を取り質問に対し，ユーザ企業が要求を記述して4. 1 実験内容

いくことで，網羅的に要求を手に入れる．この際，質提供する環境を使用することにより，以下のことを問は「ビジネス要求」，「ステークホルダー要求」，「ソリューション要求」，「移行要求」のいずれかを問うものとなっており，要求の引き出しが終わった次点で体系的に集約されるようにする．
「ビジネス要求」，「ステークホルダー要求」，「ソリューション要求」，「移行要求」の概要については以下に記述する．

• ビジネス要求
ゴール，目標，ニーズなど組織のハイレベルな要求を記述する．

• ステークホルダー要求
特定ステークホルダーのニーズを記述したもの．

検証する．

• ビジネスの中でのシステムの位置付けを明確にすることが出来るか• 要求を体系的にまとめることができ効果的に可視化することができるか• 要求の範囲を定義できるか• 要求変更があった際，それが定められた要求の範囲内かどうかを判断できるかどうか
題材は簡単なシステム化プロジェクトの上流工程とし，IT の知識が浅い人物を試験者とする．評価基準
はシステム開発を正確に行える程度のものとする．

ビジネス要求とソリューション要求の橋渡しをする．

• ソリューション要求

4. 2 実験の手法提供する環境をテスターに実際に使ってもらい，そビジネス要求とステークホルダー要求を満たすの結果として出来た要件定義を分析する．また，環境ソリューションの特性を記述したもの．の使い勝手についてもテスターにアンケートを実施– 機能要求し評価する．テスターについては要件定義をしたこと

ソリューションが管理する振る舞いと情報をがない人物に絞る．これはユーザ企業の IT に精通し記述する．ていない人からでも網羅的に要求を引き出すことを– 非機能要求

でき，まとめられた要求を視覚的に正確に認知できるソリューションの振る舞いや機能とは直接関かの検証をするためである．

係ない条件．

• 移行要求企業の現状から望ましい将来像へのスムーズな移行に必要なもの．

5 考察と今後の課題
研究を進めていく上で，要求の取得の仕方について多くの手法があることが明らかになった．それらの要これらをスプレットシートなどの従来の UML のよう求を引き出すための研究の中で効果的な手法をより取なモデル形式とは違って表現で可視化する．理由としり入れることにより，より効果的な要求の引き出し方て，ユーザ企業の人材の中には IT に精通しておらず，を考え出す．また，要件定義工程においての問題点をモデル形式の表記を理解できていない人もいるためでいくつかの項目に絞って，研究を進めてきた．しかし，ある．これは，「要件定義においてユーザ企業がリード要件定義が失敗してしまう原因はほかにも存在する．

できない．
」ため，一般的な可視化の方法をとる．こそれらは何に起因する問題なのかを根本的な部分からのように要求を可視化することにより，ユーザ企業分析し，それらについても解決できるように環境の幅を広げていく．環境の実験方法についてもより定量的アプローチを取る必要がある．また，環境の品質を図に結果を見ることができる方法を考える必要がある．

るための実験内容や実験方法についてもより定量的実験の評価基準をどのように設定するかを考える．に結果を見ることが出来るよう改善する必要がある．

6 まとめ

参 考 文 献要件定義工程を円滑に進めるために，ユーザ企業が[1] 清水千博，川添真智子，銅谷克樹:「やさしくわかるBABOK」, 株式会社秀和システム, 2011.
[2] 要 求 開 発 ア ラ イ ア ン ス: 「Requirement Development Alliance : 要 求 開 発 ア ラ イ ア ン ス 」,
http//www.openthology.org/ , 2013 年 7 月 18 日アクセス.
[3] リ コ ー IT ソ リュー ション ズ 株 式 会 社: 「 要求 開 発 超 入 門 / Vol.6 要 求 開 発 と は 何 か 」,
http//www.jrits.co.jp/tech/openthology/vol06.html,
2013 年 7 月 18 日アクセス.
[4] TechTargetJapan:「ベンダー依存のシス
テ ム 開 発 か ら 脱 却 す る 7 つ の ポ イ ン ト 」,
http//techtarget.itmedia.co.jp/tt/news/0906/04/news02.html,
2013 年 7 月 18 日アクセス.

自身で要求を引き出し，体系的にまとめ，可視化出来る環境の製作を進めている．対話形式の環境下では，IT に精通していないユーザ企業の人でも，ビジネスに基づいた要求を引き出すことが出来，要求の範囲のの定義や，体系的に集約したもの可視化までできるよう支援する．研究の中で要件定義の問題点をまとめたが，ほかにもどのような問題があるのかを再考して，要件定義工程の成功精度をより高いものになるような