今回のモデルケース
- 既存案件のリプレイス案件(API実装のみ) + コンテンツ管理システムの新規案件
- 既存案件のリプレイスのフロント部分は、別チームが担当
- コンテンツ管理システムの画面遷移図は、すでに作成済み
- 体制
- PM1(中堅), Member2(ベテラン, 若手)
- 中堅(フルスタック寄, マネジメント初めて)
- ベテランさん(設計等が強い)
- 若手さん(プログラマー要員)
- 初めてのフレームワークを試してみる(Laravel)
- 初めてのVue.jsを試してみる(SPA→部分Vue)
要件定義フェーズ
大前提
ユーザが幸せになれることを考える！
だけど、提示された要望に対して、すべて鵜呑みにしない！
なぜ、それを実現させたいのか、こだわるのかの理由を聞き出す！
要件定義前に、テンプレート用意する
- 何を目的としたシステムなのか
- 何をするシステムなのか
- そのシステムには、どんな機能があるのか
- そのシステムは、どんな機器で動くのか
- どうやって、そのシステムを作っていくのか
要件を聞く時に、意識すること
- ユーザは、何がしたいのかをしっかり理解する。
- システムで実現できるのかを考える(あいまいなら汲み取って聞き出す)
- 聞きながら、プラン立てを考えておく（機能のやるやらないのようなもの）
- 機能一覧を裏で作りながらやっておくと整理しやすい
- 何をDB管理、何を定数管理、何をファイル管理などを想定しておくとDB設計時にスムーズ
要件定義のMTGが終わった後に整理/精査する時(MTGした分繰り返す)
- その要望の可否を検討する。
- システム的に実現できる？できない？
- そもそも本当に必要かどうか？
- (既存システムなら)既存の機能でまかなえないか？
- その要望は誰が使用するのかを明確にする(工数的には省略したい)
- アクターの整理をして、やり方(HOW)を決めていく
- 要望のリアルタイム性を確認する
- データの鮮度が低いならば、バッチ処理などを提案する
聞き出した要件を元に設計を行い、クライアントと都度MTGを行う
例)
- メール設計
- 処理概要設計
- DB設計
- プログラム構造設計
などなど
要件定義フェーズで失敗したこと
- 知識の足りなさの部分で自分からの提案ができなかったこと。(上司から助けてもらった)
- 設計すべきものが見通せなかった(設計漏れがあった)
大事だけど忘れがちなやつ
- 新しく人が参画されたときに、最新資料の情報共有（必ずまとめておく）
- 何がどこにあって、どれが使い捨てで、どっちが正で、、、など
- 情報が、ゆるがないものは、mdファイルなどにまとめてしまう