■ CEDEC2日目 自分用メモ 
２日目の基調講演「ウェアラブルは本来なら日本から10年以上前に立ち上がっているべきだった。日本ならではの、小さくて新しくて面白いものを作る、というものが出てこなくなった」「アメリカは、大きいものが好き。ヨーロッパは、古いものが好き」「動きが遅いので欧米が走り出して、韓、台、中が猛追従してる」
2日目、基調講演
失われた15年、経済だけでなく企業の創造性も失われてしまった
ウェアラブルは本来なら日本から10年以上前に立ち上がっているべきだった
日本ならではの、小さくて新しくて面白いものを作る、というものが出てこなくなった
アメリカは、大きいものが好き。ヨーロッパは、古いものが好き。
あまりにも動きがもたもたしているので、欧米から動きが出て来た、韓国、台湾、中国がもう追従している。
※ドットも見えない解像度のスマホを持って、GPSで地図や電車の時間を確認したりなんて、15年前には想像もできなかった。ウェアラブルがあと10年〜15年でどこまで進歩しても不思議ではない。
「ずっとネットを見てる人がせっかく外にでても、スマホでネットに引きこもってる」
ビデオシースルーはウェアラブル、
遠隔操作はウェアラブルではない。
ウェアラブルは難しい
→装着して利用してみないとわからない事が沢山
生活の中には様尼な状況が待ち構えている→必ず開発が遅れる→経験が重要
情報系ウォッチが大量に出て来てる
※→高機能で戦わない、子供のおもちゃでいいからなにか単機能だけどすごく便利、みたいなのがつくれないか？「枯れた技術の水平思考」
Tizen
現状：「アプリの蓄積」「アップルの様子見」
リストバンド型活動量刑 →市場が立ち上がっているようで立ち上がっていない！！！
Nymi:認証用
June:紫外線対策
Moff：おもちゃ
あるシーンである目的に使うウォッチを2000円とか5000円とかで売るアプローチ
ライフログ系カメラ：ブレイクの可能性有り？
スマートシューズ：重さがある程度重くていい、発電しやすい、脚の指先にセンサーを入れやすい、などいい特性がある
※ヘアバンド駄目？、おもちゃとしてはベルトが行けるのでは、との話も。
モバイル初期、デジカメとか音楽プレイヤーなどの実用性の高い専用機が、スマートフォンに統合されて駆逐された。
ウェアラブルも、実用性の高いアクションカムやブレスレッドなどのすでに実用化された専用品を、高機能、実用化された汎用品が口酸くするのではないか
バーチャルに進化した遊びを、ウェアラブルでリアルの方向に進めてみるのが良いんじゃないか
※ingressの話をしよう
※多数の人から自動センシングした情報を、クイズの出題にして、クイズの問題を自動生成できないか？
※「カメラで撮影」で捕まえたり倒したり、みたいな判定になる鬼ごっこって同だろう？
HMDを使ったスポーツ
質疑：
→HMDには実空間のそのとき必要な情報を出すべき、着けてると危ない、という情報を出すべきじゃない
むしろ危険回避のための情報をHMDにだすべき
※何もしなくても勝手に視界に翻訳が乗る、っていうのはSF的だけど非現実的じゃなくなってるあたり、未来が。
顔認識で名前が出る、だれか位置情報を公開していい人の位置が近いと勝手に出る、とか。家族とか。
----------------------
UE4のレースゲーム、
視点を振ったら右目の方を中心に激しく点滅してた
Zロールが酔う
運転席付近を見てたら崖から飛び出して衝突してた時の脇見運転感が面白かった
----------------------
1.アウトソースににクリエイティブな作業はさせない（「できない」ではなく「させない」）
→クオリティの保証ができない
スケジュールの保証ができない
コンプライアンスと内部負担（コンプライアンス違反してないかチェックの負荷）
→「手を借りるだけ」という意思
2.発注書で指示している以上のクオリティにはならない
→クオリティが低いのは発注書の精度
暗黙の了解はない
→「完成品が見えている状態」での発注書作成
3.情報を複雑にしない
→無駄な長文は避ける、画像を増やし、誤解を軽減、
共通言語などを定義して文字数を押さえる(OKです、の言い回し一つでも！)
→わかりやすく、使いやすく、管理しやすいルールを決める
4.フィードバックで品質を高めようとしない
→検品中に発注書と違いディレクションをしない
追加オーダーやマイルストーンを戻るFBはしない
同じ箇所の修正の回数を決める
→品質は発注書に寄って達成するもので、フィードバックで達成するものではない
5.急な変更はできない
→急で大きな仕様変更は対応できない
早急な優先度の変更もできない
急な追加発注はできない
6、海外での政策である事を忘れない
→文化が違う、環境が違う、言語が違う
「できればやってください」「時間があればお願いします」と相手に判断を委ねない
→固定観念を持たない
→まとめ：アウトソースをギャンブルにしない！
しっかり準備して、想定したものが想定通りに帰ってくるように単純化するのが大事。
本政策の前にトライアル製作。
■ 何をOSに出すのか？ 
→効率を重視した反復作業
■ 担当者を決める 
→発注書、アートワークガイド
■ 大規模な製作ではベンダーの人数確保が最重要 
→最初は少なめに、スケジュールに空きを作ると別プロジェクトに振られてしまう可能せいもあるので、段階的に増やす
■ 発注書： 
短期間に数千のモデルを発注するので、必要な情報を簡潔にまとめる
ファイル名、優先度、仮モデルのSS、ドキュメント名、設定が、参考画像、概要(文字情報の補足)、分類（自動設定）、ポリゴン数（目安）、各作業項目の難易度（工数を出すための目安）、類似モデル、テクスチャパス（新規で作ってほしいなら入れてもらうパス）、工数（難易度を書くだけで自動的に算出される、一時間単位）
OS製作仕様虜
モデリングの規約
マテリアルの設定方法
ファイル階層の説明
具体的なマイルストーンの説明
→昔はエクセルで作ってたが、ワードにした（何ページ目のどこを更新したかがわかりにくいので）
アートワークガイド
敵の前面、背面。、部品が外れたときの仕様や質感のクオリティバーモデルを準備
BGは何千何百とあるのでひとつひとつ設定画を用意するのは現実的ではない
クリスタルの設定などは世界観に関わるので詳細に用意して、あとは「ここはクリスタルです」で通じるように。
クオリティバー
「このクオリティのものを作ってね」という基準
※発注や管理をする人は相当に実力がある人でないとなりたたないだろうから、こういうやり方をしないとゲーム開発がスケールしないにせよ、そういったクリエイティブが薄まるような行為は筋悪だなぁ、とは思う
■ 作業プライオリティについて 
１、質問への解答（作業が止まってしまうので、こちらの手を止めてでも解答する）
２、フィードバック（２４時間以内、などきめておく）
３、次回発注書の作成
まとめ：「準備の基本は5W1H」
■ トライアルについて 
パッケージ（契約単位、バッチの集合体）
バッチ（１０人日程度の作業内容、フィードバックシートに紐付け）
→トライアルの目安としてはバッチ単位で。
準備、契約→見積もり依頼→（二週間）→トライアル製作開始→(二週間、がちょっと伸びる)→振り返り、準備期間(ここが重要、発注書作りに専念できる最後の期間！)→見積もりから本製作へ
トライアルは本製作の二ヶ月半前くらいにやっておく必要がある
■ 青果物と作業範囲の定義 
お納期、総アセット数、装甲数、合否の定義、マイルストーンの定義など…。
マイルストーンが多ければ意図したクオリティのものが上がってくるが、負担が多い
マイルストーンが少なすぎると、差し戻しのロスが増える
→ベンダーの練度に応じて変えていくべき
■ ツール説明書、環境仕様書 
最低限の説明で、不具合対応が必要になるような便利ツールは渡さない
プライグインの更新などは、小さい更新なら古いままやっていく方がいい
パッケージ間のプラグインの更新などは基本行わない
※徹底的に相手が発注したものを出してくれる事は信用するけどそれ以上の信頼はしない、という体制。
■ フィードバックについて 
原則禁止事項：マイルストーンを虫、もしくは差し戻すフィードバック
納品が来てからの方向性を変えるディレクション（煙突をたす、みたいな）
具体性に欠けるフィードバック（具体的な基準や数字を含めた修正を依頼する）
過度のフィードバック（軽度なものはこちらで直した方が早い事も）
エクセルでフィードバック、具体的な指示を赤入れで。
■ ベンダーの評価、選定 
１、品質（クオリティ、得意分野、技術力）
２、理解力（日本語の理解力、アートやツールへの理解力）
３、コミュニケーション（フィードバックやメールの速度、不明点へのアプローチの仕方、スケジュールの管理能力）
→これらを含めてコストを考えて、どこにどう発注する課を決める
■ トライアルまとめ：トライアルをやれば全てわかる 
わかった事に対して徹底的に修正や対応などを考えて改善していく。
問題が改善しないなら、本製作を一旦止めてでも対応してから、再度トライアルする必要がある事も。
本製作：
■ 発注書の見直し 
わかりにくいので文字を減らした→文字を減らし過ぎ→いろいろやってたらエクセルに→
本製作中もブラッシュアップをくり返して、最終型に。
本製作では使用しなかったフロー
ディティールアーと→ペインとオーバー→ゲーム画面
→クオリティはいいけど時間がかかるので止めた
実際にトライアルを行うと、このペースでは発注書が間に合わない、などの状況をみてリスケ
トライアルの初期段階の見積もりが、170%ずれてた
→全体的に見れば、132%の増加率で澄んだ。（ベンダーごとに違ってた。単価も。）
内部で予定していたものから、発注数が120%増えて、ベンダーが130%増えたので、合計で160%の増加になった
BGの場合、ステージごとにずれを調べて、検討は行っていた
■ クオリティコントロール 
１、ドキュメントでの指示（クオリティバーの定時が一番大きい）
２、モニターが共有できるビデオ会議、定例会議（アジアは顔を見て話す事を好む）
３、現地での指導（ツール関連の問題は現地で見ると解決が早い）
番外：人材の育成（コミュニケーションの質が高まる、長期的、やめたときなどのリスクもある）
本製作に向けてのまとめ：アウトソースに正解はない
「止まらない事、量産に耐えうる発注書の作成」
「ゲーム制作と並列に行える体制の確立」
まとめ、総括：
業務の俗人化と標準化の使い分け（不要に属人的な部分は減らす）
情報の透明化とマニュアル化（何度も同じ説明をしない）
クオリティの意識統一（）
アウトソーシングを始める為の準備＝特別な準備ではない
→内部の人を増員するときなども同じ話はあるので。
ほぼ席が埋まってた。
※発注書の変遷が面白かった。画像が重要ではあるけど、翻訳コスト低減の為に文字を減らしすぎても伝わりづらく、エクセルのような票に組めるかたち
質疑：
外部とやり取りするスタッフは、一人で何人くらい回してる？
→一人で８人分くらいの担当＋ゲーム制作、が限界かと思っている。（担当者が一人8人月くらい）
全部外部で作成したとして、内部でブラッシュアップする人と外部を回す人の比率。
→ナックでは、BGはみんなブラッシュアップをしていた
BGのアウトソースの話が多かったが、モーションやエフェクトのアウトソースは考えているか？
→モーションはやっていた。今も作中
エフェクトは難しいという印象、エンジンを渡すのか、
テクスチャ素材を作ってもらうのも難しい、プロジェクトに寄って違ってくる
ナックではない全く違うゲームであった場合に、アウトソースの方向性はどのくらい共通項として通用して、どのくらいがゲームの内容で変わってくるか？
→どういうフォーマットであろうと、内部チームでドキュメントとゴールを用意していれば、アウトソースは対応してくれる。内部でそういう体制ができていれば、ゲームによって変わるところはあまりない
---------------------------------------------------------------------------------------------
