😸

【上流_1日目】要件定義1冊目

2024/02/25に公開

背景

今まで開発側にいることが多く、設計をバリバリやっていた訳ではないですが、要件定義をやることになったため、学習及びアウトプットをして、理解を深めることにしました。

お客さんが叶えたい事業目標や、会社の経営目標に対して、それを成すために、システムでできることや求められることを明確化すること
→やりたいことは多々あるが、その中でどこを実施していくのかを要件として定義する
当たり前であることなども含めて、目に見えない要求なども存在する
→SEはそれらを把握して、システム化させる

設計から開発までを一連の流れとし、短い期間で繰り返すアジャイルの開発手法とは違い、開発の段階で気付いてしまうことがあると、大きな手戻りが発生してしまう
→そのため、仕様が不明確であったとしても、設計段階で見える箇所は出来るだけ見える化を図っていかなければならない。

過去の案件ではありますが、準委任契約と請負契約どちらを取るのかという議論に関わっていたことがあります。もしウォーターフォールのように、システムの設計が前段階できっちり行えるのであれば、問題ありませんが、

アジャイルであったり、仕様がコロコロ変わってしまうような場合は、どこまでを請負で完成させるのかといったことがあるので、準委任契約と請負契約でどちらがいいかは、まちまちであると思われます。

物価の違いもあり、設計がバリバリに出来るような会社であれば、アウトソージングであるオフショア開発などで委託し、開発費を抑えられるということもあるようです。

これは友人に聞いたことがあるお話ですが、オフショアで依頼した際のソースコードのスペルミスなど含めて酷く、その後の運用保守が難しいといったお話も聞いたことがあります。

可能な限り漏れがないように、隠れている情報を全て洗い出すことが重要。
→漏れがあると、誤った解決策や、対処を行なってしまうことにつながりかねないとのこと。
打ち合わせで議論したことを、こまめに合意を取って進めること
→要件定義を進めていく上で、決まったことが戻ると大きな手戻りになりかねないので、こまめに合意を取りながら進めていくことが肝要とのことでした。
合意が決まったものは固める
→一度決まった要件がコロコロ変わらないように、決まったドキュメントは凍結という形を取るとのこと。現場によってはバージョン管理などを行なったり、お客さん用は編集しないように、ダウンロードのみで管理し、相手に合意を得たものだけ格納したりなどあると思います。