2014年9月アーカイブ

ゲーム会社のスマホアプリ開発日誌 5

今回の企画書です

201409290.jpg

今回のゲームの企画書です。

他社様にプレゼンする訳でもないので、最低限度のペラ一枚の企画書になります。

ダンジョンを進んで敵が出たら魔法で撃つという、ガンシューティングライクなゲームになる予定。

世界観はタイトルが「Wizbook」とあるように、ダンジョンがあって魔法とモンスターが出てくるRPG風の世界観。個人的にはTILTOWAITでヒャッハーしたりTELEPORTER解除失敗で「石のなかにいる」と出て絶望するようなゲームがいいなと思ったりしますですが、多分そうならないでしょう。私の好みはだいたい否決されますし(卑屈)、そもそも発言権が無いです。

これを弊社の実力の範囲内でできるものにしていくとどんなふうになるのか?

これは私自身も正直見えない所が沢山あるんで、不安だし楽しみでもありますです。

 

んでもって、

プレゼンして概要を把握したら、社長がGOサインを出したのでそれでイキ。

小さい会社なんで、決断早くさっさと行動する事にします。

だって予算少ないんですもん。

ある意味会社の命削って作るんで、早いとこ作ってしまいたい気持ちも少々。

 

通常他社様にプレゼンする場合は一枚企画書を数枚提出し、生き残った案を基に数枚~数十枚の企画書を作成する過程がありますです。

クライアントによって要求される情報が異なりますので、書くことは色々異なります。

ゲームに限って細かく書くものもあれば、予算や損益分岐の予測を書くものもありますです。

ですんで企画書を書くにしても、一人でできるとは限らないので、できればいろんな知識やスキルを持った人が参加した方が良いですね。たとえゲームでも。

 

つづく

ゲーム会社のスマホアプリ開発日誌 4

プロジェクトチームを作ります1

これがまた重要なんだわ。

開発の成否の大半がこれで決まります。

キングオブ重要。

人事が適当なプロジェクトは間違いなく失敗します。

大事な事なので2回いいます。

人事が適当なプロジェクトは間違いなく失敗します。

プロジェクトチームのデザイン

  • 外部仕様確認
  • スタッフ構成図作成
  • スタッフアサイン

こんなかんじ。

外部仕様、つまりグラフィックの表現方法や、ネットワーク仕様の有無とかを設定する事で、必要な役割がリストアップできるです。

役割のリストができたら、できる人員に割り振って、命令系統や判断する人を設定し、図にする。

これでスタッフ構成図が完成します。

大切なのは、責任の所在と命令系統と、役割の明文化。これ絶対。

よく打ち合わせで「誰が何しましょう」と決める事はよくあるんですが、明文化しないせいでお見合いエラーがおきる事がよくあるんですよね。

プランナー「世界観設定はディレクターが考えると思ってました」

ディレクター「え?俺は決めるだけだよ。考えるのはプランナーだろ?」

みたいな。

現場が判断を仰ぐ人は誰なのか?とか、最終的に判断を下すのは誰なのか?とか、最悪しくじったら誰が土下座するのか?とか。

んでもって、構成図に書いたスタッフがプロジェクトに参加してもらえるのかを確認。

人事もコーディングだ

人事作る時もUMLっぽく考えると楽なのかなと思う事もありますです。

今回はこんなかんじの構成図になりました。

201409291.jpg

スタッフ構成図_201409290.xls

一応プロデューサーが私になってます。

私の上は社長しかいないので、私が土下座できないようなとんでもない時は社長が土下座します。

プロデューサーは開発には関わりません。

プロデューサーはコンテンツをプロデュースするのが仕事ですので、プロデュースします。

開発の仕事はディレクターなので、ディレクターにまかせます。

本当はゲームの中身について色々言いたいんですけどね。

ぐっと我慢してディレクターにまかせます。

 

プロデューサーとディレクターの関係ですが、会社によって色々違うとは思います。

うちの会社では、

プロデューサー : 製作 : 出資、宣伝とか

ディレクター : 制作 : 作品を作る

という役割分担の認識をしてます。

 

例えば「トップ・ガン」という映画の場合

プロデューサー : ジェリー・ブラッカイマー

ディレクター :トニー・スコット

になり、「トップ・ガン」をぐぐればわかりますが、「作った人」は監督のトニー・スコットとして認識されてます。

 

私は、

ディレクターが「作品」を作り、それをプロデューサーが「商品」にする

という流れとして認識してたりします。

なので、「ゲームが面白い」という名誉はディレクター以下開発が受けるものなのかな。

「売り方が上手い」はプロデューサーの名誉かな。

○○プロデュースの歌手がいて、「歌が上手い」ってのはやっぱり歌手への褒め言葉ですよね。

ですよね?

 

なんて話がずれてしまったんでまた後日

つづくです

ゲーム会社のスマホアプリ開発日誌 3

企画会議をするのです

スマートフォンアプリのゲーム企画を作る事になります。

スタッフ集めて企画会議をはじめます。

全員に今回のプロジェクト概要とプロジェクトの目的を説明、周知します。

ここで出された、目的と条件にあわせて企画をたててもらいます。

■コンテンツ企画

今回はスタッフから企画コンペを行います。

段取りは以下の通り。

  • 事業計画、開発目的の周知
  • 企画規模、要求内容の周知
  • プロジェクトスケジュール説明
  • 企画コンペ
  • 企画会議
  • 企画選定

コンペ段階では極めて単純な企画書を提出し、みんなの前でプレゼンテーションしてもらいます。

何故そのようなやり方をするのかと言うと、

  • 数を出してほしい
  • しょっぱなから完璧な企画は出るとは考えない
  • 複数回コンペを行う事により、便乗アイデアを依頼する

という事がありますです。また、プレゼンテーションでは

  • 質問OK
  • 批判厳禁

とします。

これはブレインストーミング手法に近い形で、コンペ自体も開発工程に含める意図があります。

つまり、コンペを複数行う事により、優れた企画を生み出せるだろうという期待をこめます。

また、コンペを通らなかった企画も、ブラッシュアップして売りこんだり次のプロジェクトで使えるので、実質の生産効率は随分高いし、それなりの質は担保できるのかな?と思ってます。

 

んでもって何回か企画会議をした結果を持ち帰り最終的にどの企画でGOするかを、社長、私、ディレクターで決定します。

今回はディレクター提出の企画で行く事に決定しました。

他プランナーの企画も良かったのですが、もう少しアイデアが欲しいとか、まとまりが欲しいとかありましたので、今回は見合わせ。今後さらに良いものにして次回再提出をお願いしました。

企画書の提出

企画内容は企画書として書かれます。

スマートフォンアプリだとプレイ時間やプレイスタイルからして、初見で分かりやすさが要求されますので、最初の1ページでわからない企画は練り直しが必要だと思ってたりします。

今回は1ページで終了です。それ以上は必要ない企画だからです。

 

私個人はアーケードゲーム開発畑の人間だったので、

  • インストカードをチラ見でプレイ
  • レバガチャ+ボタン連打で理解
  • すぐ遊べる
  • タフなインターフェイス

でなないゲームは作ってはならないと教わってました。

もちろんコンシューマーゲームとかPCゲームとか、じっくり遊ぶゲームはそうでないのかもしれませんので、そこらへんの考えは色々あって良いと思いますが、スマートフォンアプリは「さっくりDL」「さっさとプレイ」での評価が重要なのではないかと思ってます。

(個人的にはチュートリアルすら面倒くさいです......)

 

さて、企画が決まり、企画書も出来あがったので、ここからいよいよ開発......

と思うじゃないですか。

でもまだ開発前の仕事があるんですよね......

 

つづく

ゲーム会社のスマホアプリ開発日誌 2

blog更新したら、SNSで報告するように心掛け始めました。

本業自宅警備員の私にとっては、身も張り裂けそうな思いなのですが、心身を砕いて皆様から「ありがとう」と集める社畜の鏡として普通の社会人として清水の舞台からダイブする勢いで淡々と書き込みします。

プロジェクト計画をつくるのです

最初はで最初はプロジェクト計画をごねごねとひねる事からはじめました。

プロジェクト初期はミニマム規模がベストでございますです。

船頭多くてなんとやらですから。

プロジェクトの最初は会社の目的を定めます。

これは前回のまとめでも書きましたが、

自社コンテンツの開発・公開の目的

  • 社内フローの統一
  • 会社ブランディング
  • データどり

この3つになります。

この目的を達成させる為のプロジェクトとして、「自社コンテンツ」を開発する事になります。

普通ゲームを作って売る場合は、

・お金を稼ぐ

という目的が入りますが、今回はノウハウやらブランディングイメージやらデータやらの無形資産を優先目的として、あえてお金稼ぎは外します。

(結構勇気いるんですけどね。「アプリ売ってジャンジャンバリバリ」したいじゃないですか)

プロジェクト単体で目的は複数設定すべきなんですが、相反したり多すぎる目的は削るべきかなとは思ってます。

目的は必要なんですが、当然プロジェクト達成の難易度に関わってきます。

自分のレベルと難易度を比較検討してみて、上手く頑張れは達成できる難易度設定をするのは、ゲーム屋さんの性のかもしれません。

 

余談ですが、よくエンドユーザーを「マス」と設定するのは失敗フラグだと思っていますです。

「誰に売るのか」を特化していくのがマーケティングの考えなんですが、全員に売りたいと思っていると当然どれにも特化できず、当たり障りが無いどころか全く誰にもひっかからず、全対象で敗北するのがパターンだったりしますです。

 

エンドユーザーがマスになっているコンテンツは、コアゲーマーから順番に浸透していき、一般層あたりまで浸透していった結果だったりしますです。

私はマスに売れるかどうかは、ゲームユーザーに浸透してからのマーケティングの問題なのではないかな?と思います。

色々とこれだけでいっぱい書きたくなりますが、ここいらで閑話休題。

 

プロジェクトの目的を設定したら、次はプロジェクトの計画を考えます。

最初は紙とペンで適当に書き散らかすのが私スタイルです。

紙にペンを走らせると、脳内が活性するのか、コックリさんが降臨するのか、宇宙電波を受信するのかわかりませんが、アイデアを出したり考えを整理するのが捗りますです。

プロジェクト計画

  • 会社目標
  • 年度計画からの予算・日程
  • 開発ラインの確保
  • 社内開発事業計画

難しい事を考えているようですが要は

「目的を達成するには何するの?」

「何時までにどんくらいのお金使って大丈夫?」

「誰がやるの?」

「書類にしてね。『頭の中にある』は無しね」

という事で、5W2Hを書類にして、それっぽくする事です。

 

まあ、これらをしっかりしないと後で大変な事が起きるんで、やっぱり大切な仕事です。

これやらないと具体的にどんな事態ですったもんだするかと言うと、

  • 開発も佳境で「これも実装しなさい。必ず」と追加仕様
    →死ぬ
  • 「予算も日程も足りない。何か削んなきゃ」
    →「どれも大事だから削れない」
    →ズルズルとコアラのデスマーチ
    →バグだらけのクソゲー完成
    →プロジェクト死亡
  • 現場「人増やしましょう」「予算増やしましょう」
    →プロデューサー「よくわからないからだめ」
    →プロジェクト死亡
  • 「作ったはいいけど、これでよかったんだっけ?」「さあ?」「そもそも俺ら、何したかったんだっけ?」
    →存在意義不明で死ぬ

結果どのルートもバッドエンドしか見えません。

同人ならば「良い思い出だったね」で済むかもしれませんですが、一応仕事ですしお金動いてますし、生活かかってますんで、使ったリソース分以上の成果は回収せんといかんのです。

「失敗したけど、これはこれで意味あったし、頑張った僕らを褒めてよう!」とか青春は学校でやりたいもんです。

 

てなわけで、事業計画書とにらめっこしながら社長とペン走らせて適当にプロジェクト資料を作って確認。

多分これなら失敗しても会社が潰れないであろう、と予測したら双方でOKを出す。

(社長も私も極めて勝負弱いので、失敗前提で考えます。負け組の極致w)

その後テキストで作成して社長に提出。

あまり豪華な資料は作りません。簡潔にわかりやすく。

決断が遅れると現場の負担は10倍にもなりますし、判断が複雑だと現場の混乱は10倍にもなります。ですので、素早さと簡潔さが求められます。

 

余談ですがうちでの「簡潔にわかりやすく」は

  • 箇条書き(リスト)であること
  • 定量的であること
  • 5W1H(2H)が記述されていること

が基本だったりします。

なんせ社長も私も、文章だと目が滑って頭に入らない人種ですし、「すっごく沢山」と言われてもよくわかりませんし、「かなりいい感じによろしく」言われてもトラブルの予感しかしません。

更に

  • 表にすること
  • 図にすること

があるとうれしいです。

そして必ずドキュメントに残します。

なんせ忘れやすいんで。私も社長も。

 

このblogは徒然なるままに書いてるので、わかりづらくてもすいませんとしか言いようがないです。すいません。

 


つづく

ゲーム会社のスマホアプリ開発日誌 1

そうだ。ゲームつくろう

昔からずっと会社でゲームを作りたいと思っていたので、作る事になりました。

いや、普段からゲームは作ってるんですが、うちの会社って普段はクライアントの依頼で作ってます。簡単に言えばデベロッパーという立場。ですから自分勝手に作りたいゲームを作るって事はほとんど無いです。

しかもゲーム開発やパブリッシュを全て通してやれる機会も無いので、いつかはやりたいなと思ってました。

社長も常々「作りたいなあ~」と言ってはいたのですが、色々大人の事情もあって難しい顔してました。お金とかお金とかお金とか。

最近感じていた必要性は以下のような事

  • 会社としてスマートフォンアプリの業務をなるだけ全て網羅して経験した方がよさげ
  • これがうちの会社だ!と言えるものが欲しい
  • 仕事全体を全スタッフが直に見る機会があった方がよさげ

つまり、「自社完結で全てをまかなって見たい」という事になります。

今まではパート毎に他社さんにお願いしたりしていたのですが、他部署のかゆい所をわかってないんじゃないか?とか思ったりもしていました。

特にゲームに直結していない広告とかそういう所ですね。

まあ、なんだかんだいっても

「自分たちの好きなようにゲームを作りたい」

これが一番の動機です。

で、これからゲームを弊社で作っていくのですが、

「こうご期待!」

ではネタに乏しいので、作っていく過程をここに報告していこうかなと思ってます。

クライアントいませんので、秘密保持契約とか関係ありませんし。

どうせ社長もOK言ってくれましたし。

許せる範囲で公開していければと思いますです。

んでもって先日その事を本プロジェクトのディレクターに言ったところ、

「わかりました。そんな事よりフォントください」

って仰ってくださったので、心置きなくここに書くことにしますです。

今回私のポジションですが、スタッフ構成図を見ると

  • 技術協力
  • マーケティング
  • デザイン

と書いてあったので、デザインを削除。これでよし。

いや、絵描きたいですが、それやると「お前は仕事するな」と社長に怒られるんで。

私は「総務」なんで。

今回のまとめ

自社コンテンツの開発・公開の目的

  • 社内フローの統一
  • 開発・運営の全てを自社で賄うことにより、企画・開発・公開・運営まで一通りのフローを統一させます

    なかなか全部させてもらえる仕事はありませんので、自分で仕事つくります

    ほら、よく言うじゃないですか?「仕事は自分で作れ」って

  • 会社ブランディング
  • ラムダ・プランニングってのをクライアント、エンドユーザーに知ってもらう

    うちが素直に作るとこんなゲームになるって事を知ってもらいたいな、と。

    10年会社続いても尚「うちらしさって何だろう?」ってまだまだ分からないんですけどね

    自分探しの旅かもしれんです

  • ・データどり
  • 実際に運用してデータをとる

    身に沁みないとわからない事は沢山ありますです

つづく

ゲームデータ制作の段取り 6

作成作業

仕様についてチェックする事が完了しますと、記入項目にそってデータを作っていきます。

データ作成に入りますと、ここからはスタッフのクリエイティブな能力を存分に発揮していくことになります。

ここでは決められたスケジュールないで満足のいくものが出来上がっていくように、下記のような事をチェックしながら作成作業を続けていきます。

また、一気に作成すると仕様の解釈に齟齬があった場合に膨大な修正がかかったりして大変なので、まずは少量のテストデータを作成し、問題が無い事を確認してから本格的な作業に入るほうが良いでしょう。

  • シナリオ仕様との妥当性
  • データ仕様との妥当性
  • クオリティチェック

シナリオ仕様との妥当性

  • シナリオ
  • キャラクター設定
  • 背景世界説明
  • アイテム設定
  • 用語指定
  • 表現規制

作成されたデータが上記の仕様にマッチしているかをチェックします。

データのチェックは必ず作成者以外の人が行います。

仕様にない記述があったり、仕様から外れるような記述があった場合は、ディレクターや担当者に確認をとり、修正するかそのまま行くかを判断します。

データ仕様との妥当性

データについてはゲームによって個別色々ありますが、これも必ず管理担当者がチェックを行うようにすべきです。

  • ユニークID
  • データのリレーション指定項目
  • 文字数
  • テキストコード
  • 改行コード
  • 挿入タグ・変数の仕様

また、作業者も管理担当者も、マクロやチェック用の簡単なプログラムを作る事をお勧めします。

機械的に確認する事は、チェック時間を大幅に減らせるだけでなく、チェックミスを減らし、時間と集中力をクリエイティブな方向に集中させる事ができ、より良いものが出来上がるようになります。

個人的には正規表現くらいは全員使えて欲しいな……なんて思ったりしてます。

いやね、だいたいの機械的チェックは正規表現使ってチェックすれば、あっという間にチェックすみますし、改行位置の全データ修正とかも一括修正してからフレーバー修正すれば、修正≒クオリティアップにつながると思ったりする事多々なんです。

納品

てなわけで色々完璧な準備と完璧な段取りをして、すんなり納品……

とはほとんどなりません(笑)

作業者が風邪ひいて倒れたり、牡蠣にあたったり、やる気なくしたりしてスケジュールがのびる場合があります。ので、多少バッファを設けてスケジュールを組んでおくのが吉ですね。

(それでも夏休みの宿題のように、最終日に頑張るのが人間の業かもしれませんが、それでも人類を信じてみたいとテーマらしい事を言ってここで一旦終わりにします)

ゲームデータ制作の段取り 5

注意する事

工数がかかる仕事

通常テキストデータを作成する際には発生しないのですが、下記のようなゲームについては必要な作業が追加されるものがあります。

主に専門性が高いジャンルを扱ったゲームや、歴史的事実にたがわないように作らなければならないゲーム、原作を扱ったゲームなどです。

これらのゲームは、作成する前に事前の調査が必要で、その為の資料をあつめたり、資料を作る必要があったりします。

また、データを作成した後で事実と間違っていないかチェックしたり、ある程度のデフォルメ表現をしたとしても、それが許容できる範囲であるか判断したりする作業が発生します。

昨今の「ネオ歴史もの」ではあまり重要視されていない傾向がありますが、ヘビーなファンがつきそうなコンテンツや、歴史のあるコンテンツではものすごく労力と神経を使うお仕事になります。

原作ものでは原作者チェックが入りますが、原作者様も大変忙しいので、なかなかチェックを入れられずにスケジュールがずれ込む事が多々あります。思い入れのあるキャラクターの口調については、かなり細かいチェックが入りますので、リテイク回数が多くなります。

  • 専門性の高いジャンル
  • 事実誤認が許されないもの
  • 原作もの
  • 事前調査が非常にかかるもの

まだちょっと続くんじゃ......もうちょっと......ちょっと......