この度弊社イマジテックは自社サービスを新規開発することにしました。
新規開発とのことで最初にすべきことはもちろん
要件定義です。
本記事では上流工程の経験がない四年目エンジニアが
要件定義フェーズで得た知見、苦悩を工程に沿ってつらつらと書き記します。
目次
1.要件のヒアリング
2.要件定義書作成で壁にぶつかる
3.非機能要件の山にぶつかる
4.おわりに
5.予告
1. 要件のヒアリング
本プロジェクトの初期案は弊社代表発なので、代表からお話を伺いました。
サービスのイメージ、そのサービスを思いついた理由などなどを聞きました。
ヒアリングを通してイメージの共有ができました。
ここまでは特に問題なく進んでいたつもりでした。
2. 要件定義書作成で壁にぶつかる
サービス内容を把握したので次のステップ要件定義書に移ります。
「じゃあ着手するかー。」と思って進めようとするとあることに気づきます。
要件定義書ってなに書くんだ？？？
今まで要件定義書は「一番最初に作成する資料で、何を作るか、なぜ作るのか等々開発するサービスの概要を記載する資料」だと認識しておりヒアリング時もここを重点的に聞いていました。
あながち間違ってはいませんが、ひじょーーーーーーに具体性が欠けております。
なので実際に手を動かそうとした瞬間に手が止まりました。
「いやー。困ったなー。」という場面でベテランエンジニアの方から参考資料を提供いただき、こちらを参考に資料作成を進めます。
非常にわかりやすく参考になりました。ありがとうございます。
参考資料提供サイト：Web担当者Forum
資料作成企業:KINOTROPE
参考資料：2-5_ダウンロード資料_現状サイトコンテンツリスト
※本プロジェクトは「若手（自分）＆ベテラン」の体制で取り組んでおり、躓いてしまった場合助言をいただきます。
しかしまた壁、いや山にぶつかってしまうのです。
3. 非機能要件の山にぶつかる
参考資料を確認しながら作成を進めていると、とんでもないものが目に移りこんできました。
それは非機能要件です。
参考資料のどのような項目が記載されているかというと
◼ 可用性
◼ 性能・拡張性
◼ 運用・保守性
◼ 移行性
◼ セキュリティ
◼ システム環境
いやー。
まったく想定していなかった
ここで要件定義書はどのような書類だと自分自身考えていたか振り返ってみます。
要件定義書は「一番最初に作成する資料で、何を作るか、なぜ作るのか等々開発するサービスの概要を記載する資料」だと認識しており
このことからわかる通り、非機能要件のことは全く頭にありませんでした。
想定していなかったのはしょうがありません。
これから非機能要件の項目を記載していこう。
参考資料もあることだし、そう奮起し手を動かします。
しかし、、、
書けない。
なぜ書けないか「6.システム環境」を例を出してお話しします。
参考資料を確認するとシステム環境には下記の内容が記載されています。
- どのOSで動作するか
- そのOSのバージョンは何を想定するか
- どのブラウザを想定するか
- 解像度は？
- デバイスのスペックは？
- 回線速度は？
などなどが定められています。
理由はたった一つで、知識不足が挙げられます。
- そのOSのバージョンは何を想定するか
各バージョンで何がどう違うのかが全くわかっていません。
当然調べればわかることではありますが、知識が全くないため調査に時間を費やしてしまいます。
例として挙げたのはほんの一部でほかにもたくさんあるわけです。
そうなると調査の時間がとんでもないことになってしまいます。
結果的には記載できる項目は埋め、調査が必要な部分は積み残しとして基本設計フェーズで決める方針にしました。
4. おわりに
何はともあれ要件定義フェーズは完遂しました。
この体験を経て得たことは下記3点です。
- 要件定義フェーズを一通り経験したことで要件定義の段階で確定させる箇所、記載の粒度を身に染みて知ることができた。
- 非機能要件ってめちゃめちゃ知識いるやん。
- (意外と記事書くの楽しい)
反省点として一部の非機能要件は基本設計フェーズで決めることになったことです。
要件定義書の認識が甘かったこともありますが、今後要件定義に携わる際はどのような項目を確定させるか頭に入った状態で進めることができるのでこれらを次に生かしたいと思います。
現在基本設計フェーズに移行していますが、基本設計が終わり次第また記事としてアウトプットするので、もし続きが気になる方はお待ちください。
5. 予告
次の記事は「基本設計を始めてすぐに起きた事件」についてまとめたいと思います。
8月11日金曜日に投稿予定です。