WonderPlanet DEVELOPER BLOG

ワンダープラネットの開発者ブログです。モバイルゲーム開発情報を発信。

図を継続的に管理するためのベストプラクティス

こんにちは。サーバエンジニアの桐島です。

今回は、図(フローチャート、シーケンス図など)をチームで継続的に管理するための個人的なベストプラクティスを紹介したいと思います。

図の有用性と、継続的な管理の必要性

図って便利ですよね。

以下の様な図があると、チーム内での認識合わせを正確に素早く行うことができます。

  • サーバ構成図
  • アプリ-サーバ間処理のシーケンス図
  • APIプログラムの複雑なロジックのフロー図
  • ER図

ただ、プロジェクトのドキュメントに含まれる図がすべてメンテナンスされ、最新の仕様と図がマッチし続けているケースは少ないのではないでしょうか。

図は有用なのですが、管理し続けなければその有用性を失い、いずれ削除される運命にあります。

図の継続的管理への課題

では、図が管理されない原因は何でしょうか。 具体的なケースを幾つか挙げてみます。

  • 再編集できないフォーマットで図が作られている
    • ホワイトボードに書いた図を撮影した写真を共有する
    • 再編集できない画像ファイルとして共有する
  • 再編集できるフォーマットで作られているが、閲覧・編集するために特殊なツールが必要となる
    • 専用ツールのインストールが必要となる
    • インストールに手間が掛かる
    • Mac と Windowsでツールの動作が異なる
    • ツールの学習コストが高い
  • 図の存在が知られていない(図が散在している)
  • 知らない間に図の内容が古くなっている

これらケースから考えると、大きな原因は以下の2点にありそうです。

  1. 図の閲覧、作成、編集がハイコスト(特に編集)
  2. 図を作成するタイミングが決まっていない

この課題をクリアし、図を継続的に管理するための方法を考えたいと思います。

継続的画像管理のアイデア

先に結論を書くと、以下方法が良いと考えています。

  • SVG形式で図を扱う
  • draw.io と GitHub で図を作成、編集する
  • 図の変更をPullRequestに含める

f:id:s-krsm:20170529121549p:plain

この方法のメリットは以下となり、上述の課題を解決できそうです。

  • チームメンバ全員が簡単に同じ方法で図を閲覧、作成、編集することが可能
    • 図の閲覧、作成、編集のローコスト化
  • プログラムと図を紐付けてバージョン管理することが可能
    • 図の作成、更新タイミングの明確化

次に、具体的な手順を見ていきたいと思います。

具体的手順1(図の作成)

1. draw.ioで作図

draw.io で図を作ります。

f:id:s-krsm:20170529121446p:plain

2. SVGとしてexport

SVGファイルとして保存することで、draw.ioで再編集可能となります。

f:id:s-krsm:20170529121718p:plain

export実行します。

f:id:s-krsm:20170529121801p:plain

3. export先として GitHubを選択

f:id:s-krsm:20170529121834p:plain

draw.ioとGitHubを連携するためには認証が必要です。

連携したGitHubアカウントがアクセス可能なリポジトリ一覧が表示されます。

f:id:s-krsm:20170529121911p:plain

4. export先のリポジトリ・ブランチ・ディレクトリを選択

f:id:s-krsm:20170529121944p:plain

commit メッセージを書き、OKボタンを押すとcommit完了です。

(SVGファイルが指定リポジトリに追加されます)

f:id:s-krsm:20170529122019p:plain

具体的手順2(図の編集)

1. GitHub上のファイルを開く

f:id:s-krsm:20170529122151p:plain

作成時と同様の手順でGitHub上のsvgファイルを選択します。

(リポジトリ・ブランチを選択可能です)

2. 変更をcommit

GitHub上のファイルを編集した場合、編集後に「Unsaved changes. Click here ti save.」というボタンが表示されます。

f:id:s-krsm:20170529122232p:plain

これをクリックすると、commitメッセージを書いてcommitすることができます。

(commit先は、ファイルを開く時に指定したブランチとなります)

f:id:s-krsm:20170529122307p:plain

具体的手順3(図の差分確認)

PRのレビュー時に画像の差分を確認しますが、GitHubのrich diffツールが素晴らしいです。

SVGファイルの文字列差分では変更箇所は分かりませんが、rich diffツールを使うと画像の変更箇所を素早く把握することができます。

2-up で差分確認した場合

f:id:s-krsm:20170529122354p:plain

Onion Skin で差分確認した場合。

f:id:s-krsm:20170529122404p:plain

具体的手順の紹介は以上となります。

ブラウザだけで図の作成、git commit/push、レビューまで完結できていることは驚きですね。

まとめ

図を継続的に管理するための個人的なベストプラクティスを紹介しました。

ただ、図の扱いはチーム(規模、構成、状況等)により、メリットもデメリットも異なると思います。

例えば、リモートワーカーが居るチームでは図を作成し共有することによるメリットが大きいですが、小さなチームの開発初期段階では、作図コストのデメリットが大きいかもしれません。

また、必要となる図の対象・粒度もチームにより異なると思います。

今回の記事が、チームに最適な図の共有方法を考える参考になれば幸いです。

バグを生まないために気をつけたいコードの書き方

こんにちは。アプリエンジニアの大橋です。

今はそれほどではないのですが、少し前まで仕事の大半をコードレビューに費やしていた時期がありました。
どちらかというと自分で実装する方が断然好きですが、
それはさておき、いろんなコードを見るなかで、
「このコードの書き方だと、正常に動作してはいるけど、後々不具合を生みやすそうだなぁ」
と感じることがあったりするので、
そういうコードのパターンをいくつか取り上げさせてもらおうかなと思います。
自分自身も気を付けたいという意味も多分に含んで。

というわけで、さっそくひとつめ。

変数名や関数名が処理内容と違う

基本的なことではありますが、たまにやってしまいます。

コードを読むとき、変数名を見て「こういうことに使ってる変数かな?」と想像して読んだりしますが、
実際は違った使われ方がされてると、コードの理解の妨げになりますし、
誤解したまま別の人がその変数を使ったりすると不具合の原因になってしまいます。

関数名やクラス名もまた然り。
ちゃんと処理内容にあった変数名や関数名を付けましょう!!

あと余談ですが、自分が実装するとき、変数名や関数名の名前に結構悩みます。
的確な名前を付けたいと思うのですが、英語が得意というわけでもないので、
なかなかこれだっていう名前が付けられないときがたまにあって、
そういうときは大抵、辞書を引いてニュアンスとかを考えだしたりして、深みにハマります……
英語が得意じゃないプログラマーは、英語圏のプログラマーより生産性がかなり落ちるんじゃないかと 常々思うところです……

あと、これに関連してですが、
耳慣れない単語を使うと後々困ります……

単語の意味が合っているからといって耳慣れない単語を使うと、

  • 他の人がコードを把握しようとしたとき単語の意味が分からないので辞書を引かなければいけない
  • 読み方を忘れるので会話するとき困る

ので、わかりやすい名前を付けましょう!!

そしてふたつめです。

public関数に暗黙の使用条件がある

ついついやってしまうのですが、気をつけたいなと思うことです。

例えば
「ある関数Aを実行するときは、その前に別の関数Bを実行しておく必要がある」
といったことがあると思います。

もし前提条件の関数Bを実行せずに関数Aを実行してしまった場合の
エラーハンドリングがちゃんとできていれば大丈夫かとは思うのですが、
エラーハンドリングもされず、その関数やクラスのコメントにも関数Bをあらかじめ実行しておく必要があることが 書かれていない(=暗黙の条件)状態だと、
後から別の人がその関数を使ったり修正したときに不具合が発生する危険が増しますし、
コードを把握するための時間もかかってしまいます。
実装した本人でも忘れてしまいますし。

あまり関数を使うための前提条件をつくらない方がベストな気がしますが、
やむおえない場合はきちんとコメントに書いておきたいところです。

ということでみっつめ。

関係なさそうなところで影響し合っている

「ある関数の処理内容を変更したら、実は他の場所でその関数の処理内容に依存した実装があり、不具合が発生した」
というようなことがよくあるような気がします。

特に、あまり関係なさそうな処理同士が依存していると、
後から関連処理を修正するときに見逃しやすく、処理を把握するのも大変。
処理の依存関係はできるだけ小さい範囲でまとめたいところです。

まぁ、テストを書け、ということかもしれませんが、
依存関係が散らかってないコードを書ける人は尊敬します。

そしてラスト。

難解すぎて何をやってるかわからない

凝ったコードでも他の人が理解しやすいコードはいいのですが、
なにをやっているか理解しづらい難解なコードは避けたいところです。

他の人が読み解くのに時間がかかりますし、
完全に把握できていない状態で変更を加えられたり、コピペして使われたりすると危険です。

コードを短くするために凝ったコードを書くより、
ある程度長くなっても理解しやすいコードのほうが良いんじゃないかなと自分は思います。
ムダに冗長なコードは避けたいですが。

最後に

この記事を書いていて思いましたが、
不具合を生みにくいコードを書くことで、「不具合を生まない」ということだけでなく、
後々の生産性の向上にもなるような気がしました。

自分自身も、
ついついめんどくさがって、あまり後々のことを考えずに簡単に実装できるコードを書いてしまいますが、
後々のことを考えて、できるだけ不具合が生まれにくいコードを書いていきたいものです。

ゲームプランナーになるには、どんな能力が必要なの?

ゲームプランナー&レベルデザイン担当の程塚と申します。

ゲームプランナーについて、つらつら書きたいと思います。

 

どんな方向性 のゲームにしたいのか、

作っていく途中で どんな問題 があり、どう解決 すれば良いのか。

それを 発案 する、または、他から発案を引き出して、リードする役目

面白いアイディアが思い付いて、且つ、

それを 具体的にゲームに落とし込む実現力 がある人。

それがゲームプランナーです。

 

① 情熱・やる気・根気
→ ゲームに対する自分なりの考えがある
→ 言われた事だけやるのではなく、自発的に学ぼう とする
→ 嫌なことがあっても逃げない
→ 好きだけでは続けられない、好き以上の気持ち が必要

 

② 感性・センス・発案力
→ 何かを真似るだけに留めず、アレンジしたり、より良くしたり、新しさやオリジナリティを考え葛藤する こと
→ ゲームだけでなく、他の遊びや芸術などの広い視野があったり、友達との思い出や恋愛経験など、色々な引き出しがあること、もしくは作ろうと努力すること

 

③ 客観的判断・論理的思考・会話力
→ 物事を 客観的に見れる
→ 自分の意見を論理的に正しく説明できる
→ 相手の意見を正しく理解する事ができる
→ 論点を明確にし、ぶれた話を起動修正しながら話す ことができる
→ 感情的になったとしても話の筋を見失わず、個人的な感情よりもそのゲームを良くする事が大事であるからと、冷静に話を分析、判断できること

 

愛情がある
→ ゲームという表現への愛情がある
→ プロジェクト自体、または、そのゲームへの愛情がある
→ チームの仲間への愛情がある
→ わざわざ 自分の人生の時間を費やして、そのゲームを遊んでくださるユーザー様への感謝の念 を常に持つ

 

絶対はない

自分を信じる事
→ ただ感覚的に自分の考えは面白いとか正しいと思い込むのではなく、自分の考えが知識やノウハウやデータから見て、客観的に正しいことを示す事が大事である。ただ現実では、それを受け取る上司や仲間にも能力が必要なので、仮にプランナーが死ぬほど頑張ったとしても、必ずしも良いものが出来るとは限らない。逆もしかり。

自分を疑う事、他人を認める事
→ 自分の考えは間違っているかもしれない。自分の考えより良い考えがあるかもしれない。他の人の考えを正しく判断し、取り入れる力が必要である。


ダメなプランニング例 〉
① 全体の各機能の関連性と役割をちゃんと見渡せていない ( 現状の問題認識が不十分 ) のに、足せばいい的に細かい枝をどんどん付けていき、まとまりのないものにしてしまうもの
② 目的や大枠ばかりを気にして、細部のバランス調整がしっかりできていないもの
③ 長い間それを使った際に将来的にどうなるか ( 各機能の消費による時間的な変動 ) を想定していないもの

 

現実と対峙する
① 利益を出さなければならない
② スケジュールに間に合わなければならない
③ 技術的にできないこともある
④ チームの連携が上手く行かない
など、他にも色んな現実の壁とぶち当たるから、それと対峙しなければならない

 

〈 やり込み 〉
プランナーたるや、そのプロジェクト内で誰よりもそのゲームを遊び、誰よりも内容に詳しくなり、たくさん記憶し、色んなものを一瞬で引き出して比較、判断できるようにしておくこと


突っ走って書きましたが、以上です。

読んでくださった方にとって何か参考になれば幸いです。ありがとうございました。

エフェクト制作におけるSpriteStudioデータのフォルダ構成

アートディレクターの榊原です。

SpriteStudioでエフェクト制作するにあたって、データのフォルダ構成で悩んだので一例として辿り着いたものを紹介したいと思います。
使用しているSpriteStudioのバージョンは5.7.0となります。

何にも考えないでデータを作ると下記のような感じになりました。
f:id:wp_sakakibara:20170511224318p:plain
見づらい・・・し、エンジニア側も色々と困りそうです。

そこで下記の要件を満たすように見直しました。

  • 整理されて見易くしたい
  • できるだけエンジニア側の実装を容易にしたい(実装するエフェクトの数が多いと馬鹿にならないようです)

f:id:wp_sakakibara:20170511224324p:plain
ポイントは主にこちらのようになります。

  • commonフォルダに各プロジェクトファイル共通のデータ(画像ファイル、ssceファイル、ssaeファイル)を置く
  • プロジェクトファイル名と同じ各フォルダにはプロジェクト固有のデータ(画像ファイル、ssceファイル、ssaeファイル)を置く(例外もけっこうありますが)
  • プロジェクトファイル内で最初に再生してもらいたいメインのssaeファイルの名前は"play.ssae"とし、再生するアニメ名は"play"とする

こうしておくと威力差分や属性差分等の差分制作エフェクトのように共通の画像でいくつもプロジェクトファイルを作成する場合でもフォルダ構成を見ればどんな構造になっているかわかりやすいですし、エンジニア側はとりあえず"play.ssae"の"play"アニメを再生すれば良いので実装し易い(らしい)です。
現状手掛けているSpriteStudioで作るエフェクトは基本このような構成にし、モノによって派生パターンを作っています。(実際はもっと細かなルールが設けてあります)

用途によってベストなフォルダ構成は違うと思いますが、私のように悩んだ時の参考の1つになればと思います。
基本的に画像素材は共用で使うものとし、ルート的な場所に共用画像用フォルダを作り様々なエフェクトが共用で画像を参照する構成にした方が賢い場合もありそうです。
f:id:wp_sakakibara:20170511225638p:plain


ちなみに今回紹介したフォルダ構成を見直し前 → 見直し後に後から変更しようとすると正当な方法ではかなり手間のかかる手順を踏む必要があります。

  1. エクスプローラー上で移動したいファイルをコピーし、移動先のフォルダに貼り付ける
  2. SpriteStudio上で移動先のファイルを追加する(既存ファイルの追加)
  3. 追加したssaeの参照セルを変更する
  4. 必要なくなった昔のssaeとssceを削除する

・・・なんて大変!
今の所SpriteStudio上ではフォルダ構成やフォルダ名を変更する機能は無いようです。そのためフォルダ構成ははじめのうちにキッチリ決めてしまっておいた方が良いと思います。

余談

SpriteStudioのデータは実装用にコンバートするとプロジェクトファイル単位のデータに変換されます。ssaeファイル毎にデータが作られるんだと勝手に思い、ssaeやssceまで共有化できるなんてスバラシイ!思っていましたがそうウマい話では無いようです。
このためエフェクト単体毎にできるだけ負荷を減らそうと考えると差分制作エフェクトであってもssaeではなくsspj単位で分ける必要があります。
ちなみにsspjファイルを同時に複数開く機能やsspjを跨いでコピー/ペーストする機能は現状無いので、sspj単位にファイルを分けて制作することは思った以上に手間がかかったりします。

GunicornのUNIXドメインソケットが喪失するバグへの対応

エンジニアの原です。

弊社内のいくつかのPythonを使用したWebサービスでは、アプリケーションサーバーとしてGunicorn を使用しています。

先日サービス全体には大きな影響がなかったものの、そのGunicornのバグを踏み、一部のサービスが不安定になったことがあったのでその事例紹介をします。

環境

  • Python 3.4.2
  • Gunicorn 19.6.0
  • Nginx 1.12.0

現象

特に負荷のかかる時間帯にもかかわらず、任意のWebサーバーのnginxからクライアントに502レスポンスが返されていました。 nginxのログ的に、Gunicornがリクエストハンドリング用に生成しているUNIXドメインソケットが喪失したようです。

nginxのupstreamとして稼働しているGunicornのログには、以下のようなスタックトレースが出力されていました。*1

level:ERROR      time:2017-02-14 00:00:00 (JST)        process:100001     name:gunicorn.error   message:Exception in worker process
Traceback (most recent call last):
  File "/var/www/example/venv/default/lib/python3.4/site-packages/gunicorn/arbiter.py", line 557, in spawn_worker
    worker.init_process()
  File "/var/www/example/venv/default/lib/python3.4/site-packages/gunicorn/workers/gthread.py", line 109, in init_process
    super(ThreadWorker, self).init_process()
  File "/var/www/example/venv/default/lib/python3.4/site-packages/gunicorn/workers/base.py", line 132, in init_process
    self.run()
  File "/var/www/example/venv/default/lib/python3.4/site-packages/gunicorn/workers/gthread.py", line 240, in run
    s.close()
  File "/var/www/example/venv/default/lib/python3.4/site-packages/gunicorn/sock.py", line 123, in close
    os.unlink(self.cfg_addr)
FileNotFoundError: [Errno 2] No such file or directory: '/var/run/sockets/gunicorn.sock'

CPU稼働率、メモリ使用率等のシステムリソースには特異点はありませんでした。

原因

同様の問題に関するissueがありました。

github.com

issue内のコメントでも言及されていますが、原因は19.6.0で入ったこの変更だと思われます。

github.com

該当箇所は以下です。

-    def close(self, locked=False):
-        if self.parent == os.getpid() and not locked:
-            os.unlink(self.cfg_addr)
+    def close(self):
+        os.unlink(self.cfg_addr)
+        super(UnixSocket, self).close()

本来ならば、UNIXドメインソケットはarbiterプロセスのみによってファイルunlinkされるはずですが、workerプロセスによってunlinkされるようになっていました。
このcloseメソッド内ではプロセスIDからarbiterプロセスであるかの判定が必要なのですが、その判定が当該コミットで削除されています。
どうやらcloseメソッドを呼ぶプロセス自体がarbiterプロセスのみになるため削除したらしいのですが、19.6.0ではまだworkerプロセスでcloseメソッドが呼ばれてしまっているようです。

対策

この現象は、GunicornをUNIXドメインソケットでバインドさせた際に発生する問題なので、 UNIXドメインソケットではなくループバックアドレスに未使用ポートでGunicornをlistenさせることで解決しました。

- bind = 'unix:/var/run/sockets/gunicorn.sock'
+ bind = '127.0.0.1:8080'

なお、このバグは2017/3/4にリリースされたGunicorn v19.7.0で修正されています。

github.com

closeメソッド自体が削除され、別の場所でunlinkされるようになったようです。
バージョンアップしたいところでしたが、内部の実装が大きく変わっていたため、緊急性と安定性を鑑みてバージョンアップは見送りました。

まとめ

UNIXドメインソケットを使用する場合は、v19.6.0以外のバージョンを使用するようにしましょう。
非常にニッチなテーマで恐縮ですが、誰かの助けになれば幸いです。

*1:ログ日時、ファイルパスなどは実際のものとは異なります

「ハッカソン」を走り抜け!!

こんにちは、今回のブログ担当の近藤(英)です。

 

さて日々の開発を行っていくにあたって、日頃から新しい技術を学び、取り入れていくことを習慣化されている方も多いかと思います。

その一つの方法・場としても、「ハッカソン」という言葉が、以前より増して聞かれるようになってきたかと思います。

最近では、テレビや各メディアでのニュース、更にはエンターテイメントの一つとして番組として企画・放映されるまでになりました。

中には既に参加されて、その魅力に気づき、または虜になられた方もいるのでは無いでしょうか?(実際、私の仲間の中では年間で数十回参加される方もいる程です)

様々なジャンル、形式のものが各地で開催されるようになり、中には豪華な賞品が出るものもあり、良い腕試しの場となるものも多いと思います。

その目的も、新しい技術やサービスの創造各地域の活性化、また近年では、採用活動の一環であったり、入試の新たな方法として取り入れられたりと、多岐に渡ります。

 

「ハッカソン」は多くの場合、「アイデアソン」と対で(最近では参加する敷居を下げる意味でも、アイデアソン単独も多くなってきているようです)行われると思います、それは自然な流れで、

 

▼アイデアソン

 ・アイデア」と「マラソン」組み合わせた造語、特定のテーマについて、様々な分野の人々が集まって、ディスカッションしながら、新たなアイデアを生み出す。

▼ハッカソン

 ・「ハック」と「マラソン」を組み合わせた造語、様々な技術者達が主にチームで競い合う開発イベント。有名なものに、あの「いいね!」ボタンも、ハッカソンを通じて生まれた機能だという話もあります。

 

ですので、アイデアを捻り出し、それを形にするまでが一つの流れになります。

 

では実際には、どんなことをするのか、何が魅力で、何が大変なことなのか、この辺りについて、大会に参加した経験を元に概要と感想を時々挟みながら、おおまかにまとめていきたいと思います。

 

▼明確な期間がある

 主に24時間で企画出しから一つのサービスを創作し、最終的には審査員や聴衆にプレゼンするという超短時間勝負

 →本当に徹夜作業になることが多く、大会などの場合、当然プレゼンの場で不具合なく動くのが最低条件となるので、気を抜けないです。どれだけ良いアイデアでも、凄い技術を使用してようとも、プレゼンの約10分間が全てで、伝えられなければ意味がありません。

 

いつも担当している役割以外の作業を経験できる(しなければならない)

 少人数(最大5人程度)のメンバーで全ての作業をこなす為、例えばプレゼンに向けての資料を作成したり、デザインしたりと普段はメインとしていない作業を行うことになります。

 →私達は3人チームで参加した為、プログラムからデザイン、企画書作成まで(ディレクションなども)を全てエンジニア3人で行わなければならなかった為、非常に苦労しました。やはりチーム編成はとても大事です。

 

大会などの場合、即時に様々なジャンルのスペシャリストの方から審査を経て、様々な視点から優しく厳しい評価・助言を頂ける

 当然、大会の場合、その規模により、様々な企業がスポンサー、または審査員をされていることが多く、各メディアからの視線であったり、提供技術のスペシャリストからの指摘や助言であったりと、とても今後の為になる批評を頂けます。

 →このプレゼンでの質問などのやり取りが評価をかなり左右する気がします。時間配分が重要になり、しっかりと質問時間を設けられる方が評価に繋がると思います。

 

他チームとの交流(実装時間中や大会後の交流会など)により、技術などの情報共有や、輪を広めることができる。

 これはそのままで、まさに醍醐味とも言えると思います。他参加チームはライバルでもありますが、その前に同じ業界の技術者仲間です、どんな技術を使用するのか、時にはアイデアの助け合いなどもしたりしながら開発を進めていきます。

 →こういったコミュニケーションを経ながら、24時間の間ずっと一緒に開発を行う訳ですから、その結果如何に問わず、学生から業界の先輩まで、まさに戦友となり、この荒波の業界を生き抜いていく仲間となります。

これは普段では得難いものです。

 

実績に繫がり、乗り越えた自信につながる

 これは正直、私にとってはおまけな感じですが、賞を頂ければ実績にもなりますし、この短期間で到達できたという達成感はやっていけるという自信になります。

 →特に学生の方などについては、実際の企業での開発の超濃縮版とも言えますし、今後にとってとても有益なものになると思います。

 

・アイデアの出し方が身につく

 大会によっては、そのテーマが当日発表される事が少なくありません、アイデアは最重要と言えるものではありますが、短時間で企画をし、実装に取り掛からないと当然間に合わないので、アイデアの出し方、またはまとめ方のコツみたいなものが身につくようにります。

 →アイデアはメンバー同士がディスカッションをしながら行う訳ですが、それらの意見のまとめ方など、論理立てた方法が身につくかと思います。

 

・プレゼン力が身につく

 これもそのままで、最後には開発したものを実際に聴衆の前で披露し、その素晴らしさを伝えなければなりません、これは慣れや経験も必要となると思いますが、それを積み重ねる良い経験となると思います。

 →何せ、様々な歴戦の専門分野の方、中にはプレゼンで勝つための要員も居ますし、これだけの数のプレゼンを見れるだけでもかなりの経験となると思いますし、素直に楽しい但し自分達の分が終わった後に限る)です。

 

・でもホントにツラい、そして2度と参加しないと強く思う

 ただ単純に、精神的に体力的に追い込まれ、何を土日を費やしてやっているんだろうと思う時間帯が存在します。

 

・だがしかし、結局、全て終わった後は、また参加しようと思う

 ホントにツラいこともありますが、終わってみれば、面白いこともやはり多くて、それが勝り、また参加してみようと思い直します。

 

 これは個人的なことですが、賞を頂けると心から嬉しく、大会に負けるとホントに悔しい、何がいけなかったのかと、深く反省をし、次回までには戦える武器を増やすために、また様々な技術を身につけようと、次へ進む新たなモチベーションが生まれます。

 

と、長くなり私的な意見も多々入ってしまいましたが、「ハッカソン」は開発していくにあたって、短期間で、特に総合力を上げるのに適しているように感じます、色々な作業をする中で、自分に適しているものが新たに見つかるかもしれません、ですので、あの作業を経験してみたいが機会がない、などの場合、思いきって参加してみるのも良いきっかけかもしれません。

たとえ失敗しても、チャレンジしたことは次に繋がると思いますし、チーム戦の中では、必ず仲間からの助けがあり、自分が助けとなれることがきっとあります、これは今後の開発の中で、とても重要なことであると思います。

皆さんも是非、勇気がいることでもあると思いますが、迷っているなら参加してみると世界が変わるかもしれません、大げさではなく、実際にそうなった仲間を何人も知っています。

最終的には自分達で開催しちゃうのもありかもしれません。

 

それでは、ゴールに向かって、是非一緒にハッカソンを走り抜きましょう!!

 

 

QAのお仕事紹介

クラッシュフィーバーQA(Quality Assurance)チームの櫻井です。
今回のデベロッパーブロクでは、QAの業務内容について紹介したいと思います。

とはいえ、QAってデバッグしてるだけなんじゃ?
そんな認識なのではないかと思います。
ざっくり言うと合ってますが、具体的にはこんな事してますという紹介です。


日々の作業内容

メイン:デバッグ
メインの作業は勿論デバッグです。
追加される新機能や不具合の修正に対して、

  • 挙動に問題がないか
  • 既存の動作に影響が無いか

色んな種類の端末を使って確認します。

基本的に機能を作ってくれたエンジニアさんが、
作ったコードについて、正しく動いているかを見てくれていますが、
思わぬ条件が複雑に絡み合った場合など、
作り手が予測していない条件で発生するような、そんな困ったバグを探しています。
そして見つかったら報告し、コードを修正してもらい、再度デバッグです。


2番目:テスト仕様書の作成
新しい機能が追加される時や、既存の細かな機能修正やバグ修正の時など、
ユーザー様に届けられるバージョン毎に複数の変更が入ります。
その変更をエンジニアさんが作り込んでる間に、QAチームではテスト仕様書の作成をしています。
そして作り上がった機能に対して、テスト仕様書を基にデバッグをしていく流れです。


3番目:データの整合確認
大きな流れとしては、
上記テスト仕様書の作成と、デバッグを繰り返している感じですが、
実はこれだけではなく、別軸のお仕事もあります。

クラッシュフィーバーでは、
毎週のように新ユニットの追加や新クエストの追加、復刻クエストやキャンペーンがあったり、
それに伴ったお知らせなど、色々なデータが作成されています。
ということで、そのデータの正しさの確認も実施しています。

メインで実施している新機能のデバッグもしないといけないため、お手伝いに入っている状態ですが、
こちらはチェックするデータが半端ない量であり、凄く大変です。
効率的かつ精度の高いチェックを実施しないといけません。


4番目:なんか色々

なんか色々1:サポートのサポート
デバッグをする上で仕様の把握が必須ですので、仕様に詳しくなります。
結果、CS(カスタマーサポート)のサポートも日々のお仕事です。
挙動に対する問い合わせに対して、

  • 仕様通りであるのか
  • 不具合であるのか

そのあたりの回答もしています。
ものによってはプランナーさんやエンジニアさんへ問い合わせをします。

なんか色々2:挙動の遅い端末の調査
最近クラッシュフィーバーに追加された機能で、
処理が極端に遅い端末がマルチプレイのメンバーに居ると、
エフェクトの再生に時間がかかり、あたかも進行不能に見えてしまうということが起きてしまいます。
そこで、仕方無く、処理が極端に遅い端末を使用している場合、
マルチプレイに限り、自動で演出を減らす対応が入っています。

集計されたログから、処理のスコアが規定値を下回っていた場合に、
演出を減らす対象になりますが、本当に遅い端末であるのか、
実際の端末スペックを確認する作業をしています。
デバッグで様々な端末に触れていることもあり、QAチームでやるのが効率良さそうだと思います。


まとめ

QAチームの仕事はこんな感じの作業になります。

f:id:Mikitea:20170217013339p:plain

 

現状・今後、QAとしてあるといいなと思うスキル
結構色々な作業をしている中で、
こんなスキルや経験があるといいなと思うものを挙げてみます。

▼デバッグ経験
 どのような所にバグが潜んでいるのか、経験から探す為にはあるといいですね。

コードが読める
 テスト仕様書を作成する際も、実際にデバッグする際にも、
 コード上の修正内容を知っていると、影響範囲の特定がしやすくなります。
 また、不要なデバッグを削る判断をする際にも役立ちます。

 C言語できれば大抵行ける!(はず)

SQLがかける
 データの確認や、絞り込みなど、使えると効率がグンっと上がります。

▼エクセル(スプレッドシート)が普通以上に扱える
 データまとめや関連性の分析や資料まとめなど、様々なシーンで必要になります。
 マウス無しで全てキーボードでサクサクやれると色々楽です♪ 

コミュニケーション力がある
 仕様を確認するために、他のチームへ質問しに行くことが多々あります。
 コミュニケーション力があるとその辺も円滑になります。

 

自分の職歴 

因みに自分は前職で車関係のSEを約8年間していました。
要求分析からシステムテストまで、
上流の工程から一通り経験したことや、
そこでの品質保障に関する考え方が凄く役立っています。

 

最後に、お仲間募集してます!

この記事を見て、一緒にQAをしてみたいと思えた方、
是非一緒に働きましょう!

あとこのようなQAのメンバーと一緒に
作り上げてくれるエンジニアさんやプランナーさん、
デザイナーさんも是非ワンダープラネットへ!