今回のモデルケース

• 既存案件のリプレイス案件(API実装のみ) + コンテンツ管理システムの新規案件
• 既存案件のリプレイスのフロント部分は、別チームが担当
• コンテンツ管理システムの画面遷移図は、すでに作成済み
• 体制
  • PM1(中堅), Member2(ベテラン, 若手)
  • 中堅(フルスタック寄, マネジメント初めて)
  • ベテランさん(設計等が強い)
  • 若手さん(プログラマー要員)
• 初めてのフレームワークを試してみる(Laravel)
• 初めてのVue.jsを試してみる(SPA→部分Vue)

要件定義フェーズ

大前提

ユーザが幸せになれることを考える！
だけど、提示された要望に対して、すべて鵜呑みにしない！
なぜ、それを実現させたいのか、こだわるのかの理由を聞き出す！

要件定義前に、テンプレート用意する

• 何を目的としたシステムなのか
• 何をするシステムなのか
• そのシステムには、どんな機能があるのか
• そのシステムは、どんな機器で動くのか
• どうやって、そのシステムを作っていくのか

要件を聞く時に、意識すること

• ユーザは、何がしたいのかをしっかり理解する。
• システムで実現できるのかを考える(あいまいなら汲み取って聞き出す)
• 聞きながら、プラン立てを考えておく（機能のやるやらないのようなもの）
• 機能一覧を裏で作りながらやっておくと整理しやすい
• 何をDB管理、何を定数管理、何をファイル管理などを想定しておくとDB設計時にスムーズ

要件定義のMTGが終わった後に整理/精査する時(MTGした分繰り返す)

• その要望の可否を検討する。
  • システム的に実現できる？できない？
  • そもそも本当に必要かどうか？
  • (既存システムなら)既存の機能でまかなえないか？
• その要望は誰が使用するのかを明確にする(工数的には省略したい)
  • アクターの整理をして、やり方(HOW)を決めていく
• 要望のリアルタイム性を確認する
  • データの鮮度が低いならば、バッチ処理などを提案する

聞き出した要件を元に設計を行い、クライアントと都度MTGを行う

例)

• メール設計
• 処理概要設計
• DB設計
• プログラム構造設計 などなど

要件定義フェーズで失敗したこと

• 知識の足りなさの部分で自分からの提案ができなかったこと。(上司から助けてもらった)
• 設計すべきものが見通せなかった(設計漏れがあった)

大事だけど忘れがちなやつ

• 新しく人が参画されたときに、最新資料の情報共有（必ずまとめておく）
  • 何がどこにあって、どれが使い捨てで、どっちが正で、、、など
• 情報が、ゆるがないものは、mdファイルなどにまとめてしまう