後者は、正直言ってすでにUnityの開発ノウハウを溜めてきた企業に新しく導入するというほどの価値はないのではないかと思う。
まず、間違いなく一人、Unity側とLua側の橋渡しをする部分の設計をし、Lua側の記述方法のルールを決める人が必要になる。
開発メンバーは、そのルールに則り、メジャーとは言い難く、Utility関数にも乏しい「Lua」という言語を1から勉強し、開発に臨むことになる。

Unityを導入することに決めて、そこからノウハウを蓄積していった軌跡を、今度はLuaで同じことをすることになるのだ。

Unityの場合は、今はもう日本語のドキュメントや情報がたくさん出ているし、そもそも C#はかなり親切な言語なので、調べながらでも何とか開発できたと思うが、それがLuaで同じ事が出来るかと言われると、正直どうなんだろうかと思う。

かといって、これから新規でUnity開発を始める企業にも、似たような理由でお勧めしない。
仮にLuaでの開発のノウハウが蓄積できたとして、企業規模を拡大しようとしても、Luaが出来るエンジニアなんてものは早々いるとは思えないし、需要も供給も少ないと思う。

結局の所、開発メンバーも資金も豊富で、技術開発という名目が行える企業なら、試してみてもいいんじゃないのかなという感想。

Luaがもう少しメジャーになって情報が出ない限りは、主流にはなりえないんだろうな―。

と思いつつ、次のUnity開発案件があったら、がっつりLua側に処理全部書いてやろうと思っている事は内緒。

その為に、自作アプリをアップル申請通して、実際にアプリ更新無しで内容変えられるかの実績を積もうと頑張っている。

がんばろ。

-----

2017/6/23現在、ひとまずApple申請は通ったので、使えそうではある。
その辺りの詳細は、また来週以降少しずつ情報を書いていく予定。

2017-06-16

仕事の話～人に問題を伝える～

考察（仕事その物）

※デザイナーさんをディスってるわけではないのであしからず
※ゲームアプリ開発の話だと思ってください

仕事をしていると、たまにこういう事がある

-----
デザイナーAさん「この画像データ、ジャギが酷くて問題あるんですよ」

筆者「はぁ」
-----

筆者は、「画像がジャギってるからって、何の問題があるの？」といつも思う。
これは極端な例だが、今回はこのようなやり取りから得られる物を見ていく。

まず、ここで言う「問題」とはなんなのだろうか。
問いかけに対して答えが欲しいわけではないだろう。

仕事上で問題問題と言われるの物を定義すると

・その事柄を解決しないことによって、将来的に不利益・不利・マイナス・悪い事が起こる

としておくのが良さそうだ。
つまり、あまりみんなが幸せになれない事が起こるというのを問題があるというのだろう。

とすると、上記の例は以下のように置き換えられる

-----
デザイナーAさん「この画像データ、ジャギが酷くて「将来的に悪いことが起きる」んですよ」

筆者「はぁ」
-----

なるほど、どうやらAさんは、画像のジャギを直さないと、将来みんなが不幸になると思っているようだ。
だが、ここまで来ても、筆者としては

筆者「で、なんでそれがみんなの不幸になるの？」

となってしまう。

理由は簡単。筆者はその分野の専門ではないからだ。
その領域に対しての「知識」が無い。「知識」が無いために、「問題」を「認識」も「理解」もできない。
理解できない物を問題と捉えるのは、思考停止状態でもなければとても難しい。

更に、上記の例はもっと根本的な問題がある。
Aさんが思っている問題の理由が、適切ではない可能性が高い。

もし仮に、Aさんが思っている問題が
「ジャギが酷くて、とてもじゃないが絵のクオリティが低いから問題だ」
とする。

なるほど、確かに理由としては真っ当である。
だが、個人的にはこれは根本的な理由ではないと思う。

一番の問題は
「ジャギが酷過ぎて、絵のクオリティが低く見えるので、商品のクオリティが下がって、収益に影響が出る」
から、問題なのである。

ここから得られる教訓と、明日から使える手法にまとめるとすると

1. 問題は、その領域の「知識」が無い人には、理解も認識もされない
2．問題の理由が、根本的な物を指していない可能性がある

1に関しては、問題提起する側は、それを聞かせる人の知識を汲み取って、その人が理解できる言葉で話すことを心掛ける事。
特に、分野が違う人に問題を話に行った時に、どうもピンと来ていない様子だったら、間違いなく問題を理解してもらえていないので、言葉を変える必要がある。
上記の例で言えば

-----
デザイナーAさん「この画像データ、輪郭がギザギザして見栄えが悪いんですよね」
-----

くらいになれば、とりあえず見た目を気にしているという事は伝わる。

-----雑談
ちょっと、話が逸れるが、上記のように知識が無い人に伝える言葉で話す事を
「レベルが低すぎてやってられない」と、否定的な人がいるが、
筆者はこれはあまりよろしくないと思う。

気持ちはわかるが、チームで作業する以上、最終目標が「商品のリリース」なのだとしたら、
その様な個人的な感情はチーム作業には必要ないので、例えレベルが低くても
作業が一番効率よくでき、成果が出るような方法を取るのが一番だと思っている。
-----雑談終わり

2に関しては、その問題が引き起こす根本的な不利益を探るというのは、癖にしておいた方がいいという事だ。
問題の根底にあるものが見えないと、解決策が正しい物ではない可能性が出てきてしまう。

例えば、上記の例で、デザイナーAさんのジャギが気になるという事に対して、
ひとまず時間をかけて直したとする。
しかし、そのせいで描画負荷が上がりゲームの動作が重くなったとしたら
根本の解決すべき問題である

「商品のクオリティが下がって収益が下がる」

が、結局解決されていないのである。

もしかしたら、その商品に責任を持つ人が、そのジャギ自体を全く気にしていない可能性だってある。
これは、プログラムのバグ修正などにも同じ事が言える。
表面に見える物だけ見て、それだけの修正を重ねていくと、
本来解決すべき問題が何も解決されずに、作業量だけが増えるといった事態になる。

なので、何かしら問題が発生したら、「それが引き起こしている一番の問題はなんなのか」というのを良く考えるようにした方がいい。
それが出来て、妥協案なども出せるようになる。

ここまでした話は、大半の人は、1，2のステップを経験則などで無意識に思考して行っていると思うが、
たまにチーム作業という事を忘れて、上記のようなコミュニケーションを取ろうとする人が居るので、
ドキッとした人は、是非明日から初心に返って業務に取り組んで欲しい。

ゼネラリストになるだとか、チームの潤滑油になるだとかいう人は（ｒｙ

困った時の自分用メモ

読んだ本を考察してメモったり、自分でいじった物の感想をメモったりする場。週1更新を目指します。

IOSの話〜アプリビルド手順2〜

IOSの話〜アプリビルド手順1〜

思考の話～迷いを無くすこと～

Appleの話〜AppleDeveloperProgramの登録手順〜

Appleの話〜AppleIdの作成手順〜

Luaの話～で、商用に使えるのどうなのよ？～

仕事の話～人に問題を伝える～