Shoeisha Technology Media

CodeZine(コードジン)

記事種別から探す

要件定義の勘どころ

要件定義は詳細なシステムの機能を決めるための入力情報

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2010/02/05 17:45

 ユーザーに取って役に立つシステムを構築していく上で、要件定義書とはどのような働きをするのでしょうか。本稿では、要件定義書の役割や重視すべき点、具体的な要件定義書の作成手法などについて解説します。

目次

はじめに

 役に立つシステムを構築するための要件定義書とは、いったいどういうものなのでしょうか。

 「何でこの機能が必要なんですか?」「理由は分からないけどXXX機能があるのでこの機能が必要なんです。これがないとつじつまが合わなくなるんです」もしくは「要件定義書にこの機能が載っているので必要なんです」など、要件定義書の役割を理解しないまま、システムの開発に着手していることなどがないでしょうか。

 本稿では、要件定義書の役割や重視すべき点、要件定義書に盛り込むべき情報について解説します。

何をやるのか、そしてなぜそうするのか

要件定義書はジグソーパズル?

 システム開発を受託した会社にコンサルテーションしたときのことです。機能とデータがある程度記述された要件定義書を受け取ったその会社では、要件定義書を読み解き、システムの全体像を掴むためにおのおのの機能の関係を整理し、その役割を把握しようとしていました。システム全体として何を実現するのかを掴むための作業です。それはまるでジグソーパズルを組みたてている様子そのものでした。

 一方、ある図書館のWebサイトで本の検索をしようと思い、「蔵書検索」「本を探す」などそれに類する言葉を探しました。しかし、そのような言葉は何処にもなく、結局1番近いのは[資料を探す]というボタンだけでした。半信半疑でそのボタンを押すと、本の検索画面が出てきました。果たして本を検索したい人の何人がこの[資料を探す]ボタンが本を検索する機能だと思うでしょうか。筆者固有の要領の悪さだとは思えません。

 図書館のWebサイトにおいて、本の検索はもっとも大事な機能だと思いますが、それが[資料を探す]というボタンで、しかも他のボタンに紛れ込むような位置にありました。このようなことはWebの世界ではそこら中にあります。これは単に言葉だけの問題のように思われるかもしれませんが、実態はもっと根が深いのです。原因は「機能に着目しすぎるために起こるミス」にあります。

 システムの機能だけに着目すると「本」も「その他資料」、「CD-ROM」を探すのも同じようなものです。検索機能につける名前としては「資料」がもっとも適切と考えたのかもしれません。しかし、「結局は利用者は誰なのか?」「そのシステムは何のためにあるのか」などの基本的な部分の意識が欠落してしまっているのです。

 果たして要件定義のジグソーパズルを組みたてると「誰がどのように使うシステムなのか」が見えてくるのでしょうか。答えは否なのです。ジグソーパズルができあがると、システムとして整合する機能の集まりは理解できます。しかし、それではその機能がどのように使われるかは理解できません。ユーザーがそのシステムを使ってどのような価値を生み出そうとしているのかは分からないのです。

 要件定義書を受け取った側としては、ジグソーパズルを組みたてるように要件定義書を読み解くのは至極自然なように思われます。要件定義書には開発して欲しいシステムの機能が書かれているからです。それらの機能を矛盾なく実現することが求められていると考えるのは当然のことです。

 では、役に立つシステムを構築するための要件定義書とはどのようなものなのでしょうか。

要件定義書にはシステムが使われる環境を含める

 要件定義書に何が含まれていればいいのか、その答えを得るために、まずは要件定義の位置づけを明らかにします。筆者は要件定義は「What」つまり「システムが何をするのか」を表したものであり、その中でも「方向性を示すWhat」を表したものと捉え、詳細なWhatを決めるための入力情報と位置づけています。

 次に、要件を定義する側とその要件定義書を利用する側の立場の違いに着目します。要件を定義する側にとっては、システムに必要な機能はさまざまな検討の末に「必要である」と判断した結果です。しかし、要件定義書を利用する側は要件定義で示されたものが出発点となり、そこから詳細なWhatを決めることとなります。

 従って、要件定義書を出発点として詳細なWhatを決めるためには、結果としての機能だけではなくその機能がなぜ必要なのか、そして、その機能によって何が実現されなければならないのかを記述する必要があります。そのためには機能を導き出した過程の情報が必要になります。その過程の情報とは、システムを取り巻く環境です。「システムがこのように使われるのでこの機能が必要になった」という、機能を導き出した前提が重要になります。

 このため、筆者はシステムが使われる環境も要件定義に含めるべきだと考えています(図1参照)。システムが使われる環境を示すことで、はじめてシステムが何をしなければいけないかが明確になるからです。

図1 要件定義の範囲
図1 要件定義の範囲

WhatそしてWhy

 システムを取り巻く環境を要件定義に含めるとは具体的にどういうことでしょうか。それはWhatとWhyの連鎖を記述することです。つまり次のような連鎖になります。

  1. 「このシステムには○○な人が関わり」
  2. 「このシステムを使って××を実現する」
  3. そのために「システムを△△のように使用する」
  4. 従って「システムには○○の機能が必要になる」

 システムがどのような人にどのように使われるのかを示すことが、システムを取り巻く環境を表すことになり、それがシステムの機能とデータの存在理由になります。図2はその環境として考えられる関係者、外部システム、そして業務やそれによってもたらされる「もの」と「サービス」などの価値が表現されています。

図2 WhatとWhyの関係
図2 WhatとWhyの関係

  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 神崎 善司(カンザキ ゼンジ)

    (株)バリューソース代表 大手SIerにおいて大小10システム以上のプロジェクトリーダを勤め、20年ほど前に独立。2002年から5年間(株)豆蔵での社員も兼任しながら要件定義などの上流工程のコンサルティングを行う。2008年に要件定義手法「リレーションシップ駆動要件分析(RDRA)」を開発し現在は...

All contents copyright © 2006-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5