ごきげんよう、ノアです。
私の今年の目標は『最低限の機能が実装されているシステムを作る』です。
なので現在コツコツ地道に計画を進めております。
前回、要求定義をしてみた感想をお話ししました。そしてその後、皆大好き『要件定義』の工程に入りました。
今回は、要件定義作成時の感想をお話しできたらと思います。
初期要求（ニーズ）を明確にしましょう
要求定義をまとめ、システム化する目的(Why)と何がしたいのか(What)をはっきりさせていたので特に困ることはありませんでした。
一般的なシステム開発は「こうしたいな～」というような”漠然とした計画・要求”はありますが、要求定義書がなく要件定義から始まることもそれなりにあるそうなので、私は要求定義があったからここでさらに何かは特にありませんでした。
あと新規プロジェクトなので、今回はそこまで困らなかったのかもしれません。
ステークホルダを洗い出しましょう
個人開発なのでステークホルダは自分とユーザーのみでした。しかもユーザーは既にいるわけではなく、”このシステムを気に入ってくれれば”というユーザーになりますね。。。
ただ、大きなシステムや他部署まで関わってくるシステムなどは、誰が関係者か洗い出し、かつ要求を集めるのは本当にすごく大変そうだなと感じました。
要求の妥当性検証をしましょう
今回の個人開発はスモールスタートを考えていて現在は必要最低限の機能の実装のみ、リリース後に徐々に機能を追加していく予定なので、ここもそこまで困りはしませんでした。
ただ、夢はそこそこあるので、ゆくゆくは今頭に描いているアレコレを精査する必要があるのだろうなと思っています。
大きなシステムはどこを削るか、かなり難航しそうだなと感じました。
制約・前提条件を明確にしましょう
個人開発なのでフレームワークは？サーバーは？という制約は選びようがなかったので、今回はそこまで気になりませんでした。
要求の優先順位付け
要求の妥当性検証と同様、スモールスタートの必要最低限の機能のみを実装予定なのでここも問題なしでした。最低限過ぎて優先順位はすべての機能が1位に輝いてます笑
リリース後に実装する要求に関しては、今出ている案自体は洗い出しており、かつ優先順位も付けられました。それに関してもよかったです。
ステークホルダと合意形成する
ステークホルダは正直居ないので私がひたすらワクワクするのみでした。
しかし現実はとっても大変そうですね。
多方面のステークホルダに合意形成をとるための時間を考えながら進めないといけないらしいので・・・。
仕様として定義しましょう
今回、一番頭を抱えたのはここでした。
用意するものが多いです。実際決めること、まとめることが多くてかなり時間を使いました。「今の時点でそこら変も決める必要があるのですか、本当ですか・・・うわ～」と頭を抱えながら作成しました。
ですが、おかげでいい感じに詰められ、確かに依頼者とここまで詰められたら後戻りや食い違いを起こさなそうだなと感じたので、すごく大事なことだなと感じました。
全体の感想
要件定義の作成はとっても大変でした。
しかしここを挫くと悲惨なことになるということですので頑張りました。よって結構な大作になりました。
あとは、資料作成のデザインセンスが欲しいなとも感じました。。。
凄い凝ったデザインである必要はないのですが、もう少し見やすい分かりやすい資料はどう作ればいいんだろうと悩みました。
終わりに
正直個人開発なのでとにかく動くものを世間に早く発表した方がポートフォリオにもなるし、「自走でここまで実装できるんだよ」とアピールになるだろうなとは思っているのですが、実際の業務となった際にいきなりシステム作るぞー！環境構築！！！！とはならないと思うので、経験として要件定義書を作成してよかったです。
あとはプログラマでしたら機能の実装ができることが大事だと思いますが、ゆくゆくはシステムを1から作れる人になりたいので、機能を実装できるだけではなくユーザーが希望するシステムを作ることができないといけない。ユーザーが希望するシステムを作るということは、コミュニケーションであり、となるとプログラムを書けるだけではダメなのです。ユーザーとどんな問題を解決していくのか、どんな目標を達成したいのか、それを文字や図解で共有交渉していくことが大事なので経験してみてよかったです。
コメント