ゲーム開発の外部発注で気を付けることはなんですか？②
サイバーコネクトツーの山岡です。
前回の記事でゲーム開発の外部発注の話をしました。
①ゲーム開発では外部発注を絡めた開発が必要不可欠
②問題発生時は発注元も問題解決にあたる必要がある
③トラブルは小さな問題積み重ねなので早期発見と対応する仕組みが必要
④そのためには押さえておくべきポイントがある
私自身、20年間のゲーム開発で多くの外部発注にかかわり、うまくいかなかったことやご迷惑をお掛けしたこともたくさん経験してきました…
トラブってしまうとマイナスをゼロに戻すために多くの労力、時間を消費することになり、お客様のためになりません。
今回はそんな私自身のしくじり経験を元に「外部発注時に問題点を早期に見つけ対応するためのノウハウ」を言語化しておきたいと思います。
１．発注前
①マイルストーン、成果物設定は発注元が明確にする
外部発注時のマイルストーンや成果物設定を発注先に任せきりにしない。曖昧にしない。発注元が最終決定をする。
マイルストーンはプロジェクトを完成させるための重要な節目であり、達成しないと先に進めない目標でもある。発注元側が言語化できていないといけない。でないと発注先が組み立てたスケジュールや内容が正しいか判断できない。正しいチェックをするためにも、なにを達成しないといけないのかを理解しておく必要がある。
外部発注の納品スケジュールに合わせてプロジェクトの全体スケジュールを組み立てるのではなく、全体スケジュールを達成する為の外部発注でないといけない。
詳細なスケジュールを立てる必要は無い。発注先に何をいつまでにどのような状態を目指すのかを伝え、その目標を達成するためのスケジュールや体制を具現化してもらう。マイルストーンや目標設定に不明な点、明確に出来ない点があれば、発注先と協議して意見を聞いて発注元が最終決定をする。
②双方のチェックフロー、責任者を明確にする
発注先、発注元のクォリティを判断する人、スケジュールを管理する人やチェックフローを確認し合った上で制作を進める。その体制やフローに沿って納品日やチェック日を決める。
外部発注は成果物が納品されたら、したら終わりでは無い。必ず検収が発生する。検収に合格しないと作業は完了しない。検収をするということは誰かが承認のハンコを押すこと。
承認のハンコが押されるまでの道のりや期間を押さえておかないと、スケジュールは簡単にズレる。また、承認のハンコが押されるクォリティラインを双方で把握しておかないと全然承認されないものを制作してしまうことになる。
チェックフローや責任者が変更になったら双方とも情報を共有する。うやむやにすると、どこでだれがいつチェックしているのかがわからなくなり、たちまちコントロールできない状態になる。
③予算内、スケジュール内で対応するフィードバック範囲を決める
発注予算、スケジュールの中で対応するフィードバック範囲をあらかじめ決めておく。
フィードバックはゲーム開発終盤まで続く。ゲーム全体が見えてきてから発生するものもある。クライアント様や版元様等のフィードバックも発生する。その物量や内容をあらかじめ予想するのは不可能。
「その後のフィードバックは対応しない」ということでは無い。発注元でさえどうなるかわからない不確定な要素の対応を発注先に求めるとスケジュールや予算はすぐに破綻する。不確定なフィードバック内容はいったん外して発注は行い、不確定なフィードバックが明確になったら残りスケジュールや予算を比べつつ追加発注や対応範囲を検討する。
ちなみに、CC2ではディレクターとクォリティラインを握り合った発注責任者がOKなら納品完了（その後のフィードバックは追加発注または社内対応）としています。
２．進捗管理
①双方の進捗状況を見える化する
発注先の進捗を見える化するだけでは無く、発注元の状況も見える化する。チェックの日付や担当者、仕様やレギュレーションの決定、クライアント様との決定事項待ちなど発注元でしか知りえない情報は多く存在する。
発注前でも触れた通り、発注元のチェックフローやフィードバック内容、レスポンス速度は進捗に大きく影響する。発注先はチェックしてくれているだろうと思っているのに、発注元のチェックが滞っていたら守れるものも守れない。
発注元の進捗も把握し積極的にアウトプットすることで問題の早期発見や対応に繋がる。発注先もスケジュールを組み立てやすくなる。
②中間成果物のチェックを曖昧にしない
最終納品までの中間成果物チェックの内容、粒度を明確にしてしっかり行う。
最終納品までに仮組みやα実装、デザインチェックなどいくつかの中間成果物が設定されているハズ。中間成果物のチェックの際「もうちょっと様子を見てみよう」「全部出来上がってからフィードバックしよう」など後回しにしてしまうと中間成果物を設定している意味が無い。最後に取り戻せない問題やフィードバックが発生して大きなトラブルに繋がる。
チェックの際に今対応しないといけないこと、後で対応することの仕分けも行う。データがレギュレーションに即していない、デザインの方針が大きく異なっている、重篤な不具合が発生している、不完全な実装または予定されている成果物になっていない、などはすぐに原因と対策を双方で協議して対応する。
また、中間成果物のチェックをしっかりと行うことで、発注時の内容との差異やここまでやっておかないと先に進めないという目線合わせにもつながる。完成の確度を上げるために以降のスケジュールや体制の見直しを検討することもできる。
③スケジュールや作業内容を安易に変更しない
制作途中で仕様や方針変更が発生することはよくある。しかし発注時に決めたスケジュール、作業内容を安易に変更してはいけない。必ずトラブルに発展する。
ゲーム開発は前工程、後工程が非常に複雑です。前工程で安易に作業内容やスケジュールを変更すると後工程のケジュールにも影響が出る。変更⇒調整⇒変更⇒調整⇒変更⇒あれ？いつの間にか当初のスケジュールから大幅に遅延している…ってなりがち。
結果、プロジェクト全体のマイルストーンに影響が出た場合、発注先の責任問題につながってしまう。また契約時の納品予定と異なる場合、正しい納品検収ができなくなり、ますます責任の所在がわからなくなる。
仕様変更や方針変更をしてはいけないということでは無く、変更する場合は全体スケジュールの確認、調整もセットで行う。マイルストーンや人員編成、契約内容も含め確認、見直しを行いチーム全体と会社間の足並みも合わせる。（発注前の①の状態にする）その上で適切な変更タイミングを判断する。
３．コミュニケーション
①連絡はオープンな場で行う
個別連絡で伝わった、伝わっていると思ってはいけない。特に口頭のみでの連絡はコミュニケーションミスが必ず発生する。企業文化や組織が異なる会社と遠隔でコミュニケーションを取る外部発注だとさらにミスが発生しやすい。結果、認識が違っていた、言った言っていないの議論に発展してしまう。
確認とか感触を伺うとかは個別でも口頭でも良い。仕様やスケジュール、優先事項の変更や決定事項、相談事項は主要メンバーの揃っている場で連絡する。さらにテキストでも共有しておく。認識違いや問題がある場合は互いに指摘し合えるようにする。「指示内容は●●さんには言ってる」という状況を無くす。伝言ゲームにならないようにする。
②定例ミーティングは必ず実施し進捗を確認しあう
日時と参加メンバーを決めて必ず実施する。議題は進捗、予定、決定事項の共有、問題有無の報告と相談。よほどの理由が無い限りスキップしない。どうしても難しい場合でもテキスト報告は行い後日開催する。発注先だけでなく、発注元の進捗や決定事項も共有する。
日時を決めることで自ずと締め切りが決まる。それまでに状況の確認をしておく必要がある。問題があれば議題とする。次の定例までの双方の宿題を明確にして進捗を報告し合う。PDCAのリズム、サイクルを作る。
ミーティングは手を止める時間でもあるので、規模や状況、残り期間によって頻度やメンバーは可変にする。無駄にメンバーを集めすぎてもいけないし少なすぎてもいけない。ただし主要メンバーは固めておく。
③共有資料は常に更新を行い、正確な情報を記載する
スケジュールや進捗資料など双方に共有する資料に現状と異なる情報は記載しない。日付やステータスは常に更新しておく。精査中で日付が記載できない、何らかの要因で未定なら、そのように記載しておく。
外部発注は顔が見えない所で多くのスタッフが稼働している。スタッフにとって資料は重要な情報源であり判断材料でもある。その資料が間違っていたら、間違った行動や無駄な作業が発生してしまう。正しい情報を得るために確認して回るコストが発生する。
口頭で言っていたとしても伝わらなければ意味が無い。トラブルが少ないプロジェクトは資料情報が常に更新されており、情報共有がしっかりしている。さらにオープンな場で共有がなされていて協力会社様含め動きに無駄が生まれにくい。
４．問題発生時
①問題発生時には双方で取れる対応を最大限行う
問題解決を一方通行にしてはいけない。問題の解決方法で行き詰まることが多い。問題解決しないと外部発注は完了しない。発注先で解決するのを待ってはいけない。発注先に問題の改善方法を求めるとともに、発注元も問題の原因を把握し本当に解決できるかを判断する。
発注元でも作業優先付けやフィードバック内容、頻度、人的サポートなど予算やスケジュールの範囲内で出来ることはある。双方が協力して問題解決にあたることが近道。それでも問題が解決しないのであれば、発注内容の見直しを行う必要がある。
②期日や成果物に変更がある場合は、会社間で協議して決定する
契約締結時の成果物や納品スケジュールをどうしても変更せざるを得ない場合は、現場間で安易に決定するのではなく会社間で協議した上で決定する。
発注先にも今後の予定や人員編成など会社の都合がある。簡単に人の延長や期間の延長、契約条件の変更が出来ない場合もある。外部発注には色々な要因が影響することを理解する。
また、どちらの責任で期日や成果物を変更するのかも重要。会社間の協議にすることで変更の責任が明確になり健全な外部発注になる。
③クレームは事実を正確に把握し会社間で協議の上、対応する
大なり小なりクレームは発生する。その際、人の問題に言及することが多い。それだと問題解決にはつながらない。
クレームは本来あるべき姿からズレが生じた原因を明確にした上で行わないといけない。そのために具体的に起きている現象と経緯を明らかにする。その経緯の中に問題に繋がるポイントが必ずある。ひょっとすると発注元にも原因があるかもしれない。
クレームは泥試合になってはいけない。誰が悪いとかではなく事実を正確に把握し外部発注を成功させるためにどうすれば良いかを判断し対応するものでないといけない。そのためには客観的な視点が必要。なので双方の会社間で協議し対応とする。
■まとめ
サイバーコネクトツーでは協力会社様とは対等な関係であるべきと考えています。以前、私があるプロジェクトのPMだった際、協力会社様全員のスタッフ名、役割を把握しておらず松山社長、宮崎副社長からものすごく叱られたことがありました。
上とか下とかではなく、互いにリスペクトの気持ちを持ち、忌憚なく意見を言い合える、力を合わせて協力できる関係が外部発注の成功につながるんじゃないかなと思います！
しかし、外部発注では様々な要因が絡むこともあり問題に遭遇しないことはありません。本記事が最前線で頑張っている方、困っている方、苦しんでいる方の少しでもお役に立てたらうれしいです。
最後までお読みいただき、ありがとうございました！
山岡 寛典