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

開発要求の精度向上のための提案依頼書の作成支援
若林 沙弥

伊藤 恵

現在，短期間のプロジェクトが増えており，手戻りや遅延なくプロジェクトを完了させる必要がある．そのため，要求を的確に反映し，確実性の高い要求事項が書かれた提案依頼書が重要である．このような提案依頼書を書かなければ要求が曖昧になり，情報伝達ミスが起こることで手戻りや遅延が発生してしまう．提案依頼書には業界標準的な書式はなく，作りたいシステムの概要を正しく伝えるための記述方法が明確になっていない．そのため書籍等を参考に，自己判断で記述内容を決める必要がある．現状では良い提案依頼書の書き方が十分に確立されていない．本研究では，提案依頼書をターゲットとし，システム開発における発注者の要求を的確に反映し，要求事項の確実性を高めるために，提案依頼書の作成支援を行う．提案依頼書の作成支援方法として，記述内容を誘導する方法の提唱と評価項目の作成を新たに行う．被験者を募り，提唱した方法と従来の方法で提案依頼書を書いて，評価をして比較することで開発要求の精度向上を図る [2]．

Projects of the short term increase at present. In order to let projects complete without rework and delays, it is important that request for proposals (RFP) are written by reflecting precisely requirements andenhancing certainly of requirements. When we do not write such RFP, requirements are ambiguous. Also,
when communication errors happen, rework and delays occur. There are not the industry-wide standard-likeformat for RFP. It is not clear description contents for telling exactly an outline of the system which wewant to make. Therefore, we need to decide description contents using reference books. The good makingof RFP is not suﬃciently established at present. In this study, our research target is the RFP and support
the making of RFP. We aim to reflect precisely requirements from the client and enhance certainly of requirements in system development. We propose a method for making support of RFP and make the new
evaluation points for RFP. To evaluate the method, we compare the method with the other methods byexperiments. In the experiments, subjects write RFP using each for method.

がら自力で作成するか，コンサルティング会社に相1 はじめに談をして業務分析や提案依頼書の作成を行っていた．

1. 1 背景

しかし実際に情報システムの開発案件でユーザー自提案依頼書は，システム開発の上流工程以前 (超上身が提案依頼書を書くケースは実に少ない．要求を流工程) でユーザー企業がベンダー企業に要求の概要的確に反映し，確実性の高い要求事項が書かれた提を伝えるために使われている．要求を的確に反映し，案依頼書を書くために，記述するべき内容がわから確実性の高い要求事項が書かれた提案依頼書を作成ないことが原因と考えられる．また，提案依頼書の書することは，ユーザー企業側とベンダー企業側の両者き方の参考となる書籍や資料は少なく，理解するのもにメリットがあり，後の要件定義の段階をスムーズに膨大な知識を必要とするため提案依頼書を的確に書行うことができるようになっている [4]．従来は，提ける人が少ない．また，提案依頼書は業界標準的な案依頼書の作成方法が書かれた書籍等を参考にしな書式が無く，書き方に制限がないため参考にするものがわかりづらいと非常に書きづらいと感じてしまう．

Making Support of Request for Proposals for Precision Improvement of the Development Requirements.
Saya Wakabayashi
Kei Ito, 公立はこだて未来大学,Future University Hakodate.

現状では，理解しやすいサンプルが少なく，具体的なイメージが沸かなかったり，コストがかかるためにコンサルティング会社に相談できない企業もあるため，

提案依頼書の作成方法を見直すべきとされている [2]．

2. 2 提案依頼書
提案依頼書とはユーザー企業がベンダー企業に対

1. 2 研究目的して提案依頼を文書にて提示したものをいう．主に日提案依頼書をターゲットとし，システム開発におけ本でのシステムの受注開発の場などで使われている．

る発注者の要求を的確に反映し，要求事項の確実性を提案依頼書は標準的な書式はなく書き方に制限はな高めるために，提案依頼書の作成支援を行う. 本研究

いが，実現させたいシステムの概要が記述できるよでは，提案依頼書作成支援方法として，記述内容を誘うに作成することが望ましい．提案依頼書には概要，導する方法の提唱と評価項目の作成により開発要求予算，納期，要求，特記事項を記述することが一般の精度向上を図る．

的である．概要には，目的・趣旨，対象の範囲を記述し，目的・趣旨の項目では企業の概要やビジョン，提2 関連研究案にいたった背景や提案の目的を現状のシステムや現

2. 1 要求工学

状の問題点と結びつけて記述する．対象の範囲は対象

要求とは「必要である, 当然であるとして強く求め業務の範囲などを記述する．要求はシステムに必須なること」とされているがソフトウェア要求はそのソフ機能，根幹ではないが実現させたい機能を記述する．

トウェアのユーザーがソフトウェアに当然備わっていユーザー企業側とベンダー企業側の両者にメリットがるべきと考えた機能や性能などを意味している．要求あり，ユーザー企業側には提案依頼書を渡すことで良

工学はソフトウェア工学の一分野という位置づけであい提案を受ける可能性が高くなったり，実現させたいる．ソフトウェア工学は「高品質高機能なソフトウェことが把握できる．提案が評価しやすくなるなどの効アを効率よく作成したり，利用するための方法論の集果がある．また，ベンダー企業側には発注者が望んで大成」である．ソフトウェア工学の初期の成果の一ついることが伝わる，提案に必要な情報が把握できるなに，ソフトウェアライフサイクルモデルの提案があどの効果があり，高いレベルで要求が提案依頼に表現る．具体的にソフトウェアの開発や運用，管理がどのされている場合に要件定義の段階をスムーズに行うようなプロセスで進んでいくかをモデル化したものことができるようになっている [4]．

である．ソフトウェアライフサイクルモデルでは要求定義が一番最初の段階となる．要求定義はソフトウェ

2. 3 BABOK

ア利用者の抱える問題やニーズを正確に定義する段企業の経営課題を解決し，企業競争力を高めるた階である．ソフトウェアライフサイクルでは各プロセめに戦略や業務上の課題を整理し，目的達成に役ス毎に成果物としてドキュメントを作成し次の段階立つソリューションを推進することを「ビジネスアに繋げるのである．よって要求定義の段階を徹底させナリシス」という．またビジネスアナリシスを行うることが大切なのである．ソフトウェア要求定義は，人をビジネスアナリストという．BABOK(Business

ソフトウェア開発の一番最初の段階に位置づけられAnalysis Body of Knowledge) とはビジネスアナリるが，開発側だけではなく利用者が関わってくるためシスに必要な知識を体系化したものである．BABOKに難しさが生じる．要求定義の難しさとして，要求獲を策定しているのは，カナダのトロントに本部がある

得や要求分析，要求言語と仕様，プロトタイピング，IIBA(International Institute of Business Analysis)

要求仕様と要求定義などの分野において難しさが生である．BABOK には 7 つの知識領域と知識領域にじる．要求定義をしっかり行わなければ利用者にとっ対応するタスクとテクニックがあり，ビジネスアナリて使い物にならないシステムができあがってしまい，ストは知識領域ごとに理解するべき知識を確認し，ビ時間もコストも無駄になってしまうためソフトウェアジネスアナリシスに関する作業を行う．BABOK を要求をきちんとまとめられるようになることが開発ソフトウェア開発の場面で活用することで，課題が明のキーとなる [3]．

確になり，課題解決への要求漏れの改善を助ける．以下に７つの知識領域に関して記述する [1]．

• ビジネスアナリシスの計画とモニタリング

要求漏れを発見するのみならず BABOK の導入が促進されることを目的とした．実験内容はシナリオと– プロジェクトにかかわるステークホルダー

過去に作成された提案依頼書を読んでから，30 分間を把握し，役割を明確にする．また，情報伝で提案依頼書を作成して，その後にチェックシートで達の方法や要求変更時の承認プロセスやルー提案依頼書を評価するものであり，複数の被験者によル決めを行う．

る相互評価を行っている．実験からチェックシートの• 引き出し– ステークホルダーからビジネス上の課題や要望を引き出す．

• エンタープライズアナリシス

35 項目中 20 項目がインタビューを通して判断しづらいことが確認された．判断しづらい原因は項目に出てくる言葉の意味がわからない，言葉が何を示しているのかが曖昧である項目があるためであった [6]．

– ビジネス上の課題や解決策を導き出す．
• 要求アナリシス– 要求を体系化してシステムの要件を整理し，要求の優先順位を決める．

• ソリューションのアセスメントと妥当性

3 作成支援方法
本研究では提案依頼書の作成支援を行う．作成支援の方法として作成方法の提唱と評価項目の作成の 2つを行うが，本稿では作成方法の提唱のみ行う．

– 提案されたソリューションが課題を達成できるものかを評価する．

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

3. 1 誘導シートを用いた作成方法
本研究では誘導シートを作成して，提案依頼書の作– 要求の状態を管理し，要求変更時の影響力成支援を行う．2.4 章で説明した BABOK でチェックを明確にする．また，書面と口頭による要求シートを作成して評価する実験で被験者が判断しづ伝達方法を再度見直す．

らいと感じた項目が多かったことから，判断しづらい• 基礎コンピテンシと感じた項目に対してチェックシートによる評価項目– ビジネスアナリシスを円滑にすすめるためとしてではなく，提案依頼書の中で質問形式で記入での 34 種のテクニックが掲載されている．

きる欄を設けて提案依頼書が項目を満たせるように誘導していく方法で精度をあげたほうが良いのでは

2. 4 BABOK を活用したチェックシートによるRFP 評価の試みないかと考えたことから誘導シート作成にいたった．
付録 A の図 2 から図 7 までは，本研究で作成した誘

斉藤は [5]，受託開発において IT に精通していない導シートである．これは誘導シートに直接書き込むこユーザー企業が多いことや，RFP(提案依頼書) 作成とで提案依頼書が完成するシートであり，提案依頼書自体をベンダー企業に作成依頼する現状から，要求の必須項目の他に質問形式による誘導や記入できる漏れが発生することでユーザーが意図しないシステ欄を作る．従来は提案依頼書をすべて記述してから評ム開発が行われやすいことから，要求漏れのないシ価するという方法をとったが，誘導シートを用いた提ステム開発が実現できるようにするために提案依頼

案依頼書作成では一部を記述して評価をするという書における評価項目作成を BABOK を使用して行っことを繰り返しながら作成できるため，要求漏れや記た．BABOK の 7 つの知識領域は，課題や要求分析載事項の不備などが減る可能性が期待できる．に役に立つが，活用が難しいとされており，活用例が少ない．そこで斉藤は，BABOK をシステム開発の4 予備実験

現場で活用するために提案依頼書の評価に使用できる

4. 1 実験目的のではないかと考えた．提案依頼書のチェックシート

提案依頼書作成において誘導シートを用いた作成を作成して，実験を通して有効性を確かめることで，が有効であるかを確かめる．また，誘導シートの改善

点を考察し，実験後に更なる改善をして本実験に役立できるように提案依頼書を書くこととした．実際にてる．

ユーザー企業が提案依頼書を書く際は，自社業務をよく理解している状態で提案依頼書を書くため，学4. 2 被験者

生が運営側の動きを想像しやすい題材を採用するべ

被験者は公立はこだて未来大学 4 年生から 2 名採きと考えて題材を決めた．そして，サンプルに記載し用した．被験者は過去にチームでシステム開発を行った提案依頼書は発表会オンライン評価システムとし，た経験がある者か，ソフトウェア開発の知識があり，PBL 等の発表会で参加者によるオンライン評価とそシステムの概要や要求を考えられるスキルを持っていの集計結果および発表者へフィードバックするシステる者である．

ムを提案する内容とした．サンプルは発表者を評価するというものなので，サンプルから参考になる部分が4. 3 手順多いと考えたので，この題材を採用した．

予備実験手順を以下に示す．

1. 題材の説明

5 結果と考察2. 提案依頼書の作成

5. 1 結果

3. 誘導シートによる提案依頼書の作成

被験者 2 人を被験者 1 と 2 と表現する．被験者に

4. 相互評価

予備実験の題材を見せた後，誘導されていない状態で5. アンケート

提案依頼書を書いた結果，被験者 1 は 30 分，被験者各手順の具体的な内容は以下の通りである．題材の説

2 は 25 分ほどかかって仕上げた. また，誘導された

明では実際に提案依頼書に書くシステムの内容の題状態では被験者 1 は 60 分，被験者 2 は 50 分かかっ材が書かれた紙を用意した．詳しい題材の内容につて仕上げた．誘導されていない状態で書いた内容を見いては 4.4 章で説明する．次に提案依頼書がシステムると，被験者 1 は概要の項目で目的と背景の項目に分開発でシステムを提案する際に要求の概要を伝えるけて記述をしていたが，被験者 2 は概要の項目では項ものであることを被験者に伝えて，概要 (提案依頼の目を分けずに 1 つの文章で書き上げていた．また要求目的・背景)，システムの対象の範囲，要求についてに関する記述で被験者 1 と 2 はレビューを投稿するの記述 (求める機能) を記述した．書き終えた後に誘ための機能を記述するというよりも，「レビューを投稿導シートと提案依頼書のサンプルを渡して提案依頼する」で 1 つの機能としており，とてもシンプルな提書を再度書いた．その後被験者同士で 2 枚の提案依案依頼書を書いた．しかしサンプルを見て誘導シート頼書をお互いにチェックシートで評価した．チェックを使って書いた結果，内容が細かくなり，自分が伝えシートは 2.4 章の研究で使われたものであり，評価項たいことのほかに相手が知りたいことが書けていた．

目の新たな作成をするために改善点を見つけるために例えば，自分が伝えたいことは現状のシステムで解決今回使用した．そして最後にアンケートを実施した．

して欲しい問題点等である．相手が知りたいことは，また，予備実験中は音声の録音をしており，予備実験機能に対する要件や機能がなかった場合に起こる問題の会話の中で聞いた質問や感想をまとめた．

等である．表 1 は書いた提案依頼書がチェックシートを満たすことができた項目数をまとめたものである．

4. 4 題材

最終的に相互で評価した結果，表 1 より，誘導シート

予備実験で提案依頼書に書く題材は研究室書籍情で書いた時の方が満たすことができた項目数が多く，報管理システムとした．研究室にある書籍の情報を誘導シートで書いたほうが提案依頼書の内容の確実研究室メンバーで登録して，貸し出しの管理ができ性が高くなることがわかった．また，チェックシートるシステムがすでに存在すると想定して，新しく書の項目内容と詳細な結果を表 2 として付録 A に載せ

籍情報を交換する場所を作るためにレビューが投稿た．表 2 は被験者 1 と被験者 2 が評価項目に対して，「できた」，「できない」，「できたかどうか判断できな悩んだと回答した．また改善したほうがいい点としてい」，「項目の意味がわからない」の 4 つから評価した

被験者 1 は紙であるとコピー・アンド・ペーストがで結果である．項目の意味がわからないものは少数できず，同じことを書かなければならないので電子化しあったが，できたかどうか判断できないものは誘導さて欲しいと回答した．一方被験者 2 は提案依頼書のれていない状態で書いた提案依頼書に多かった．

中に予算やプロジェクトの納期をいれるべきではないかと指摘した．全体的に話をしているうえで，誘導

表1

チェックシートで満たせた項目数

被験者 1

被験者 2

普通版

17/35 項目

7/35 項目誘導シート

26/35 項目

22/35 項目

シートがあったほうが書きやすいとの意見が多かった
が，チェックシートの内容が今回の実験には合っていなかったという意見があった．例えば，表 2 より，「すべての要求を主観を廃して客観的に見ることができるか」という項目に対して，何が主観で何が客観なのかよくわからないなど，判断しにくい項目があったからである．また，自己評価と相互評価に適している項目が混ざっており，判断できない項目があったという意見があった．例えば，表 2 より，「要求に漏れはないか」という項目に対して，漏れているかどうかは本人にしかわからないという意見や，「誤字・脱字はチェックしたか」という項目に対して，本人にしかチェックしたかどうかはわからないという意見があった．

5. 3 考察
今回の実験では，提案依頼書の作成において誘導図1

実験の様子シートが有効であることがアンケートやチェックシートでの判断でできたが，チェックシートでは判断しづらい項目に対して誘導しているため，チェックシート

5. 2 アンケート結果で誘導シートが書けているかを判断するというやり実験後に被験者 2 名にアンケートを行った結果，誘方を少し変えたほうがいいと感じた．アンケートで導シートがあったほうが書きやすいかという問いには誘導シートが良いという評価をもらったが，より有対して 2 名とも書きやすかったと回答した．被験者

効性を評価するために評価項目が必要である．また，

1 は誘導シートを使ってみてよかった点として，書いチェックシートの項目に対して，自己評価か相互評価たことがなくてもある程度書けて書きやすかった・自か分けて整理するべきである．今回は，少数の被験者分の頭の中身が整理できたと回答しており，被験者 2で実験を行い，誘導シートによる提案依頼書作成は有は自分が伝えたいことではなく相手が知りたいと考効活用できる結果となったが，本実験ではもっと人数えているんだろうと思うことが質問事項からわかり，を増やして実験を行う予定である．

詳しく書けたと回答した．逆に誘導シートの設問内容がわからなかった・書きづらいと感じた点を聞くと，

5. 4 本実験の計画

被験者 1 は見本がないと書けないと思ったので見本

本実験では予備実験と同様の手順で実験を行うが，がなければ漠然としたものしか書けない気がすると予備実験で改善するべきと感じた箇所を変更して実回答した．また被験者 2 は機能対要件を記述する箇験を行う．変更する箇所は以下である．

所で要件が空白の部分があり，本当にそれでいいのか• 提案依頼書の書き方の説明を加える．

• 誘導シートを電子化させてコピー・アンド・ペーストができるようにする．

• 相互評価ではなく自己評価に変える．
• 使用するチェックシートを自己評価用に変える．
• アンケートの内容を増やす．
• 人数を増やして実験を行う．

6 まとめ
提案依頼書は，システム開発の上流工程以前でユーザー企業がベンダー企業に要求の概要を伝えるために使われており，手戻りや遅延なくプロジェクトを完了させるためには，要求が的確に反映し，確実性の高い要求事項が書かれた提案依頼書が重要である．本
研究では，提案依頼書の作成支援を行うために，記述内容を誘導する方法の提唱と評価項目の作成を新たに行うことで開発要求の精度向上を図ることとした．
誘導する方法として誘導シートを作成し，提案依頼書の必須項目のほかに質問形式による誘導や記入できる欄を作ることで要求漏れや記載事項の不備などが減る可能性を期待した．そして予備実験を行い，誘導シートによる提案依頼書作成は有効活用できる結果となった．今回は，少数の被験者で実験を行い，誘導シートによる提案依頼書作成は有効活用できる結果となったが，本実験ではもっと人数を増やして実験を行う予定である．

参 考 文 献[1] 広川智理: BABOK 超入門, 日経コンピュータ.
[2] 永井昭弘: RFP ＆提案書完全マニュアル, 日経 BP 社.
[3] 大西淳, 郷健太郎: 要求工学, 共立出版株式会社.
[4] 佐川博樹: 図解入門よくわかる最新 RFP と提案書の基本と作成方法:株式会社, 秀和システム.
[5] 斉 藤 篤 史 :BABOK を 活 用 し た チェ ック
シ ー ト に よ る RFP 評 価 の 試 み, 日 本 ソ
フ ト ウェア 科 学 会 第 31 回 大 会, https://librepos.fun.ac.jp/dspace/bitstream/10445/7760/1/ippan81.pdf.
[6] 斉藤篤史: BABOK を活用したチェックシートによるRFP 評価の試み, 2014 年度公立はこだて未来大学卒業
論文.

A 付録: 実験に使用した資料

図2

誘導シート 1 ページ目

図3

誘導シート 2，3 ページ目

図4

誘導シート 4，5 ページ目

図5

誘導シート 6，7 ページ目

図6

誘導シート 8，9 ページ目

図7

誘導シート 10 ページ目

表2

チェックシートの評価結果

普通版

誘導版

要求の内容は明確か△○○○要求の発生源は明確になっているか○×○○

要求の背景 (根本原因) は明確になっているか○×○○

1 つの要求 (記述) に複数の要求が含まれていないか？△？○

要求に漏れはないか△×△△

図や表を使って表現を理解しやすくできる文章はないか

×○

○○

××

○×

要求のグループ間，要求間に親子関係や兄弟関係はあるか

××△○

なぜその要求が必要なのか，理由を明確に説明できるか○×○○

その要求内容にかかわるステークホルダーは誰か分かっているか○△○○

他の要求と比較して，要求内容に矛盾や対立構造がないか△○○○要求をグループ化できないか，できそうであればグループ化したか

その要求は本当に実現するシステムに必要な要求か，その妥当性はあるか△×○△

関連する他の業務や情報システムについても調べたか

××○○

機能要求だけでなく非機能要求も整理されているか

××

××

×△

△×

すべての要求を主観を廃して客観的に見ることができるか△△△△要求が仮定 (思い込み) ではなく事実に基づいているか×△○△

要求に優先度がつけられているか××○○

システム化の背景が記されているか○△○○

正しくわかりやすい用語や表記で説明しているか

○○

○○

○○

○○

短期間で全体像を把握できる適切な要約文をつけているか○×○×

相手が正しく理解していることを確認するチェックポイントを入れているか

××

×○

××

○○

話題の関係性が破綻していないか (ロジックが破綻していないか)○○○○

文章中に主語，述語が抜け落ちてないか○×○×

誤字・脱字がないかチェックしたか△？

△？

結論や目的を最初に伝えているか○×○○

文章の表現に一貫性があるか

○△

○○

○△

○○

あいまいな表現はないか○×○△

二重否定など，わかりにくい表現をしてないか○○○○

1 つの文章が長すぎないか，目安は最長で 120 文字○×○△必要に応じて，図や絵で内容を補足しているか

××

△×

○△

○○

例外処理を見逃していないか

相手が理解しやすい用語を使って説明しているか

適切な例を用いて，説明しているか

文章内の情報の粒度 (詳細さ) のバランスがとれているか修正が容易な文章構造になっているか○：「できた」もしくは「はい」，×：「できなかった」
もしくは「いいえ」，△：○か×かどうかわからない，？
：項目の意味がわからない
左側の記号が被験者 1，右側の記号が被験者 2 の評価結果を表している．