シャワーを浴びずして、良いアイデアを閃く技術

はじめに

僕の将来の夢は「狂った金持ちのジジイ」になって葬式の式場として採石場を買い取り、式の最後に棺を爆破する"ダイナマイト葬"で人生を締めくくること。

こんにちは。クライアントワーク事業部の井上宗汰(@inolalala)です。
普段会社ではUnityをちょしたり、エンジニア目線から企画のお手伝いをしたり、飲み会の場で少し嘘をついたりしてその場の空気をかき乱す等の仕事をしています。
あ、この記事はTech KAYAC Advent Calendar 2019の23日目の記事です。

さて。
「なんか新しいアイデアを!」って言われた時、やっぱ困っちゃうこと、少なからずあったりしますよね。
そういう時に限っていい考えがパッと浮かばないものです。
そんな時有効な方法、それは「シャワーを浴びる」だと僕は個人的に思っています。かのアルキメデスもお風呂に入っている最中にアイデアを閃き「Eureka!」と叫びながら全裸で街を駆けずり回って家に帰ったと言います。
しかし、だからと言って四六時中シャワーを浴び続けるわけにもいきません。ガス水道代が跳ね上がる上に指がふやけてしまうからです。
「シャワーを浴びる」以外にアイデアを閃く技術は無いものか...
と言うわけで、今回はアイデアを出す為の技術とか考え方を色々まとめつつ、「シャワーを浴びる」以外のアイデアの閃き方を考えます。
これは何もコンテンツを考える時だけではなく、もっと日常生活に根ざした所にいきてくるはずです。ちゃんと真面目に実践すれば、少なくとも、その日の晩ご飯の献立で迷うことは無くなるでしょう。
僕はコンビニのカップ麺を選ぶのに30分かかることがあるので、まだまだ勉強が必要なようですが...
一緒に頑張っていきましょう!

ブレスト、秘められた力とその限界

さてさて、新しいコンテンツの提案をしなければいけないが、果たして一体どうすれば良いものか...

例えば、よく行われる手法として「ブレインストーミング」が挙げられると思います。
そう、なんかお題があって、それに対してなんか言うあれです。
弊社では、ブレストを文化としているわけでして、なんならブレストカードなんてカードゲームも出してるくらいなので、弊社ではしつこいぐらいに「ブレストすっべ!」という言葉が飛び交うわけです、多分。

ただ、ブレスト自体は「いいアイデアが生まれるかもしれない場」を用意する為のもの、と言う側面が強いな、と僕は考えていて、結局のところ参加してる我々が「う〜ん」となっていては効果が薄れてしまう場合があると思うのです。
最悪みんなでシャワーを浴びにいけば良いのかもしれないですが、それではシャワールームが混み合ってしまいますし、そもそも弊社にはシャワールームがありません。
う〜ん、困ってしまいましたね。シャワーに入らずして、ブレストをより実りの多いものにするには...

やはりここは一つ、先人たちの知恵を借りる事にしましょう。
家にあるアイデア系の本を三つ紹介します。

アイデアのつくり方

アイデアのつくり方

アイデアのつくり方

結構昔の本ですが、これ系の話題には必ずと言っていいほどついて回る名著中の名著です。
「アイデアとは既存の要素の新しい組み合わせ以外の何ものでも無い」
この一節はあまりにも有名で、同じようなことは色んな人が言ってると思います、確かスティーブ・ジョブズとか。正直、これだけ知ってればもうこの本読まなくてもいいんじゃないかな(おい)
まぁもちろんそんなことは無いですがそれぐらい重要な概念だと思います。
あと、この本で語られている、もう一つ重要な考えは「アイデアが作られるまでの五つのステップ」でしょう。

  1. 資料集め
  2. 資料を咀嚼する
  3. 問題を完全に忘れて寝かせる
  4. どこからともなくアイデアが浮かんでくる(マジか)
  5. そのアイデアをうまくいくか試してみる

1、2段階目まではまぁ何となくわかりますが、後半が結構センセーショナルだと思います。
これに習うなら、新しいことを考えるときに時間をとってウンウン考える時点でまずアウト、ということのようです。日々の積み重ねが重要なようですね。
考えてみれば、「シャワーを浴びたら思いついた」みたいなのって「問題を完全に忘れてリフレッシュ」する瞬間だからなのかもしれない。

この本自体は(物理的な意味で)とても薄い本なのでチャチャッと読めるはずなので、買って読んじゃいましょう。

アイデアのヒント

アイデアのヒント

アイデアのヒント

僕が学生時代に一番影響を受けた本です。多分7週はした気がします。
ここまでどハマりしてしまった理由は「何か新しいこと・面白いことを考えるのに特別な才能は要らない」という事を教えてくれて、僕はすごく勇気をもらえたからです。僕の価値観はかなりこの本の影響を受けている気がします。それでも全てを実践できているかと言われるとまだまだ至らない所がたくさんありますが...

あなたが思い切ってアイデアを提案できない理由の一つは、自分の評判、ひいては自分の将来までもが、今から言おうとしているアイデアにかかっている気がして怖いからだろう。確かにそれは杞憂とも言い切れない。つまらないアイデアを出したせいで笑い者になるかもしれないし、成果が出ずに会社の売り上げに響き、クビになった挙句に家族にも縁を切られ、人生の敗北者として惨めな死を迎えるかもしれない。ならば、一つのアイデアに人生を賭けるようなことをしなければいい。アイデアをたくさん考えよう。そうしたらあなたは「あのくだらないアイデアを提案したろくでなし」ではなく、「アイデアをあふれるほどもっている天才」ということになる。

↑ここ好き。
多かれ少なかれ、会議とかで発言する時ってスリリングな気持ちになるので、かなりハッさせられる一文だと思います。
そういう意味では、ブレストには「安心して発言しても良い場所」という保証があるのが重要なんですね。

ちなみに前述の「アイデアのつくり方」はこの本から知りました。 この本は「アイデアのつくり方」で書いている事をなぞりつつ、もう少し具体的に補足してくれています。まぁ技術を提供してくれているというよりかは心構えみたいな部分に触れている感じですね。 本当にこの本はオススメしたいところです。

目次だけでも結構いい感じなので抜粋します。

  1. アイデアってなんだろう(ここではまさに「アイデアとは既存のうんちゃら」に言及しています)
  2. もっと楽しもう
  3. 自分を信じよう
  4. 「その気」になろう
  5. 子供に戻ろう
  6. 「知りたがり」になろう
  7. 笑われることをおそれるな
  8. いろいろなものを組み合わせてみよう
  9. 質問を変えてみよう
  10. 情報をかき集めよう
  11. とにかく数で勝負しよう
  12. いったん全部忘れてしまおう
  13. ひらめいたら実践しよう

アイデアのちから

アイデアのちから

アイデアのちから

この本は「記憶に焼きつく」ようなアイデアを生み出す為のフレームワーク「サクセス(SUCCESs)の原則」を提案しているもので、結構面白いです。

かなり胡散臭い名前の原則ですが、SUCCESsとは

  • 単純明快である(Simple)

  • 意外性がある(Unexpected)

  • 具体的である(Concrete)

  • 信頼性がある(Credible)

  • 感情に訴える(Emotional)

  • 物語性がある(Story)

の頭文字をとってSUCCESsとしたものです。全然胡散臭く無いですね。
ただ、実際問題、「単純明快で意外性があり、具体的で信頼できるエモくてストーリーを感じるアイデア」をいきなり出すのはかなり至難の業のような気がします。
なので、出した自分のアイデアをより精製する為の評価軸としておくのが有効なのだと思います。

実践して考えてみた例

さて、シャワーを浴びずしてアイデアを閃く方法を考えてみましょう。
何を考えればいいのか。
ここで「シャワーを浴びずして、良いアイデアを出す方法とは?」という質問を変えてみましょう。
先人たちの知恵をお借りするならば「考えている問題をきっぱり忘れられる瞬間は何?」ってことになりますね。
考えないし、忘れてしまう。
悩むなんてもってのほか。
そんなキッズの気持ちで楽しまなければいけません。

いたずら1歳 やりたい放題ビッグ版リアル+ (リアルプラス)

いたずら1歳 やりたい放題ビッグ版リアル+ (リアルプラス)

  • 発売日: 2019/08/08
  • メディア: おもちゃ&ホビー

何より、いいアイデアは必ず存在する...ということを確信しましょう。

<シャワーの代わりになるような、考えている問題をきっぱり忘れられる行為についての一人ブレスト>

  • ヨガ

  • 砂遊び

  • 料理をする

  • キャッチボールをする

  • ゲームをする

  • 本を読む

  • 食器を洗う

  • 羊を数える

  • 無心で米粒を箸でつまんでテーブルの上に並べてみる

無心で米粒を箸でつまんでテーブルの上に並べてみる

ん?これ良さそうですね。
「アイデアを出す為に、無心で米粒を箸で一粒づつつまみ、テーブルの上に並べている会社員」
まあやってることはシンプルだし、意外性しかないし、これ以上ないくらい具体的で、何となくシュールでエモストーリー性を感じなくもない。信頼性は一切ないですが。
これを採用しましょう!!

まとめ

シャワーを浴びずにアイデアを閃く為の技術...
それは「無心で米粒を箸でつまんでテーブルの上に並べてみる」に決定しました。
なので今度からブレスト終了後にアイデアを閃く為に、会社で米粒を箸でつまんで並べてみようと思います。
今晩の献立に迷ってしまったら、皆さんも是非やってみてくださいね。

運用中プロジェクトをUnity2017からUnity2018にUpgradeした時の話

表題の通り、Unity2017.4→2018.4にアップデートした時のハマった点や、普段アップデートする時に意識してる事などを紹介できればなといった感じです。

Unityのアップデート作業を初めてやる方や、あと来年2017から2018へ移行する稀有な運命の方がググった時に何か参考になれば幸いです。

ちなみにバージョンを上げる事になった経緯としてはAndroidの64bit対応がUnity5を除くバージョンの場合は8月までに対応必須だったからです。

ゲーム事業部、技術部所属の須藤(@p_chin)です! この記事はTech KAYAC Advent Calendar 2019 Migration Trackの23日目の記事となります。

大まかな作業段取り

Unityバージョンの選定

基本運用中タイトルなので最新のメジャーバージョンにてLTSリリースである4のマイナーバージョンあたりが出てる場合はそれを選択しています。

今回は.net4.0を2018から使える様になってるのでメンバーのテンションは高い状態でした。

試しに動かしてみる

ゲームが前のバージョンと同じ様に動くか?を見るんですが、だいたいAssetBundle(以下AB)にしてるアセットの互換性がなかったりで死ぬパターンがよくあります。

後述しますがUnity2017-18間では主にshader周りで自分のプロジェクトでは互換性が崩れていたのを確認できました。

アップグレードして出てしまった問題を全て潰す

言うは易しですが、一番重く辛い作業ですね。

詳細は後述しています。

他の開発branchへのmergeタイミングを調整

問題を潰し切ったら次はアップグレードを受け入れるタイミングをPMやQA担当とすり合わせします。

(ちなみに前提としてバージョン管理にはgitを使用してます)

よくあるのが端末の環境依存や、NativePluginを使用してる機能で問題がある場合が過去のアップグレードで多かった印象です。

開発側で対応完了した後、2018化したbranchにて一週間ほど致命的なバグがないか狙ってるアプリバージョンのbranchを毎日mergeしてビルドを作り直した状態でQAを行います。

事前にチームメンバーにアップグレードのアナウンスをする

自分のチームではアーティスト、プランナーもUnityを使って仕事をしてるので広域に渡ってUnityバージョン移行の段取りを指揮する必要があるので、案内文を作ります。

内容としては

  • 『N日までにinstallしておいてね』
  • 『分からなかったらエンジニアに聞いてね』
  • 『新しいgit-repositoryをcloneしておいてね』
  • 『{2018対応のbranch名}をcheckoutして一回新しいUnityで開いておいてね』
  • 『2017で作ってたアプリが本番から消えるまでは複数バージョンを使って仕事するのでUnityHubを紹介するので使ってね』

...などです。

各スタッフのUnityやgitに関するリテラシーは様々なので手厚くサポートが必要でした。

理想的なやり方してるプロジェクトだとUnityの外でデータやアセットをエンジニア以外が作れる環境があるのかもしれませんが、ツールを作りきる時間がなかったので自分のプロジェクトではUnityEditorにかなり頼っています。

対応完了

めでたい!!!

QA中に課金など主要機能で重篤なバグが出なかった事を確認できたら2018対応を狙ってるバージョンのbranchに一応Unity使用者の準備が整ってることを確認してからmergeします。

作業中に発生した問題

shaderの互換性崩れ

自分のチームではキャラモデルに適用してるKamakuraShaderと、エフェクトなどに利用してるUnityの標準shaderあたりが対象でしたので、全てそれに関連するABを作り直しました。

逆にそれ以外のアセットの互換性はUnity2017で作成したABを2018で読み込んでも問題なかったので、無駄にユーザーにアセットをDLし直させる必要は無いのでrebuildしませんでした。

やった事としては2018の対応branchでABのビルドする時にはshaderに依存してるかをチェックし、依存してるアセットのみビルド対象にする処理を書き、実行させていました。

QAの為に毎日別のbranchの修正を2018対応branchに取り込んでいるので、これによって更新の手間が楽になりました。

CrashlyticsでiOSのレポートが通知されない

Unity関係あるか不明ですが同時にFirebase Crashlytics v6.0.0にアップデートした所、なぜかクラッシュレポートされない問題が起きていました。

これに関しては謎だったのですがアプリのビルド時に BuildOptions.AllowDebugging を抜いたらビルド時のsymbolから --enable-debugger が抜けた様で問題なくなりました。

UniversalApkのサイズが50MB増えた

なぜかapkの中に含まれる /lib/armeabi-v7a/libil2cpp.so のサイズが 3倍になった現象でした。

調査していくと、Monoのsymbolが入ってる so ファイルに問題が起きてる様でした。IL2CPPでビルドしてるのに謎です。

最終的にはこちらに関してもリリースビルドで試した所、余計なMonoのライブラリが除外されたからかapkサイズが戻ったので --enable-debugger のデバッグ用のsymbolのせいでした。Unityのビルドシステム側のバグ。。。?とりあえず対処療法で治ったので以降は深追いしていません。

UI.Textの拡張したComponentでバグった

unity2018でUnityEngine.UI.Textに変更が入っていたので、その変更分を追従し忘れていました。

ちなみにローカライズ対応で指定したRectに収まらない文字数だった場合に横に頂点を潰してRect内に収める様なComponentを作っていました。

拡張先のComponentでは2018でメッシュの頂点をキャッシュから取ろうとすると取れない時があったらしく、大元のText.csの中身を真似する形で問題を解消しました。

unity issue tracker で報告されてたバグを修正した結果、バグの挙動を期待してたコンポーネントがバグってしまった様です。

ちなみにこれは2018.3で直されていたバグの様でした

UI: Fixed issue with Font Sizes that are too big for Rect Transform causing "Argument Out Of Range" error.

Unityをアップデートした場合に見るべきだと思う観点

QAに先行で重篤なバグを見つけてもらう為に以下のケースを優先してもらってました。

以下は実際にQAに共有した箇条書きです

今回はshaderの互換性が崩れてたので見た目も重点的に見ていました。

  • 各種NativePluginの更新があったので、それらに関する機能
    • SNS連携(データ引き継ぎ) android/ios
      • Twitter
      • LINE
    • 課金 android/ios
    • GooglePlayGameServiceへのサインイン android
    • リモートプッシュ通知 android
  • ゲームの見た目への変化(描画周りの更新があったので、何か軽微な問題が出てるかもしれません)
    • アウトゲームのUIの見た目
    • インゲームの3D表現周りの見た目
      • キャラモデル
      • 建物モデル
      • エフェクト...etc

エンジニアは以下も事前に確認しておくと安心かと思ってます

  • 通信切断時のエラー&リカバリ処理
  • 画面遷移時の割り込み操作
  • 発熱、バッテリー消耗が激しい
  • ABの読み込み耐久テスト
    • Loadを繰り返してクラッシュしないかなど
  • ビルド後のサイズが急激に増えてないか
  • 各画面でのメモリ使用量が急激に増えてないか
  • 1フレームの処理時間が急激に増えてないか?
    • 特にアクセスの多い画面やバトルなどの様に特に速度が求められる場面でのチェックは優先的に
  • Unityが提供してるclassを継承してる機能が問題なく動くか?
    • UI.Textなどは自分の周りでも拡張してる人が多いので特に注意かも

リリース前にUnity2018に上げておけば楽だったのでは?

Unity2018.1が出た時点でリリース前のQAフェーズに入ってしまってたので無難に2017.4のLTSリリースのバージョンを選択肢しました。

2019年夏にAndroid64bit対応に向けて確実にUnityをアップデートする必要がありましたが、Unityのメジャーバージョンが安定するまでは最低でもマイナーが2になるまではかかるという宗教を自分は信じてるので安全側に倒した判断をしていました。