しるろぐ

いろいろ書きます。

#aimingstudy 7 「ロードオブナイツ UnityからHTML化する際のアプリの設計とアジャイル的開発管理の話」に行ってきました

勉強会

前回の勉強会からちょっとしか経ってないのにもう次の勉強会。すごい。

というわけで、Aiming Study 7に行ってきました。

今回も事前にスライドが公開されていたので、メモは少なめ。
質疑応答はスライドに載ってないので、スライドをじっくり読んだあと、「質問」だけ読めば完璧ですね！


UnityのオンラインゲームをHTMLに移植してわかったこと- 設計と作業分担の視点から

移植の経緯と教訓について。

Unity版の開発

  • 当時リッチなゲームが少なかったので、さっと作って出せば勝てるのでは？
  • 使えそうなフレームワーク探してUnityになったが、部分的にHTMLを使用
  • 動くところはUnityで、更新頻度の高いところはHTMLで
    • 連携するネイティブプラグインを書いた
    • トリッキーな実装で後悔
  • コードレビューはgeritを使用

移植の話

  • クライアント側はUnity版と別メンバー
    • Unity版は大きめの開発してて忙しかった
  • クライアント側は別ソース
再利用性
  • Unityで作ったクライアント部分は全部作り直し
  • HTMLで作ったクライアント部分は再利用したが、テンプレートはデザインが変わったので作り直し
  • サーバ側はほぼ再利用

よかった

  • APIは超再利用性高い
  • JSON-RPCもデバッグしやすい
  • 通信設計が仕様書代わりになった

悪かった

  • UnityとHTMLの連携部分がトリッキーだった
  • もともと画面遷移させてたところをワンページアプリでどう実装するか
  • Unity版メンバー不在
    • 後半から入ってスピードアップ

移植の教訓

  • API設計はしっかりする
  • トリッキーな設計はしない
  • コミュニケーション大事

質問

  • 全部のコードをレビューするのは大変では？なにかコツは？
    • メインのレビュアーがいたほうがよい
    • コストはかかるが、変な設計や命名が減って追加コストを減らせるので結果的には良い
  • ペアプロってなにがおいしいの？
    • 仕様の理解度などの知識の偏りがあるときに効果がある
    • 知識が少ない人だけで実装してしまうと、隠れた仕様が抜け落ちてしまう
    • ペアプロにより、知識が共有でき、後々のバグや抜け漏れを防げる
    • リアルタイムコードレビューなので、コードレビューのコストが減る
  • どこらへんがトリッキーだったの？
    • レスポンスをフックしてURLをパースして云々みたいな
  • 次作るならどう作る？
    • Unityが4.0になったらHTMLでやってたこともUnityでできるので全部Unityで作るよ
  • 仕様書をredmineで管理ということだったが、Unityチームと移植チームのでどんな感じ？
    • Unity版の子プロジェクトとして移植プロジェクトを作った
    • 親プロジェクト見れる権限あるので、元々の仕様も見れる
    • 元々の仕様も、目を通した
  • それぞれの今後のメンテに対するメリットは？
    • どうなるかはこれから次第
    • HTML版はリリースまでの期間が短い（10分とか）
    • Unity版は審査があるので10営業日とかかかることも
    • Unityはマルチプラットフォームでさくさく動かせるのがメリット

スライド


大規模JSプロジェクト ロードオブナイツの管理手法紹介

「サムライエピソード」と「ゲームクリエイターが知るべき97のこと」の人。

スクラムマスター的な立場から、移植のプロジェクト管理の話。

黎明期：締め切り最優先になり体制組み換え

  • 全員新宿に読んで常駐化
    • 停止できそうなものを止めて人員確保
    • 技術的素養は違うがとにかく人を増やした
  • 環境整備

ポストイット期：工数わからなすぎる

  • 仕様が変わるので、思いついた端からポストイット
  • カオス化したが続けたのは、チームが前進している感
  • 進捗とかなにも管理していなかった
  • ゴールを決めたが完成しなくて検討がつかないのは変わらず
    • 大ざっぱに見積もったが全然間に合わない
    • 四天王調整
  • 小田レビュー
    • Doneの定義が曖昧だったので小田さんがOKしたら完了
  • ペアプロ表
    • これいいなー。と思いつつ人数多くないと効果無さそう
四天王
  • 時間
  • 予算；Unityメンバー呼ぶ
  • 品質
  • スコープ：IE8を切る

ストーリーカード期：リリース無理っぽいぞ

  • 手っ取り早く定量化したい
    • 大中小で見積り
    • 「全部」を定義できたのはよかった（バーンダウンチャートが作れるので）

Redmine期：リリース前

  • 場所が離れているので、オンラインじゃないと歩調合わせできない
  • リリース直前だと、あのバグなおった？とかが重要になってくる
  • バグの個数を測定
    • これを0にするのが重要

まとめ

  • フェーズによって必要なものは違う
  • 固定的な方法論や指標にしがみつくのは危険
  • 期間内にやることを明確にし、チームのコミットメントにする
  • 進捗を定量化して計測するために最適な指標を考える
  • 開発手法を変更しやすくする土壌を作る

質疑応答

  • 品質を下げる方向にいかなかったのは？
    • 品質落としたら……
    • リファクタリングせずに動いてるから出せ、だとメンテナンスが大変
    • マップをとりあえずリリースしてしまったが、実際に苦労したことがある
    • そもそも品質悪かったらPOがOK出さない
  • 品質の定義に細部の作りこみは含まれているか？
    • YEAH。リリース前の作りこみ期間がなかったことはない
  • モチベーションに関して
    • 納期優先だからとにかく作れはモチベーション下がる
    • テンション高く作れた
    • 移植元のアプリがあるので遊んで、仕様理解、距離把握
  • もろもろの管理方法を変える決定はどうやった？
    • 間に合わないと分かったとき超焦った
    • ペアプロとかSML見積りは自分が提案した
    • みんなの知恵が入ってこうなった
    • 自分はスクラムマスター的な関わりをしたが、「こうやれ」とは言わなかった
      • 自分たちでやってるんだぜ、というのがモチベーションになる
  • スプリントの期間について
    • 2週間は実は会社の中では長い
    • 運用がはじまると1週間じゃないと遅い
  • メンバーとの関わり方
    • チームではスクラムマスター
    • 外部との交渉はゼネラルマネジャー
  • リリース日がすでに決まっていることについてメンバーの納得感は？
    • やるまでわからん
    • とりあえず動いてみよう
  • 朝会夕会等の取り組みについて
    • 朝会＝いわゆるデイリースクラム（なにやるよ）
    • 夕会＝今日こんなことやったよ、残業対策
    • 振り返り＝KPT方式

スライド