IPAが定義する要件定義成果物に関して、サンプルやフォーマットを以下サイトからダウンロードできたので、それぞれどういった目的で、どういった内容なのかを整理し、作成する際のポイントについて、自分なりに整理したいと思います。
IPAが提唱する要件定義成果物の一覧はこちらから参照ください。
親切なことにサンプル、フォーマットをダウンロード可能です。実際のフォーマットやサンプルをダウンロードしたうえで、比較しながらご覧いただければより理解が深まると思います。
「超上流から攻めるIT化の事例集：要件定義」に挙げられている成果物１つ１つに対して、そのサンプルを確認し、どのような成果物か、私がこれまで経験したプロジェクトではどのように作成し、作成する際はどのようなことを意識していたかをまとめていきます。小冊子の小項目名ごとに解釈をまとめていきますので、最後までご覧ください。
要件定義成果物：機能要件（プロセス）
機能、プロセス要件ということで、業務そして、システムの機能に着目した要件定義成果物となります。開発するシステムが対象とする業務を理解し、まずはシステムを度外視し、業務そのものを定義するところがからがスタートとなります。その後に、業務とシステムの関係性を考慮して、業務フローやシステム機能の定義を行っていきます。
機能情報関連図
DFD（データフローダイアグラム）と呼ばれる成果物です。
システムを構成する機能とシステムが扱うデータの関係性を表す成果物として利用されます。
プロセス中心アプローチとして利用されます。最近では、データ中心アプローチが主流になってきているので、私の経験上でも作成したことは一度あった程度です。
DFDによって、データが入力され、システム内でどのように処理され、出力されていくかという一連の流れを視覚的に整理することができるようになります。したがって、新システムを導入する場合にはしばしば用いられる成果物となります。
業務流れ図
所謂、業務フローにあたる成果物です。
業務フローには、概観業務フロー、業務フロー、システム化業務フローの３種類があります。
システム開発において最低限必要となるのは、3つ目のシステム化業務フローです。これは、一連の業務の流れと、その業務を支えるシステムとの関係性を表したフローになります。
参照元のIPAのサイトでは、３つを定義し直しているわけではありませんが、サンプルの中身を確認すると、本質的な業務を定義している業務フローと、その中に更にシステムの要素も盛り込んでいるシステム化業務フローにある程度わけることも可能かと思います。
３種類の業務フローについては、こちらで詳しく解説していますので併せてご覧ください。
業務処理定義書
業務要件定義書だと読み替えてもらうと理解しやすいと思います。
システムが対象とする各業務に関して、それぞれどのような業務かを定義するドキュメントです。
IPAの例では、受注管理における納期回答という業務がピックアップされていますが、まずはシステムに依らず、納期回答という業務そのものがどういうものであるか、どうあるべきかを整理します。そのあとに、システムによる何かしらの制約があり、それにより業務を変える必要がある、定義し直す必要があれば、その内容を業務定義書としてまとめます。
業務定義書の他に、業務の手順をフロー形式で記述することもIPAの成果物として挙げられていますが、重要なことは、対象となる業務がどういうものかを定義することだと思います。定義する際は5W2H（いつ、どこで、誰が、何を、なぜ実施するのか、そしてどれくらい、どのように実施するのか）が網羅されるように定義すると良いと思います。
システム機能階層図
平たくいえば、システム機能一覧に相当します。
業務フロー、業務定義書が決まることで、その業務を実現するために必要となるシステム機能を定義することができます。したがって、IPAでもシステム化機能一覧表をシステム機能階層図の中の成果物として位置づけ、定義していると思います。
ここで列挙したシステム機能が設計工程以降の見積分母となるため、抜け漏れがないようにします。また、私の経験上、要件定義が完了した時点で、後続工程の見積精度は±10%以内なるようにするのが望ましいと考えています。
したがって、システム機能一覧で定義する機能詳細は、見積精度が±10%以内になる程度には詳細化する必要があります。逆に、見積がまだできないような精度であれば、検討が足りていないと考えて、要件の整理をする必要があります。
スポンサーリンク
要件定義成果物：機能要件（データ）
業務システムは、データを扱ってこそ意味を持ちます。昨今の業務システムは、オペレーションを簡略化すること、業務効率化を図ることだけでは足りず、業務システムにどのようなデータを蓄積することができるかどうかの方が重要視されてきていると感じます。
したがって、データ要件を整理することは、機能要件、プロセス要件を定義する以上の重要性があるといっても過言ではありません。
概念E‐R 図
概念データモデルです。開発するシステムが扱う業務や情報をモデル化したものになり、エンティティを定義します。
あくまで概念ですので、主キーや主要項目まで洗い出されていれば十分です。
後続の工程で論理データモデルを作成することになると思うので、全項目を洗い出すのはその際で問題ありません。
例えば、受注、出荷、請求、といったように、システムが扱う業務をモデル化し、扱う情報の集合体としたものになります。また、例えば、受注：出荷＝１：Ｎというように、各エンティティの関係性については概念データモデルの段階で整理しておくことをお勧めします。
データ項目定義書
IPAの成果物では、概念データモデル、論理データモデル、データ項目定義が主な成果物として挙げられています。
IPAの例では論理データモデルで桁数や型についても定義していますが、大前提としてすべての項目を列挙することが必要だと私は考えています。
裏を返せば、要件定義の段階で対象システムが扱う情報に関しては、すべての項目を整理し、且つ桁数や型についても検討が済んでいる状態であるべきということです。冒頭、要件定義が完了した際には見積精度が±10％以内になるようにすべきとお伝えしましたが、すべての項目を列挙しきれていないと見積にぶれが生じることは容易に想像できるかと思います。
スポンサーリンク
要件定義成果物：機能要件（インターフェイス）
ここでいうインターフェースとはシステム間のインタフェース、ユーザーとシステムとのインタフェースの両方を指しています。
前者については、昨今のシステム開発では必ず周辺システムとの何かしらの連携開発が発生するため、外部インターフェース連携に関しては必須の検討事項だと思っておくことが重要といえます。後者に関しては、実際にユーザーが利用する画面や帳票に関する定義になりますので、システム開発におけるもっとも重要な要件整理になってきます。
いずれもどういうシステムを作るかを方向づけする重要な要件整理だといえます。
システム間関連図
システム間関連図は、システム全体図、サブシステム構成図ということも出来ると思いますが、重要なことは対象となるシステムと、そのシステムとの対向システムとの境界線を明確にすることです。
この関連図がベースとなって、必要となる外部インターフェースの本数を明確にしていきます。
システム間インターフェース定義書
インターフェース定義書になります。
対向システム、連携方向、頻度、方法、主要項目（主キー）、何単位か（連携データの粒度）については要件定義の段階で明確にしておく必要があります。
項目については、主要項目については最低限、確定する必要がありますが、論理データモデルの検討にあたってはインターフェース項目についても合わせて決定させる必要があるため、インターフェース項目についても全項目精査する必要が基本的にあると考えておくべきです。
その精査の中で、現状の不足している項目や、インターフェース連携の為に考慮しなければいけない項目、読み替えなければいけない項目については開発対象としていきます。
画面・帳票一覧
画面、帳票の一覧を洗い出すことは勿論重要ですが、各画面、帳票に関する機能についても記述し、どのような機能かを定義します。ポイントとしては、入力項目（IN）と出力項目（OUT）を明確にしたうえで、どういった機能であるかを整理します。
システム機能階層図で列挙した機能が各画面、帳票に盛り込まれるように検討するとより精度が高まると思いますが、要件定義の根幹となる内容ですので、検討漏れがないように十分熟考します。
画面・帳票レイアウト
画面・帳票の具体的なイメージ、レイアウト定義書です。
ポイントは、要件定義終了段階で、画面・帳票イメージまで確定させていることにあるといえます。つまり、前述の画面・帳票一覧、データ項目定義書と合わせれば、IPAの方針でいえば、要件定義にて開発する画面・帳票のレイアウトは項目レベルで全項目（桁数、型まで）確定し、どういった機能を保持するかまで定義する必要があるということができます。
また、IPAの例では、画面・帳票イメージの中で表現する表示項目については桁数についても定義に即した内容で表現（10桁であれば1234567890など）していることにも注目するとよいです。
スポンサーリンク
要件定義成果物：非機能要件
続いては、非機能要件になります。非機能要件に関しては、非機能要件グレードを参照するのが最も望ましいと思います。
とはいえ、最低限要件定義として必要となる成果物として列挙されているこれらの成果物についてもどのようなモノか考察していきたいと思います。
品質要件
運用要件一覧表が成果物事例として挙げられています。
品質要件というよりは、本番稼働後の運用要件に該当するといえます。
本番稼働後の保守体制などを決めておくと思えばよいかと思いますが、保守体制についてはそれはそれで別途保守に引き継ぐためのルール作成や、資料準備などを行っていく必要があります。
技術要件
移行要件整理表が成果物事例として挙げられています。
先ほどの運用要件と並んで、移行に関する要件整理と考えるとよいと思います。
IPAのサンプルでは、システムをどう切り替えていくかというシステム移行について整理した内容となっています。
ただ、移行というのは業務移行、データ移行、システム移行という３種類あると認識すべきです。業務移行とは現行業務からどのように新システムを使った業務に切り替えていくか、データ移行とは現行システムで稼働しているデータをどのように新システムに移行させるか、システム移行とはIPAのサンプルにあるようにどのようにシステム切り替えを行っていくかになります。
運用・操作要件
性能目標設定が成果物例として挙がっています。いわゆる、パフォーマンス定義になります。
ただし、個人的にはパフォーマンスに関しては余程の要件がない限りは何秒以内というような要件を定義しない方がよく、あくまでベストエフォートとしておくのが無難です。なぜならアプリケーション性能だけではなく、ネットワークなど他の要因によって大きく結果が変わる部分でもあるため、必ずしも要件を実現できるとは限らないためです。
それ以外については、ユーザーが使う想定のOSやブラウザなどを定義しておくことで、開発時の標準利用想定を定め、それをもとに開発することができるようになります。
その他（情報リスト）
その他の成果物としては、情報リストが挙げられています。情報リストとは、概念データモデルの各エンティティがどこの部署の管轄か、どこの部署が入力するのか、利用するのかを整理します。
ただ、あまりこの情報リストを私は作成したことがありません。
スポンサーリンク
まとめ
今回は、IPAの超上流から攻めるIT化の事例集：要件定義の成果物に沿って、要件定義で作成すべき成果物について考えてきました。
実際のサンプルをIPAのサイトからダウンロードいただくことができますので、実際の中身と共に確認するとより理解が深まると思いますので、ぜひ皆さんも実施してみていただければと思います。
コメント