マネージャーによるメンタリングの話
マネージャの勉強会に参加させて頂きました。
セッションは2つ、スライドは見つかりませんでした。
1−1：開発中の失敗体験型新人教育と、中堅エンジニアへのメンタリング 森田 和則
1−2：検討中の「個性を活かして成果を最もあげるチームメンタリング」について話してみる 絹川 達也
全体を通しての感想
森田さんのセッションはちゃんと失敗させてあげるという内容がとても興味深かった。
ちょうど今年の新卒のメンターを任せることになってるんですが危なっかしいので何か本でも渡して体系的なことを教育のベースに持たせた上で関わってもらったほうがいい気がしてるのでとても参考になった。絹川さんのセッションは途中参加でまともな感想が出来ない状態でした＞＜。
Regional Scrum Gathering Tokyo 2017 報告会
スクラム関連のイベントに参加してきました。
セッション・スライド資料はこんな感じ。
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を取得したりミニマムなチームでスクラムを実践したりはしているものの、そこから開発のしやすさ(気持ちよさ)が手に入ったことはあれどそれが最大限の利益を生み出すには至っていない。プロダクトやサービスの価値と開発手法に関連性がないならウォーターフォール/スクラムそれこそどちらでも良いことにならないだろうか。結論としては組織や開発メンバーのレベルに応じて手法を選択する必要があるのかなと思いました。
ちゃんとまとめられてる方がいらっしゃったので紹介しておきます。
Unreal Engine Package 1
UEを使ったプロジェクトで市場に出したり形式にする場合、パッケージする必要があります。
プラットフォーマー(Sony/Microsoft/Google/Apple等)へ最終的に提出する形式ですね。
コンシューマではリージョン毎にスマホではAndroid/iOSで出力したりする必要がありますよね。
コマンドから作れると色々便利なのでEditorからのパッケージ作成を調べてみます。
まずEditorからのパッケージは次の手順で作成できます。
パッケージする時のプロジェクト設定
出力するときに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)。
ビルド出来なくなってたり、色んなプラットフォームで動かしてたりすると動かなくなったりすることがあるのでJenkins等と連携して早期にバグを検出するためにも機械的にパッケージする方法を調べてみました。
Unreal Engine アプリ配信への道のり
Unreal Engineに触る時間が増えてきて経験値としていくつかの市場で配信してみたいと思い、その経過をブログに残しておきたいと思います。
1年後にどんな成果や経験からどう成長していくのかやるだけやって見ましょう。
タスク管理ツール Trello編
本日はタスク管理ツールについてご紹介。
タスク管理と聞いて何を思いつくでしょうか？
ツールとしてはエクセル、Redmine、JIRA、chatwork、Brabio、Backlog等
思いつく限りでも沢山ありますし検索すると他にも沢山でてきます。
私は数年の間、Googleカレンダーに予定を入れたりToDoリスト作ったりしていましたが
優先順位が見辛かったりどれくらい遅れてたり足りてないのかが視覚的に見えないことが
あってもっと便利なものがあればなと思って探してました。
そこで見つけたのがこちら、Trello です。
スクラムボードぽいデザインをしててカードの順番も簡単にブラウザ上で動かせます。
ChromeにもFireFoxにもプラグインがあってよりスクラム的な使い方なんかも出来たりします。
中々に面白そうなツールなのでアウトプットの質をあげれるか試しに使ってみようと思います。
アンリアルの可能性
アンリアルフェス２０１５大阪に参加させて頂きました。
概要はこちら⇒https://www.unrealengine.com/ja/blog/unreal-fes-2015-osaka-event
当然ちゃ当然なんですが、やや宣伝要素の色が濃かったかなというのが印象。
無料化に伴いゲーム業界は当然ながらそのほかの建築業界やアニメ業界など
様々な業種にも入り込んでいかないとビジネスとして拡大していけないので仕方ない。
フリーとしては後発だし、もうブルーオーシャンじゃない市場で
どこまでパイを広げていけるかが重要になりそうですね。
質問タイムにて9割方ライセンス料金の話になってたので現実に
5%のロイヤリティがどの程度の温度間なのか数字で計ってみましょう！！
大前提として次の2点があります。
・四半期で３０００ドルを上回ったプロダクトのみが対象
・ゲーム以外にはロイヤリティは発生しない
現在が1$＝118.920205円なのでこれをベースに計算すると四半期で
約35万を超えるとロイヤリティが発生することになります。
ということはよほどの大失敗でもない限りはロイヤリティは発生します。
Android/iOSのアプリ市場でざっくり計算するとこんな感じ。
月商からプラットフォームで30%、UE4へのロイヤリティ5%がひかれて残ったのが利益。
コンシューマ向けだとロイヤリティ契約以外もあるみたいだが大まかな温度間は伝わっただろう。
当たり前の話だが自社で作れるエンジン・ミドルウェア・ツールなどの価値が高く維持できれば
プロジェクト毎にコストは発生せずより高い利益が確保され使う必要性はないということだ。
ただ各分野において最前線のエンジニアが6人必要であればそれで年収800万＊6人で4800万程度
のコストは発生することになる。こういった扱う額が大きくなってくるとやや未来が読みにくく
なりますが自社の技術力やエンジニアの離職率や勤続年数に伴う能力の上昇幅などが見える人なら
選択はそんなに難しくはないように感じます。
個人や数名の小規模なチームで一発当てたい場合は率先して使うことをオススメします。
企業では色んな数字とプロダクト規模、会社の技術ロードマップ考えてからの選択ですかね。
スクラムマスター Part2
認定スクラムマスター研修は2日間行われ時間は10時～18時。
講師の方はJames O. Coplien氏、同時通訳で行われ通訳は3名ほどおりました。
最終2日目の最後の数時間には2~3名の方が別会社から協力で講師の手伝いで参加されてました。
英語が分からない場合はイヤホンで研修を受ける形で参加人数は30名以上40名未満ほどでした。
参加者の年齢層は２０代前半～４０代後半ぐらい、男性も女性もいて、国籍も多種多様。
さっそく感想やら学んだことを書こうと思いますが結論から言います。
20万円の対価として価値はないと私は感じました。
最も大きな理由としては事前にある程度の事前準備をしていたことが大きいと感じてます。
事前準備があったことで多少の認識違いに気付いた程度でそれ以外は復習程度の感覚でした。
研修内容は講義：6、ワークショップ：4ぐらいの割合で進められてました。
スクラムにおける知識やイベントを体系的に学ぶことは確実に出来ます。
それは間違いないのでスクラムの知識や経験ゼロな方には価値のある内容だと思います。
スクラムは自己組織化を促すための手法としてとても再認識できましたがチーム内でキーと
なる人物の性格や気質、能力が極めて大きな影響を及ぼし向かないチームもあると思います。
ある一定の能力が担保されているチームであればわざわざスクラムなんて手法をとる必要はないとも感じてます。
採用するにしてもチームを限定して成功した場合に横展していくスタイルが最も受け入れやすく浸透しそう。
会社によっては新しいプロセスへの抵抗が強い方が多数派の会社もあると思うので目に見える結果が
ついてこないと受け入れづらいと思うのと、ただの技術オタクの集りから採用しても目的がぶれそうなので
あくまで自己組織化に伴うメリットを理解できる or しようとするチームが採用するべきかなと思います。
自分が会社で参加するのに承認を出す立場であればエンジニアの文化形成(チャレンジ推奨)や
エンジニアへの福利厚生の一環、会社としての税金対策程度の感覚でしか承認できないだろうなと。
継続的に結果を出す方法に明確なやり方なんてないので受ける前と変わらず
バンバン稼ぐ(ユーザへの高い付加価値提供)ためにももっともっと色んな事を
学びながら何より結果を出すことを最優先に行動して行きたいと思います。
