要件定義のやりかた(新人さん向け)

要約

  • 5W2Hを意識して書こう
  • 応用技術者試験は参考になる

最初に断っておきます。

要件定義といってもかなり幅がある。

ウォーターフォール開発では、実現可能性を含め
かなり細かいところまで詰めてるだろう。
これに対し、いわゆるアジャイル開発では、要件定義というフェイズを置かないのかもしれない。

でも呼び方が変わっている、もしくは作業内に取り込まれているだけで
要件定義的な要素はなくなることは無いと思う。ゴールを設定する作業だからね。

じゃあ、ゴールはだれが設定するのか?
コンサルがいる場合はコンサルだ、いやユーザだ、PLだ、いろいろと議論はある。

しかし普通に考えてみてくれ。
どう考えても依頼する側だろう。
「システムを作ってください。これこれこういう課題があるんです・・。」
と言ってお金を払うほうだろう。

もしこれがPLに要件定義の権限があるという話なら、お客は文句が言えないということになる。

男(PL)「今日の昼ごはんなにが食べたい?」
女(お客)「ん〜任せる」
男(PL)「じゃあ中華で」
女(お客)「え〜!!中華は苦手なの!」

となると広島弁でいうと「クソたいぎい」女です。
両者のすり合わせは当然行うとしても、最終決定権は「お客」です。

IPAの「超上流から攻めるIT化の原理原則」原理原則9(p11)にも書いてある。
「要件定義は発注者の責任である」とね。
※これは良いドキュメントなので契約を巻く前に膝を突き合わせて読むと良いです。

前置きはこれくらいにして、要件定義は何をしたら良いのか?

ざっくり言うと、システム全体について以下のことが分かればよい。

「なぜ」「やるのか」(目的・背景)

「何を」「やるのか」(対象)

「誰が」「やるのか」(アクタ)

「いつ」「やるのか」(イベント・年次・月次・日次、移行データ、並行稼動など)

「どこで」「やるのか」(複数拠点がある場合は拠点ごと)

「どのように」(画面・バッチなど)

「いくらで」(工数・具体的なスケジュール)

あ、もう一つ大事なこと。
「何をやらないのか」(システム境界、外部IFがある場合はそれも書く)

もちろんスケジュールなどはもっと上流で決まってることが多い。
けど中日程(週)くらいまで落とし込むのが理想。

で、これを読んでる新人の君はこう言うだろう。
「そういう抽象的な話が聞きたいんじゃない!とにかくフォーマットを出せよ!」

「そこを考えるのが仕事だろう!コピペで済むほど甘くねえ!」と言いたいところだが
サンプルとして良いのがあるんですよ。

またまたIPAの手先みたいなことを言いますが
応用技術者試験のH27秋 午後問8を見て欲しい。
PDFの40ページです。良問。

1)改善要望の整理

2)業務機能の定義

3)新業務フローの作成

4)フィットアンドギャップ分析

5)外部設計

6)内部設計(クラス図)

まで書いてある。要件定義では、おそらく4)まであれば良いだろうね。

標準機能はパッケージを利用し、追加機能はスクラッチで作成するテイの設問
なので、フルスクラッチの場合はフィットアンドギャップ分析は不要になる。

もちろんウォーターフォール開発で規模が大きい場合だと足りない資料はある。
バッチのスケジュールやシステム構成図など他にも必要な資料はある。
でも根っこの部分はこれ。
細かく書いてるのが欲しい人は「官公庁 要件定義 サンプル」とかでネットで調べて欲しい。
総務省のサンプルはこれ。

ということで、うまずたゆまずがんばってください!
弊社の新人教育のカリキュラムについてはこれをご参照ください。

補足
いわゆる基幹系だとゴールが決まってる。
要は「売上を上げる」か「費用を下げる」という会社の勘定科目の話につながってるはず。
なので上記内容を淡々と詰めていけばいいだけの話なので簡単。

これに対し、企画とか広告に寄ったシステムは難しい。
ゴールが動いてるのと同じだからね。
これに関しては、瞬間的にでもターゲットを決めるしかないかも・・・と思案中。

補足2
設計書の書き方についても書いています。
よかったら見てね。

補足3
良い記事があった。実際にお客様と要件定義を行う際のお作法が書いてあります。
そういや見様見真似でできるようになっただけできちんと教わったことはなかった。