リーダーを簡単に辞めさせる方法
幾つもプロジェクトを持っている会社であればチームに必ずリーダーやエースがいると思います。
場合によっては簡単にモチベーションを下げ、辞めさせる事ができる方法を1つ紹介します。
「リーダーをそのプロジェクトから強制的に外し、燃えているプロジェクトに何人かリーダーを投下し、誰がやってもいいような仕事をアサインする」
です。これでまず１００％デモチして、かつ退職を考えるようになります。
リーダーはリーダーだからモチベーションを持っている
これは一見当たり前の事ですが、誰にでも自尊心があります。仕事を奪い、どうでもいい仕事をアサインする事がその自尊心を傷つけることに十分すぎる効果があります。リーダーからリーダーを意に反して奪うことは非常に強い効果を持ちます。そして、退職を考えます。
誰にでもできる仕事を与える
これも非常に効果的で、誰にでもできるスキルレベルに見合わない仕事を与えることで、無気力感を与えます。燃えているプロジェクトでは仕事に融通が利かないことが多く他にも元リーダーがアサインされているので動きづらくなります。自分はいなくても良いのではと思い始め、そして、退職を考えます。
指示を出す側から指示を出される側に変える
今までスケジュールを考え、タスクを考え、アサインを考えていた人を逆に仕事を与えられる立場にします。スケジュールは考えなくてよくなり、タスクも分解せずに済み、アサインに頭を悩まされる必要もなくなります。そして、退職を考えます。
こんな事がありえるのだろうか？
アサインの権限者がバグってると往々にしてありえます。
よくあるシチュエーションとしては1つのプロジェクトが無茶苦茶燃えていて、それを何とかしようとして他のプロジェクトからリーダーを連れてきて何とかしようとする場合です。現場のリクエストとしては多くの場合「出来る人をアサインしてほしい」となり、通常は「出来る人＝リーダー」となるパターンが多く、リーダーを複数連れてくるケースなどがあります。
対策として
燃えているプロジェクトにリーダーを突っ込む場合、最初から一時的な約束にするか単に突っ込むのではなく裁量を殺さずに課題ベースで仕事を与える必要があります。
この事案に限らずアサインのマネジメントというのは非常に難しいものだと考えます。良い人を採用してもワークしない、というのはこういうケース（とりあえずアサインすれば何とかなるだろうケース）もあると考えています。
株式会社gumiを退職しました
2015年9月30日をもって、株式会社gumiを退職しました。
入社は2010年6月29日でしたから、5年程度務めたことになります。5年の間に会社の人数は膨れあがり、40人程度だった会社が800人くらいの会社になりました。
5年間の間にフィーチャーフォンのゲームからスマートフォンのゲームの企画開発から、部門の責任者、エンジニアの採用、評価、育成、拠点の立ち上げ、海外での開発、等々、様々な経験を詰むことができました。
会社としては幾度となく危機に見舞われ、倒産すら視野に入ることもありましたが、こちらも大変良い経験となったと思います。
また、この期間の間、gumiという会社が単なる集団から組織にならざるをえない状況でもありました。会社としての機能がほぼない状態で何とか邁進していた集団が組織になるという体験は今までになかったものなので、なかなかに得がたい経験でした。
特に100人の壁、200人の壁、400人の壁といったように、会社が大きくなるにつれそこには明確な壁が存在するようでした。
そして、gumiは上場もしました。執行役員という立場として、内部から上場に向かっていく組織の姿を見ることが出来たのも、良い糧となっています。
今回退職に至った理由としては「次にやりたいことができた」ということになります。
小さな集団が組織になっていくにつれて「ここはああすべきだった」「こういうこともできた筈だ」と感じることが増えました。
今が決して間違いでは無いと思いますが、それでももっと良くできた筈だという思いは残ります。
そして、もっともっと面白いものが作れる筈だという自負もあります。
限られた環境の中で限られたリソースで最善の手を打つ事は自身を成長させるのに十分な状況でありましたが、そうではない環境で自分の力を試したいという気持ちも強くあります。
gumi退職後も、引き続きゲーム開発には関わっていきたいと思います。今後とも宜しくお願い致します。
エンジニア歴14年で自己投資してQoLあがったったもの
Voluntasに、
給与全部使うを読んで @isoparametric しか思いつかなかった。
— voluntas#1345 (@voluntas) 2014, 7月 6こんなことを言われつつ、
http://mizchi.hatenablog.com/entry/2014/07/06/163724
が面白かったので書きます。
常飲用炭酸飲料:月2000円〜
炭酸水ですが、ペリエ派。
ビンの330mlくらいが持てあまさずに使えてよいです。
![Perrier(ペリエ) 330ml×24本 [並行輸入品]](http://ecx.images-amazon.com/images/I/41vDEMqckpL._SL160_.jpg "Perrier(ペリエ) 330ml×24本 [並行輸入品]")
330の24本入りなので1ヶ月もちます。
キーボード: 1万~3万〜
キーボードはゲーム会社に入ってから、
会社に落ちてたXBox開発用のMicrosoftのNatural Keyboardを使ってたんですが、
返還するので返せと言われたので、
HHKB派に変わりました。
Natural Keyboardが英語配列だったので、今でも英語配列です。
http://www.amazon.co.jp/dp/B000EXZ0VC/
昔はこれを持ち歩いてましたが、結構ガタガタになるので家と会社用を買いました。
会社用は、Type-S。
PFU Happy Hacking Keyboard Professional2 Type-S 白／無刻印（英語配列）
- 出版社/メーカー: PFU
- メディア: エレクトロニクス
- クリック: 21回
- この商品を含むブログ (3件) を見る
会社へ自転車圏内への引っ越し:プライスレス
会社への自転車圏内への引越は当初からやってます。
最初は会社が新宿で、練馬に住んでました。
朝帰りも多かったので自転車は神。
今は会社が新宿で、中野に住んでます。
徹夜あがりの自転車は最高です。（最高に眠いです）
自転車:１万〜
自転車も、いいものだと道中疲れません。
個人的にはクロスバイクお勧め。
これは個人差あるので、乗って確かめましょう。
自分が乗ってるのはライトウェイのシェファード アイアンF(2012)です。
↓は2014版。
ベッド: 5万~
ソファ……はそれほどでもなくて、
やっぱりベッド。
自分はドリームベッドで、Sertaのマットレスを買いました。
ベッド選びは、
http://www.airtravelers.jp/2013/04/sleep.html
ここが参考になります。
ドラム式洗濯乾燥機: 15万~
ドラム式洗濯機
日立のビッグドラム安定です。
Amazonは高いので家電のお店（ヨドバシ、ビッグ）で買いましょう。
ワーキングチェア: 10万~20万
会社はミラチェア、家はバロンです。（勿論、実費）
バロン (Baron) チェア 【エクストラハイバック】 可動ヘッドレスト ポリッシュフレーム 可動肘 座メッシュ ブラック CP81AR FDH1
- 出版社/メーカー: オカムラ (岡村製作所)
- メディア: オフィス用品
- クリック: 10回
- この商品を含むブログ (3件) を見る
これはマジで捗るのでいれるのがお勧めです。
疲れ無さが違う。
バロン (Baron) チェア買うならエクストラハイバックで。
あうあわないがあるので、ちゃんと試しに座れる家具屋で見てから、
最安値のところを探しても遅くないです。
あと、ルンバ。
休日にでも平日にでも回しとけ。
まとめ
→うまい水を飲みながらだとコード書いたり勉強が捗る
→手に馴染むキーボードを使うとコード書く時間が短縮される
→通勤時間が短いと本読んだり、コード書いたりする時間が増える
→自転車で出かけられると、コード書いたりする時間が増える
→良い眠りを得ると、体調が良くなってコード書いたりする時間が増える
→洗濯物を干している時間をコード書いたりする時間にできる
→良い椅子だと疲れずにコード書いたりする時間が増える
→掃除している時間をコード書いたりする時間にできる
時間は買えないので、ある程度時間を買えるアイテムを揃えておくと、
時間が有効に使えたりします。（まだまだ自動化出来る気はするけど）
最初に投資すると後で返ってくるから畏れず投資せよ。
独り暮らしの日々を自動化し時間を得るためのライフハック
こないだエンジニア同士で集まって話していたとき白物家電の話になりました。
日々を最適化するために「これは買うべき」という話で盛り上がったわけですが、自分自身今まで生活してきた中でこれを使うことで日々を最適化し、効率化および自動化できた、と感じたものを紹介したいと思います。
１．全自動洗濯乾燥機を導入
こいつは要するにJenkinsです。洗濯物を放り込んでおくと自動的に乾いたタオルやシャツが準備されます。そもそも独り暮らしのエンジニアにとって一番面倒だと感じるのは「洗濯」ではなく「干す」という行為ではないでしょうか。
天気や気温、湿度にある程度のランダム性がある以上、乾きには揺らぎがみられますし、そもそも干すという行為がめんどくさい。となれば、ちょっと考えて安定的にビルド（洗濯／乾燥）してくれる環境が必要ということです。
もの凄く高いものである必要はないのですが、独身エンジニアの間では２０万くらいのが高性能で人気でした。
うちはこれを使ってます。日立が良いのは「風アイロン」という機能が搭載されており、洗濯物の皺取りまでしてくれます。（＝アイロン時間の短縮）
注意点としては、
- 一度に沢山いれすぎないようにしましょう（＝乾きませんし、皺もとれません）
- 型崩れするもの、普段着にしないものは別途洗いましょう
- 縮むことは計算にいれましょう
２．ルンバを導入する
こいつは要するにガベージコレクタです。時間経過と共に部屋には埃という名のゴミが蓄積します。
スケジューラーで不在時に自動で掃除することもできますが、居るときにボタンを押して自動で掃除をさせることができます。一度使って見れば分かるのですが、もの凄い量の埃をとってくれます。
思ったよりも吸引力もあり、落ちているちょっとしたビニールであればサッと掃除してくれます。これで日々の掃除を自動化することで、掃除している時間をもっと有意義に使えるようになります。うちで使っているのは770ですが、今度800シリーズもでるようですので、型落ちなどを狙ってみても良いと思います。
３．２４時間いつでもゴミを出せるマンション
こいつは要するにジョブキューです。
燃えるゴミ、燃えないゴミ、ビン、カン、粗大ゴミ、本当に面倒ですよね。そんなときに便利なのが、いつでもゴミを出せる仕組み（マンション）です。
燃えるゴミの日に出し忘れたらずっとゴミを置いておかないといけない……なんてことになりがちですが、これならいつでも好きなときに捨てられますし、いちいちウェイトしなくてもキューに突っ込んだゴミは詰まらずに順次処理されます。
粗大ゴミも置いておけば日付がこれば勝手に処理されます。
まとめ
エンジニアは日々のプログラム作業を自動化していたりするものだと思います。
ですが、日々のリアル作業も自動化したり、効率化することが可能です。
勿論お金はかかりますが、それに見合う効果が得られますし時間はお金では買えません。
メモリや、CPU時間、プロセス、スレッドと色んなものを自動化する事が日々の助けになるように、リアルな生活も自動化してみてはどうでしょうか。
本当に怖いC++erとC++という糞言語
かつて、ゲームプログラミングはアセンブリが主流で、8bitのCPUは掛け算や割り算すらないものでした。割り算がないCPUっていつの時代だよ、っていう人たちもおりますが、ゲームボーイアドバンスに搭載されているARM7TDMIは除算の命令を持っていません。（故に除算を書くと死ぬほど遅いので、乗算で代用したりする）
また、浮動小数に対する演算ユニットを持っていないハードウェアもあります。ニンテンドーDSに搭載されているARM946E-Sですら、浮動小数演算ユニットはありません。（CPUの機能としてはオプションで存在する）そのために固定小数点といった技術もあるわけですが、古くさい話です。
これらはCとC++の機能を駆使していかにパフォーマンスを出すかを余儀なくされた時代です。
さておき、最近はスマートフォンでのゲーム開発も進化しており、C++がiPhoneとAndroidの両方で動くということもあり、C++でのゲーム開発の需要が高まっている中で、それでもC++は人的な最適化（適切な使い方）を余儀なくされる言語であります。そこで「こんなC++erは嫌だ」という話をまとめてみました。
（決して他の言語が適切な使い方をしないでいい、という論旨では無い）
1. dynamic_castとstatic_castの違いが分かっていない
「dynamic_castとstatic_castわかる？」
「あー、あの動的なキャストと静的なキャストのことね」←まるでわかってない
RTTI（Run-Time Type Information）の関する知識が無いままにC++をプログラミングしているケース。
他の言語においては、型情報を普通に備えている訳だが、
C++はCの規格上動的に型情報を備えていないケースがある。
（オーバーヘッドに対して明示的にOFFにされるケースがある）
RTTIが有効であれば型情報を備えているが、これらのcastが何を意味しているかわからない場合はC++を使えていないと思って良い。
C++では適切に型情報を理解しなければcastは使いこなせない。
特にstatic_cast/reinterpret_castは型情報を騙して（強制して）本来取り出せない筈の情報（例えば、privateやprotectedなメンバ変数）を取り出すことができる手段の１つとしてとても重要なものだ。
（ただし、この動作は言語仕様としては未定義であり、処理系としてそういったコードを生成するケースが多いというだけ、ということに注意）
SDK側でインスタンスを既に作成しているケースなどでは、こちらで継承をしてそれらを作り直すことは難しい。
だが、メモリ上にある数字は防御されることなくプログラマによって書き換えられる。
protectedであれば継承を使う。
privateであれば強制キャストを使い、同じアライメントにある値を書き換える。
そして、このことはhackされたiPhone/Androidは常にメモリを書き換えられて不正をされる可能性を秘めている事と同義だし、そういう意識を持つべきだ。（C/C++でなくても、メモリ空間は書き換えられるが）
2.mapとhash_mapの違いがわかっていない
「mapとhash_mapのアルゴリズムわかる？」
「あー、mapね、mapは使った事があるよ」←まるでわかってない
二分探索とハッシュテーブルの差がわからず、アルゴリズムを理解しないままにC++でプログラミングをしている。
他の言語においては、連想配列や集合などのアルゴリズムとして覆い隠されているケースが多いが、
C++においては、これらの知識を持つべきである。
JavaのHashMap、PerlのHash、Pythonのdict、RubyのHash、JavaScriptのobjectなど他の言語で身近に使われるものであり、
高速化には必須の概念である。
C++ではSTLの規格で二分木のmapを提供するが、別途に実装系の拡張としてのhash_mapや、C++11のようにunordered_mapを提供するケースが多い。
これらの使い分けは必須であり、特性を理解して使うべきである。
また、vectorのアルゴリズムを理解していない場合、reserveを適切に使えないケースがある。
各種のコンテナの速度比較を以下に示す。
mapとunordered_mapになぜ速度差があるのかはアルゴリズムを考えればわかる筈。
3.スマートポインタ（弱参照）に対する知識がない
「shared_ptrとweak_ptrの使い分けわかる？」
「あー、話には聴いたことあるけど。weak_ptrってのは知らない」←まるでわかってない
弱参照を理解していない場合、リファレンスカウンタの所有権と循環参照に苦しめられる。
殆どの言語が（GCで管理されている言語でさえ）弱参照を持っている。
Objective-Cなら、__weak、
これほど言語に標準的に備わっている機能なのに殆ど知られていないのが弱参照だ。
C++なら既に死んだポインタを判別できるし、ポインタの消滅を邪魔しない。（弱参照は所有権を持たない）
弱参照という概念は他の言語においてでも標準的に用いられる概念であるのにも関わらず、軽視されている傾向がある。
すべてのプログラマは「所有権」について考える必要がある。
まだ他にもあるけど、長くなるのでここまで。
まとめ
C++使うならちゃんと勉強しろ。
C++使いたいならちゃんと勉強しろ。
C++使って無くてもちゃんと勉強しろ。
C++は、恐らくちゃんと理解されずに使われてしまっている言語だと思います。
故に多くのケースで糞言語と化しますし、（メモリはリークしまくり、所有権は無茶苦茶、何でも線形探索など）
cocos2d-xを使っていてもC++だけど、メモリ管理はcocosがしてくれるからしなくてもいいよ、安全だよ、なんて話を聴くと悲しくなります。
もっとC++の事を知ってからコードを書いても良いのではないでしょうか。
そして、他の言語を使う人たちも言語の事をちゃんと知ってあげて下さい。
- 作者: Bjarne Stroustrup,ビョーンストラウストラップ,επιστημη,岩谷宏
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2005/01/19
- メディア: 単行本
- 購入: 2人 クリック: 322回
- この商品を含むブログ (160件) を見る
C++ Advent Calendar 2013 の記事でした。
http://partake.in/events/91328710-3c7b-436e-bd4e-4d98d88333f9
ネイティブ開発アンチパターン
TexturePacker を使う時がきたようだ
と、最近はネイティブ開発なんかをしていたりするのですが、
ネイティブで動作するゲームをつくる場合、
Textureのロード時間や、サイズといったものは問題でしかないです。
メモリも食うし、そもそも管理がめんどくさい。
例えばTexture違いのキャラがいるとか、
Textureアニメーションをしたいときとか、
ファイルは一杯増えるし、今何をロードするべきなのかを管理する必要があります。
そういうケースに一番役に立つのは、Texture管理ソフトで、
iPhone/Androidで開発する際に、Textureをpackするのに最適なのが、
TexturePacker
http://www.codeandweb.com/texturepacker
です。
どう使うかというとと、起動して、ファイル（例えばpng）をドラッグ。
あとはPublishボタンを押すだけ、というくらいの簡単さ。
すると、plistや、結合されたpngが出力されますし、
SDやHDに対応する事もすごく簡単になってます。（ほぼ自動）
コンシューマーゲームをつくってるときに、画像ファイルの最適化に苦戦したのは何だったんだ……、と思うくらいの簡単さです。
勿論、デメリットもあって、
全ての画像を1枚のTextureに収めることはナンセンスです。
（使わない画像をメモリに置くなんてとんでもない！）
しかし、同時に使うであろうTextureを纏める必要はあるというときに、
是非これでTexture管理を行ってみて下さい。
spriteに対する抵抗がなくなることは間違いないです……。