キックオフ前の確認事項

この時期にやる意味

契約が終わると、つい「あとは任せた」という気持ちになります。しかし着手直後の数週間は、決めごとが最も多い時期です。ここで待ちが発生すると、後の工程がそのまま後ろにずれます。逆に、着手前の数日でこのリストを埋めておけば、開発側は初日から手を動かせます。相手から求められる前に、こちらから渡す姿勢が、結果的に自社の時間を守ります。

1. 契約書の内容を関係者が読んでいるか

契約書に署名した人と、日々やり取りする人が別なことはよくあります。範囲、納期、検収の条件、追加費用が発生する条件、成果物の権利、保守の扱いについて、実務の担当者も内容を把握しておいてください。特に「どこまでが契約の範囲か」を実務者が知らないと、善意で範囲外の依頼をしてしまい、後から費用の話で気まずくなります。

• ✓契約の範囲と、範囲外になる作業の条件
• ✓検収の方法と、検収期間
• ✓追加費用が発生する条件と、その承認の手順
• ✓ソースコード・デザインデータの権利の扱い
• ✓契約期間の終了後、保守をどうするか

2. アカウントを自社名義で用意する

ドメイン、サーバー、クラウド、各種外部サービスのアカウントは、原則として自社名義で作成し、管理者権限を自社が保持します。開発会社の名義で作られていると、将来の移行や解約の際に手続きが煩雑になります。開発期間中は開発側に権限を付与し、終了後に整理する形が扱いやすくなります。支払いに使うカードの名義や、請求書の宛先も、このタイミングで揃えておいてください。

• ✓ドメインの名義と、更新の管理者
• ✓クラウド・サーバーの契約名義と請求先
• ✓外部サービス（決済、メール配信、解析など）の名義
• ✓誰にどの権限を渡すかの一覧と、終了後の整理方法

3. 連絡・進捗共有と、決める人の流れを決める

どの手段で、どの頻度でやり取りするかを最初に決めます。手段が分散すると、決定事項がどこにあるか分からなくなります。チャットでの相談、定例での判断、記録を残す場所、という3つの使い分けを決めておくと運用が安定します。返答の速さについても、互いの現実的な線を共有しておきます。あわせて、判断ごとに誰が決めるか、確認にどれくらいかかるかも開発側に伝えてください。決裁が定例会議に依存する場合は、その日程と資料の締め切りまで共有すると、相手は確認待ちを織り込んだ段取りを組めます。

4. 自社が用意するものと締め切りを決める

原稿、画像、ロゴ、既存データ、社内規程の確認結果など、自社側で用意するものを一覧にし、締め切りと担当を入れます。「開発が進んでから用意すればよい」と思っていると、いざ必要になったときに数週間かかることがあります。特に写真の撮影や、法務の確認が必要な文章は、着手と同時に動き始めてください。原稿が揃わないまま開発だけ進むと、最後に仮の文章のまま公開する事態になりがちです。

• ✓掲載する文章の原稿（誰が書き、誰が確認するか）
• ✓画像・ロゴ・動画（権利の確認を含む）
• ✓既存システムから移行するデータ（形式と件数）
• ✓利用規約・プライバシーポリシーなどの文書

5. 完成の基準と、確認・公開の段取りを決める

「完成したら教えてください」では、検収の場で認識が割れます。何ができていれば完成とするかを、動作の形で書いておきます。画面の見た目だけでなく、「この操作をして、この結果になる」という形にすると、双方が確認しやすくなります。対応する端末やブラウザの範囲もここで確定させます。あわせて、動作を確認する環境を誰がいつ用意するか、本番へ切り替える手順と、うまくいかなかったときに戻す手段も、この段階で話しておきます。既存のシステムを置き換える場合は特に重要です。

• ✓主要な操作ごとに、期待する結果
• ✓対応する端末・ブラウザの範囲
• ✓検収に参加する人と、確認にかける日数
• ✓確認用の環境の用意の担当と、外部に見せない方法
• ✓本番公開の手順と、問題が起きたときに元に戻す手段

6. 個人情報とセキュリティの前提を確認する

どんな個人情報を扱い、誰がアクセスでき、どこに保存されるかを整理します。社内に規程がある場合は、それを開発側に共有してください。規程が無い場合は、この機会に最低限の方針を決めます。外部サービスを使う場合、データがどこの国に保存されるかを気にする取引先もあるため、早めに確認しておくと安心です。利用規約やプライバシーポリシーの用意も、公開直前ではなく今から始めてください。

• ✓扱う個人情報の種類と、保存する期間
• ✓誰がその情報にアクセスできるか
• ✓外部サービスを使う場合、データの保存先
• ✓利用規約・プライバシーポリシーの用意と、確認の担当

7. リリース後の運用を決めておく

公開したら終わりではありません。誰が問い合わせに答えるか、不具合を見つけたらどこに連絡するか、保守の範囲と対応時間はどうなっているかを、着手前に確認します。運用の体制が決まっていないと、公開直後に社内が混乱し、せっかくの開発が評価されません。公開直後は問い合わせが集中しやすいため、最初の1〜2週間だけ体制を厚くしておくと落ち着いて対応できます。

• ✓利用者からの問い合わせの受け口と、対応する人
• ✓不具合を見つけたときの連絡先と、優先度の付け方
• ✓保守の範囲・対応時間・費用の扱い
• ✓定期的に確認する数値と、その見方

8. キックオフの場で確認すること

初回の打ち合わせでは、進め方の説明を聞くだけでなく、ここまでの項目を一緒に確認してください。相手の理解と自社の理解がずれている箇所は、この場で洗い出すのが最も安い時期です。最後に、うまくいかなかったときにどう相談するかも話しておくと、後で切り出しやすくなります。なお、契約や個人情報の扱いについては一般的な情報であり、個別の事案は専門家にご確認ください。

• ✓最初の数週間で何が決まっている必要があるか
• ✓互いの理解がずれている箇所はどこか
• ✓うまく進んでいないと感じたときの相談方法