note6:コンセプトの作り方

ゲーム業界歴10年目、ディレクターをやってます。
昨年は、中々、noteの更新できなかったのですが、年末年始休みで、少し時間があったのでが、下書きで置いていた記事を再編集して投稿します。

今回のテーマは「コンセプト」。
ゲーム開発現場、ゲーム系専門学校、カンファレンスなどなどで頻出してる言葉なので、1度は耳にしたことがある人が殆どだと思います。
頻出している反面、定義や捉え方が、会社・人によって、異なるのもこの「コンセプト」だと認識してます。
ですので、この記事に書いてあることも含め、何か絶対的な正解を求める。というよりは、自分自身で集められるだけ情報は収集し、その中でご自身に合った解釈を見つける（もっと良いのは自分の言葉で語れる）のが良いと思います。

よく「コンセプトとは何か」と聞かれ、
・そのゲームをヒトコトで表したもの。
・ベネフィット/バリュー/ターゲットをまとめたもの。
・ユーザーに与える体験(UX)を短い文章にしたもの。
・ゲーム概要/テーマ/ゲーム内の操作/楽しさ/面白さ
このような言葉で定義していることが多いのかなと推測します。
特に「このゲームの面白さ」という意味合いで定義してることが主流なのかなと思ってます。特にそれらの定義を否定も肯定もするわけではないですが、大切な観点を１つ挙げるとすると「何にコンセプトを使うか」だと個人的に思ってます。

「コンセプトとは何か」は、「コンセプトを何に使うのか」が明瞭に定義されていて、その定義を満たしているものであれば、おのずと良いコンセプトと言えるのかなと思ってます。反対に、上で挙げたような定義の深い部分の理解をせず、表層のコンセプトを作ると、形骸化します。特に「面白さ」という要素をコンセプトに組み込んだ場合ですが、作った初期は上手く回ることが多いですが、開発規模が大きくなったり、定義した「面白さ」が実は「面白くなかった」時に、途端に瓦解するのかなと、今までの経験で感じます。私自身、一番少ない時は個人開発で1人、多い時で200人規模の開発現場でディレクターの経験がありますが、何度も失敗を繰り返して、今に至ります。繰り返しになりますが、まだ完璧に、絶対解と言える定義に出会ってない為、この記事で書いてある内容も2年後に自分が見ると、古臭く感じてしまうかもしれません。ですので、この記事は、現在時点で、自分が思っている「コンセプト」についてお話できればと思います。＊余談ですが、この記事で指す「コンセプト」は1つのゲームを開発する時に用いるコアコンセプトであり、各機能ごとに個別のコンセプトを作る現場もありますが、今回はその上位概念にあたるゲーム本体のコンセプトです。

少し話が逸れましたが、「コンセプトは何に使うのか」ですね。
これも各社さん、国ごとに異なっていますが、短い言葉で言うと、開発方針を判断する時に使います。

開発方針を判断する。とは何か、ですが、ゲームというメディアは、「入力」「処理」「出力」から構成される「機能/システム」が「フロー」によって繋がれています。それら何れかを作る時、無限に手段があるわけですが、開発者の価値観や主観で、手段を決めていると、全体を見た時に、「軸」「結果」「体験」がバラバラ、または相殺がおき、まとまりに欠けてしまう状態になります。その時に、指針となるのがコンセプトです。優れたアイデア/面白さでもコンセプトと相反していれば採用されませんし、採用してはいけません。

主観、という言葉を出しましたが、「面白さ」をゲームコンセプトに組み込んだ時の罠がここにあります。何かを面白いと、感じるのは、主観的な感覚が支配的です。万人が共通して面白いと思うことは恐らく存在しないでしょう(限りなく広い人に理解される面白さは時代によって確かにあると思います)
したがって、◯◯によって△△が面白い。といったコンセプトを掲げた場合、開発中期で、△△が面白くはない。◯◯では実現できなかった。または実現でき△△の面白さを確認できたが、そもそも市場規模が小さかった。などが起こり得ます。それを回避する為、プロトタイプやMVP（Minimum Viable Product）を用いる現場もありますが、私の経験上、プロトタイプで終了するか、強引に進めた結果、結果が振るわなかったケースが多いです。

また、このコンセプトを掲げるだけでなく、開発メンバーがそのコンセプトを理解できるように、コンセプトの面白さを分解した取扱い説明書を作ってるチームもあります。どちらにせよ、「面白さ」を軸にした場合、コンセプトという曖昧な定義を面白さという主観的な定義に置き換えるたことになるので、再翻訳が必要になります。その為、開発に関わるステークホルダーが少なかったり、非常に有名なクリエイターが指揮する現場の場合は、そのクリエイターのセンスに投資している面もあるため、この方式が採用されやすいと感じます。とはいえ、私自身は「面白さ」もコンセプトを実現するための手段の1ピースだと考えています。

またゲームの中には「メインの面白さ」とは切り離された機能も沢山あります。例えば、日本刀を振り回す面白さ。をコンセプトに置いたゲームのマッチングロジックは、どのように考えると良いでしょうか。よく言われているのが、機能はコンセプトを実現する為のものですから、そのまま置換すると、日本刀を振り回す面白さを実現できるマッチングロジック。となります。よくわからないですよね。あくまでも一例ですが、こうなると、マッチングロジック個別のコンセプトを考えることになりますが、この機能用のコンセプトとコアコンセプトに繋がりを作るのは非常に困難なことが多いです。これらが「面白さの罠」だと感じます。

話を開発方針について戻します。
良いコンセプトは、開発チームを一つの方向に導き、無限の選択肢の中から最良の選択肢をチームに与えてくれるものです。つまり、機能/グラフィック/プロセス/面白さを手段とし、開発によって達成したい目的を示しています。そして、これらを作る時に複数の選択肢があった時、コンセプトの実現に一番寄与するのは、どれか。という軸で開発チームを導いてくれます。

では具体的に、どんな要素がコンセプトに必要か、私が使っているチェックリストを公開します。この内容は、カンファレンス、書籍、開発現場での失敗を集積した内容から作ったものです（これとは別に、コンセプトから除外すべき要素という観点もあるのですがここでは割愛します）

・そのコンセプトは、他の作品と差別化できているか
・そのコンセプトに、反応する市場があり、十分か
・開発実現可能性があるか
・ゲームとして成立するか

それぞれの項目について説明します。ちなみに上の項目から優先順位が高いと考えています。

コンセプトを聞いた時、他の作品と差別化できているか
あえて説明する必要は無いと思いますが、既に他のサービスや作品で達成されているものと完全に同一のものを追うのは避けた方が良いです。コンセプトを聞いた時、それって△△も当てはまるな。となる場合、考え直した方が良いです。また、完全一致はしてないが、7割程度他作品と同じ内容のコンセプトを考えつくことがあります。それ自体がＮＧというわけではないですが、先行タイトルとユーザーを取り合うことになるので、何かしら競争優位性をもって開発に挑んだ方がよいです（これは特徴的なシステムがある。等ではなく、他社が真似できない要素という意味です。このあたりは企業の戦略寄りの領域なのでまたどこかで切り出してnoteにできればと思います）しかしながら競争優位性を用意したとしてもゲームというメディアにおいては直ぐにその優位性は模倣されたり、一般化することが多いです。ですので最初から他の作品と並走することはおススメしません。

そのコンセプトに反応する市場があり十分か
どんなに独創性、差別化されたコンセプトでも市場が無ければ受け入れてもらえません。ので、市場が存在するかのチェックは非常に重要です。コンセプトチェックなど市場調査を行うのが有用です。ただし現在、市場が存在しておらず、今から自分たちで開拓する場合、周辺領域の市場はどれだけの規模かを検証する必要があります。ここで言う内容は、「ターゲット」ではないことに注意してください。

開発は実現可能性があるか
差別化され、市場が十分にあると判明しても、自分/自社のリソースを使っても実現できないものは見送るか、実現の為の土台（スキルアップ・組織づくり）を作ることをまずは優先した方が良いです。

ゲームとして成立するか
最後は、やや抽象的ですが、優れたコンセプトの中にはゲームというメディアが最適解ではない場合もあります。その場合、ゲームという手段を取らず別の方法で実現したほうが良いです。何をもってゲームとして成立するかは難しいところですが、コンセプトを作った時点で、「これはゲームで実現する必要があるか？」と自問した方が良いです。

これらの項目を作ったコンセプトに照らし合わせて、少しでも気になる部分があれば練り直した方が良いです。精度が不十分な場合でも開発や発売まで漕ぎつけること可能です（どこかで折り合いを付けながら、またはスケジュールに追われて無くなく開発するというケースがそれにあたります）しかし、往々にして結果は、ふるわないことが多いです。最初のリストに記載してませんでしたが、もう１つだけ、重要なチェック項目があります。

このコンセプトを実現する為、自分やチームの時間を費やす価値があるか
今から作るゲームが発売され、結果が振るわなかった時、何かしら表面的な罰則やデメリットを個人が負うケースは殆ど無いと思います（稀にありますが）しかし、長期化するゲーム開発現場においては、時間だけは確実に経過します。ご自身の貴重な残り時間は確実に減ります。またあなたが責任ある立場であれば、プロジェクトに関わる全てのメンバーの時間を年単位で拘束することになります。その上で、上記の質問への答えがYESでないのなら、考え直した方が良いです。

以上がコンセプトのチェックリストです。

これでこのnoteは終わりです。
この内容は、冒頭にも記載した通り、現時点で私が思うコンセプトについてまとめた記事であり、回顧録的な側面が強い為、すべての開発現場に適用できないとは思いますが、何かの参考になれば幸いです。