(そんなのいるかどうか知らんが…)
は、ご存知のことかと思いますが、
私、今月半ばまでソーシャルゲームの開発でベトナムでデスマっていました。
結局、このプロジェクトは発注者側が契約解除という形でプロジェクトが収束したのですが…
その時に感じた今のソーシャルゲーム開発の落とし所と言うか、SIに慣れきったオレには開発プロセスとしてあかんやろコレと思ったところを列挙していきます。
もちろん、私自身のマネージメント能力が足りない部分もあるので、そのあたりは良い感じに読んでください。
また、私は開発者であるので、あくまで開発者側の視点であるということも考慮の上、読んでください。
- 発注者(ゲーム企画)側はたいてい要求と仕様の違いを全く理解していない。
- 最初に仕様書とか要望書とか渡されるが、そんなものは当てにはならない。かならず、プロジェクトの終盤で大きな変更が入る。
- 新規にソーシャルゲームに参加しても勝てない。
- 発注者(ゲーム企画者)側があとは実装するだけと言っても、それを信用してはならない。
- 発注者(ゲーム企画者)側が仕様が確定していると言っている場合は、たいてい開発可能性を考慮していない上での仕様確定なので、その分の仕様確定プロセスは見積もりに載せておいたほうがよい
- コピーゲームっぽい要素があって、そのゲームをやったことがないなら、そのゲームを勉強する期間を1ゲームに付き1人月程度は工数に上乗せしたほうがよい
- 発注者(ゲーム企画者)側が該当するゲームに関連するゲームの開発を始めてやる場合には、仕変があとから大量変更するので、参考ゲームの数分、人月を上乗せしたほうがよい
- 仕様変更が発生した場合は、リリース時期等の調整を行いましょうと確約しても、そんなものは守られない
- マルチプラットフォームでやりたいということはしばしばあるが、自社でマルチプラットフォームの経験がない、あるいは発注者(ゲーム企画者)側がその経験がない場合は、対応しないほうが良い。それがどんな理由を並べられたとしても。もし、それでもとゴリ押しされるなら工数は2倍とっとけ。
- 発注者(ゲーム企画者)側で画面を用意しますとかいうことを言われるが、この画面の精度は当てにしてはならない。はっきり言って同じ画面を作りなおすだけの工数は上乗せしておけ。
- 運用を考慮して設計して欲しいと言われたら、実開発コストに倍位の工数を加算しておいたほうがよい。
いろいろと不満だったことを書き連ねました。
少しづつ解説。
No.1とNo.4とNo.5に関して
まあ、得てして発注者というのは要求と仕様との区別はわからないものです。これは仕方ありません。
だから、こういう部分についてはプロフェッショナルである開発者側がちゃんと要求と仕様とを整理する必要があります。
…で、ここからが重要ですが、
「あとは実装するだけ」と発注者側が言ったとしても、要求から仕様を抽出、もとい、ちゃんと要求を整理する必要はあります。
発注者のもう要求も整理できているし、仕様も固まっているなんていう甘い文句につられてはいけません。
仕様が整理できているというのは、ゲームとしての企画ができているという状態で、ゲームを実装する仕様としての仕様はまったく定義されていません。
なので、開発側としてはこの部分の工数をけちってはいけません。
そして、これは発注者と開発者とで同じ言葉を使いながら、まったく別の意味を指しているので、互いに共通認識をあわせておく必要がある場所です。
No.2について
はい、これもよくあります。SIerでもよくありますね。なんかプロジェクト終盤になって、考慮漏れが発覚するケース。
これ、まだエンプラ方面だったらまだ意外となんとかなるケースが多いのです。
代替策(これによって、目的をどのような形でもいいから達成できる方法)を何か一つ考えればいいから。
ゲームではこの辺は違います。
目的を達成するのは当然のことで、その上でクオリティを重視してきます。
なので、考慮漏れだった箇所について確認すると、もれなくその考慮漏れを隠すかのようにメチャメチャでかい仕様が追加されて返ってきます。
ちなみに、ベトナムでデスマっていたときに、このような確認をしましたが、半端無い仕様追加で返ってきました。
むしろ、この返答によって、私は発注者(ゲーム企画者)側の人間が、日本語を理解していないのではないか、ゲーム開発を終わらせる気がないのではないかという疑念を抱きました。
No.6に関して
発注者(ゲーム企画者)側が、「これこれの部分はドラ○コレやればすぐわかります」とか言った場合は、ゲーム企画者側の協力放棄にも近い(ゲームで何をやりたいのか要求を明確に伝えようとする努力を怠っている)ので、こんなやり取りがあるのであれば、ちゃんと参考ゲームを理解するための工数およびゲームの課金にかかる費用は請求しておいた方が良いでしょう。(あくまでSIerの立場でしゃべっていますが…)。
というのも、こういう説明でかたされる場合は、ゲームの要求あるいは仕様に明文化された形で仕様が残らないので、開発側に非常にリスクが残ります。
なので、こういう説明のされ方をなされた場合は、参考ゲームを実施した記録を保存しておき、どのゲームのどの箇所であるかリバースエンジニアリングして明文化しておいたほうが無難です。
で、で、で、さらにゲーム開発を現在するということは課金要素が必ず関係していますので、参考ゲームの調査には課金部分を通過しないといけません。
それは費用ですので、ちゃんと請求してください。
さらに、No.2でも触れましたが、複数ゲームのコピペな場合は、複数ゲームの要素で埋め尽くされていて、その部分を解体する必要があります。キメラを解体して、各内臓諸器官をどの動物のどの臓器であるかをマッピングする作業が発生してきます。なので、プロジェクト終盤の仕変に備えて、工数は多めに見積もっておいたほうが良いでしょう。
No.7くらい
諦めましょう。
大概はスコープは変えてくれません。
ちゃんとスケジュールを出しても、どうにかして間に合わせろと言われます。
そういう場合は、発注者(ゲーム企画者)側のキーマンを拉致って、開発現場の中に投入して、軟禁状態にしてください(キケン)。
そうでもしない限り、無理なんだということを実感させることは不可能です。
No.8くらい
マルチプラットフォームは今のうちに抑えておきましょう。
Unity、Titanium、Phonegapなどがありますが、Unityは知らんですが、他のはWebViewを用います。
HTML5の企画などに精通しておきましょう。
それでも、Native周りの実装、特にIn-App PurchaseとかIn-App Billing、C2DM、APNsとかは必ず関わってきますので、Android、iOSともに勉強していないと厳しいです。
コレに加えて、ゲーム関連のプラットフォームなどがありますので、このあたりはちゃんと勉強しておかないと厳しいです。
で、開発者側がそれらのスキルがなく、発注者側にもそれらのスキルがない場合は、地獄を見ますので、それでもやりたいと発注者側が主張するときは、片方だけに限定してもらえるように交渉するしかありません。
または、もう片方のプラットフォームには倍の工数をかけて見積もりを提出してください。
No.9
これは、私のプロジェクトだけがおかしかったのかもしれませんが、画面制作担当者がゲームの仕様に詳しくなく、出来が悪い画面ばかり送りつけられて、心のなかで「んだよ、これ！」と思いながら、ここのこの部分、こういう動きをした場合の画面がないので製作していただけませんか？とお願いする次第になります。
私はデザイナーさんを馬鹿にする気持ちは全くありませんが、チームとして目的が共有できていないような発注者(ゲーム企画者)のもとで作業しているデザイナーさんはヤル気が欠如してしまいがちです。そしてそれらは、開発者側の作業遅延として発注者側から指摘されることが多いです。
ですので、発注者側が画面を準備しますという場合は、ほぼ作りなおしを想定して工数をくんでおいたほうが安全です。
結論
この世からコピゲーはなくなるべき。
0 件のコメント:
コメントを投稿