時代に翻弄されるエンジニアのブログ

ゲームプログラマをやっています。仕事やゲームや趣味に関してつらつら書きたいと思います。

チーム作り 主体性があるチームが やっていること

f:id:tkymx83:20190301002100j:plain

こんにちは、チームで開発してますか?

チームで開発している以上、みんなの力を最大限に使って、最高のゲームを作りたいですよね!

だけど主体性を持って取り組んでくれるチームってあんまりないですよね。だいたいが忙しいからっていう理由が多いと思いますけど、どうしたら主体性を持ってくれるのでしょうか?

今日はチームの主体性を上げるための方法を考えてみたいと思います。

主体性が持てない状態とは?

チームに蔓延している問題をみんなが見て見ぬふりしている状態だと思っています。

問題は小さいことから大きなことまで種類はいろいろあると思います。誰かがやればすぐ解決するかもしれないから、誰かがやるだろう。そうみんなが思うことで、行動が遅いチームが出来上がっていきます。

ではなんで主体性が持てないのでしょうか?

主体性が持てない理由

簡単です。誰かしかできないからです。

自分には仕事があり、今それに手を付けることはできない。だから誰かがやるだろうという気持ちです。このとき架空の人物を作り上げてしまうのです。自分のキャパシティを超えて物事を行うことはできません。なので、自分の仕事が詰まっているときには、誰かに任せるしかないのです。

ではどうするのか?それは、仕事を選択できるようにすることです。

主体性を持つために

主体性というのは、自分から動いていくことを言います。

つまりは、自分で選択するということです。仕事を自分から選択することができれば、それだけで主体性が高い状態であると言えると思います。選択できる状態であれば、問題としてチームで抱えているものに関しても主体性を持って選択することができるのです。

そして、このためには仕事を選べるほどの余裕を持たないといけません。

仕事に余裕を持つために

仕事を選択するためには、やらなければいけないことを少なくすることです。

時間で言うならば、一日8時間のうち5時間はやらなければいけないことがあり、3時間は選択できるとします。自分でその3時間の選択をすることができれば、自分で選んだ内容なので主体的になることができるのです。ようは、やらなければいけないことを5時間で正確に見積もることができればいいのです。

結局は見積もり

結局は見積もりです。事前に自分がやらなければいけないものの見積もりが正確にできれば、仕事をする時間を制限でき、主体性をもって仕事をすることができるのです。

この見積もりは、1時間単位の正確さが必要です。計画を立てたら、後は実行するのみと言えるくらいの見積もりを初めに立てる必要があります。時間がかかるように見えますが、主体性を持って仕事を行うためには、正確な見積もりの上に、余裕を持った実装が理想となるのです。

まとめ

主体性を持って仕事をするためには、仕事の選択が必要。そのためには、やらなければいけないことの見積もりを正確に行う必要がある。

正確に見積もることで、一日の選択できる時間を作ることができるのです。





見積もり大切!!

ゲーム開発 モチベーションの正体

f:id:tkymx83:20190219020010j:plain

こんにちは、皆さんモチベーションは高いですか?

ゲームを作るときはいろいろなモチベーションが存在します。

お金を稼ぐためにやりたい!誰かに喜んでもらうためにやりたい!自分の世界を作りたい!

今日はそんなモチベーションをちょっと深ぼっていきたいと思います。

収束するモチベーション

お金は最大のモチベーションだとおもいます。お金をもらうことで、それ以外のほぼすべてのものを手に入れたり欲を満たすことができます。

人のために作ることも最大のモチベーションです。ゲームをやってくれる人の笑顔を見ることができれば、自分がゲームを作ることへの意味を見出すことができるかもしれません。

しかし、これらのモチベーションは、目的がはっきりしているため、最適に物事を作っていこうという思考が働きます。その結果、自分の今の最大限できることでアウトプットしようという思考になります。

これを僕は収束型のモチベーションと呼んでいます。

収束型のモチベーションは、最適なアウトプットにつなげることができ、モチベーションの種類としてはとても大きなものとなります。しかし、このモチベーションははじめから出てくるものではありません。

ゲームを作ったことがない人が、人にゲームをやってもらうことをモチベーションに動けるでしょうか?ゲームでお金を稼いだことがない人が、いきなりお金のためにゲームを作ろうと思うでしょうか?

その前提には発散するモチベーションから始まったと考えています。

発散するモチベーション

ゲームづくりに限らず、どんなものも、まずは自分が作りたいもの、自分が感動したものを自分のために作るところから始まります。

そうしてできたものを、人にやってもらって反応が良かったら「誰かのために作る」モチベーションが生まれます。同人即売会で売ったら「お金のための」モチベーションが生まれます。

このように、誰しもはじめは自分本位のモチベーションを持っていたのです。そしてそのモチベーションは最適化などされません。自分の好きなタイミングで自分の好きな方向に進んでいくことができるので、どんどんと新しい知識を身に着け発散していきます。

どちらがいいの?

実際、ゲームを一度作ってその改良などを行うときは、収束するモチベーションをつかうことができます。改良した結果をすぐに人に見せることができるし、それによってダウンロードをしてもらってお金が入るかもしれません。

しかし、ゲームを一度作る必要があり、そのときは発散するモチベーションが必要になるのです。

まとめ

よく人になんのために作っているの?と聞くと「遊んでくれる人のために」、「誰か喜んでくれる人のために」というような発言を聞くことがあります。コレ自体はとても良いことでゲームをブラッシュアップしていくときには非常に必要な要素となってくると思います。

しかし、新しいゲームを作ろうと思うときは、遊んでくれる人のために最適なゲームを作ろうと思っても、モチベーションが上がりません。それは、自分の知っているものを目的に最適に作ることにたいして、ワクワクを感じていないからです。そのため、誰もやってくれる人がいないときにゲームを長時間作っているとなんのために作っているのかわからなくなってしまいます。

なので僕は、ゲームづくりにはワクワクがとても大切だと思っています。ワクワクするようなゲームをいっぱい作れるようになってから、お金や人のことを考えてもいいのかなと思います。

簡単解説 U理論とは?

f:id:tkymx83:20190217041808j:plain

こんにちは、相手に壁を感じる、話していて辛い、うまく話が伝わらない。会議でいつも言い争ってしまう。

こんなことはありませんか?

世の中には、その話題に触れているいろいろな本がありますが、どれも具体的には書かれていなかったり、再現性のないものがかなり多いです。キャッチーなタイトルで読んでみてもなんかしっくりこない。。。そんな事ありませんか?再現性のある具体的な方法論があれば。。そんな悩みに答えられるのが

U理論です。

今日はそんなU理論について簡単に話したいと思います。

U理論とは?

簡単に言うと、自分のプライドを捨て物事をフラットな視点で考え、今までの枠を超えた発展を目指す理論です。

言葉で言うのは簡単ですが、この状態に行き着くまでの過程が明確に定義されており、U理論では、大きく分けて4段階の過程が存在します。

  • ダウンローディング
  • シーイング
  • センシング
  • プレゼンシング

この過程は、自分を知り、相手に対しての理解を深め、最終的に壁を超えて物事を考えられるまでの仕組みが詰まっています。相手に意見が伝わらなかったり、いつも対立してしまうのは、自分の中の偏見と相手への理解が足りないことが原因に挙げられることが多いです。U理論を使って少しずつ変わっていければ良いと思います。

それでは、一つ一つ段階について解説したいと思います。

ダウンローディング

この段階は、相手への偏見に満ちている段階です。

例えば、いつも話が長い人に対して、「今日も話が長いんだろうな」と思って話半分に聞いてしまう状況です。この状況では話の広がりはありません。広がらないということは新しい行動も起こらないため、気まずい雰囲気だけが流れます。

この状態がダウンローディングです。過去の経験などから自分の枠を決めてしまい、そこから抜け出せない状態です。原因は思い込みです。何か相手が話しているときに別のことを考えてしまったらそれはダウンローディングです。

ここから抜け出して次の段階に進むには、思いついたことを頭の何処かに保留しておくことが大切です。今考えてしまったなと気づき、それを意識せずに話に向き合う努力ができれば次の段階に行くことができます。

シーイング

この段階は、自分の偏見なしに物事に集中できている段階です。

自分の中にある変更や差別的な思考を自分でしり、保留という形で別においておくことができれば大丈夫です。物事をフラットに聞くことができますが、受動的な段階なので自分から発言するときにまだうまく行かないことがあるかもしれません。それは、自分の発言や行動の中にまだ、過去の経験からできた枠組みが存在しているからです。

次の段階に行くためには、相手の気持になって考えることが大切です。しかし、それはかなり難しいものになります。U理論では相手の気持になる方法が定義されています。それは、出来事に対して自分の認識と行動、相手の認識と行動をテンプレートに沿って文章し、客観視するというものです。これを対立ループダイアグラムといいます。

ここで重要なのは、自分の認識にたいする「言い訳」と相手のみになって考えた相手側の「言い訳」を考えることです。こうすることで客観視された状況で自分の非を認めることができます。ここまで来ると、相手と自分の会話の一歩目を踏み出せたとなります。

センシング

この段階は、相手の目線で物事を見るようになれた段階です。

相手の目線で物事を見れるようになることで、相手の思考があった上でどう動くかを考えることができます。U理論ではここが大切になってくると僕は思います。お互いのことを深く考えずに行っている会話は、それぞ独立に考えてしまいがちで、どこかを良くすると他に角が立つ状態になってしまいます。実際はお互いが相手+アルファの思考で話すことができれば複雑な事象に対しても共に立ち向かっていくことができるのです。

ここまで来るとプレゼンシングには後少しです。ここで足りないことは、自分の執着を受け入れることです。そのために効果的は自分を開示することです。執着している自分と本当の自分を分けて考えれるようになることです。自分が傷つくかもしれないから行動ができない。失敗したらどうしよう。意見を言ってけなされたら自分がけなされているみたいだ。。。

そのような自分の気持への執着を取り払うことが大切でそのための一歩が自分を開示することです。実際の人間関係でもブログでもTwitterでも、自分がどんな人間で、物事に対してどう思っているかというものをすべて吐き出すことができればその後の静寂が生まれ、人として一皮むけた状態になれるのです。

プレゼンシング

自己の開示を通して、自分の執着しているものを捨て去り、フラットな形で物事と接することができる段階です。

この段階はフローやゾーンのように自分の中に静かに眠っていてとても生き生きとできる段階です。この段階になれば本当の自分らしさで物事に当たることができ、一人の枠を超えた思考をすることができます。

まとめ

このように色々な段階を経ることで、本当の自分を手に入れることができ、これが会話や議論含め全てにプラスになっていくと考えられます。




と、いろいろ書きましたが、再現性があるといえどかなり難しそうです、特にプレゼンスになるためにはある程度自分を捨てる覚悟が必要だということで、しっかりと段階を経ていかないといけないなと思います。


ちなみに僕がU理論と出会ったのはこれです↓↓

チーム開発 コーチングとは?

f:id:tkymx83:20190216023106j:plain

こんにちは、悩みはありますか?僕はよく悩んでいます。

悩んでいるのは考えているのと違い、考える方向性を見失っている状態のことを言います。

近年、IT起業を中心に、その悩みに対してコーチングというものが流行っています。

コーチングは 1 on 1などの形で実施されることが多く、基本的には相手の行動を整理して主体的に物事に取り組む手助けをするものと思っています。

ただ、このコーチングはいろいろな解釈があるため、意見の押しつけのような間違った方法を実施してしまうこともあります。

今日はそのコーチングについて自分の意見を書いていきたいと思います。

コーチングとは?

コーチングは相手の話を聞いて、相手に気づきを促すための手法です。そのためには、相手の話を導いてあげる必要があります。

相手の話を導くと言ってもゴールはありません。ゴールに導くのではなく、相手の話を聞いて合理的な終点に導くことが必要なのです。

なんのためにやるの?

なんのためにやるのか、それは主体性を持って取り組むためだと思っています。

主体性は自分から何かを行おうと思ったときに起こるもので、人に言われたことから起こることは少ないです。まれに自分の方向性を相手の方向性にしてしまうようなカリスマ性を持っている人がいますが、なかなか普通の人にできることではありません。主体性は自分から何かを行うことで芽生えるため、基本的に喋ってもらうことが大切で、それに対して否定をしてはいけません。

コーチングの間違い

コーチングをするときには相手の意見を否定してはいけません。

否定をするということは、その行動はやってはいけない行動であると言っているようなもので、そこには話す人の意志が介在するものになります。それは主体性を育むものではないと思っています。

否定してはいけないというのは、言葉で言うのは簡単ですが実際はとても難しいです。相手の悩みを聞いたとき、人は今までの経験から自分なりの解決策を考えます。その解決策とそれることがあれば、それに対して自分の解決策への修正を図ろうとします。これが否定と言った形で現れます。

否定をしないためには

自分なりの解決策があるから否定してしまいます。ということは解決策を持たないことが大切だと思います。

相手の話を聞いて、話を広げるような形で会話を発展させる。そして収束するときに、それが、本来達成しようとした悩みを解決してくれるのか?その点に対して意識するのです。

そうすることで、自分の意見に対するエゴが消え、否定することがなくなります。このときに出てくるのは、否定ではなく、疑問です。

まとめ

いままでなら、命令することで相手にその行動させることができるかもしれません。

しかし、昨今の変化する社会のなかで、多様性に対処していくためにコーチングが生まれたと思います。

いろいろな意見の中に正解はありませんが、一番いい方向を考えていくことが大切なのかなと思います。

チーム開発 責任感の醸成

f:id:tkymx83:20190214023856j:plain

最近ゲーム開発をしていて、責任感ってなんだろうっと思うことがあります。

自分が作ったものを最後までやり抜く?
自分以外で_もリリースブロックに対して口をはさむ?

いろいろな責任感があると思いまが、僕は責任感は与えられたもので変わると思っています。

責任感がある人とは?

責任感がある人は基本的に視点が広いです。

自分が実装した部分以外の面も見ることができるし、自分の実装に関してはそこまで見るのかと思うこともあります。そんな人に話を聞くと、自分の責任範囲は、作ってからリリースするまですべての部分であると話します。

責任感が薄い人は?

責任感の薄い人は基本的に視点が狭いです。

自分が実装したらあとは、他の人に任せて自分は関与しないということが多いです。そんな人に話を聞くと、自分の責任範囲を明確に考えていない人が多いです。

責任感が薄いことはない

僕は責任感が薄い人はいないと思っています。

この2つの違いは、自分の責任範囲を事前にしっかり意識できているか?ということです。自分が、どこまでみて、どこまで見なくてもいいのか。

基本的に責任感が強いと言われる人は、この部分を自分で作り出すことがうまいです。

責任感を醸成するには?

つまりは、責任範囲を事前にしっかりすり合わせておけば、いいのです。

リーダー職であれば、この実装を通してリリースするまでのすべてを見てほしいのか?実装だけをしてほしいのか?そこをしっかりはじめにすり合わせておくことで、皆が責任感を持って行動できると思います。

言うなれば、明確に行動を想像できるときに人は行動に責任を持てるのだと思います。

ゲーム開発 企画とエンジニア はじめかた

f:id:tkymx83:20190213013952j:plain

こんにちは、エンジニアやっています。

ゲーム開発には、いろいろな業種の人が存在しますよね。

企画やエンジニアやデザイナーなど、小さなゲームでもある程度役割に分かれているものです。



企画したものが正確に出来上がっているうちはいいですが、企画の考えていることが違った形でエンジニアに伝わっていると意図した動作をすることはなく、なんとなく統一感がなかったり、面白さが表現できていなかったりします。


同じチームでゲームを作る上でコミュニケーションがとても大事なのです。今日は、成功した開発と失敗した開発で、同コミュニケーションが関わっていたのかを話していきたいと思います。

失敗した開発

このプロジェクトでは企画がいました。

企画はゲームを面白くしようと企画を考えてはみんなに公表しています。そして、良さそうな企画ができたら、その仕様をエンジニアに伝えて実装してもらっています。わからないことがあればエンジニアから企画に聞いて開発していくというスタイルです。

しかし、このプロジェクトではあまり面白いゲームにはなりませんでした。実際に作ってみると企画が思ったようなものが出来上がってこずに微妙にクオリティが悪いゲームになったのです。

成功した開発

このプロジェクトでは企画がいました。

企画は面白いゲームの方向性が定まった段階でエンジニアを呼びました。定まった方向性に対して、どんなことをする必要があるかをエンジニアと一緒に考えていきました。ある程度ゲームの要素が決まった段階で、企画は仕様をねり、エンジニアは簡単なプログラムをはじめました。

このプロジェクトは、とってもうまくいきました。細部に渡ってユーザーを感動させれらるような工夫が凝らしてあり、とても満足の行くものとなりました。

2つの違いはなにか?

伝えているか?考えているか?

だと思います。

失敗した方では自分の意図を伝えようとしています。しかし、エンジニアは表面的には納得していても実装しているときに、自分の感性が入ってきます。仕様や大まかな意図はエンジニアに伝わったのかもしれませんが、感性までは伝えることができず、細かいところで齟齬が出てしまったのです。

成功した方では、一緒に考えることで感性を共有することができました。そのため、仕様が固まっていなくても、エンジニアの実装で、細かな方向性は擦り合っており、とても統一感のある企画意図を十分に満足した実装ができたというわけです。

まとめ

分業が一番良いのではないか?お互いの専門分野で勝負したほうがいいのではないか?といった声が聞こえるかもしれません。

ですが、ぼくは、一緒に考えることの最大のメリットはすべての職種が伝えなくても同じ方向を向いて実装をしていけることだと思います。

iOS Unity OnDemandResources ことはじめ

f:id:tkymx83:20190205194819j:plain:w1000

オンデマンドリソーシーズ(OnDemandResources:ODR)をしっていますか?僕は今日知りました。

簡単に言うと、Appleにビルドを提出する段階で画像などのアセットをサーバーに登録しておき、アプリ内からリアルタイムに取得するという仕組みです。

今日はそんな OnDemandResources の機能を始めるにあたって概念的なことメモしたいと思います。

なお、OnDemandResourcesは iOS の機能です。Unity 上でもそれを利用することができると言うだけです。

f:id:tkymx83:20190205192934p:plain:w1000

リソースにタグ付をする

OnDemandResources を実現するにあたって、リソースにタグ付をします。具体的には画像のように、この画像は "image" だという形で決めていきます。

このタグを目印にアプリ上からはリソースのダウンロードを行います。アプリ上でタグを指定することでそのタグがついているリソースをダウンロードしてくるということです。

ゲームで言えば、ステージごとに違うアセットを使っている場合に役に立ちます。ステージ1の開始時点でステージ1のマップをとってくる。ステージ2ではまたステージ2のマップを取ってくるなどができます。

Unity では、アセットバンドルにタグをつけてダウンロードすることをおすすめします。

OnDemandResources とは、基本的にこれだけです。

Unity はスクリプト上でタグ付けを行う

OnDemandResourcesは基本的に iOS の機能ですので、Xcode上からは手動でタグ付などの設定ができます。しかし、Unity は基本的にXcode をそのまま扱うことはしないので、スクリプト上でタグ付をしていきます。

new UnityEditor.iOS.Resource( "textures", "Assets/ODR/textures" ).AddOnDemandResourceTags( "textures" )

上記のように、AddOnDemandResourceTagsを使用することで、タグ付けをできます。上記のコードは UnityEditor.iOS.Resourceの機能をつかい、"Assets/ODR/textures"フォルダ内の texturesのアセットバンドルタグを持つものに、textures と ODRのタグを打っています。

基本的に Unity では、Asset Bundle タグというものがあるので、それを利用してODR のタグをつけるのも良いと思います。

Prefetching Tags を利用してインストール時に選択ダウンロード

Prefetching Tags はアプリのインストール時に、ダウンロードするタグを指定することができます。この場合、アプリの容量にタグ付けしたリリースがそのまま乗ってくるのでサイズがかなり大きくなってしまいます。

しかし、近年はゲーム内ダウンロードを極力しない方向性で動いているため、これを利用することができるかもしれません。

OnDemandResourcesで Prefetching Tags を使った場合、アプリのアップロード時にすでにローカルにファイルがある場合は差分のみダウンロードすることができます。

Xcode上からは手動で設定できるのですが、Unity でこれを実現する方法はまだわかっていません。。。。
誰か教えて〜〜

使用していない場合はローカルから消える

これが一番大きい機能ですね。アプリ上から使用されないで一定日たったリソースはローカル上から排除されます。これによって、リソースの無駄を省くことができます。

逆を言うと、毎日使うものに関しては、毎度リソースをダウンロードすることになるので、通信量の無駄になります。なのでチュートリアルや期間限定のイベントなど、もう使用することのないリソースに対しては効果的です。

まとめ

OnDemandResources は便利な面が多いです。Unity 5.2 からあったそうで、知らなかったのでびっくりです。ただ近年にゲーム内ダウンロードを縮小しようと言う方向性には反しているので使うときは注意ですね。

リジェクトされるかも。。

参考資料を貼っておきます。


developer.apple.com

blogs.unity3d.com

docs.unity3d.com