hkusuです。今回はシステム開発の「要件定義」について、個人的に意識していたことを書きます。

はじめに

「要件定義」というと、実現する機能を洗い出さなきゃ、、となりがちで、また例え実現する機能を仕様の決定者へ説明し合意を得たとしても、後から仕様が変更される、ということは良くありますよね。

多くのケースは「認識の違い」「見えてる範囲の違い」によるものかと思います。定義されてないけど当然これは出来るよね、というグレーの部分です。

ですので、私が要件定義をする際は「実現できないこと」に着目し、予め仕様検討のテーブルに載せるということを意識していました。初めから仕様が明確であれば、開発の際に考慮できますし、リリース直前に仕様が変わるということを防ぐ（現実では減らす..）ことに繋がります。

例

例えば次のようにキャンペーンシステムの要件定義をするとします（あくまで例です。本当はもっと色々定義することはあります）。

○○キャンペーン機能

(1) 利用できるブラウザはスマートフォンに標準搭載されるブラウザとする
(2) ユーザの登録項目について
(2-1) 住所、生年月日とする
(3) 応募期間は2014年4月末とする

一見はこれで良さそうなのですが、それぞれ「実現できないこと」を追加していきます。まず(1)については、

(1) 利用できるブラウザはスマートフォンに標準搭載されるブラウザとする
(1-1) 日本国内の通信キャリアから発売された端末に限定する
(1-2) Windowsフォンは含まない
(1-3) ネィティブアプリのWebViewからの利用は動作保証外とする
(1-3-1) ネィティブアプリから外部ブラウザとして端末の標準搭載ブラウザを起動することを想定する

具体的になりました。ここで仕様の決定者は、海外端末やWindowsフォンが対象外ということが気付くことができます。また(1-3)については、もし保証内とするなら、予めテストフェーズに作業を組み込むことができます。

次に(2)については、

(2) ユーザの登録項目について
(2-1) 住所、生年月日とする
(2-1-1) 性別は含まない

もし発送する賞品が衣服などの場合、性別を聞いておかないとまずいよね、ということに気付けます。

次に(3)については、

(3) 応募期間は2014年4月末とする
(3-1) 住所登録の完了が 4月 30日 23時 59分 59秒までに完了しているユーザを対象とする
(3-2) 上記の時間は 日本標準時間であるものとする

初めから分かっていれば、予めキャンペーンの規約や注意事項に書いてトラブルを防止できますね。

ついでに(4)(5)(6)を追加して、まとめると次のような感じです。

○○キャンペーン機能

(1) 利用できるブラウザはスマートフォンに標準搭載されるブラウザとする
(1-1) 日本国内の通信キャリアから発売された端末に限定する
(1-2) Windowsフォンは含まない
(1-3) ネィティブアプリのWebViewからの利用は動作保証外とする
(1-3-1) ネィティブアプリから外部ブラウザとして端末の標準搭載ブラウザを起動することを想定する

(2) ユーザの登録項目について
(2-1) 住所、生年月日とする
(2-1-1) 性別は含まない

(3) 応募期間は2014年4月末とする
(3-1) 住所登録の完了が 4月 30日 23時 59分 59秒までに完了しているユーザを対象とする
(3-2) 上記の時間は 日本標準時間であるものとする

(4) 本システムは応募状況のレポートに関する機能を有しない

(5) 本システムにおける応募データの保持期限は○○までとする

(6) 本システムではキャンペーン期間をリリース後に変更することは出来ない

おわりに

実現できないことを列挙すると嫌がられるかもしれませんが、、ただ後々に仕様が追加されることに比べたら、予め明確にしておいた方が皆が幸せになれます^^;

また実現できないことに着目することで仕様がブラッシュアップされ、結果よいシステムになるのかなと思います。もし要件定義に行き詰まっている方は、是非このような観点での要件定義を試してみてください。