ソフトウェア開発

ソフトウェア開発技術

要件定義

超上流工程

特集

企画・要件定義プロセスの改善

ソフトウェア開発においては，その最初のプロセスとして，企画・要件定

いいむら

ゆかこ義プロセスがあります．このプロセスでは，関係するステークホルダ要求を飯村 結香子整理し，実現するソフトウェアへの要件を明確化する必要があります．しかこばやし

し，実際には多くの課題があり，その改善が要望されています．本稿では，

小林 伸幸

や ま だ

せ つ お/山田 節夫

のぶゆき

企画・要件定義に関する実務・研究の動向を踏まえ，私たちが検討を進めている企画・要件定義プロセスの改善に関する活動を紹介します．

NTTソフトウェアイノベーションセンタ

用者が何を要求しているのかについて，や，利用者側企業の経営者を含みま漏れや誤解があるにもかかわらずソフす．開発者側も同じく，経営者，プトウェア開発が進められた場合には，ロジェクトマネージャ，ソフトウェア開による出来上がるソフトウェアはユーザの要発者などを含みます．それぞれのスと，ソフトウェア開発プロジェクトで求に沿うものにはなり得ません．そのテークホルダの立場が異なるため，相目標QCD〔Quality（品質），Costため発見されるまでのすべての作業が反する利害を持つ場合があります．こ（コスト），Delivery（納期）〕の達成やり直しとなります．その際のコストのため，異なるステークホルダから矛率は徐々に改善が進んでいますが，まは，誤りの発見が遅れるほど急激に増盾する要求が出る場合もあり，これらだまだ十分とはいえない状況です．

加することを複数の研究が指摘していを調整しながら，開発するソフトウェ

企画・要件定義プロセスのソフト
ウェア開発プロジェクトへの影響（1）

情報処理推進機構の調査（2）ます．ある研究によれば，運用段階アに関する合意を形成していく必要がのアプローチとしてソフトウェア開発プになって要求の誤りが発見された場合あります．そのためステークホルダの数ロジェクトにおいて「何をソフトウェアには，企画・要件定義プロセスで発見が増えるとその調整の困難さは上昇しで実現するか」「どのくらいの投資対効された場合と比較して，68〜110倍以ます．

果が得られるか」といったことを決定上の修正コストが必要になると報告し（2） 変化する要求への対応する「企画・要件定義」プロセスの改ています（表）．

企画・要件定義プロセスでは，ス私たちは，この状況を改善するため善に取り組んでいます．
同調査では，QCD目標不達成の原因についても調査をしています．それ

企画・要件定義プロセスの難しさ
企画・要件定義プロセスにはどのよ

テークホルダから出された要求を整理し，ソフトウェアが実現する機能や性能を定め合意を取ります．しかし，実によると，要件定義以前に問題があっうな難しさがあるのでしょうか．

際には，要求に抜け漏れがある，あるたためととらえているプロジェクトが，（1） ステークホルダの多様性

いは，その後の環境の変化により要求開発者の視点では 35％以上あり，利ステークホルダとは，ソフトウェア開が変化するなど，実現する機能や性能用者の視点では約9 0 ％にのぼります．

発プロジェクトにかかわったり，プロを変更する必要が出てくる場合がありつまり多くのプロジェクト関係者が企ジェクトから影響を受けたりする人と画・要件定義プロセスにおける問題をグループを指します．一般的なソフト認識しているといえます．

ウェア開発プロジェクトのステークホル

企画・要件定義プロセス

１倍

また，一般的に企画・要件定義プ

ダは，大きくソフトウェアの利用者側，設計２〜３倍

ロセスにおける問題は，利用者が本当開発者側に分けられます．利用者側に製造５〜10倍に必要としていたものと，開発者が実は直接ソフトウェアを利用するエンドテスト

８〜20倍

運用

68〜110倍

現したものの違いとして現れます．利

ユーザだけでなく，情報システム部門

表 要求の誤りを修正するための相対コスト

NTT技術ジャーナル 2013.1015ソフトウェア開発技術ます．その変更に対応しようとした結このように文書化された要求の曖昧されています．次に，要求工学の知識果，スケジュールの遅延や品質の劣化さにより，ソフトウェアで実現される体系であるREBOK（3），＊ ，要求工学につながる場合があります．また，追機能に対する期待がステークホルダ間に関する標準規格ISO29148（4）および加された要求がすでに出されていた要で異なるとソフトウェア開発プロジェ

共通フレーム2013（5）について解説し求と矛盾する場合には，既存要求の見クトの手戻りが発生します．例えば，ます．

直しも必要になり，関係するステーク開発者は文書化された要求に従ったに■REBOKホルダとの調整作業など，多くの影響もかかわらず内容が曖昧だったために，一般社団法人情報サービス産業協が発生します．

開発者が利用者の意図とは違う理解を会（JISA）によりREBOKの第一版（3） 文書化された要求の曖昧さしてソフトウェア開発を進めた場合にが2011年に公開されました．REBOK

企画・要件定義の本質がステークホは，ソフトウェアの設計からそれ以降は図１に示すように要求工学，つまりルダ間の合意形成であることを考えるの手順をやり直す必要があります．

情報ソフトウェアやコンピュータを組と，要求の文書化は非常に重要であるといえます．しかし，要求の記述に曖昧さがあると，書かれた要求を，複数

企画・要件定義プロセスに関する標準，知識体系
近年，企画・要件定義プロセスへり，何通りにも解釈できるため読み手の関心の高まりを受け，関連する標準が混乱したりします．

類・ガイドラインや知識体系が公開要求の源泉︵ステーク
ホルダ・
文書など︶

＊ 要求工学知識体系REBOKは，JISAの登録商標です（商標登録 第９類 登録第5458370号）
．

要求開発
獲得要求

④要求分析

分析要求

⑤要求仕様化

要求仕様書

エンタープライズ分析

基礎知識

NTT技術ジャーナル 2013.10⑥要求の検証・妥当性の確認評価

プロダクト分析②要求工学プロセス①要求工学の基礎

図１

16

理・体系化したものです．REBOKは⑦要求の計画と管理

③要求獲得

REBOK
拡張知識
カテゴリ

なる要求の獲得，分析，仕様化，妥当性の確認などのプロセス，知識を整の読み手ごとに異なる意味に理解した

REBOK 共通知識
カテゴリ

み込んだ製品の開発をする際に必要と実践
知識

REBOKのプロセス⑧実践の考慮点

シス
テム
構築特集

ソフトウェアの利用者と開発者が協調を包括的に規定しています．2007年

ア開発プロジェクトに対しての共通のした要求開発を実践することをねらいには，事業や業務検討の始まりから要理解を持つ必要があります．としており，その特徴として，利用件定義までのプロセスの中に問題の本

そこで，NTT研究所では知識体系者・開発者を問わない共通の知識体質があるという考えを取り入れ，運用や各種国際標準等をベースとしながら，系であること，要求アナリストに加えプロセスや利用者プロセスの強化が行

企画・要件定義で実施すべき作業手て，エンドユーザ，経営者などの要求われた「共通フレーム2007」が発行

順，成果物様式の定型化，標準的な開発に関与するステークホルダが必要されました．さらに2013年に，要件定役割分担を明確化する企画・要件定に応じて取得すべき範囲と水準を整義プロセスの強化や運用・サービスプ義プロセスを検討しています．

理した知識体系であること，が挙げらロセスの強化をはじめとした改定が加また先に述べたように企画・要件れます．

えられ，「共通フレーム2013」として定義プロセスの中で，環境の変化やス■ISO29148

発行されました．

テークホルダ間での調整の結果，要求ISO29148は，2011年12月に公開された要求工学に関する国際標準規格です．ISO29148では，ソフトウェア企画・要件定義に関する研究所での取り組みが変化していきます．要求の変化がすでにステークホルダ間で合意をとっていた実現機能やスケジュールの変更をライフサイクルを定義するISO12207，NTT研究所では，企画・要件定義必要とする場合もあります．このため，ソフトウェアライフサイクルを定義するに対し，以下の検討を行っています．

要求の変化内容の管理，その要求のISO15288の要件定義に関するプロセ■企画・要件定義プロセスの検討

変化に対応するための影響分析などを行うための要求管理プロセスも併せてス群を詳細化しています．この国際標

企画・要件定義プロセスは多くのス

準規格では，要件定義の作業を進めテークホルダがかかわります．ステーク

るうえでのガイド事項，ならびに要件ホルダ間でコミュニケーションを円滑検討しているこれらのプロセスの活として記載すべき情報項目を規定してに行うには，どのような順序で，何を用により複数のステークホルダ間で共います．図２に示すようにこの国際標する必要があり，そのために何をイン通の認識を持ってソフトウェア開発プ

準規格は，ソフトウェアといった視点プット，アウトプットすべきか，自分ロジェクトを進めることに貢献できるのみならず，その根底にある業務，事が何を果たすべきかといったソフトウェと考えています．

検討しています．

業，またそれらの運用視点も含んだものとなっています．

■共通フレーム2013
共通フレームは1994年に日本においてソフトウェア開発に関係する人々が同じ言葉で話すことで，お互いの認識のずれをなくすことを目的に作成され

外部環境
・市場動向
・法律と規制・法律に基づく負債
・企業の社会的責任
・技術基盤
・予備労働力・競合製品
・標準と仕様・公共的文化
・物理環境・自然環境

組織環境
・方針と手順・標準と仕様・ガイドライン
・ドメイン技術
・地域特性

ビジネス執行・プロセス
・制約
・方針と規則・モード
・品質
・ビジネス構造システム
ソフトウェア要求

ステークホルダ要求（ビジネス管理レベル）ました．「業務分析，業務設計，およびソフトウェアを中心としたソフトウェ

システム運用ステークホルダ要求（ビジネス執行レベル）

システム
要求

システム要素ソフトウェアシステム要素アの企画，要件定義，開発，運用，保守およびそれらにかかわる諸活動」

図２ISO29148を対象とし，必要な作業項目や役割等

NTT技術ジャーナル 2013.1017ソフトウェア開発技術■企画・要件定義プロセスで活用で（％）

きる手法，技法の検討

60

プロセスでは作業の手順や何をつくるべきかを定めていますが，例えば，要求を文書化する際にどのように記述す

23
20

10０

ためのノウハウやコツが存在します．
NTT研究所では，そういったノウハウやコツを集めた用例集の作成，整備も−20

期間

25シス
テム
試
験

18

れば曖昧さを減らすことができるのかなど，その作業をスムーズに実施する

コスト

3740

要求
件
定義−40６アー
キ
テク
チ
ャ
設計

単体試
験実装ソフ
トウ
ェ
ア
設
計

検討しています．

−９−12結合試験−９−12−９−12−46 −45■REBOK WGへの参画−60

図３REBOKの内容は，要求工学やソフある企業の取り組みによる改善例

トウェア工学の国際会議において発表やチュートリアルが実施され世界中の業のようなソフトウェア開発プロジェ研究者・実務者から注目を集めるようクトにおける改善を実現していきたいになってきており，REBOKの英語版と考えています．の発行の検討が進んでいます．また，その検討にあたっては，調査などをREBOKの活用支援の取り組みも実施

通じて開発の現状を把握するとともに，されています．NTT研究所では要求工実際の開発に携わる方たちの意見を取学 の 知 識 体 系 で あ る REBOK WGり入れながら，検討を進めていく必要（Working Group）に参画しており，があると考えています．

これらREBOKの普及活動に貢献して

■参考文献

います．

（1） IPA： 2012年度「ソフトウェア産業の実態把握に関する調査」， 2013.４．
（2） ウィーガーズ： 要求開発と要求管理−顧客の声を引き出すには， 日経BPソフトプレス，
2006．
（3） JISA： 要求工学知識体系REBOK， 近代科学社，2011．
（4） ISO/IEC JTC1/SC7: IEEE Std.29148：
2011,IEEE Systems and software engineering― Life cycle processes― Requirements
engineering， 2011．
（5） IPA： 共通フレーム2013， IPA，2013．
（6） M. Broy： Opportunities and Challenges in
Software Engineering for the Next Generation
Automotive， COMPSAC 2011，Munich，Germany，July 2011．

開発の現状を踏まえた検討
図３は，あるドイツの企業における取り組みによる改善報告です．要件定
義をはじめとして，上流工程をしっかりと実施することで，それ以降の工程のコストや期間が短縮され，全体では総開発コストが27％削減，開発期間（6）の36％短縮に成功しています ．
私たちも企画・要件定義プロセス，および企画・要件定義プロセス時に活用できる技法の検討を通して，上記企18

NTT技術ジャーナル 2013.10（左から）山田 節夫/ 飯村 結香子/
小林 伸幸
ソフトウェア開発プロジェクトの成功には企画・要件定義プロセスの改善が大きなインパクトを持ちます．私たちは実際の開発に携わる方たちの意見を伺いながら企画・要件定義プロセスの改善に取り組んでいきたいと考えています．

◆問い合わせ先NTTソフトウェアイノベーションセンタ
ソフトウェア開発技術プロジェクト
TEL 03-6712-9874
FAX 03-6712-8372
E-mail iimura.yukako lab.ntt.co.jp