CEDEC 2010「アジャイル開発手法スクラムの基礎とゲーム開発導入事例」

セミナー

今回はゲームリパブリックさんのアジャイル開発手法のセッションまとめます。

このセッションは、アジャイルとはなんぞや？スクラムはどういうもの？という基本的なところからの説明で非常に分かりやすい内容でした。今までアジャイルの基礎をすっ飛ばしてきた自分には最適です。

なので自分でも詳細を振り返りつつ、レポートしてみます。

概要

スクラムの基礎の紹介と、ゲーム開発に導入した時の成功・失敗談

公式サイト

スクラムの基礎

参考にした資料
スクラムとは何か？
アジャイル開発手法とは何か？
  • ウォーターフォール型開発とは下図のように、仕様書を決めてから開発を行う手法
  • 仕様書通りのものは完成するが、途中でレビューを設けていないので、完成してから「あれ？思ってたものと違う」となることが多かった。


  • アジャイル開発とは「繰り返し開発」と呼ばれ、定期的にレビューをして、開発を繰り返す手法
  • 特徴としては、レビューを複数回設け、ここで「思ってたものと違う」となった場合は、仕様を変更して開発を繰り返す

質問：ゲーム開発はウォーターフォール？、アジャイル？
  • そもそもゲーム業界は、昔からアジャイル開発のような事をやってきた
    • 「プレイしては仕様変更」というのはゲーム開発特有のもの
アジャイル開発の種類


スクラム系が74％を占める
スクラムの技法
  • 1.チーム分けと役割
  • 2.リリース計画
  • 3.スプリント計画
  • 4.スプリント
  • 5.デイリースクラム
    • バーンダウンチャート(残作業時間リスト)
  • 6.スプリントレビュー
  • 7.ふり返り
スクラムの流れ

  • パブリッシャーさん・スタジオマネージャー・お客さんから要望を聞く
  • プロダクトオーナーはゲームに入れたい要素を羅列(100〜500個になる)
    • 「攻撃が欲しい」「モードが欲しい」など
  • チームメンバーは、その仕様を細分化
    • 攻撃が必要なら、モーション・キー入力・SEが必要になってくる
  • スプリントバックログに基づき、スプリント
      • バーンダウンチャート
  • 2〜4週間後にゲームが完成
  • そのゲームを、チームメンバーでレビュー
    • 振り返りを行ない、プロダクトバックログを書き換える
コレらを繰り返し繰り返し、ゲームの完成まで続ける

1.チーム分けと役割

  • チームの人数は5〜8人が理想的
    • チームの中の一体感・情報伝達のしやすさ
    • 人数が多い場合は、チームをいくつか作る
      • そのチームの代表同士で、またチームを組む
チーム分け
  • これまでのチーム分けは職種ごとに行われる場合が多かったが、スクラムでは特徴(機能)ごとに職種混同のチームを作成する
    • チーム単体で成果があげられる
特徴ごとのチーム分け
  • 例えば「バトル」チームがあった場合、
    • 企画：1人
    • デザイナ：3人
  • プログラマ：2人
  • エフェクト：0.25人
    • 0.25というのは、チームの掛け持ちを行う場合もあるため
職制を越えて意見を出し合い、チーム内で仕様を作っていく。
役割：プロダクトオーナー
  • チームに所属し、以下の責任を負う
    • 黒字にする責任
    • ビジョンを提示する責任
    • ゲームに入れる要素の決定権
    • ゲームの出荷時期の決定権
  • あくまで決定権なので"独裁者"ではない
  • プロデューサーや、ディレクターがなることが多い
役割：スクラムマスター
  • 2〜4のチームに所属し、以下の役割を担当
    • 進捗のチェックを行ない、障害を取り除く
    • 改善立案をする
    • レビュー・振り返りの準備
    • コミュニケーションを促進させる
  • 何かを決定はしない
  • プロジェクトの流れを促進する役割
  • 出来れば開発者・プロダクトオーナーと兼任しない方が良い

2.リリース計画

内容 重要度 工数(時間) PG 2D MODEL BG VFX 企画
車を20台作る。なぜなら他のゲームが19台だから 800 300 40 70 160 0 20 10
ヘッドライトが点灯して欲しい。何故なら車の接近に気がつかない 1000 20 10 00 0 0 10 0
壊れるように... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... ... ...

※この表はイメージです。

  • ゲームに必要な機能をまとめたリストを作るのが目標
  • 機能・理由(何故必要なのか？)・重要度・工数を書く
  • 最初から全てを書くのは無理、徐々に追加していく
  • 更新出来るのはプロダクトオーナーのみ
  • プロダクトバックログはチーム全員が見れる場所に置いておく
    • チームメンバーの目に触れる所印刷して壁に貼るなども効果的

3.スプリント計画(作業計画)

  • 今回のスプリントで行う内容を決めるMTG。最終的に出来るのはスプリントバックログ
    • プロダクトバックログの中からプロダクトオーナーが決定
      • 決定するのはプロダクトオーナーだが、みんなで相談して決めるのが基本
      • プロダクトバックログに記載した"重要度"の高いものから行う
      • その内容がスプリント内で実行できるか、実作業者が見積もる

4.スプリント

  • スプリントバックログで決めた内容を消化していく
    • 毎日朝会を行ない、進捗確認・バーンダウンチャートの更新を行う
    • 期間は2週間〜1ヶ月
      • ゲームは2週間(次書こうと思っているQ-Gamesさんの事例では1週間と言われていました)
    • 付箋とバーンダウンチャートを使用して進捗を把握する
      • 紙が良い。常に関節視野に入る事でメンバーにスケジュールに対して意識を持ってもらう
    • スプリント中の追加作業は避けるべき
      • チームの責任と自律性を保つ
    • 自分たちで作った計画に責任を持たせるため
    • 途中で仕様を追加して「コレ入れたからスケジュール伸びても良いよね」となるのを避ける
ゲームでは仕様が変わりやすいので、期間が2週間というのはここから来ている

5.デイリースクラム(朝会)

  • 平日の決まった時間(15分前後)に行う
  • 各自が以下の報告を行う
    • 昨日、なにをしたか
    • 今日、なにをするのか
    • 問題はあるか
      • メンバーがお互いの進捗を確認するのが目的
      • 雑談は入れない

6.スプリントレビュー

  • 成果物の確認会
  • スタッフ全員とプロデューサーとディレクターが参加
    • 現状の確認
    • 問題点
    • より良くするアイデア

7.ふり返り

  • 各チームでそれぞれ今回のスプリント内容を振り返り、改善案を出す
    • 反省会ではなく、改善する会議
    • KPT法が使われる事が多い
      • Keep : 今回良かった所。これからも続ける
      • Problem : 今回の問題点
      • Try : 今後改善するところ
チームメンバーで相談しながら、次やることを決めていく
KPT法：例
  • Keep : プラグインで作業効率が上がった
  • Problem : モーションのエクスポートでトラブルが多かった

↓

  • Try : モーションエクスポーターに、不具合チェック機能を追加

スクラムを導入すると

  • リソースの破棄が減る
    • コミュニケーションの強化(デイリースクラム・ふり返りなど)
    • ビジョンの共有
  • 管理コストが減る
    • 自己管理
  • スケジュールが明確になる
    • 透明化(プロダクトバックログ・バーンダウンチャート)
開発効率が上がる！！

スクラム導入事例

  • 2009年末頃からの新規PJ
  • メンバーは20〜30名
  • 過去、同じチームで製品を開発したことがある。
まずはディレクター(プロダクトオーナー)に賛同してもらう
説明するときのポイント
  • 実績を伝える
    • Bioware,Valse,Naugty Dogで採用されている
  • 味方を作っておく
  • 正しく理解してもらうために
    • 専門用語は極力使わない

1.チーム編成とメンバーの役割

  • 今回は、3つに分けた。
上の説明では職種では無く、機能ごとに分けると書いていたが・・・
  • 何故、機能ではなく、職制でわけたのか？
    • そもそも、機能で分けるほど人数がいなかった
    • スクラムをいきなり導入して、編成を大きく変える事を避けた
取り入れたスクラムの技法
スクラムの機能 現在のPJ 以前のPJ
チーム分けと役割 X X
リリース計画 △ X
スプリント計画 ○ X
スプリント ○ X
デイリースクラム ○ X
スプリントレビュー ○ △
ふり返り X X

スクラムを導入することで、開発効率が落ちては本末転倒。
チームに合った導入方法を探す事も大事。
ただ、振り返りについては、無理にでも導入した方が良かった。(理由は後ほど)

2.スプリントバックログ

スプリントバックログは、Redmineで管理

  • バーンダウンチャート機能は無かったが、ガントチャート機能で代用
  • 紙はさすがに面倒なのと、チームが以前Tracを使っていたので、乗り換えやすかった
  • 紙ではないので、常に眼に触れるわけではないので、そこは不便だった
    • 現在も悩んでいるところ
おまけ

3.スプリント

  • 期間が2〜4週間と言う事だったので、ひとまず4週間に設定。
    • パブリッシャーへの提出が月1だった
    • 今までのチームが1ヶ月単位で動いていた
      • ただ、やはり長かった・・・。
  • 開発期間1年のプロジェクトだと、8回くらいしかレビューできない
    • 8回しか変更できない・・・。
  • プロジェクト中、時々仕様変更が入ってしまった
次は2週間で検討

4.レビューとふり返りでの工夫

  • 最初はとりあえずチームメンバー全員を集めた
    • 会議室に全員押し込んだ
    • 時間は2時間
  • プロダクトオーナーが遊んだ後、メンバーが自由に遊んでみた
結果はあまり良いものではなかった
  • 日本人特有、意見を出す人が少ない
    • ひとまず、声の大きい人から意見が徴収できた
    • メンバー全員で、ゲームの進捗の把握ができた
  • 2回目からは、1回30分交代制
    • 最低6人(プロダクトオーナーは、全てに参加)
  • 発言しないメンバーへの対策
    • 付箋に良かった点・改善点を書き、壁に貼っていく方式に
  • リラックスできるように、お菓子を常備
結果：
  • 付箋だと、たくさんの良い意見と、たくさんの悪い意見を徴収できた
  • 30分だと拘束時間も短い
  • ただ、人数が少なくなるので"議論"ができなくなった
  • レビュー会以外で、議論の場を設けて改善

5.振り返り

  • 会社には全く無かった習慣だったので、当時は効果が不鮮明だったため導入を見送った
    • ただし、次回からは導入したい
何故なら
  • 制作タイムライン改善の機会がなかった
    • レビュー会で問題点を洗い出せるが、それからどうしようという行動を議論できなかった
    • 行動を議論する場所が"振り返り"のはず

まとめ

スクラムの効果
  • メンバーの意見が多くひろえるようになった
    • レビュー会の付箋・議論の効果が大きかった
    • ビジョンが共有できるようになった
  • リソースの破棄が減った
    • 朝会の効果
  • チームが生き生きしている
    • 目で見て感じるくらい
    • 周りのチームからも「あのチーム楽しそうだよね」と、よく言われるようになった
      • ビジョンが共有できて、迷い無く仕事が出来ている
スクラムを10ヶ月続けてみて
  • スクラムをやっていない周りのチームでも自主的に朝会を初めた
  • スクラムというのは、良い開発習慣を集めたもの
    • 朝会を始めるだけでも、情報共有が円滑になる
    • ハードルが高いと感じているチームでも、一つ一つなら導入は容易ではないか

さらに学びたい方へ

参考資料

特におすすめな資料3点

勉強会

※こちらも1点、書き逃しています…。このあたりのどれかだったような…。

そろそろ寝ます…。次はQ-Gamesさんのアジャイル開発レポートしますー。

CEDEC 2010「いまどきのUIワークフロー」と、UIアーキテクト職について

セミナー

このセッションはゲームデザイン枠で行われた、30分のショートセッションです。

今年のCEDECから導入されたショートセッションですが、必要な情報のみで構成され、要点も分かりやすく、個人的には満足なものが多かったです。

ではレポートです。

概要

Scaleformを利用したワークフローの紹介と、UIアーキテクトのススメ

  • 一般的なUI作成の流れ
  • 問題点
  • 方策
  • 事例デモ
  • Scaleformを導入して気づいたこと
公式サイト

CEDEC2010:いまどきのUIワークフロー

一般的なUI作成フロー


チェックから仕様まで戻る
  • 手触りが悪いと、1から作り直し。
  • 手触りがわかる段階が遅い…。
海外のパブリッシャーはユーザーテストを行う事が多い
  • メニューのどこどこで、ユーザーが引っかかったので対応してくれ。というエクセル表が直接来る
    • 理由としては「UIで設定がしにくい」というだけでメタスコアが下がる
    • メタスコアは減点方式なので、対象は潰せと言われる
  • ユーザーテストは、開発末期にくる事が多い
    • 結果、対応が困難な状態になる

昔のワーフローの問題点

１、他種類のアセットとのやりとりが発生する
  • 全ての種類のアセットを一元管理できる
２、アートとコードが混在している
３、早い段階での動作確認が出来ない
  • 実機と同等のプレビュー構成
４、貴重なリソースが拘束される
  • 各職種が並列進行できるワークフロー

→Scaleformの導入で解決

方策

UIアーキテクト職の新設
  • UIアーキテクトが、Flashで各メニューの"モックアップ"を作成
    • 画面遷移・必要な情報・コンセプトレイアウト・触り心地を決定する
    • Action Scriptも書く

→プログラマ・デザイナ・UIアーキテクトの並列作業が出来る
→またFlash上で触り心地が確認できるので、後戻りが少ない


Scaleformを導入して気づいたこと

コンポーネントで動作の指定
  • オプション画面の遷移
  • ドロップダウンメイン
HUD
  • ScaleformをC++で叩く
  • 昔ながらの手法で
まとめ
  • Flashを導入して、半年経っていないくらいの期間
  • 難しかったところ
    • 描画負荷やメモリ負荷のコントロール
    • Action Scriptに頼る部分が多い
    • Flashコンテンツ制作のノウハウが必要

質疑応答

Q,Action Scriptの習得はどれくらいかかったか？
A,Action Script 2.0であれば比較的簡単
  • プランナーは、他の作業をやりながらでも1月やっていれば大体わかってくるはず
Q,UIアーキテクトを分けていたが、作業分担はどうしているのか？
A,前回は、自分がディレクターとUIアーキテクトを兼任した
Q,メモリの負荷計測に"アンプル"AMPっていう機能が便利だが使っているか？
A,使っている。便利だった。
Q,会社がUIのミドルウェア導入に否定的。「Scaleform採用！」はゲームの売りにならない
A,お金を出してもらうための説得方法を考えてみてはどうか？
    • コンバーター作るのにも、お金かかる
    • 仕様が決まらないので、どうにかしろ！とか。
Q,UIアーキテクトをさがすのが大変。今後さがす方法はあるか？
A,Flashって事で、WEB業界をさがすのはどうか
  • 餅は餅屋。Flashの専門家に任せたほうが良い


以上。

CEDEC 2010「torne(トルネ)のUIでこだわった19のポイント」

セミナー

CEDEC2010、3日間参加してきました。

かなりたくさんセッションを受講したので可能な限りレポートしようと思います。ただ、すでにニュースサイトではたくさんアップされているようなので、かぶらないように最初はtorneのやつから書こうと思います。

概要

PS3専用の地上デジタルレコーダーキット「torne（トルネ）」の開発の経緯の紹介
  • torneのコンセプト
  • torneのUIでこだわった19のポイント
  • 技術面から見たtorne
公式サイト

コンセプト:Torneと家電の違い

Torneは開発当時、BD/DVDに焼けない、CS/BS/短波が映らない、録画モードが標準しかない、撮った映像を編集出来ないなど欠点があった。

→そこでTorneでしか体験出来ない、スペックに頼らないモノづくりの追求

家電製品 torne(トルネ)
コンセプト 機能ベース(Function Oriented) ソリューションベース(Solution Oriented)
機能 あらゆるニーズに答えるため多機能 簡便化
差別化 機能重視（〇〇エンジン搭載など） ソフトウェア
総じて No.1商品を目指す Only Oneを目指す
  • 家電は他社と差別化した要素を入れたい。なぜなら機能の○☓表で比較される。結果、機能ベースになる。
  • Torneに関しては初めからそんなに機能がない。UI強化・トルミル機能・リモートプレイを絞って投入。
  • Torneはハードウェア的にそんなに凄いものではないのでそもそもNo1は目指せない。
    • Only Oneを目指す。

Torneを生み出せたのは？

１、社内でも珍しい制作体制
  • ソフトウェアプラットフォーム開発部(システムソフト)と、SCEJAPANスタジオの連携(ゲーム)
  • GUIのデザイン部分はデザイン会社Mu.Incが担当
２、ゲームデザインのノウハウ

PS3らしいレコーダーとはなにか？

  • 圧倒的な快適操作の実現
    • XMBに通じる、サクサク動くUI
  • PSPとの連携
    • PSPに書き出して、外に持ち出す
    • TVから離れてのリモートプレイ
  • ネットワークを利用した、新しい体験
    • トルミル機能で、他のユーザーの視聴がわかる
    • TVを見ながらWEBを視聴できる
    • ネットワークアップデートで、進化するレコーダー

→これらは、他の家電には真似できない要素！

UIに注力

圧倒的な快適操作に、ゲームのノウハウが脈々と受け継がれている。

  • マニュアル不要の分かりやすさ
    • ゲームの場合、マニュアル読んでからゲームをプレイする人があまりいない
    • 操作はやりながら覚えていく
  • 気持ち良い応答
    • ユーザーのやりたい事を、少ないステップで実現してやる
  • 効果的な演出
    • グラフィカル・アニメーション・サウンドを効果的に使用する

→操作することが楽しくなってくる！

TorneのUIでこだわった、19のポイント

マニュアル不要の分かりやすさを実現するためのポイント

１、ボタンの意味付けを統一
  • ○は「決定」、☓は「キャンセル」
  • 画面が変わっても意味を変えない
２、基本操作を、十字キーと○・☓だけでもできるようにする。
  • 分かりやすい操作
  • PSPでのリモートプレイ・BRAVIAのリモコンも利用できるということもある。
３、メニューやボタンの説明を、画面の中に必ず入れる
  • 画面最下部に、ボタンを押したときの説明を表示
４、またその説明を動的に変化させる
  • 画面下部にヘルプラインを設け、合わせているカーソルの機能を表示させる
５、方向に対しての意味付けを行う
  • 左右の意味付け
    • 1つ1つの機能は、左から始まって、右のどん突きで完了
    • プログレスバー・シーンサーチなども、左から右
  • 上下の意味付け
    • メニューやリストは上下に並べる
    • 設定パネルも、上下のみで項目選択
６、途中で迷子にならないようにする
  • 階層が深い場合でも、☓ボタンの連打でメインメニューに戻る
  • 失敗しても大丈夫だという安心感を与える
７、表示メッセージに配慮する
  • 専門用語は極力避ける
  • メッセージの改行位置を調整する
  • 視点が動かなくて済むようにダイアログを小さめに、内容も簡潔に
  • 読みやすいようにフォントを使い分ける(基本は2つ、デザイン的にいくつか)
８、できるだけ中央に表示する
  • トップメニューなどは、選択している項目の名称が中央に来る
  • ヘルプラインやチャンネル切り替え時の番組表示も中央に寄せる
９、必要な情報は際立たせ、不要な情報は隠す
  • 選択されているものに対して、必要な情報のみを表示する
  • 番組情報を選択したときに、後ろの背景をぼかす
  • 必要の無い選択肢は隠すなどなど
１０、いつでも操作を受け付ける
  • 先行入力の受け付け、操作のブロッキングをしない
  • 画面の切り替え時などでも、操作を受け付ける
１１、直前の状態を覚える
  • 画面を切り替える前の状態を覚えておき、戻った時にカーソルを合わせる
  • 自分のたどった軌跡を、戻っていける
１２、最もよく使う機能を優先する
  • 番組リストで、現在放送中の番組で、○ボタンを押すと「再生」が始まる。
  • まだ放送されていない将来の番組で、○ボタンを押すと「録画」が始まる。
  • 状況に応じて機能を変える。
  • ゲームだと、宝箱の前だと「開ける」、人だと「話す」といったあたりまえの操作
１３、キーリピートの調整
  • 一定時間、同じ方向への入力でキーリピートが入り高速化
  • 番組表では上下にスクロールする際、２段階でキーリピートが入る
  • メニューの各所でキーリピートを調節する事で、ストレスを減らす
１４、公演時間の都合で割愛
１５、リビングに合うデザイン
  • 白基調で明るく清潔な印象
  • テレビをインテリアとして扱う
１６、長時間つけっぱなしでも馴染むような
  • 長時間使っていると、BGMが切り替わる
  • サムネイルが飛び交うメニューなどなど
１７、常に動かす
  • 止まってしまうと、死んだUIになってしまう
  • フリーズした様に見えるので避ける
１８、SEによるフィードバック
  • ほとんどの行動にSEを付ける
  • スピード感を感じる音を設定(XMBのような、小気味よい雰囲気でデモされました)
１９、待つ時間のストレスの軽減
  • 地デジの読み込みは必然的に、２,３秒かかってしまう
  • クロスフェードや、拡大縮小を利用して、待ち時間を感じさせない
  • 途中でアニメーションや、繋ぎの絵を入れる
  • ゲームでいうローディング中の処理の応用

実装された時に、ゲームと同様のチェック

上記の様なコンセプトはあるが、実際に触った時の感触は分からない。そこで...

  • クラッシュアンドビルド
    • 良さそうなアイデアは、まず実装し試してみる
  • チューニングチーム
    • ゲームと同じレベルまで、操作感をチューニング
  • QA
    • ゲームのQA部隊に依頼

ゲームデザインのノウハウまとめ

ユーザー視点にたってストレスなく優しく使える工夫を一つ一つ丁寧に仕上げる。
ゲームUI制作の基本をtorneに応用する事で、家電には無い製品が開発できた。

技術面から見たtorne、構成するモジュール

torneのシステムは2つのモジュールで構成されている

  • アプリケーションモジュール
    • 通常のゲームと同じ仕組みで動いている
    • 番組録画・テレビの視聴などを操作するアプリケーション
  • 録画モジュール
    • 他のゲームと並列で動作するもの
      • こっそり動作させる
    • ゲームの負荷に影響しないようなモジュール



技術面から見たtorne、高速な番組表の実装

TVの番組表は"文字数"が多く描画負荷が高い。
ただ、1080pでスイスイ動くというのは死守したかった。
そこで考えた二つの手法、

番組単位でレンダリング 文字単位でのレンダリング
利点 文字の位置計算が少なくて済む 文字種が少ないため、テクスチャサイズを小さく出来る
欠点 番組1つづつがテクスチャになるため、VRAMを圧迫 文字の位置計算の量が膨大

→数えてみると全番組で1000文字くらいしか使用していなかったため、1枚のテクスチャに収まることがわかった。

テクスチャのサイズ
  • 4096 x 4096 pixel、一文字 64 x 64 pixel、DXT1、MIPMAPあり

まとめ：今後の展開

家電との差別化・UIの操作性の向上という目標がある程度形になり、これから面白い事に挑戦できる土壌が出来た。
今後の予定としては、トルミル機能を膨らませてエンターティンメント方向に強化。今以上に触って楽しいレコーダーに進化させたい。

関連記事

特に無し

近況まとめ(CEDEC2010・フィギュアのススメ・Blender・ほか)

雑記

最近、近況についてはTwitterでモショモショつぶやいているのですが、その中からいくつか気になった事がまとまってきたので、書いてみます。

雑記のつもりが長文になったので、今日のお題を簡単にまとめると。

  • 今年のCEDECに出ます
  • フィギュア購入のススメ
  • UDK近況
  • 今年中に調べたい8つの事柄、進捗状況
  • Blender


の5つです。では早速1つ目。

CEDEC2010

紆余曲折ありましたが、最近興味を持ってるネタ、TOP2のうちの片方の話題で、登壇できる事になりました。

経緯としては、最初に公募で出そうと思ったもう1つのネタが、色々あってボツになり、ショボーンとしてTwitterでつぶやいたところ、締切り最終日に委員長の吉岡さんから、励ましのつぶやきをいただき、その日の夜帰宅して数時間でまとめた書類でギリギリ引っかかった感じです。

ギリギリというのも、まとめた書類は内容が薄かったので、最初はショートセッションで応募してたのですが、あれよあれよと事態が転がって良い感じに落ち着きました。

どのセッションかはボンヤリさせますが、ひとまず頑張ろうと思います。

フィギュア購入

今まではあみあみや、moeyo.comといったサイトで、気にいったフィギュアのいろんな角度からの画像を集めて満足していたのですが、友人からのススメで購入した人体模型を買ってから世界が一変しました。

実際に手にとって、360℃回転させて見ることで理解できる情報量は、写真と立体では雲泥の差があり、筋肉の配置・量感・回していくごとで変化するシルエットなど、得れるモノが違いすぎました。立体を360°回すと、脳ミソに情報がこびり着いていく感じです。最高。

あと最近、大阪日本橋のボークスのショールームに行ったのですが、ここが大変素晴らしくて、萌えからアメリカンなものまでたくさんのフィギュアが展示されていて、間近で見ることが出来ます。腰の高さまでありそうな綾波とか、ディティールすっげぇマイケル・ジャクソンとか、アイアンマン、百姫などなど。

やはり写真で見たスケール感と、実物の存在感って全然違いますし、各部のディティールも大きさによって全然違うので、これからも購入を続けていこうと思います。

最近購入して満足してるのはコレら。ちなみに一番下のヴェノムは、次に狙ってるやつです。

[rakuten:holly-colle:10000986:detail]

西村キヌコレクション 不知火 舞 (1/6スケールPVC塗装済み完成品）

西村キヌコレクション 不知火 舞 (1/6スケールPVC塗装済み完成品）

CCP マスキュラーコレクション vol.90 バッファローマン1000万パワーVer

CCP マスキュラーコレクション vol.90 バッファローマン1000万パワーVer

[rakuten:atmart:10073728:detail]

※ちなみにあみあみも、moeyo.comもRSSリーダーに登録するとウハウハです。ただ美少女系の数が多いので、それらが嫌いな方は注意が必要です。

UDK

わからないなりにずーっと触ってたら、やっと糸口が見えてきて、自分がやりたかった

  • 三人称視点
  • キャラ制御
  • キャラのモーション作成
  • キャラ表現(シェーダ関連)

あたりは、実現できそうな感じになってきました。


ただ全ての項目に置いて片手落ちの状態で、モーション単体ではエクスポートできるけどパッキングの仕方がわからない。前後左右ジャンプは出来たけど、ダッシュの制御が出来なかったりします…。

一番うまくいってるのは"三人称視点での操作"で、[ http://udn.epicgames.com/Three/CameraTechnicalGuideJP.html:title=UDKのカメラ制御の項目]や、UDKの情報をまとめてくれている方のスクリプトを参考に、ツギハギしながらなんとかなりました。最初に試していた4Gamerさんに掲載されている三人称視点のやり方だと、視点が固定されたり、壁にめり込みまくったりで、上手くいかなかったので、もし挑戦される方は上記の方法をオススメします。

ゲーム作ったりは、まだまだまだまだ先ですが、ひとまず「三人称視点で、自分の作ったキャラに良い感じのシェーダー割り当てて、アニメーションもカッチョ良く、操作も自分の思ったように」ってのを作ってみたいですね。今の目標です。

今年に調べたい項目8つ

今年の頭に設定した目標を見なおして、正直ゾッとしました…。

DirectX11に対応する事で、結局アーティストの作業はどうなるのか？ X
サイバーコネクト2さん独自の、製作体制について ○
Bungieの体制について ○
Face Robot再調査 X
SoftimageはVBScript？Python？ △
海外での外部協力会社について X
プロシージャル技術について △
DCCツールの今後について X

という感じで壊滅状態です…。

各項目でいうと、

FaceRobot

とある会社のアーティストの方と飲みに行ったときに、やっぱり使えないんじゃないかなという話を聞いて、実はちょっと諦めかけてます…。重いし・セットアップの時間もかかるしで、ゲームに使うにはちょっと厳しいような…。なんか良い知恵ないですかね？？？

BattleFieldの地形について

要約は出来てるので、あとはまとめるだけです。時間が取れれば…。

海外での外部協力会社について

脳ミソの奥の方にしまわれててなかなか記憶を戻すのが大変でした(汗) 最近技術の調査の方が面白くなってしまっているので、スルーしてましたが、年末に向けて調査しないとですね。これも結構重要な事なんで。

うぅん、今年も残すところ4ヶ月。気合を入れ直します。

Blender

自分は無料のソフトだと侮ってる時期が長かったんですが、Twitterでフォローしている方々がBlenderを触って好感触だったり、Blenderで作った映像を紹介しているのをみて、非常に興味を持っています。

というのも、自分の大好きなSoftimageの、サブスクリプションの更新を今年で止めようかと思ってて、その代替えソフトとして検討していたりします。乗換の理由としてはサブスクリプションの値段が、趣味で持ってるには辛くなってきました…。というわけでSoftimage 2011を継続的に触りつつ、徐々にBlenderに乗り換えていこうかなと思っています。

以下、最近面白いと思ったBlender関係の情報。


将来的には仕事でBlenderを使う日がくるのかな？とかちょっと思ってます。当分先だと思いますが…。Autodesk製品が値上がり傾向の今、ひとまず自宅での作業は徐々に移行させていきます。……でもSoftimage好きすぎるので、2011をずっと使ってる可能性もあるなぁ…。


.....

今はUDKを触ってる時が一番楽しいですが、他の事もやらないといけませんね。今日はそれがわかっただけでも満足なはず！？

サイバーコネクトツーさん独自の体制と、その核となる文化 (後半)

ゲーム開発 cc2

では前回に引き続き、サイバーコネクトツーさんの体制を見ていきたいと思います。

積極的な情報の発信

”情報はアウトプットする者の元に集まる”という信念の元、積極的な情報発信を心がけているようです。理由としては自分たちが情報を公開する事で、他社さんがそれをアレンジする、それをまた自分たちで吸収するスパイラルを作るのが目的のようです。

この辺りは最近開始された活動も多いため、ご存知の方も多いと思いますが、面白い動きをピックアップしていきます。

CC2 LIVE

最近の動きの中では、印象に残る活動ではないでしょうか。

サイバーさんの社内で行われた講演を、Ustreamで配信してしまおうという動きです。現在は、もじぴったんなどに携わられたプロデューサー、中村さんの講演が、2回(+ 1)配信されており、上記サイトの履歴からも確認する事が出来ます。

実はうちの開発でもみんなで見てたのですが、社内のトラフィックが急上昇して、映像が受信できなくなったのは良い思い出で…。

これからも続けていってもらいたい活動の一つです。

CC2 Tweet

ゲーム開発会社の中では、早い段階から実名公開に踏み切って、つぶやきを開始しています。

気持ちとしてはユーザーさんとの距離を縮め、身近に感じて欲しいと言う思いからされているようです。たまに掲載される写真から開発機材をチェックしたり、本棚の画像からはマネージメントの本のタイトルを盗みみたりと情報収集をさせてもらっています(苦笑)

CEDECへの参加

今回のCEDECではサイバーさんの開発者が関係するセッション数が過去最大になるようで、発表されていないものも含めると大手の会社とも肩を並べるほどの数になるそうです。キチンと数えたわけではありませんが、デベロッパーの発表としては過去最大になるのではないでしょうか。

他社の開発者から聞く事もありますが、CEDECやGDCで講演すると、同じ方向に興味を持つ開発者さんが声をかけてくれ、交流が一気に広がり、そこからお付き合いが始まって技術の交流が活発になる事もあるようです。次に紹介する会社同士の技術交流会もその一部だと思われます。

ちなみに下記は、現在までにサイバーさんが、CEDEC・GDCで行った講演のリストです。自分もCEDECのものはいくつか観ていますが、説明が分かりやすくて、帰ってからの作業にも反映させやすい内容ばかりで、重宝しています。今年は、FXアーティストラウンドテ−ブルあたりに顔を出したいですね。

※今年のやつは、まだ全て公開されていないようです。

会社間での開発者同士の交流会

交流会の時に聞いた話ですが、他社さんに開発者を送りこんで、積極的に技術の交流を進めているようです。

とある会社さんの場合は、サイバーさんから10名程度のメンバーを送り込み、自社の開発体制をプレゼンした後、逆に訪問した会社さんの開発体制についてプレゼンをしていただく。その後開発者同士で議論を交わし終了 or 飲み会となるようです。

この交流会の目的は、自分たちの足りないものを知ることだと言う事です。やはり技術的に先を行く会社さんに訪問した時などは、体制の違いに悔しい思いをする事もあるようで、そういう時は「悔しいなぁ、自分達に足りないものがわかったし、帰ったら勉強せなアカンな」となって帰社ということもあるようです。

でも、交流会の中で悔しい思いをしつつも、他社さんには無い自分たちの強みに気づく事もあり、そういうものは逆に「俺達でも通用する。勝負できる！」と自信となって帰って来ることもあるようです。

あと渡辺さんが言われていたのですが、会社間の交流会を始めてから、想定していなかった効果があったようで、交流会の休憩中などに「他社さんあんなことやってるわ、コレはこうやったら取り入れれるし、帰ったら実装してみよか。」など、開発者のモチベーションが上がる事が多々あるようで、最近は一番の目的になっているとのことでした。

あと、どれくらいのペースでやってるのかを聞いた所、去年1年間で16回位やっているようで、1ヶ月に一回以上は行うペースを保ちたいとも言われていました。

これは本当に羨ましい体制です。GDC・CEDECなどで各社の開発情報が公開される事はありますが、お互いの開発体制を腹を割って話して議論出来る事って少ないですからね。こんな活動してたら、嫌でも鍛えられますね…。

あと、以前にウチにも来た事があるようでしたが、残念ながら当時は違うチームだったので来たことも知らなかったです…。是非参加したかった…。

単独会社説明会

毎年福岡・大阪・東京で行われている、サイバーさんの会社説明会です。

以下のサイトから、会社説明会のレジュメが確認できますが、学生に向けた内容ですが、自分が見ても聞きたい内容があったりします。

■説明会プログラム

２. プロが見る応募作品と人物像
　実際の合格作品等をお見せしながら、サイバーコネクトツーが求める人物像・スキル
について具体的に説明します。 ゲーム会社に受かるコツを伝授します！

１）プログラマー
２）アーティスト
３）ゲームデザイナー

「サイバーコネクトツー単独会社説明会2010 IN 東京」開催のお知らせ！！(2010.9.11)

終了した会社説明会は参加者のアンケートとともにブログでまとめられています。

自分もブログを定期購読しているので「毎回、会社説明会のレポートを上げてるのは凄いですね。」という話をさせてもらったところ「だって、やりっ放しで、フィードバックしないってのは、参加者にも失礼でしょ。」との事で、ごもっともです…。でもこれが出来てる会社は、ほとんどないので、素晴らしい事だと思います。

制作したゲームを盛り上げる試み

アクセル3 ナルティメットトーナメント

自分たちが手がけたゲームでトーナメントを開き、その模様を動画配信しています。

この動画を見た時はかなり衝撃的でした。自分たちも会社で作ったゲームでトーナメント開いたりする事ああったりするんですが「この模様をUstで配信したらおもろいよなぁ」的な事はアイデアがでても、「まぁ無理やろな」と議論になる前に、やめることが多く。しっかり形にしたのはすごいなと思います。

あとは、テロップとか編集とかキッチリしていて、映像としてのクオリティもなかなかのものです。

自分は開発者なので、このチームの開発楽しそうやなぁ、羨ましいぃ。とか思うんですが、実際のユーザーさんからの反応とかどうなんでしょうね？またお会いする機会があれば聞いてみたいところです。

CC2東京(追記)

はてブで、noitseuqさんから指摘があって思い出しました。前回の東京スタジオの項目から抜けていた項目を追記します。

チャレンジャー

東京スタジオの求人が公開された時に、ゲーム・CG業界関係者界隈で話題になった、東京スタジオ独自の募集形態です。

求められる資質

・情熱を持ってゲーム制作に取り組む事ができる
・迅速に判断を下し、素早く行動する事ができる　
・問題を分析し、クリエイティブに解決する事ができる
・集団で制作を行う事の利点を理解し、周囲と協力し助け合いながら仕事に取り組むことができる
・貪欲な知識欲と飽くなき探求心を持ち、広い視野で物事を見ることができる。
必要なスキル

・他のプログラマー職のカテゴライズに当てはまる技量は現時点では持っていないが、
　いずれサイバーコネクトツーのプログラマーとしてかけがえのない存在になる覚悟を持っている。

交流会で東京スタジオの話になった時に、チャレンジャーのお話を聞かせていただきました。「究極、ゲーム制作はやる気が一番大事で、それを持ってたら技術なんか後からでも教える事ができる。覚悟完了できてるものは、入社当初周りの人間に技術が負けていても、将来的には確実に逆転する。そのリスクはうちで取ります。」という事です。

今までのサイバーさんの考え方にもあるように、この職種の募集はサイバーさんの考え方を極限まで突き詰めた募集形態だと言えます。ただ、この枠で採用されるには、かなり強力なゲームへの情熱が必要との事でした。

今後この枠で採用されたメンバーとは、是非お話してみたいものです。


ちなみに裏話として聞いたのは、この職種、東京スタジオのマネージャの渡辺さんが提案したもので、松山さんに提案書を見せに行ったところ、サラッとみて「OK!」と承認となったようです。ただ、その態度に不信感(？)を持った渡辺さんは、

渡辺「社長、チャレンジャーの項目、見てもらえましたか？」
松山「見たよ、見た見た」
渡辺「本当ですか？ココは東京スタジオで一番力を入れたい所なんです。ちゃんと読んでください！」
松山「だから見たって（怒）」

というようなやりとりがあったようです。実は先日の交流会でも「実際はあんまり読んでなかったんじゃないですか？」「見たよ。チャレンジャーの項目を見た瞬間、俺は良いと思ったんや！」と、上記のやりとりが再度繰り広げられていましたが、とっても羨ましい関係だなと思って見てました。

ブログで展開されるやりとりも、あながち嘘じゃないような気がします…。

GFF(GAME FACTORY'S FRIENDSHIP)と、福岡ゲーム産業振興機構

実は、このエントリーを書くまでは、GFFと福岡ゲーム産業振興機構は一緒のものだと思っていました(汗) 交流会でも意味を混同して使っていたようです…。すいません。

ざっくり書くと、GFFは福岡のゲーム関連会社が加盟している集まりで、福岡ゲーム産業振興機構は、GFF・九州大学・福岡市が協力して作り上げた産学官の連携事業のようです。

福岡ゲーム産業振興機構とは？
http://www.fukuoka-game.com/about.html

インターンシップ (http://www.fukuoka-game.com/internship_08.html)

GFFで行っているインターンシップの制度です。

他の企業さんでもインターンシップをやっているところはありますが、現状はそんなにうまく活用されていない制度ではないでしょうか？GFFでのインターンシップの結果は、ブログでレポートされており、この活動で学んだ結果が報告されています。(サイバーさんと、エレメンツhttp://www.elements-soft.jp/ さんが公開しているようです。)

GFF Podcasting (http://gff.jp/gffcast/blog/cat5/)

GFFに参加している開発会社の方々がゲスト出演して、自分の関わったゲームの事や開発体制の事、またGFFのイベントの内容を音声配信しています。

サイバーさんの他にも、福岡のゲーム開発関連会社さんのお話を聞くことが出来ます。

CEDEC・GDC報告会 (http://www.cc2.co.jp/blog/?p=2079)

CEDEC・GDC後に行われる、GFF主催のセミナーの報告会です。

ブログでも詳細にレポートされていますが、前半・後半にわかれた内容、両方共が面白いです。

報告会の前半は、GDCに参加してきたCC2スタッフによるレポート発表。
そして後半は・・・。
プランナー、グラフィックデザイナー、プログラマーのグループに分かれて、
それぞれの場所でラウンドテーブル（互いに情報や意見を交換し合う）が行われました。

交流会で言われていたこととしては、後半に行われるラウンドテーブルが熱く、GFFのメンバーに加え、学生なども参加するようです。

GDC・CEDECといえば最先端の技術を発表する場なので、その話をしてもついてこれないメンバーもいるようですが、それでも大事なことだし、将来に必要な技術もあるのでそのまま続けてしまうようです。特に学生などは、今まで開発の経験もないので全くわからない事もあるようですが、プロの空気感を伝えたいので毎回参加してもらっているようです。

次回は、自腹を切ってでもこっそり忍び込みたい…。

まとめ

サイバーさんの体制を見てきましたが、ここから浮かび上がってくるのは、サイバーさんの独自の体制の中心にあるのは「ゲームを面白くするにはどうすればよいか？」という確固たる信念に基づいた行動なのだと思います。

社内の人員の数、福岡という立地、他社との違いなど、現在の状態を分析した上で、この手持ちの札で、どのようにして面白いゲームを作るのか？効率良く開発するにはどうするのか？を考えた結果が、サイバーさんの独自の体制につながっているように思います。

なので「他社さんがやっていたので、うちも取り入れるぞ！」ではなく「自分達にあった体制はなにか？」「それでゲームが面白くなるのか？」と考えられて作られているのではないかと言う事が話の端々から感じられました。例えば、トライファクターの次の体制も、カバル式をそのまま採用せず、カバル式からヒントを得て自社にあった体制を議論し、将来的に出来上がったものをみれば「カバル式・改」ではなく、「サイバー流の〇〇体制」になるのだと思います。

そう、サイバーさんの凄いところは一つ一つの体制ではなく、それを考える”文化”、自分たちに最適なモノを考えていく土壌なのではないでしょうか。それを周りのみんなが理解して挑戦する姿勢が凄いので、それが世に出たときに独自の体制に見えるのだと思います。

交流会の途中で松山さんか言っていた言葉を思い出しました。

「見送り三振はアカンけど、空振り三振は許される。」

交流会でお話した松山さん・渡辺さん・下田さんの発言からは、この気持ちが熱いほどに感じられました。

最後に

交流会を開いてもらい、たくさん聞かせていただき勉強になりましたが、自分は聞くばかりで全然情報が提供できませんでした。それが心残りです…。また機会があれば、こちらからも情報が提供できるように頑張ってみます。

サイバーコネクトツーの皆様、ありがとうございました。感謝しております。

Aqu






・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・


一方その頃、桜島の地下にあるサイバーコネクト基地では...


サイバーコネクトスリー　「サイバーコネクトツーの秘密が暴露されたようだな…」
サイバーコネクトフォー　「ククク…奴の体制は、我々が100年前に考え出したもの」
サイバーコネクトファイブ「体制の秘密を話してしまうなど、一族の面汚しよ…」

サイバーコネクトフォーエバー総統
　「今こそ一族の大秘法”オクタファクター構造”を発動するときぞ、ガハハハハ！」


・
・
・
・
・
・
・
・

というような事があってもいいほど、たくさんの情報をいただけたと思います。
本当にありがとうございます！