DcardはなぜGameNobilityを選んだのか
「ゲームを作りたい」から実際のリリースまでの協業
このプロジェクトで最も語るべき点は、ゲームが完成したことだけではありません。まだ曖昧だったアイデアを、双方が一歩ずつ、開発でき、テストでき、Dcardアプリの中で実際に動くプロダクトへと形にしていった過程にあります。
これはアプリ内に組み込むウェブゲームの開発事例です。GameNobilityはDcardとともに曖昧な要件からハイパーカジュアルなゲーム性へと絞り込み、API、ランキング、シェア機能、Android／iOSの互換性、チームをまたいだテストに対応し、最終的にDcardアプリ内でリリースしました。
協業は一つの開発者交流会から始まった
DcardとGameNobilityの協業は、台北で開かれたゲーム開発者の交流会から始まりました。当時Dcardはさまざまな開発チームと接点を持っており、ゲームを作りたいという思いはあったものの、どのようなプロダクトにするのか、まだはっきりした答えはありませんでした。
知り合ってから、双方はさらに約10回の打ち合わせを重ね、ゲームの目的、利用者層、予算、技術的な条件を一つずつ明確にしていきました。GameNobilityにとっては、ここからが本当のプロジェクトの始まりです。お客様に言われたものをすぐに作り始めるのではなく、まずこのゲームを作る価値がある理由をはっきりさせること。
Dcardはなぜゲームを作りたかったのか
Dcardはもともとコミュニティプラットフォームです。そのためゲームを作る目的はゲーム自体で収益を上げることではなく、ユーザーのインタラクションを増やし、自社のキャラクターIPがより多く目に触れ、記憶される機会をつくることにありました。
初期には麻雀やカードゲームといった案も出ましたが、こうした遊び方はブランドにギャンブルを連想させやすいものです。最終的にチームは、ルールがシンプルですぐに遊べるハイパーカジュアルなゲーム性を選びました。ユーザーはすぐに始めてスコアに挑戦でき、ランキングやシェアにも向いています。ブランドにとっても、楽しさがありながらブランド自身のキャラクターの存在感を奪わない選択でした。
本当に難しいのは、画面を作ることではない
このゲームはウェブ技術で開発しながら、Dcardアプリに直接組み込む必要がありました。ユーザーは別途ダウンロードすることなく、いつものプラットフォーム内で遊び始められます。便利に見えますが、その裏ではDcard API、ランキング、データのやり取り、シェア機能、そしてAndroidとiOSという異なる環境での互換性の問題が関わっています。
開発中には、フロントエンド、バックエンド、API連携の作業分担について、双方の理解が食い違うこともありました。窓口を介して伝言を往復させるのではなく、GameNobilityは双方のエンジニアを同じ議論の場に入れ、技術的な問題をはっきりさせたうえで、それぞれが担う作業を改めて確認しました。
この経験から、チームはさらに確信しました。異業種との協業で最も必要なのは技術力だけではなく、専門用語を相手が理解でき、行動に移せる言葉に置き換える力だということです。
大手プラットフォームとの協業で問われるのは、開発スピードだけではない
Dcardには独自のプロダクト、エンジニアリング、テストのプロセスがあります。外部の開発チームにとって、このような協業はゲームを作って納品すれば終わりではなく、相手の既存の仕事のリズムに入り込み、技術仕様、テスト方法、リリース環境に合わせる必要があります。各要件を誰が確認するのか、各コードを誰が担当するのか、問題が起きたときに誰が判断するのかを、すべて明確にしなければなりません。
これは大企業との協業で最も見落とされやすい点でもあります。企業の規模が大きいほどプロジェクトに関わる役割は多くなり、企画、ブランド、エンジニアリングから意思決定の窓口まで、それぞれが関心を持つ点は異なります。GameNobilityはブランドの期待と技術的な制約を同時に理解し、双方の情報を実行できる仕様にまとめる必要があります。
このプロジェクトでGameNobilityは、受け身で要件を待つだけではありませんでした。方向性がはっきりしないときはゲーム性の絞り込みを手伝い、APIや責任範囲の問題が生じたときは双方のエンジニアが直接話せるようにし、テスト段階ではDcardアプリ、Android、iOSの実際の環境をすべて考慮しました。大手プラットフォームの協業スタイルについていけてこそ、プロジェクトを安定してリリースまで導くことができます。
リリース後、ユーザーの継続率とシェアの動きはDcardの予想を上回り、プロジェクト終了後も双方はやり取りを続けています。
Dcardも今回のGameNobilityとの協業を、この種の協業における代表的な成功事例の一つとして評価しています。
なぜプロジェクト開始前のコミュニケーションが最も重要なのか
GameNobilityは、ゲーム開発で最も重要な段階は、プログラミングではなくプロジェクト開始前のコミュニケーションであることが多いと考えています。目標、機能、予算、責任範囲、検収方法を最初にきちんと話し合っておけば、その後の制作はずっと順調に進みます。
開発の途中で新しい要望が出てきた場合も、チームはただ受け入れたり、すぐに断ったりはしません。まずどれだけ作業が増え、どのスケジュールに影響するかを説明し、そのうえで予算を追加するのか、機能を調整するのか、元の方向性を維持するのかを一緒に決めます。必要であれば一度立ち止まるほうが、作り終えてからすべてをやり直すよりも責任ある対応です。
業界経験があるから、先に対処すべき問題がわかる
ゲーム開発は、企画、アート、プログラムのどれか一つが優れていれば十分というものではありません。画面デザインが美しくても実際の開発に向いているとは限らず、ある端末で動く機能が別のシステムに入れても安定するとは限りません。プロジェクト経験の価値は、問題が実際に起こる前に、起こりうるリスクを見抜けることにあります。
GameNobilityは長年ゲーム案件に携わり、ゲーム業界のチームやさまざまな分野の企業と協業してきた経験があります。そのため要件を受け取ると、チームはまず、ゲーム性が予算に合っているか、技術的にバックエンドの支援が必要か、ビジュアルの仕様が実現可能か、その後にシステム更新や保守が関わるかを判断します。細かく見えるこうした問題こそが、プロジェクトを期限どおりに完了できるかどうかの鍵になることが多いのです。
さらに重要なのは、業界ごとに仕事の言葉が違うことをチームが理解している点です。ゲーム業界の同業者となら多くの仕様をそのまま話し合えますが、コミュニティプラットフォームや一般企業に対しては、ゲーム開発のプロセスをより丁寧に説明する必要があります。専門用語を並べるのではなく、お客様の理解の仕方に合わせて説明し直せること。それこそがGameNobilityが業界経験を積み重ねて身につけた力です。
このDcardの案件が残したものとは
最終的に、ゲームは無事に完成し、Dcardのプラットフォーム内でリリースされました。チームへのインタビューによると、ユーザーの継続率とシェアの動きは当時の予想を上回りました。今回の協業は、GameNobilityが大手プラットフォームとの協業方法を整理するうえでの重要な事例にもなりました。
この案件が本当に証明したのは、GameNobilityがゲームを作れるということだけではなく、大手プラットフォームとの協業に必要なコミュニケーション、統合、納品の力をチームが備えているということです。要件がまだ明確でなく、関わる役割が多く、会社をまたいだ協業が必要なプロジェクトでも、GameNobilityはお客様とともに方向性を見つけ、リスクに先回りして対処し、最後にはその方向性をリリースできる成果へと落とし込むことができます。
関連記事
よくある質問
DcardとGameNobilityはどのように協業を始めたのですか？
双方は台北で開かれたゲーム開発者の交流会で知り合いました。当時Dcardはさまざまなゲーム開発チームと接触し、新しいインタラクティブなプロダクトに挑戦したいと考えていましたが、要件はまだ固まっていませんでした。GameNobilityはイベントの後もDcardのチームと話し合いを続け、約10回の打ち合わせを経て、ゲームの目的、利用者層、ゲーム性、予算、技術的な条件を少しずつ明確にし、最終的に正式に実行できる開発の方向性をまとめました。
Dcardはなぜコミュニティプラットフォームでゲームを開発したのですか？
このゲームの目的は、ゲーム自体で収益を上げることではなく、プラットフォーム上のインタラクションの場面を増やすと同時に、Dcard自社のキャラクターIPがより多く目に触れ、ユーザーに記憶される機会をつくることでした。シンプルなゲーム性、ランキング、シェアの仕組みによって、ユーザーはプラットフォームでコンテンツを読むだけでなく、ブランドのキャラクターとより直接的に関わることができます。
なぜ麻雀やカードゲームではなく、ハイパーカジュアルゲームを選んだのですか？
プロジェクトの初期には、若い世代の日常的な娯楽に関わることから、麻雀やトランプといった案も検討しました。しかしカードゲームは、ブランドにギャンブルを連想させるおそれもあります。検討の結果、チームはルールがシンプルですぐに遊べるハイパーカジュアルなゲーム性を選びました。ユーザーはすぐに始めてスコアに挑戦し、ランキングに参加でき、気軽なインタラクションとキャラクターIPの普及というDcardの目的にもより合っていました。
このDcardのゲームは別途ダウンロードが必要ですか？
必要ありません。このゲームはウェブ技術で開発されていますが、Dcardアプリに直接統合されています。ユーザーはいつものプラットフォームからゲームに入ることができ、独立したアプリを別途インストールする必要はありません。この体験は便利ですが、開発側はDcardアプリ、ウェブゲーム、API、そしてAndroidとiOSという異なる環境の間の互換性の問題に対応しなければなりませんでした。
Dcardのゲームプロジェクトで最も難しかった技術的な問題は何ですか？
難しかったのは画面やゲーム性を作ることだけではなく、Dcardの既存システムの中でゲームを安定して動かすことでした。プロジェクトにはDcard API、ランキング、データのやり取り、シェア機能、そしてフロントエンドとバックエンドの連携が関わっていました。スマートフォンのOSやアプリ内の実行環境にもそれぞれのルールがあるため、GameNobilityはテストと調整を続け、実際の利用時にプラットフォームの違いによる問題が起きないよう確認する必要がありました。
GameNobilityはDcardのエンジニアチームとどのように協業したのですか？
プロジェクトの初期には、フロントエンド、バックエンド、API連携の作業分担について、双方の理解が食い違っていました。技術者ではない窓口を通じて伝えるだけでは、情報のずれが生じやすくなります。そこでGameNobilityは双方のエンジニアを同じ議論の場に入れ、技術的な要件、責任範囲、完了の方法を改めて確認しました。こうした直接的で実務的な協業によって、技術的な問題が窓口の間で伝言を繰り返すことなく、きちんと解決されるようになりました。
お客様が最初に要件をうまく説明できない場合、GameNobilityはどう対応しますか？
GameNobilityは作業を急いで始めることはしません。まず、お客様がなぜこのプロダクトを作りたいのか、誰のためのものか、どのような成果を目指すのかを確認します。そのうえで、ブランドのポジショニング、ゲーム性、技術的な実現性、予算、スケジュールの重なる部分を探します。Dcardの案件で初期に何度も話し合いを重ねたのは、企画、アート、プログラムにすでに着手した後で、全員が思い描いていた目標が違っていたと気づく事態を避けるため、先に方向性をしっかり絞り込みたかったからです。
開発途中で追加の要望が出た場合、GameNobilityはどう対応しますか？
チームはまず、新しい要望が当初確認した機能や見積もりの範囲を超えるかどうかを判断し、追加の作業がどのコストやスケジュールに影響するかをお客様に説明します。双方は、予算を追加する、機能を調整する、元の方向性を維持する、のいずれかを選べます。核となる方向性についてまだ合意できていない場合は、必要に応じて関連する作業を一度止めます。立ち止まって問題をきちんと話し合うほうが、作り続けて最後にすべてをやり直すよりも、たいていお客様と開発チームの双方を守ることにつながります。
大手プラットフォームとの協業には、どのような力が必要ですか？
ゲームの企画、アート、プログラムの力に加えて、大企業の既存のプロダクトプロセス、エンジニアリングの仕様、テスト方法、意思決定の仕組みに合わせられることも必要です。大規模なプロジェクトには通常、企画、ブランド、エンジニアリング、テスト、意思決定の窓口などさまざまな役割があり、それぞれ関心を持つ点が異なります。GameNobilityはブランドの期待と技術的な制約を同時に理解し、情報を全員が行動に移せる仕様にまとめる必要があります。これが大手プラットフォームとの協業を順調に進められるかどうかの鍵です。
