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

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

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

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

ゲーム開発 炎上案件物語 深掘り解決編1

f:id:tkymx83:20190205175041j:plain

原因は人によって見方が変わる。

プレイヤーは自分が悪いと思っても、実際は監督者の質が悪いこともある。

プライヤーは自分が悪いと思っても、仕組みそのものが悪い場合がある。

なにか問題が起きたときの解決策は根性論になるべきではなく、根性がなくても実行できる仕組みづくりが大切になる。

前回炎上案件の原因を模索したが、今回はそれを少し視点を変えて深ぼっていきたいと思います。

過去の記事を貼っておきます。
tkymx83.hatenablog.com

tkymx83.hatenablog.com

視点を変えてみる。

前回原因と上がったものは以下の三点になります。

第一に仕様が期間内に終わらなかったことだ。
→ 期限が切られていない。

第二は仕様が詰めきれていなかったこと
→ 仕様変更があったときに仕様書に記載されていなかった。

第三は試遊会の段階で方針に変更があったことだ。
→ 方向性レビューが行われていなかった。

これらの原因の視点はプレイヤー側に絞られている。プレイヤーがどのように行うかである。

ここで視点を変えて、戦術策定の段階から深ぼっていきたいと思う。

何をやりたいかと言うと、もっと上の段階や大枠で見たときになにか原因があったのではないか?ということである。

一つ一つの原因に焦点を当てていると、長くなるので一つ一つ分割する。

原因 : 第一に仕様が期間内に終わらなかったことだ。

仕様が期限内に終わらなかったのは、なぜだろうか?

期限が明確にきられていないこともあるが、だからといって仕様書を完成させなければいけないことは担当者もわかっていたと思う。仕様書を決めるときは、戦略をディレクターが企画に伝え、その企画が仕様をまとめ、エンジニアやデザイナーと相談して決定していく。

つまり仕様策定は企画だけではなく、エンジニアやデザイナーが関わっている。にもかかわらず、実装ができない仕様を放置していたのはエンジニアだし、デザイン方針が定まっておらず仕事が来るのをまっていたのはデザイナーである。

まとめると企画以外の役職が仕様策定に対する主体性に問題があったのではないかという話である。

それぞれの役職が主体性を持っていれば、少なくとも遅れの放置はないし、決まらない企画に対してもアイデア提供のような形でアプローチができたのではないかと思われる。そして主体性は根性論ではなく組織形態や組織フローなど自分がどこに責任を持つかによって仕組み的に変わる。

ではなぜ主体性を持つことができなかったのか?

それは、エンジニアやデザイナが作業者になっていたからである。

作業者は決まったものをただ作るだけの存在であり、そこに主体性はない。なくても仕事ができるからである。作業者になるには、仕様をトップダウンでただ任せればいい。「仕様ができたから作ってくれ」という形だ。自分が仕様に関わるような仕組みでなければ作業者が量産されていく。

ではどうすれば主体的になれるのか?モチベーションに関わる部分なので人によって良し悪しはあるが、少なくとも仕様策定に係る仕組みを作る必要がある。

例えば仕様策定の前段階の戦略が決定して作る要件の企画書ができた段階でキックオフを行う。このキックオフは仕様を説明するのではなく、企画の意図を説明する。

  • 戦略の意図は?
  • 誰を対象としているのか?
  • この要件で何を達成したいか?
  • 何を満たすことができればこの要件は達成と言えるのか?

などなどである。目線を仕様策定者と同じに持ってくることで、少なくとも、作業者ではなくなるため、仕様を持つという姿勢はなくなる。そして、仕様を待つのではなく、自ら作ろうとう言う意識になる。

ここまで来てようやく、仕様の締めを決めて、それを追うことが役に立つ。エンジニアやデザイナは作業に対してはプロであり、プロは期限を守る責任がある。自分ごととして仕様書の作成を行うのであれば、企画だけではなく、エンジニアやデザイナもともし仕様を期限内に守ろうという動きになる。

根性論ではないのか?

主体性と言う言葉を話すと、やはり根性論ではないか?という声が聞こえてくる。

しかし、理想的なチームの状況というのはみんなが面白いゲームを作ろうと情熱を燃やして真っ直ぐに進んでいける状態である。情熱の燃やし方は人それぞれかもしれないが、目的を達成しようという主体性を持つことは理想である。

根性論にならず仕組みを作ろうという話をしたが、

仕組みを作って達成したいことはチームの理想に近づくことである。

そのため、主体性を持てない形から、持ちやすい形に変えていくことは立派な解決策であるといえる。

なお、間違えてもみんなで大きな挨拶をしよう!やレッドブルを増やして頑張れる体制を作るなどといった誰かに頑張ってもらうような対策はご法度である。

ゲーム開発 炎上案件物語 原因究明編

f:id:tkymx83:20190202024029j:plain

なにか物事が起きれば、原因がある。

人は、1つのことに原因があると思っているが、物事は1つの事象に見えて複数の事象の組み合わせであることが多い。

そのため、物事に対する原因は1つとは限ららない。

今回は前回の出来事に関して話させていただいた炎上案件の原因究明に関するお話をしたいと思います。

出来事編のリンクを張っておきます。
tkymx83.hatenablog.com

問題は何だったのか

ここまで来ると、問題点が露呈する。

第一に仕様が期間内に終わらなかったことだ。

第二は仕様が詰めきれていなかったこと

第三は試遊会の段階で方針に変更があったことだ。

これらの原因を噛み砕いて深掘りする。

なぜ仕様が期間内に終わらなかったのか?

まず疑われるのは、仕様を考える期間が決まっていたのか?ということだ。

今回の実装は3ヶ月周期のリリースの中での決まったマイルストーンとは外れて動いていた。それは機能が通常よりも大きなものになっていたからである。事前に必須な部分ははじめから決まっていたし、その部分の実装は進んでいた。

そのため、企画が仕様書を作らなくとも、作業は進んでいたし、制限を設ける動きもなかった。動きがないということは誰も仕様書ができていないことを疑わない。そして仕様書作成が遅延したと考えられる。

次に疑われるのは、仕様を策定する期間が適切かどうかだ。

今回作成する機能はかなり大きなものだったため、通常の仕様よりも量が膨大になっていた。そのため、通常の仕様策定期間ではまかなえなかった可能性がある。

しかし、この期間が適切かを図ることは具体的にはできない。それは仕様は考えれば考えるほど深みにハマっていくからだ。期日があれば、それに合わせて適切な仕様を作成する。この仕様の優先度順に実装を行っていけばいい。

まとめると、
期限が設定されておらず、それを追う人もいなかったことが原因となる。

なぜ仕様が詰めきれていなかったのか?

基本的に仕様は企画が作成して、エンジニアに漏れがあるかを確認するフローを経て完成する。エンジニアは実装の担保を行っており、具体的な実装方法を模索しているため、辻褄が合わない仕様があればそれに気づくことができる。しかしそれは、仕様書が正常に出来上がった後の話である。そしてそれが仕様書に記載されていたときの話である。

今回の開発では実装と一緒に仕様書が作成されていった。そのため、仕様書は常に完成されておらず、常に更新され続けた。更新されればよいのだが、口頭ですり合わせた内容が仕様書に記載さていないことも多く、暗黙の了解になっているものもあった。暗黙の了解が増えると、その事象に起因した別の条件で不具合が起きることがあり、それが仕様漏れへと発展していったと考えられる。

つまりは、実装途中であれ、実装前であれ仕様が変わり次第仕様書を更新し実装者に伝えていない体制が原因になる。

なぜ試遊会の段階で方針に変更があったのか?

まず気になるのは、方針を理解して仕様が作られていたのか?その方針が満たされていることを他の人も確認したのか?ということである。

方針というものは基本的に一年前から決まっており、それに則ってゲームというものは作られていく。その方針は全体共有はされているがかなり抽象的な内容になっている。その抽象的な内容を企画担当が具体的な仕様へと落としていく。この過程は企画の仕事になり、企画の腕が試されるところである。

しかし、作成するのは個人であり、方針も抽象的なことから必ず認識の齟齬が発生する。その認識の齟齬は仕方のないことであり、それを防ぐには他の人にも仕様を見て貰う必要がある。方針のレビューである。

これができていなかったために、
仕様の策定の段階でだんだんとずれたものになっていき、最終的に方向修正の工数がかかってしまうのではないかと考えられる。









このような場合どのような対処が必要なのか?

解決は一つ一つが長くなるので記事を分けて書こうと思います。
tkymx83.hatenablog.com

ゲーム開発 炎上案件物語 出来事編

f:id:tkymx83:20190202023208j:plain

漠然とした問題は誰しも持っていると思う。

僕の場合はチーム開発に関してのものが多い。リリースする機能の開発がいつになっても終わらない。俗に言う炎上案件である。

終わらない理由はいろいろあり、時間がかかっているのもいろいろある。だから、はっきりとこれが問題で何を解決すればいいかがわからない。

今日はそんな炎上案件に対応したときの自分の備忘録として今回起きた問題を聞いていただければ良いと思います。最終的には問題に対する原因の深掘りをできればいいと考えています。

前三部作になっており、
原因究明編のリンクも張っておきます。
tkymx83.hatenablog.com

開発はどんな流れで進んでいたの?

チームの開発は三ヶ月周期で行われている。大体二ヶ月開発をして、一ヶ月検証を行ってバグがないことを確認したらリリースする。その案件は、期間がかかるものだったので、4ヶ月前から開発が行われていた。

ゲームづくりのはじめは仕様決めから行われている。仕様決めを行ってから開発の工数の算出を行って開発が始まる。今回は仕様決めがかなり難航していた。実際に仕様として落とし込むまでに時間がかかり、作業工数がはじめの段階で算出できないことが多いにあった。それは、仕様が決まっていないから、出せないというものだった。

その後、仕様が決まらず、共通部分の開発のみ行っていた。その間も仕様作成が並列で行われており、開発は行われていたが、詰まっていないところもあり、十分に作れなかった。十分に作れるとなったのは開発終了の二ヶ月くらい前でその段階へ工数を再度見積もったが、その時点で開発の遅延が起きることがわかった。

仕様書が作成されてから、仕様書の漏れがいくつか見つかった。それらの追加仕様に対する見積もりは別途追加され、当初よりも想定以上の仕様の開発工数が発生していた。

その後現在の仕様で試遊会が行われた。試遊会では、実際の機能を遊んでみてその感想をインプットシートにまとめる。インプットシートにまとめたものはその後、企画の中で精査されて、改修が必要な場合はそこで修正が入る。

今回はこの試遊会で企画の方向性に難があるといわれ、変更仕様が多数発生した。その後、その仕様の実装の再見積もりが行われ、再見積もりの結果かなりの遅延が見込まれることがわかった。

このプロジェクトはいまだに終わっていない。

事実からわかること

今回の開発では、三回の遅延が発生している。

一回目は、仕様の策定が遅れたことだ。それによって、工数の見積もりができず十分に開発ができなかった。企画が定まった段階で再度見積もりを行ったがすでに開発遅延が決定していた。十分にできないというのは、仕様追加があることを前提で作るため、設計にもれが出る可能性があるということだ。

二回目は、仕様の漏れによる仕様の追加とそれによる実装期間の延長である。実装内容が物理的に増えることで、実装見積もりは大きく変わってくる。今回は仕様の漏れに起因する実装工数増加が複数発生した。

三回目は、試遊会によって企画の方向性が大きく変わったことだ。実はこの段階で企画の担当者が変わっており、変わった段階で方向性が若干異なることがわかった。これによって、追加仕様や修正が発生し仕様が変更。一度に変更があるのではなく、その都度変更が発生したため、最終的な工数見積段階ではすでに遅延が発生していた。

これが今回の事象のまとめである。

理想の開発とは?

理想的な開発について話す。

まず、仕様が期間内に終わっておりそれが当初想定した目的を満たしていることである。仕様期間内に固まっていることで開発工数の算出を行うことができる。それによって、具体的なスケジュールを持って開発を行うことができる。企画がその段階で定まったため、設計を行うことができる。それによって実装の効率化や共通部分の算出などを行うことができ、開発効率化につながる。

次に試遊会では、作成した機能のブラッシュアップを行うことができる。試遊会では実際に手にとって一連の流れを追うことができる。一連の流れを体験することでわかることがある。それは、使いづらさや、機能の分かりづらさなどである。これらは机上の空論ではわからず、実際にやって見なければわからない。試遊会ではそのようなブラッシュアップに関して意見が出て細かな修正にとどまる。

そして、それを直して検証フェーズへと移行する。
これが理想的なパターンである。






では何が原因でこの理想が達成できなかったのか。
それは次の記事で考えていきたいと思います。

tkymx83.hatenablog.com