Game Programmer Blog

ゲーム製作に伴うプログラミング技術や開発手法や環境などを公開していきます

フィードバック

自分と関わるエンジニアに対して成長を促せているか、そのために

必要な適切なフィードバックが出来ているか、時折、指摘するのが遅れたなー

とか伝え方間違えたな~とか後悔する事があるんですがよくよく考えたら

そういったフィードバックを今まで受けてきた記憶がそれ程ありませんでした。

 最近迷ってしまったケースがあってそういった場合はどうするのが

正解だったのか不明だったのでフィードバックについて学ぶために本を買いました。

同機は単純。チームや部下の成長を迅速かつ正確に行いたい・行えるような能力を

身に着けたい。

 

規模でいうと数名~百数十名、10程度のチームで働いて数十のチームの

働き方を見てきて思うことは最終的には人がチームを形成しているということです。

成果にこだわろうと思ったら人にこだわらないといけないと確信しています。

ただ一緒に働くメンバーを選べるわけではないので現行戦力をどう伸ばせるかが

重要だと思ってます。組織やチームの価値観を徹底的に落とし込み、成果とは何かを

定義し全員が同じベクトルを向き、役割を把握しながらも助けあえる組織。

 

フィードバックする側として厳しさを持てなければその役割は果たせてない。

言語化できればあとは必要なことをすたすら実行していくのみ。

 

 

ロケットリーグ

ロケットリーグ、Steam・独立系開発会社で直近最も成功しているタイトルだと思います。

f:id:TrueSnowman:20170807232358p:plain

UE3で作られてるそうです、Switch版もUE3で作らざるを得ないのかな?

ロケットリーグ - Wikipedia

f:id:TrueSnowman:20170807231627p:plain

私の夢の一つである全プラットフォーム、クロスプレイ。

その実現に最も近いタイトルでもあるので参考のためにもプレイしました。

オンラインプレイヤー約10万ってマジ!?そりゃ繋がりまくるわ。

プラットフォームごとのユーザ数が知りたいなー。

f:id:TrueSnowman:20170807231629p:plain

アンテナ表示+ping、アンテナオンリーよりこっちの方が納得感あるのかな?

f:id:TrueSnowman:20170807231631p:plain

 

Steam市場

 

どのプラットフォームでいつアプリをリリースするのかはとても悩むと思います。

そこで各市場でどれだけどんなユーザーがプレイしてるのか調査してみます。

 

同時接続ユーザー

ピーク時 12,633,521

f:id:TrueSnowman:20170805175844p:plain

 

Steam ダウンロード統計

f:id:TrueSnowman:20170805175855p:plain

国/平均ダウンロード速度/グローバルSteam通信の割合

USA 31.6 Mbps 18.00%
China 27.5 Mbps 11.50%
Russia 17.5 Mbps 6.30%
Germany 20.1 Mbps 5.50%
UK 24.4 Mbps 3.80%
South Korea 96.2 Mbps 3.20%
Canada 29.8 Mbps 2.50%
France 11.4 Mbps 2.60%
Australia 12.2 Mbps 1.70%
Poland 15.6 Mbps 1.40%
Japan 51.5 Mbps 1.30%
Sweden 47.6 Mbps 1.30%
Thailand 23.4 Mbps 1.10%

作ってるソフトにも英語,簡体,繁体の対応を入れたほうがよさそうですね。

 

プレイヤー数が多いゲーム

f:id:TrueSnowman:20170805175859p:plain

 

2016年トップセールスf:id:TrueSnowman:20170805175850p:plain

超有名プロデューサーでも無い限りスタート時点で開発費出してもらって

大規模開発出来ることなんて無いので独立系開発会社のソフトをリストアップしてみます。

プラチナ ROCKET LEAGUE / レース,スポーツ

ゴールド Stardew Valley / RPG,趣味レーション

シルバー Rust / アクション,アドベンチャー

 

どれだけ分析したとして傾向が掴めたと理解したつもりになったとしても

それは過去の傾向に過ぎないことを理解しておかなくてはならない。

その傾向からまさに今この瞬間リリース出来れば話は別だがそれは無理。

 

プラットフォーム、ユーザ数、ジャンル、対応言語、タイミング、プロモーション、

開発期間、製作技術、他プラットフォームや他業種への展開のしやすさ、

自分が作ったものを可能な限り多くのユーザーに届けるために

色々考えることだらけで楽しいですね~。

シリコンバレーから学ぶサーバントリーダーシップ

勉強会に参加させて頂きました。

会場はサイボウズ 大阪オフィス 。勉強会等に会場提供しても印象が下がらない

ぐらいのおしゃれ感のあるスペース、エンジニアを集めるために何が必要か理解の

ある会社(文化)っていいですね。

内容はサーバントリーダーシップについてです。

スライドはまだ公開されてないようなのでリンクは後日張らせて頂きます。

 

アジャイル開発において大きな役割の一つにあるサーバントリーダーシップ

フィードバックはポジティブ・ネガティブ両方必要ってのが

自分としては意外と出来てなかったかな~と思って反省しました。

課題や問題に取り組んでクリア出来たりする状況を見てるとこれが

出来たら次はこれが出来るの繰り返しでクリアするためのアドバイス

しているつもりだがそれがクリアした時のフィードバックが出来てなかった。

 

「心理的安全性」のことに思いを馳せてみる

心理的安全性についての勉強会に参加させて頂きました。

ここ数年注目されてる言葉だと思います。 

 

職場によってはこのバグ?誰の!?誰の責任?みたいなことで追及したり

犯人捜しに一生懸命、力を割く人がいます。そういう人が何に焦点を

当てているか(言い方や伝え方)を確認すれば何をしたいのか見えてきます。

問題を修正したい場合の焦点は状況把握です。誰のバグかというよりは

どうやって発生しているのかとかどんな実装をしているのかを確認します。

そうでない例えば自尊心が高い場合、誰のせいかがその人によって大事になります。

見つけたことによって自分>バグを生んだ人という構図によって自分がその人より

優秀であるとその人にとっては確認出来ている(出来ているつもり)ので

それを周りに伝えることでより多くの人に認知させることでより自分を

安心させています。自分の能力が低いと本当は把握しているにも関わらず

認められず努力出来ない場合に人の足を引っ張ることでしか安心出来ないのです。

 

上記の例は心理的安全性とは離れた内容かもしれませんが 

チームのゴールとかチームが求める価値観みたいなものは徹底して

理解してもらわないと分けのわからない主張が出てきたり余計なタスクに

時間を費やされていたり責任押し付けあったりしてしまうと思います。

 

Cybozu Meetup Osaka #2 SRE, 生産性向上, スクラム/アジャイル

勉強会に参加させて頂きました。

cybozu.connpass.com

 

参加した動機は次の2つほどです。

1.使ってるサービスを作ってる人ってどんな人?どんな基準でどんな技術使ってる?

2.働き方の特集とかで見てるニュースがサイボウズの事例だったりで興味があった

 

改めて会社のホームページ見ると社長が育休を3回とってる!!すごい。

効率よく働いて成果出すとかってよく言ったり言われたりする場面は多いと

思うがこれを体現するのってとても難しいことだと思います。

 エンジニアであれば効率上げるため仕組みを作るために時間がかかったり

自分で作っても無い技術的負債まみれのシステムの改修だったり短い時間で

すますためのシステムを作り続けてたりするので結果働く時間が長くなったり

するケースも多々あると思います。

トップが働き方の選択を体現しているというのは従業員からすれば

ある種の安心感やエンゲージメントが高くなる要素の一つになると思います。

 

話を戻して勉強会では業務改善チームとかスクラムとかの話があがりました。

トップダウン的にアジャイルへ移行したようですが抵抗は少なかったようです。

BtoBはユーザの声が届きにくい印象があるのでこういったイベントで

開発者がユーザやどういった人が働いているのかを知れる機会というのは

とても良い効果があるののかなと思いました。

 

自社に置き換えるとユーザや開発者との接点を持つ機会や場所を作る。

あんまり人が集まる気配は感じないがやると集まったりするのかな?

コストは日程土日であれば希望者で開発者固めて参加してもらえれば

場所代+軽食代ですむし能動的に参加した人はエンゲージメントあがるし

ユーザや将来の新卒・中途採用者の満足にも繋がる。目先の数字が

見えにくいけどこういうのはひたすらやり続けて認知度あげてくタイプの

施策なんで仕方ないんだろうな〜。

 

まいど!Agile Japan 2017 大阪サテライト

勉強会に参加させて頂きました。

agilejapan-osaka.connpass.com

 

参加した動機はアジャイルの有効性と導入障壁の取り除き方を知りたかったからです。

 

資料リンク

http://www.agilejapan.org/img/session/document/modernAgileJapan2017.pdf

speakerdeck.com

www.slideshare.net

speakerdeck.com

speakerdeck.com

 

正直、初心者向けの内容だったのかなと思いました。

その中でもヴァル研究所は会社的にアジャイルを推進しておられて

とても興味を持ちました。エンジニアの基本欲求に新しい手法や技術を

試したいみたいなものってあると思うんですが他の部署で理解される?

通用するの?って感覚がありましたがうまくいってるように見えました。

 

数値化しづらかったり効果の説明がしづらいものの導入や検証はつまるところ

権限を持った人が推進していくことで軌道にのるんだな〜と思いながら最近、

若手のチャレンジをこっそり支援するように動いてる自分とリンクさせながら

権限は必要だなと思いました。誰かが正しいことをしようとしている時に

能力が低くて権限を持っている人のせいで出来ないのは馬鹿らしいので

どんな手法やシステムを用いるにしても結果を出して権限を広げていく

これしかない。

 

短期・中期・長期で見てどういう方向性で品質をあげていけるか

どうやって市場で勝ち残っていくのか

どうやって新たな市場を作り出せるか

を個々でなくチームで方向性持って業務にあたれるように出来ればいいな。

文書化すると結構ハードル高いな・・・