要件定義、システムを発注しようとして初めて聞く人も多いはず。
今回はこの『要件定義』についてふんわりどんなものなのかを書いていこうと思います。
要件定義書って？
要件定義書とは「これからこんなシステムを作りますよ。」「完成したらこんな風に動きますよ」というのを定めてまとめた資料になります。
これやりたい！あれやりたい！
これならできる！こっちの方法だとイメージと近いかも！
こんな風に発注者と受注者で完成形のシステムのイメージをすり合わせて作成していきます。
要件定義って誰が書くもの？
天下のIPA曰く、本来は発注者が書くべきものであるらしいです。知らなかった。
要件定義とは、どのようなシステム、何ができるシステムを作りたいのかを定義することです。それはあくまでも発注者の仕事であり、発注者の責任で行うものです。要件定義があいまいであったり、検討不足のまま、受注者に開発を依頼した場合、その結果として、コスト増、納期遅れ、品質低下を発生させるおそれがあります。その責任を受注者に負わせることはできません。
IPA「超上流から攻めるIT 化の原理原則17ヶ条」より引用
こちらの原則を見たところ、発注者側の業務部門とIT部門部門でなんとかしてくれ、とのこと。
まあ業務のことを一番知っているのが発注者側でしょというのも理解できます。
とはいえ、会社によってはシステムについてよく分かってないIT室がいたり、そもそもIT室がなかったり……ということも。そうなったら結局要件定義どころではなくなってしまいます。
A.結局は金額次第
もちろん、お金を払えばシステム屋に「要件定義を書いてくれ！」と頼むこともできます。
ただ、冒頭に書いたように外注したとはいえ発注者は「こういうシステムを作りたい！」と意見を伝える必要性があるのでお金を出したとしても結局丸投げはできないです。
ここで手間を惜しむとイメージと全く違うシステムが作られてしまうよ
要件定義なんていらなくない？
要件定義、手間も暇もお金もかかりますよね。
発注者側からしたら、必要ないんじゃないかと思うのも理解できます。
ぶっちゃけエンジニア側からしても、設計したりシステムを製造するころにはほとんど要件定義なんて見なくなるのでいらないんじゃないかと感じることもあります。
ただ、あくまでも要件定義は『プロジェクト最初期の認識合わせ』がメインです。このフェーズをすっ飛ばすとスタートダッシュから方向性が間違っていた……なんてことも起こりえます。
一応「要件定義はいらない！」という方向性でシステム開発を行っている例も見つけたのでここで紹介しておきます。
こちらの本で紹介されている手法は要件定義は納品物としてはないものの、要件定義に近いレベルの認識合わせを半年以上行ったうえで要件定義なしで開発を行っている、ということだったのでなんだかんだ要件定義っぽいことはしていました。
結局完全に要件定義そのものをすっ飛ばすというのは難しそうです。