4章システム設計へ橋渡しする要件定義４‐１要件定義とはＨ１０２０４２小林弘晃要求仕様書と要件定義書  要求仕様書とは  システム開発に対し「発注者が求めるもの」を記述したドキュメント  要件定義書とは  「発注者が求めるもの」を分析し、システム開発者の観点から要求をドキュメント化したもの要件定義作業の流れ要件定義の重要性  要件定義が不十分な場合、システム開発に及ぼす影響  実現できない場合のリスク  要件定義工程の長期化  システム開発の停滞  稼動後のトラブル実現できない場合のリスク  失敗事例  受託したシステムに倍以上の開発費がかかった  約束したシステムを開発できず、費用の回収ができないばかりか違約金を支払った要件定義工程の長期化  要求仕様書が未完成  記述内容が抽象的で具体的なことが分からない ↓ ＳＥがユーザと共同して相当部分を作成システム開発の停滞  あいまいな要求仕様のまま設計工程へ  いずれ後続の開発工程で問題が浮上 ↓ 問題解決が長引くと、開発費が予算超過稼動後のトラブル  稼動後、トラブル続きのシステムユーザから仕様変更が多い ↓ 仕様検討待ちや仕様変更対応が重なる ↓ 開発スケジュールの遅れ ↓ テスト不十分なまま稼動要求仕様の本質的な問題業務の詳細設計が開発と同時に平行して進む  ユーザ企業の要求仕様認識レベルが１００％に達していない  要求仕様のコミュニケーションギャップが避けられない  ゴールになるシステムそのものが変動する  仕様に対するユーザの認識とＳＥの理解  ユーザの認識レベル、ＳＥの理解レベルは図４‐３のように時系列的に推移する４‐２ＳＥが行う要件定義Ｈ１０２０４２小林弘晃要件定義の要件  達成していなければならない要件  システム設計に必要な情報が記述されている  あいまいな要件仕様、記述されていない要求仕様がない  システム設計に必要な情報を収集しドキュメント化する  ユーザとシステム要件について合意を形成する要件定義の作業内容 4-3 要求仕様書の分析 H102124 宮澤新一要求仕様書分析の手順 1．業務量の見通しを付ける 2．要求仕様の理解に努める 3．疑問点、不明点を抽出する業務量の見通しを付ける  要求仕様書を受け取ったら、まず、要求仕様書の分量と完成度を確認し、業務量の見通しをつける。  与えられた期限にできるものかどうか、また、分析手順を大まかにでも計画し、作業工数を見積もる。要求仕様の理解に努めるプロジェクトの全体像を把握する  最初は、ユーザ企業が目指しているシステム化の狙い、システム化する対象業務・対象範囲などのプロジェクトの全体像を把握する。要求仕様の理解に努める業務仕様の骨子をつかむ    業務仕様についても、仕様の詳細は後回しにし、始めは骨格をつかむようにする。中心となる業務を流れに沿って業務仕様を追いかける。要求仕様書が文章で書かれていたら、フローチャートを作成するなど図式化して理解に努める。要求仕様の理解に努める説明を受ける   ユーザ企業の窓口担当者に依頼して、最初に要求仕様書の内容を説明してもらう必要がある。要求仕様書に記載されていない計画段階の問題が見えてきたり、要求仕様書の手薄な部分を推測できるようになったりする。要求仕様の理解に努める資料を請求する  要求仕様書だけでは情報が不足しているので、分析に必要な資料を請求する。要求仕様の理解に努める＜請求する資料の例＞        会社パンフレット、組織表製品カタログ製造工程図、設計表・部品表現行システムのシステム設計書、操作マニュアル伝票・帳票類、管理資料現行業務の執務書・BR・業務フロー図、用語集システム設計開発標準、設計標準疑問点、不明点を抽出する  要求仕様書の記載事項は全体からすると一部で、記載されていない事項の方が多いつもりで取り組む必要がある。  記述内容のヌケやオチ、あいまいな記述、矛盾点、そうした要求仕様書の不備を確認して、疑問点、不明点を明確にし、それらの解決を図る。疑問点、不明点を抽出する疑問点、不明点を抽出する記入洩れを確認する  記入洩れを確認するひとつの方法は、要求仕様書の目次レベルで必要な項目が記載されているかどうかを確認すること。疑問点、不明点を抽出する疑問点、不明点を抽出する  記載がない場合は、以下の3つのケースが考えられる。 1．暗黙の前提になっている２．ユーザで検討を洩らしている３．指定なしで、開発者にフリーハンドを与える疑問点、不明点を抽出する  当事者にとって常識になっているような事項こそ最重要なことが含まれていることもあるので、要注意である。  要求仕様書に現状業務について記載がない場合は、現状業務を確認する必要がある。疑問点、不明点を抽出する 5W2Hで精査する＜5W2Hで機能要件を確認した例＞ Who(入力者は誰か) When(利用するタイミングはどういうときか) Where(利用する場所はどこか) What(どんな機能が必要か) Why(なぜこの機能を必要とするのか) How to(どういう使い方をするのか) How many(使用頻度はどれくらいか) 疑問点、不明点を抽出するあいまいな表現を具体化する    要求仕様書には、データ件数、発生頻度等が示されていないことがある。形容詞的な表現になっていたら、具体的な数字を聞き出して数量表現に改める必要がある。あいまいな表現があれば、個別に確認する必要がある。疑問点、不明点を抽出する＜あいまいな表現の例＞  数量・・・多い、少ない、大量、少量  サイズ・・・大きい、小さい  発生頻度・・・たいてい、ときどき、いつも  増減・・・増加した、減少した、多くなってきた疑問点、不明点を抽出するトラブルの起きやすい箇所を精査する 1．現行業務が変更になる部分  業務量が多い場合は、特に注意する。  運用面を含めて旧来の方法を確認する。  新しい業務方式に移行する方法や準備事項が考慮されているかを確認。  特に大きな変更が現場の利用者にどういう影響を与えるか考慮する。疑問点、不明点を抽出する 2．実現が難しい要件  一般に実現が難しい機能や開発に時間がかかる機能、特殊なノウハウや使用していないソフト利用技術が要求される場合は要チェック。  十分に要求事項を確認しておかないと、後々問題になることがある。疑問点、不明点を抽出する 3．他とのインターフェース  他システムとのインターフェース部分はトラブルが発生しやすいところである。  要求仕様書の中に、どういうインターフェースが記載されているかを調べる。  ひとつのシステムが処理するデータは、そのシステム内で入力するか、作り出すか、他のシステムからデータを受け取るかのいずれかになる。疑問点、不明点を抽出するその他のチェック項目    システム設計に落とし込むのに必要な事項が網羅されているかを確認する。各システム要件や記述内容の間で矛盾点があれば質問する。要求仕様が確定済みでも変更になることがあることを心得ておく。疑問点、不明点を抽出する疑問点や要調査事項を整理する   要求仕様書の分析過程で見つかった問題点や疑問点は気づいた時点でメモを残し、リストアップしておく。すぐに解決しない項目も多くなるはずですから、そうした事項は未確定項目としてリストアップしておく。疑問点、不明点を抽出する疑問点や要調査事項を整理する   重要なものは定期的に検討状況を確認し、必ず、要件定義の段階で片づけるようにする。要求仕様書を分析するだけで十分に理解できない点や、主要なシステム機能については、現地調査課題としてリストアップしておく。 4-4 現状調査 H102124 宮澤新一株式会社ディー・アート上野淳三・広田直俊・白井伸児[著] 「システム設計の考え方」現状調査の手順調査目的として以下のものがある。     システムを構築する目的や基本的な考え方を把握する主要な業務の処理フローを調査する要求仕様の疑問点を確認する業務の発生回数や所要時間などの基礎データを収集する現状調査の手順  調査目的に応じて、適切な調査対象(ヒアリング相手や監査する業務)を選定し、実施方法・手順、実施日時を決めて取りかかる必要がある。現状調査の手順  現地調査は何回も繰り返すことはできないので、計画を立てて事前に十分な準備を行なうことが欠かせない。現状調査の手順＜現地調査の基本的な手順＞ 1．現地調査を行なう目的を明確にする 2．この目的を実現するための方法手順を考える 3．現地調査を行う日時・場所の了解をとる 4．事前の準備を行い、実施する 5．結果をまとめ、問題点を整理するヒアリングヒアリングの準備(1)  限られた時間に聞きたい事項を確実にカバーできるようにするため、事前に質問項目をリストアップしておく。  正確な内容を引き出すためには、アンケートを併用することも有効である。ヒアリングヒアリングの準備(2)  あらかじめヒアリング相手に聴取内容を伝える。  ヒアリングを受ける相手にしても、事前に聴取内容がわかっていれば、前もって回答内容を考えておくこともできるし、説明用の資料を用意することもできる。ヒアリングヒアリングの準備(3)  質問したい項目がたくさんある相手でも、1回あたりの面談時間はあまり長くならないように設定する。  1時間程度がひとつの目安になる。  何回かに分けて実施する方が好都合である。ヒアリングヒアリングの実施  ヒアリングする対象者はプロジェクトチームのリーダーを始めとする主要メンバーや利用現場の関係者が該当する。ヒアリングヒアリングの方法(1)  初めて面談するときは、システムを構築する目的や基本的な考え方について自由に話してもらい、プロジェクトについて理解を深めると同時に、相手の考え方や価値観をつかむようにする。ヒアリングヒアリングの方法(2)  現状の業務について説明を受けるときは、その業務の関連事項も質問し、業務の背景にある情報を引き出すなど、せっかくの機会を活かす。ヒアリングヒアリングの方法(2) ＜質問の項目例＞      現行の業務について問題と感じていること現行の業務における例外事項、異例処理現行システムに対する評価、問題とかんじていること新システムに対して期待すること現行システムから新システムへの移行方法ヒアリングヒアリングの方法(3)  実務担当者をヒアリングする場合は、最初から質問リストに従って質問を始めると警戒されたりするので、担当している業務内容について説明してもらうぐらいから始めるのが適当。ヒアリングヒアリングの方法(4)  業務の詳細を確認するためには、用意したリストに沿って質問を行なうとともに、回答内容をもとに、より細かな質問を行い、詳しい情報を引き出す。ヒアリングヒアリングの方法(5)  ヒアリング時には、キーワードや数値をメモしておき、事後に記録を残す。ヒアリングの方法(6)  できるだけ、ヒアリングは書記役とペアを組んで行なう。その他の考慮事項(1)  ヒアリングは、プロジェクトにおけるキーパーソンを見つける重要な機会になる。  ヒアリングの相手は、今後、システム開発の過程で、相談を持ちかけたり、協力をお願いしたりする人達になるので、ヒアリングの機会を通じて、よい関係が作れるように心掛ける。その他の考慮事項(2)  一般にヒアリング先では、どういう専門家が来るのかと期待と懸念を抱いている。  顧客からSEの真価を問われる場面でもある。その他の考慮事項(3)  ヒアリングを行うまでには、その業界に関する市販本を読むとか、その会社の新入社員向けテキストを借用して目を通したりして、その業界の基本的な知識・業務知識を身につけるように心掛ける。その他の考慮事項(4)  一般に、質問リストに沿って質問している間は当たりさわりのない公式的な回答しか返ってこない。  いろいろな話を聞くには、ある程度相手に自由に話してもらう方がいい結果につながる。  肝心の質問を洩らしてしまうといけないので、会話をうまくリードする必要がある。現場での観察  システム化対象の業務の実施を把握するため、システムを利用する現場に足を運んで調査や観察を行い、業務の流れや作業内容を把握する。現場での観察 1．データの流れを追っていく工程分析 2．作業現場で作業状況の推移を観察する作業測定現場での観察  ひとつの業務プロセスを取り上げてみると、それがいくつかの作業手順に分かれていることがわかる。  工程分析では、作業手順に沿って、作業内容と情報の流れを追跡し、プロセスチャートにまとめる。現場での観察  要件定義段階では、作業測定を行なうことはあまりないが、必要があれば、連続時間研究法や、ワークサンプリング法などの手法を用いて時間測定を行なう。現場での観察  要件定義を進める上で、書類の調査や話を聞くだけではなく、一度は現場の業務状況を観察しておく価値がある。４-５システム要件の分析  分析作業要求仕様の詳細を確認するとともに、要求仕様の実現可能性を評価する。  要求仕様の確認事項業務機能や入出力データなど業務面の機能要件と、ハードウェア・ソフトウェアなどのシステムに構成に関する要件がある。要求仕様の詳細確認  システム開発を進める上で、制約になりそうな要件について、変更不可の絶対条件か、ある程度相談に応じてもらえる弱い条件かを確認する。実現可能性の評価  要求仕様書の中にはユーザ企業の期待や願望が混じっている。発注者の希望は尊重すべきであるが、実現可能性をきちんと評価する必要がある。  特に要件定義の結果に基づいて開発請負契約を締結する場合は、開発事業者にとってこの実現性評価は非常に重要な作業である。実現可能性を評価するポイント  指定された予算、スケジュールの範囲内で開発が可能か  指定された前提条件で要求される機能要件が実現可能か  技術面能力面で対応可能か４-６要件定義書の作成とレビュー  要件定義書には次の側面がある。１．発注先との合意文書である２．システム設計に対する仕様書である  いずれも、要件定義書がこれから行うシステム開発の枠組みを決めることを意味する。要件定義書の作成  要件定義書の一番の目的は、記載内容について発注先の確認を受け、合意を得ることにある。  一般的な留意点は４つある。合意事項を明瞭に記述する  確定していない要求仕様が残っていたら、重要なものとそうでないものを選別し、重要なものについては、できるだけ要件定義の段階で決着を付けるようにする。  重要でないものは、要件定義書の本文に記載せず、別途覚書にするとか、後工程への引継資料として備忘録的に記録を残す。見やすく、わかりやすい工夫をする  要件定義書を提出してもユーザ側ではなかなか読んでもらえないものである。  読む側では、提出された書類は分量が多く、たいてい生硬で読みづらいことを理由にあげる。読みやすくする工夫例箇条書き、図や表を多用し、見やすくする  要求仕様書からの変更点や追加項目を明示する  詳細な記述とは別に要点をまとめたものを付記する  専門用語や技術用語はできるだけ避ける（相手のレベルに合わせる）  要件定義書の様式は指定があればそれに従う  最初に提示された要求仕様書の書式に従うのもひとつの考え方であるが、発注者が作る書類は読みづらくても読んでもらえるものなので、参考にならないケースが多いかもしれない。要件定義書のレビュー  要件定義書を提出する前に開発事業者の内部でレビューする必要がある。レビューの留意点必ず、複数の人間でレビューする  レビューを担当する人間の担当分野と役割を明確にする  主要な業務機能、難易度の高い機能、開発工数、開発スケジュールなど重要なポイントを明確にする  重要な部分は複数のメンバーで別途詳細にレビューする  要件定義書の構成  システム開発の対象が広範囲にわたる場合は、システム機能を適当なサブシステム単位に分け、システム全体の共通編と機能別のサブシステム編で構成する。