こんにちは。
最近社会人のバレンタインというものを初めて経験しました。
若い頃のドキドキするあの感じってもう味わえないんですね。学生諸君に教えてあげたい！
でも、日頃の感謝を伝える機会づくりとしては重宝しますよね。バレンタイン。
筆者はディレクターですので、今回はディレクターの最大の山場とも言うべき計画フェーズ＆要件定義フェーズの流れについておさらいします。
（以下、計画フェーズと要件定義フェーズをまとめて初期フェーズと明記します）
初期フェーズとは
初期フェーズとは、具体的に
クライアントへの提案書が受諾され、案件化することが決まった後、実際に制作に入るまでの間
のことを指します。
（ここでは、プロジェクトの一連の流れを以下の様に定義しています）
正直、ディレクターの仕事という面でも、プロジェクト全体を通して見ても
ここにすべてが掛かっていると言っても過言ではありません。
初期フェーズを制する者がプロジェクトを制します。一番の肝です。
初期フェーズでディレクターが作成すべき成果物
では、ディレクターは実際に何と格闘するのでしょうか。
大きく分けると、2つあります。
スコープ定義書・要件定義書
これは担当者によって書き方、内容、提出タイミングは様々だと思いますが、
私は基本的に、キックオフ（初回）ミーティング後に最終的なまとめとして2点を提出するものと思っています。
（案件の特徴的にキックオフ前にスコープ内容が固まっている場合は、事前に作成しておき定義書に基づいてキックオフを行うのも手です）
書くべき内容は、事前に提出済みの提案書の中から実際に採用になった部分を抜き出し、
そこに実際のスコープ箇所、納品形態、スケジュールなどを加えればOKです。
つまり、具体的な内容は
●プロジェクト発足の背景、目的（恐らく提案書に書いてあるもの）
●納品物一覧、及びその形態
●スコープ範囲（実際にどのような作業をするのか）
●制約条件（納期、予算、外注先など）
●スケジュール
ということになります。
注意すべき点
ここで注意すべき点は、スコープ範囲の書き方です
・スコープ範囲は細かく指定しましょう
例えば新規でサイトを公開する場合、もし既存サイトからある程度コンテンツを引っ張るならば
その流し込み作業はどちらが担当するのか、などです。
・スコープ外範囲を明記しましょう
盲点なのがここです。
例えば、開発したシステムの運用トレーニングがスコープ範囲に記述されていたとします。
しかしこの書き方だと、クライアントの担当者なのか、システムユーザーに対してなのかの認識の相違が生まれます。
想定工数に大幅なズレが生まれますので、ここはしっかり明記しましょう。
・言葉遣いに気を付けましょう
スコープ範囲は一歩間違ると「こっから先は知りません」と投げているように捉えられかねません。
言葉遣いには細心の注意を払う必要があります。
WBS
ディレクターが初期フェーズに作成すべき成果物、2つ目がこのWBSです。
WBSとは、“Work Breakdown Structure”の略で、日本語にすると文字通り作業内容の細分化、となります。
WBSは、よく料理を作る工程として例えられます。
（引用元：https://products.sint.co.jp/obpm/blog/serial-umeda07）
料理の工程というと、材料の準備や動き（切る、炒めるなど）までしか想像できませんが
ここではもっと細かく分割する必要があります。
ここで最大限細分化しておくことで、後々の仕様の見落とし、工数のズレ、アサインミスなどが防げます。
その後の流れ
スコープ定義書、要件定義書、WBSの作成が終わったら、定義書のみ先方と確認します。
お互いに認識の齟齬がないかどうか、依頼内容や実装すべき仕様は全て網羅されているかどうか、ここで最終確認を行いましょう。
きっちり固めておくことで、後々要件追加などが発生した場合も、当初予定されていたものかどうか確実に把握することができます。
まとめ
このフェーズにいかに時間をかけたかが、後々物を言います。
制作フェーズをスムーズに進行させるためにも、初期段階での地固めはしっかりやっておきたいところです。
