キックオフミーティングで何するの？
はじめに
新規のお客様に自社の暗黙知は通じません。開発担当者の思い込みでプロジェクトを進めないように、プロジェクト開始時にキックオフミーティングを実施して、プロジェクトの内容と進め方についてお客様と擦り合わせをしましょう。お客様と信頼関係を築く最初の第一歩です。
プロジェクト計画書
キックオフミーティングでは、プロジェクト計画書を説明します。
今回はプロジェクト計画書について記載します。
プロジェクトの目的
開発範囲
スケジュール
前提条件
成果物
体制
コミュニケーションルール
会議体
その他運用ルール
各項目について説明します。
プロジェクトの目的・開発範囲・スケジュール・前提条件
受注前の提案書にも記載する内容ですが、お客様側の担当者に確実に共有されているか、認識違いはないかを確認するために改めて説明します。
見積りの前提条件の認識違いはプロジェクト開始後は致命的になりかねません。契約条件であることを改めて説明してプロジェクトが始まる前に軌道修正します。
成果物
納品物としての成果物を記載します。納品対象外の自社内用の資料とお客様のレビュー対象の成果物を明確にします。上流工程の成果物はレビュー対象になることが一般的ですが、下流工程の成果物は全てをレビュー対象にすることはレアケースだと思います。
詳細設計書、ソースコード、単体テスト仕様書及びテスト結果をレビュー対象から外すことができると開発側の負担は軽くなります。
体制
両社の体制図、担当者の役割を記載します。
ステークホルダー、特に、お客様側の仕様決定者と、万一、スケジュールや費用の調整が必要になった場合の交渉先となる責任者の確認は重要です。開発側は、責任者（一般的に役職者）、プロジェクトリーダー、開発担当者、営業担当者を紹介します。
コミュニケーションルール
日常使用するコミュニケーション方法を記載します。
近年ではメールよりもSlack等のコミュニケーションツールを使用することが多いのではないでしょうか。
メールだけで仕様に関するやり取りをすると仕様が埋もれてしまうリスクがあります。
仕様漏れが発生しないように、課題管理表で管理して、会議でお客様に確認して合意を得て、設計書に反映後にクローズするようにしましょう。
会議体
定例会の日時、両社の参加者、議題、提出資料を記載します。
定例会が週次であれば、お客様に毎週どの時間帯で会議に参加いただけるかを確認して、時間を確保していただきます。スケジュール表と課題管理表で進捗報告をする、成果物のレビューの場にするのが一般的です。
その他運用ルール
お客様側に特別ルールがないか確認します。
仕様追加・変更についても触れておくとよいでしょう。
プロジェクトの終盤に差し掛かってきて、仕様変更・追加を無条件に受けますと、スケジュールとコスト面で影響が生じる場合があります。
製造以降の仕様追加・変更は、変更管理表で管理し、両社協議の上、有償・無償の取り決めになることを合意しておくとよいでしょう。
