目次
前提･先方方針
- 更新箇所・頻度は減らしたい。
- パーツ：極力共通で使えるようにしたい。
- ページ制作：SPメイン。あくまでPCはSPに合わせる形にしたい。
- バナーサイズ：共通で使用可能なサイズで指定希望。
進行前
対応箇所が広範囲となりそうな案件の場合、一度要件確定のフェーズを設ける。
- mtgを実施し、要件摺り合わせる
- サイト内の影響箇所の洗い出しを行う
- 関連･先行タスクを整理してスケジュールを作成する
すべての要件定義は難しいため、最低限の前提と基本とすべき点を中心とする。
先方が一番優先したい希望を軸とする。
先方のご要望を聞きつつ寄り添いつつを大切に、
「こうした方がよいかと思いますがいかがでしょうか？」という感じで提案しつつ伺う。
選択肢の幅を持たせる(納期重視か、タイミングの都合がつけられるか)。
デザイン校正、コーディング校正の段階でそれぞれ要件やご要望が変更となる可能性がある。
要件確定前にデザイン校正1回･修正1回でよいか確認する。
＊大和様はご要望がありデザイン校正2回･修正2回を前提としている。
進行中
仕様書、指示書ファイルが複数になる場合がある。
最初のフォーマット原稿をこちらで作成する。
2回目以降は見積もりの際、「要件定義」で工数を確保する。
先方が都度別ファイルで用意される場合は、社内用の取りまとめファイルに一元化する。
工数が嵩みそうな場合は途中で判断する。
進行中に要件変更等があり再見積もりやスケジュール調整が発生しやすい。
要件変更の際の再見積もりは、デザイン･コーディング･ディレクションすべての追加工数を確認。
日程調整も都度確認。
リリース後
リリース後は先方の更新作業とバッティングする可能性があるため、
追加調整のご相談をいただいた場合は、正式な指示や依頼をいただいてからキノスラで作業を開始する。
