ベイジでは、プロジェクトが正式に始まるタイミングで、顧客とキックオフミーティングを実施している。ここでは、プロジェクトにおける前提条件などの共有を目的としているが、このミーティングの精度により、以降のプロジェクトにおける進めやすさに影響が出る重要なミーティングだと位置づけている。
過去のプロジェクトを振り返ると、キックオフミーティングの精度が低いために、事前に伝えておけば大きな問題にはならなかったようなトラブルも発生した。例えば、既存サイトのリライトにおける注意点やリニューアル時のリダイレクト設定における説明が不足しており、プロジェクトの後半で追加対応が必要になってしまうケースもあった。
プロジェクトマネジメントにおいても、プロジェクトが正式にスタートする際にはプロジェクト憲章を作成することが一般的だが、ベイジでは「プロジェクト定義書」として、プロジェクトの目的やスコープ範囲、成果物などを記載したドキュメントを作成して、顧客とのミーティングにより、後から認識違いが発生しないように注意している。
プロジェクト定義書では、具体的には以下のような項目を記載して、キックオフミーティングで認識合わせをするように徹底している。
プロジェクトのゴール
キックオフミーティングに至るまでに共有されていることではあるが、あらためて明記するようにしている。例えば、情報発信によるリードの獲得を目的とする場合や、ブランディング・販売促進を目的にする場合など、プロジェクトの途中から加わるメンバーに対しても目的がずれないようにしておく必要がある。
また、リリース日も明確にしておくことになるが、別途作成するWBSにおいて、詳細な工程表を組んでいるので、そちらをベースにして伝えるようにしている。
スコープ
顧客と我々との間で、対応する内容や成果物を明確にしておく必要がある。顧客側が対応する内容であれば、社内における承認や合意、原稿素材の手配や受入テストなどを対応してもらい、我々が対応する内容は、戦略設計や情報設計、コンテンツ企画から進行管理まで、顧客が対応しないものはすべてと言えるだろう。
作成する予定の成果物においても、ログ解析や競合分析のレポート、ワイヤーフレーム、運用マニュアルのように、具体的な成果物を明記しておかないと、後になって「このドキュメントも納品されると思っていた」といった認識違いが発生してしまう。
連絡・開発体制
双方の担当者や役割、連絡先を記載することになるが、主な役割も明確にしておくべきだ。大規模なプロジェクトの場合、主となる連絡窓口を決めておかないと、さまざまな方面から連絡が入ってしまい、意見の集約ができずにプロジェクトが横道にずれやすい。
自社の担当者においても、それぞれの役割分担を明確にしておくことで、各フェーズにおいて何人程度が関わるのかも伝わるので、顧客にとっても安心材料になるのではないか。
サーバー・セキュリティ関連
当たり前のことだが、顧客情報の取り扱いには、慎重を期す必要があり、セキュリティには充分に注意を払っている。プロジェクトが正式に決まると、企業名だとは分からないユニークなプロジェクトコードが割り振られ、ドキュメントのファイル名やメールの件名に至るまでプロジェクトコードを付けて管理するようにしている。
また、開発環境の基本認証やドキュメントに設定するパスワードなども、この段階で決めてしまう。とは言え、最近ではメールやチャットでのやり取りのほか、顧客が導入しているプロジェクト管理ツールを利用して進めることも多いので、顧客特性や要望に応じて柔軟に運用している。
コミュニケーション
打ち合わせの頻度や議事録送付のルール、チャットやタスクツールの利用など、主にプロジェクト開始後のコミュニケーションについて記載する項目となる。また、メールでやり取りする場合には、必ず社内用のメーリングリストをCcで入れてもらうようにしてもらっている。これはプロジェクトの進捗状況を社内の全員に見える化すると同時に、担当者が不在の場合でも、他のスタッフが顧客に一次回答をするようにしているためだ。
特記事項
最後の特記事項のなかでは、スケジュールは今後決定する仕様や顧客が用意する素材の提供時期、フィードバックの内容やボリュームによってはずれ込む可能性があることを伝えている。
同様に、プロジェクトの途中で仕様やタスクが追加となることはよくあるが、規模が大きいものや、明らかに当初スコープから外れるものは、別途で追加費用やスケジュールの相談をする可能性があることも伝えるようにしている。こういった点を曖昧にしていると、要求は増えるのに追加費用の請求やスケジュールを変更する相談がしにくくなってしまう恐れがあるので、キックオフミーティングの時点ではっきりと伝えるべきだろう。
最後に
プロジェクト定義書の内容は、定期的に見直しを行っており、確認すべき項目を追加したり、プロジェクトの進行中に適宜説明をした方がよい項目などは削除している。例えば、プロジェクト終盤における注意事項などをキックオフミーティングで伝えても、多くの場合は忘れられてしまい、リスク回避だけを目的とした内容になってしまう。制作段階における注意事項などは、ディレクターが適切なタイミングで伝えてハンドリングするべきだ。
大切なことは、前提条件や事前に相手が不安を感じるであろう点などを先回りして、丁寧に伝えていくことだ。プロジェクトにおけるトラブルは、「言わなくても分かるだろう」といった説明不足から発生していることが多々ある。キックオフミーティングだけに留まらず、プロジェクト全般で丁寧なコミュニケーションを取るように徹底したい。
