ゲームプログラマのすすめ

https://coconala.com/users/3696234

プロジェクトマネジメントの勘所

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

devlove-kansai.doorkeeper.jp

 

セッションは2つ、スライドも公開されていました。

1−1:レガシープロジェクトでやる気を引き出す5つの工夫 森本 千佳子
http://www.slideshare.net/ChikakoMorimoto/devlove-71958383

 

1−2:心理的安全を保証されたチームづくり 粕谷 大輔
https://speakerdeck.com/daiksy/devloveguan-xi-puroziekutomanezimentofalsekan-suo

 

全体を通しての感想

森本さんのセッションを聞いてると修羅場を何度も潜り抜けてる感があって説得力が半端ない。PMOという言葉はこの勉強会で始めて知りました。何百・何千人で動くプロジェクトってどんなやり方なんだろう?そんなチームがパフォーマンスを発揮出来る環境作り、とても興味が深くきかせてもらいました。参考になりそうな本も紹介されてました。

粕谷さんのセッションは心理的安全の話、自分が欲しいと思っていたチームの雰囲気が言語化されたような内容でとても腹落ちしたセッションでした。過去に体育会系のマネージメントをした上での今は違うやり方をしているそうです。マネージメントも時代やチームによって維持しやすい形があるし模索する必要があるのかなと感じました。

 

 森本さんチョイスのお勧めの書籍

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解

 

 

熊とワルツを - リスクを愉しむプロジェクト管理

熊とワルツを - リスクを愉しむプロジェクト管理

 

粕谷さんチョイスのお勧めの書籍

 

マネージャーによるメンタリングの話

マネージャの勉強会に参加させて頂きました。

devlove-kansai.doorkeeper.jp

 

セッションは2つ、スライドは見つかりませんでした。

1−1:開発中の失敗体験型新人教育と、中堅エンジニアへのメンタリング 森田 和則

1−2:検討中の「個性を活かして成果を最もあげるチームメンタリング」について話してみる 絹川 達也

 

全体を通しての感想

森田さんのセッションはちゃんと失敗させてあげるという内容がとても興味深かった。

ちょうど今年の新卒のメンターを任せることになってるんですが危なっかしいので何か本でも渡して体系的なことを教育のベースに持たせた上で関わってもらったほうがいい気がしてるのでとても参考になった。絹川さんのセッションは途中参加でまともな感想が出来ない状態でした><。

Regional Scrum Gathering Tokyo 2017 報告会

スクラム関連のイベントに参加してきました。

devlove-kansai.doorkeeper.jp

セッション・スライド資料はこんな感じ。

 

2−1:つらい問題に出会ったら 開原 隆弘
http://www.slideshare.net/kaihara_t/rsgt2017

2−2:Scrumありがとう、そしてさようなら-Scrum 破- kyon_mm
https://confengine.com/regional-scrum-gathering-tokyo-2017/proposal/3246/scrum-scrum-

2−3:結果的にスクラムになってる!なのがいいと思う! 椎葉光行
https://speakerdeck.com/bufferings/jie-guo-de-nisukuramuninatuteru-nafalsegaiitosi-u-number-rsgt2017

2−4:アジャイルカルチャーが組織に根付くまでの挑戦 中村 洋
https://speakerdeck.com/yohhatu/asiyairukarutiyakazu-zhi-nigen-fu-kumatefalsetiao-zhan

3:Regional Scrum Gathering Tokyoの雰囲気を味わう

 ピザとお酒と一緒にスクラムについて色んな話やRegional Scrum Gathering Tokyo 2017の雰囲気などの話。

 

全体を通しての感想

スクラム推進派の方と会ったり話聞いてたりすると反ウォーターフォール?みたいなノリありませんか(笑)。本質としては最大限の利益を獲得できればウォーターフォール/スクラムでもどっちでもいいです。ただ手法として振り返りやユーザへの付加価値に目を向けることが日常的に組み込まれてる手法はときに変な拘りを持つエンジニアや若手エンジニアをコントロールするのに向いていると思う。私自身はスクラムの失敗経験からSCMを取得したりミニマムなチームでスクラムを実践したりはしているものの、そこから開発のしやすさ(気持ちよさ)が手に入ったことはあれどそれが最大限の利益を生み出すには至っていない。プロダクトやサービスの価値と開発手法に関連性がないならウォーターフォール/スクラムそれこそどちらでも良いことにならないだろうか。結論としては組織や開発メンバーのレベルに応じて手法を選択する必要があるのかなと思いました。

 

ちゃんとまとめられてる方がいらっしゃったので紹介しておきます。

blog.eumyang.net

Unreal Engine Package 1

 

UEを使ったプロジェクトで市場に出したり形式にする場合、パッケージする必要があります。

プラットフォーマー(Sony/Microsoft/Google/Apple等)へ最終的に提出する形式ですね。

コンシューマではリージョン毎にスマホではAndroid/iOSで出力したりする必要がありますよね。

 

コマンドから作れると色々便利なのでEditorからのパッケージ作成を調べてみます。

まずEditorからのパッケージは次の手順で作成できます。

f:id:TrueSnowman:20170110084021p:plain

パッケージする時のプロジェクト設定

f:id:TrueSnowman:20170110084023p:plain

f:id:TrueSnowman:20170110082326p:plain

出力するときにOutputLogにコマンドが流れるのでそれを解析していけば辿りつけます。

 

コマンドラインからのパッケージ出力

"D:\Program Files (x86)\Epic Games\4.14\Engine\Binaries\DotNET\AutomationTool.exe" -ScriptsForProject="D:/Unreal Projects/Package/Package.uproject" BuildCookRun -nocompile -nocompileeditor -installed -nop4 -project="E:/Unreal Projects/Package/Package.uproject" -cook -stage -archive -archivedirectory="D:/Unreal Projects/Package/Test" -package -clientconfig=Shipping -ue4exe=UE4Editor-Cmd.exe -pak -prereqs -distribution -nodebuginfo -targetplatform=Win64 -CrashReporter -utf8output
 

解説

"D:\Program Files (x86)\Epic Games\4.14\Engine\Binaries\DotNET\AutomationTool.exe"

 ビルドするためのコマンドを走らせるためのUEのパス

 

-ScriptsForProject="D:/Unreal Projects/Package/Package.uproject"

 パッケージする対象のuproject

 

-archivedirectory="D:/Unreal Projects/Package/Test"

 パッケージを出力するパス

 

-clean

 Project Setting - Full Rebuildで付加されるオプション


-nodebuginfo

 Project Setting - Include Debug Files で付加されるオプション

 

-distribution

 Project Setting - For Distribution で付加されるオプション

 

Github

テストしたプロジェクトもGithubにコミットしています(UE4.14.2)。

github.com

 

ビルド出来なくなってたり、色んなプラットフォームで動かしてたりすると動かなくなったりすることがあるのでJenkins等と連携して早期にバグを検出するためにも機械的にパッケージする方法を調べてみました。

Unreal Engine アプリ配信への道のり

 Unreal Engineに触る時間が増えてきて経験値としていくつかの市場で配信してみたいと思い、その経過をブログに残しておきたいと思います。

1年後にどんな成果や経験からどう成長していくのかやるだけやって見ましょう。

タスク管理ツール Trello編

本日はタスク管理ツールについてご紹介。

 

タスク管理と聞いて何を思いつくでしょうか?

ツールとしてはエクセル、Redmine、JIRA、chatwork、Brabio、Backlog等

思いつく限りでも沢山ありますし検索すると他にも沢山でてきます。

 

私は数年の間、Googleカレンダーに予定を入れたりToDoリスト作ったりしていましたが

優先順位が見辛かったりどれくらい遅れてたり足りてないのかが視覚的に見えないことが

あってもっと便利なものがあればなと思って探してました。

 

そこで見つけたのがこちら、Trello です。

trello.com

 

スクラムボードぽいデザインをしててカードの順番も簡単にブラウザ上で動かせます。

ChromeにもFireFoxにもプラグインがあってよりスクラム的な使い方なんかも出来たりします。

中々に面白そうなツールなのでアウトプットの質をあげれるか試しに使ってみようと思います。

f:id:TrueSnowman:20150510020526p:plain

アンリアルの可能性

アンリアルフェス2015大阪に参加させて頂きました。

概要はこちら⇒https://www.unrealengine.com/ja/blog/unreal-fes-2015-osaka-event

当然ちゃ当然なんですが、やや宣伝要素の色が濃かったかなというのが印象。

無料化に伴いゲーム業界は当然ながらそのほかの建築業界やアニメ業界など

様々な業種にも入り込んでいかないとビジネスとして拡大していけないので仕方ない。

フリーとしては後発だし、もうブルーオーシャンじゃない市場で

どこまでパイを広げていけるかが重要になりそうですね。

 

質問タイムにて9割方ライセンス料金の話になってたので現実に

5%のロイヤリティがどの程度の温度間なのか数字で計ってみましょう!!

大前提として次の2点があります。

・四半期で3000ドルを上回ったプロダクトのみが対象

・ゲーム以外にはロイヤリティは発生しない

 

現在が1$=118.920205円なのでこれをベースに計算すると四半期で

約35万を超えるとロイヤリティが発生することになります。

 ということはよほどの大失敗でもない限りはロイヤリティは発生します。

 

Android/iOSのアプリ市場でざっくり計算するとこんな感じ。

月商からプラットフォームで30%、UE4へのロイヤリティ5%がひかれて残ったのが利益。

コンシューマ向けだとロイヤリティ契約以外もあるみたいだが大まかな温度間は伝わっただろう。

f:id:TrueSnowman:20150419234829p:plain

当たり前の話だが自社で作れるエンジン・ミドルウェア・ツールなどの価値が高く維持できれば

プロジェクト毎にコストは発生せずより高い利益が確保され使う必要性はないということだ。

ただ各分野において最前線のエンジニアが6人必要であればそれで年収800万*6人で4800万程度

のコストは発生することになる。こういった扱う額が大きくなってくるとやや未来が読みにくく

なりますが自社の技術力やエンジニアの離職率や勤続年数に伴う能力の上昇幅などが見える人なら

選択はそんなに難しくはないように感じます。

 

個人や数名の小規模なチームで一発当てたい場合は率先して使うことをオススメします。

企業では色んな数字とプロダクト規模、会社の技術ロードマップ考えてからの選択ですかね。