COSCon(中国オープンソースカンファレンス)行ってきました

なんのイベント

実は私もあまり詳しく存じておりませんが、とにかくなんかオープンソースなものについてみんなで一緒に盛り上げようぜっと言うカンファレンスです。そしてそれもソフトウェアに限らず、ハードウェアとかでも、オープンソースなら話しましょうぜっというスタンスです。実際日本からもラズパイユーザグループの方が登壇に招待されたりしています。

開催は先週末の11月2日〜3日、上海の華東師範大学にて2日間でしたので、私にとってはもしかするとほぼ10年ぶりの上海だった気がします。

詳しくはこちらの公式HPからご覧ください(中国語注意)。

www.bagevent.com

なんでお前が行ったの

正直申し上げますと、実は私はそもそもこのイベントのこと知りませんでした。そもそも普段は日本でしか活動していないし、活動内容も基本Swift周りのみなので、オープンソースとか言う主語のデカイイベントにはずっとハードルが高いと思っていました(まあ実際参加してみてもやはり周りはフロントエンドバックエンドばかりでモバイルネイティブのエンジニアが少ないのは事実である)。

それなのになんでこれ行ったの?と言うと、これもまた偶然に偶然を重ねた結果で、まず私はWeibo(中華Twitterみたいなもの;以下皆さんが分かりやすいように、Weiboの各機能をTwitterの機能名に置き換えて説明します)での知り合いが、「COSConに登壇に招待されたからチケット5枚もらってるけど、同僚や知り合いにあげてまだ1枚余ってて誰か欲しい人いる?」と言う抽選ツイートをしたのです(Weiboでは公式で「抽選」機能があり、対象のツイートを締め切りまでにRTすれば抽選に参加でき、締め切りになったらRTしたユーザから自動でランダムに当選者を選んでくれます;また当選者の人数も設定可能です)。絶対当たるわけないだろwww当選率を下げたろーと言う軽い気持ちでRTしてしまったら、まさかの本当に当選してしまったと言う…

f:id:elhoshino:20191108170013p:plainf:id:elhoshino:20191108170017p:plain
抽選率下げたろーと言う軽い気持ちでRTしてしまったら、本当に当選してしまったの巻

見ての通り、当選したのは10月29日と言う開催直前のタイミングでした。本当にいきなりでした。しかし当選してしまったら仕方ない。さすがに行かないのは行きたくてRTしたのに落選した人には悪すぎる。行くしかない。そんな時にとても助かったのは、弊社の勉強し放題制度、と言うものです。勉強のためなら安心していけ、金銭的な負担は全て会社が担いでやる、と言う勉強好きな人にとって夢のような制度です。

note.mu

とは言え、さすがに会社のお金は無限ではありませんし、こんな素晴らしい会社が倒産してしまったら次のカモはそうそう現れない心が痛みますので、節約できる部分は節約しましょう。と言うわけでほぼほぼ前日ですが、LCC渡航することによって、通常の航空券の半分もかからない、往復で25000円程度に抑えられました。それに会場近くのホテルと合計して45000円程度の経費を計上(することを予定)しました。ちなみにLCCは福岡⇄上海航路がないため、佐賀空港発にしました。航空会社は安定の春秋航空です。佐賀空港は駐車場がタダなので、一人で数日渡航しても駐車料金がかからないから、燃料代考えても非常にお得です。

f:id:elhoshino:20191108135840j:plain

カンファレンスをどう過ごしてきたの

スケジュール構成は午前は大きなトラックを一つ確保して大袈裟なKeynoteを、午後は分野を分けて小さいトラックをたくさん用意して細かい発表を、さらに最終日の午後最後にLTをいくつか登壇させるスタイルです。正直午前中のKeynoteは基本「マイクロソフトオープンソースを愛してるよ」「アリババはこんな風にクラウドサービスでオープンソースを活用してるよ」と言ったスポンサーの宣伝タイムの匂いが濃厚なので、私は午後の知り合いのトークと興味がある分野だけしか行きませんでした。それでも実は思った以上の収穫がありました。

まず1日目は知り合いと合流したのち、その知り合いを通じて中国でのiOSエンジニアと何人か会いました。中国のモバイルネイティブ開発、引いてはプログラミング全体の空気がある程度イメージが湧きました。なんか中国では最近「KPI」と言う概念をほとんどの企業が導入しており、簡単に言うと業績を叩き出せなかったら即解雇という流れがあるらしいです。まあ結果主義なのでそこまでは驚かないですが、ただ本当に中国のエンジニアと会話するたびに「KPIガー」「KPIガー」が登場するので、今回ようやくその正体を突き止めてきました。もちろんそれによってストレスもたまりますが、最近は好景気も相まって、本当に給料がだいぶ上がってきてるらしいです。特にエンジニアの場合、直接数字を聞いておりませんがまあ私より稼いでますね確実に。

お金の話といえば、ちょっと脱線しますが、今回の会場が大学内であることもあり、近くのコンビニに文房具とかの学生向けのライナップもそこそこ充実しています。そこでいかにも学生さんが使ってそうなペンの値段を見てみたら…もちろんモデルとか機能とかにもよりますが、単色の黒色ボールペンというカテゴリで見るともう日本とほとんど変わらないやんけ…筆者が中学生の頃はボールペンなんて1/5の値段しかしなかったから金銭感覚が狂ってしまう

f:id:elhoshino:20191108144259j:plain
昔1元とか1.5元しかしなかったボールペンが今や6.5元とか7.5元かかる

そして2日目はとりあえずとっつきやすそうな発表「开源是菜鸟通往大神之路(オープンソースこそ素人からベテランへの道)」を聞いてみました。とても面白かったので2枚スライドを共有します:

f:id:elhoshino:20191108144320j:plain
ソースコードGitHubに上げるだけでIssueについてオープンに議論しなければ、これオープンソースとは言えずただのgitを使ってるエンジニアでしかない

f:id:elhoshino:20191108144402j:plain
今社内で使われているモジュールをオープンソースにすれば、プロダクトがよりハイレベルに更新され続け、ある意味世界中のベテランプログラマを雇った事になる

うん、まさにこの通りだと思います。と言うわけで実は弊社もこれからいくつかのライブラリーをオープンソースにしようと準備をしています。ただ自社サービスの会社と違い、「じゃあこれソース公開するね」と自分たちだけ言ってぽんって公開できないので、いろいろ準備をしなくてはならないのです。

ちなみにこの発表の後の質疑応答タイムで質問したら、発表者だけでなくその場にいた主催の方の一人からも答えをいただいて、なぜかと言うと発表者は台湾の方で、更にその主催の方も台湾出身で、発表者の答えの後に追伸をくださいました。それを機にWeChat(中国のLINEみたいなもの)友達を追加しておきました。

この発表が終わったらしばらく特にやることなかったので会場の外のキャンパス内の芝生に来てちょっと休もうと思ったら、立ち話してるグループから「日本」と言うキーワードが聞こえて、特に今やることもなくて退屈してるから初対面にもかかわらずとりあえず会話に参加してみたら、ここからまた友達ができました。やったね!と言うかみんなの経歴すごすぎ、高校卒業してアメリカの大学通ったりエリア51で遭難しそうになったりスイス行って登山したりアクティブすぎw

そして最後はLTを聞いてみたかったのでみんなお別れしてLTの教室に。ここにも面白い発表があったのでスライド貼ります

f:id:elhoshino:20191108144438j:plain
我々は「996」を反対しているが、本当に反対しているのは「視野と生きる空間が制限され、仕事と生活が機械化され、それによって想像力が少しずつ無くなっていき、最終的に生き甲斐がなくなること」だ(996は「朝9時出勤夜9時退勤週6日勤務」の略で、中国では特にITベンチャーでは「労働法」違反にもかかわらずこの勤務スタイルを取り入れてる企業がちらほら見られる)

f:id:elhoshino:20191108144450j:plain
自分の趣味が見つかったら、もう一生働かなくて済む。

f:id:elhoshino:20191108144518j:plain
どうやって自分のOSSをPRするか:StackOverflowで人の問題を解決するツールを答えとして返すのはいいぞ(この登壇社はVSCodeプラグインCode Runnerなどの作者です)

そしてLTの始まりに、先ほどの台湾出身の主催者から、「今日のLTは今からでも登壇したい人募集してるよ」と言われて、ちょっと悩んで(日本語のスライドしかないから)結局応募しましたwまあ漢字はちょっとあるしとりあえず言葉で喋れば大丈夫だろうと思って応募してしまいました。ところでいろいろ探してみたがオープンソースのカンファレンスで喋っても大丈夫であろうスライドが15分の発表のもので、このLTがスケジュールの問題で5分以内にと言われました、まあ頑張って超早口で喋って所々を飛ばすしかないと開き直りましたwそして更になんと参加者に動画撮影してbilibiliにもアップロードされたので、初めてbilibiliの他人の動画に出ることになりましたw興味ある方はぜひこちらの動画をご覧ください(もちろん喋りは中国語ですが先ほど言った通りスライドは日本語です)

https://www.bilibili.com/video/av74440949?p=1www.bilibili.com

カンファレンスについてどう思うの

とりあえず正面の入り口の看板や会場のバナーとかをご覧ください

f:id:elhoshino:20191108135924j:plainf:id:elhoshino:20191108144226j:plainf:id:elhoshino:20191108144236j:plainf:id:elhoshino:20191108144423j:plain

見ての通り、多くのスポンサーがついています。知らない人はいないであろうマイクロソフトもいれば、日本市場にもますます存在感を増してきたアリババやファーウェイもいます。そこそこ大規模なカンファレンスですね。

私は本当に何も知らずにチケット当たっちゃったから行かないのはまずいと思って行ってみただけなので、行ってみて思ったよりは全然楽しかったです。知り合いと合流して業界全体の会話ができたり、発表でiOSとは全く関係ない分野の話が聞けたり、何より新しい友達ができたのがとても嬉しかったです。別に当分の間は中国に帰る予定が全くないですが、繋がりができて共通の話題が持てるのは嬉しいことです。

そして中国人は本当にアクティブです、最終日のLTはその場での応募もたくさんあったらしいし(日本人はその場で登壇申し込みどころか質疑応答タイムですら積極的に質問する人少ないよな…後で聞くくせに)、参加者のWeChatグループがいまだに毎日活発に会話していてある意味うるさい(笑)

ただもちろんちょっとうーんなこともあります。一番思ったのはスケジュール管理がずさんすぎですね(苦笑い)。実は1日目に他の聞きたかったセッションがあったのですが、もらった紙のスケジュール表の時間割が古く、その後のセッションと入れ替えられてしまったので、会場についたときはすでにその発表が終わってました。その後携帯アプリから調べ直したら入れ替えられたことを知ってとても残念な気持ちでした。せめて会場内でどこか案内が欲しかった(逆に今の中国人はもうみんなアプリしか見ないのかな…?いやアプリ見るのはいいことだけど携帯の画面ちっちゃすぎてスケジュール見づらくない?)。そして発表時間も人によってはオーバーしたりでその後の発表の時間が押されてしまったり。

でも後で聞いた話ですが、そもそも今回の主催や運営は学生さんが多いらしいです。まあそもそも開催地が大学ですもんね。それを考えれば、むしろ学生主体でこれだけ大規模なカンファレンスが主催できたのが既に凄すぎます。自分が大学生の時はサークルの飲み会で精一杯でしたよな…

他に何か言いたいことあるか

チケットくれた知り合いにお土産あげたら、加藤ちゃんの絵を書いてくれた

f:id:elhoshino:20191108144218j:plain
加藤恵

会場の大学食堂のお昼

f:id:elhoshino:20191108135948j:plain
懐かしい大学食堂

ホテルから見た上海の夜景

f:id:elhoshino:20191108144547j:plain
日本にもこう言うフリーウェイ欲しい

大学のすぐ近くにあるショッピングモールに、タオバオの公式店舗サービス「天猫」のマスコットキャラがあった。かわいい

f:id:elhoshino:20191108144155j:plain
天猫ちゃん

よくわからないなんかそのサービスでは車のコーティングもやるらしくそれの宣伝トラックもあった。かっこいい

f:id:elhoshino:20191108144207j:plain
よくわからない店舗のトラック

レストランの前に飾られてる古典的な漢服を着てるお人形

f:id:elhoshino:20191108144536j:plain
かわいい

そろそろ洗車した方がいいぞ、のかわいい車

f:id:elhoshino:20191108144601j:plainf:id:elhoshino:20191108144614j:plain
流石にそろそろ洗車しないと…

以上、中国も楽しいよ!

iOSDC JAPAN 2019 参加してきました

年に 1 度の日本 iOS 開発者の祭典、iOSDC に今年 3 回目の参加してきました!

私のこと知ってる人なら知ってると思いますが、私は今年 2 月に福岡に引っ越しましたので、それまでに東京で知り合ったエンジニアと会う機会が非常に減りましたので、iOSDC のような日本全国から集まってくれるイベントはとても貴重です。そしてもちろん半年ぶりに会った東京のエンジニアもいるし、一年ぶりに会った他の地方のエンジニアもいますし、さらに新しい知り合いもできました。ありがとう、iOSDC!

そして iOSDC は一方通行のコミュニケーションではなく、登壇者も視聴者も対等に双方向のコミュニケーションの場として提供したい!とのことですので、聞いた発表に気軽にフィードバックをオンライで できる仕組みが作られています。とりあえず聞いた発表全部フィードバックを送ったら、なんとフィードバッカー賞をいただきました!ありがとうございます!!今年は大体一言で終わらしました(何人かは一言もなく空白で送っちゃいました)から申し訳ないと思いますので、来年はもっと長文のフィードバックを送れたらと思います💪

ちなみに個人的に今年で一番良かったと思ったセッションは koher さんの「Heart of Swift」でした。やはり私は iOS がどうのこうのではなく「Swift」言語そのものが好きです。残念ながら執筆した現時点ではまだスライドの PDF が公開されていません、と言うのもそもそも発表スライドは Keynote とかではなく、iPad アプリで作ったらしいです。さすがの気合です。と言うわけでとりあえず CfP のリンクを貼り付けます: fortee.jp

会期中は発表とおしゃべりに集中してましたので、あまり写真をたくさん撮れませんでしたが、とりあえずいくつかお見せしましょう:

f:id:elhoshino:20190908123719j:plain 入り口のバナー

f:id:elhoshino:20190908124748j:plain 弊社の紹介バナー

f:id:elhoshino:20190908125016j:plain みんな大好きタピオカミルクティー

f:id:elhoshino:20190908125231j:plain ベストフィードバッカー賞でいただいた T シャツを早速着てみた

それでは!

町、時の流れ、人

2019年7月18日午前10時半過ぎ、京都アニメーション第一スタジオが放火され、執筆している現時点で34人の方が死亡し、34人が重軽傷を負う事件が発生しました。

事件発生した当時のニュースは火災の報道しかなかったため、私は「京アニ燃えちゃったか…早く火を消せたらいいな」くらいの温度感しかなく、普段通りに仕事場に向かいました。

ところが時間の経過につれて、「死亡確認」のニュースが出始め、さらに死亡者数も見るたびに上がって行きました。

頭がだんだん白くなっていきました。何も考えられなくなりました。あまりにものショックで、出社して4時間も経たずに帰宅することにしました。そして翌日も、面接して最低限の作業だけに留まりました。

最初はまだ被害者への悔しみと放火犯への怒りで頭がいっぱいでした。古代中国の凌遅刑が復活すればいいのにとすら思いました。しかし新しい情報が入ってくるうちにいつの間にか全ての感情を失いました。19日はただロボットのようにひたすらニュースやコメントを更新して眺めるだけの1日を過ごしました。

京アニは私にとってとても大事な存在です。2004年高校生になった私はクラスメイトの影響でアニメにハマり、新旧問わず様々な作品を見ていました。そんな頃に、京アニの元請け作品2作目のAIRと出会い、京アニファンと鍵っ子になりました。感動的なストーリーはもちろん、今でも印象に残ってるのは、周りの多くの人は「あんなクッソでかい目玉まじクソ作画じゃんw」と笑う中、私は逆にあの宝石のような瞳の描き方に魅了されました。中国では「目は心への窓口」の言葉もあり、瞳にこんなに力を入れる作品は神作に決まってると断定しました。そして完結と共に、私の判断は間違ってなかったと安堵しました。もしヒロインが最後死ぬ物語は悲劇ならAIRは間違いなく悲劇ですが、不思議と一般的な悲劇と違うのは最後まで見終わったあと、心に残ったのは憂鬱ではなくまた明日も頑張ろうっという希望に満ち溢れたポジティブな感情でした。

それ以来、女性向けのFree!も含めて京アニのほぼ全ての作品を見てきました。とてもハマった作品もあれば、当然それほど好きになれなかった作品もあります。ただ「適当にこういうのだしとけば儲かりそう」という薄っぺらい作品は一つもなく、どれもスタッフの熱意と苦労がこもった作品ばかりです。この拝金主義が横行し、とりあえずソフトポルノなやつだしとけばホイホイとお金出してくれる楽な商売で生きていける現代社会で、落ち着いてゆっくりと、それもしっかりと一つ一つの作品を心を込めて大事に育てていく会社はそう多くありません。だからこそ、アップルCEOのティムクック氏も京アニを、「home to some of the world’s most talented animators and dreamers(一部の世界で最も才能溢れたアニメーターとドリーマーにとっての家だ)」と高く評価してくれたでしょう。

ティムクックや私のような京アニファンだけでなく、京アニに「監督降板」させられたヤマカンこと山本寛氏も、最初の頃は「ちょっと黙っといて」で炎上しましたが、事件翌日偶然、中国新華社ライブ配信に献花の姿を撮られました。正直なところ、私はヤマカンのことそれほど好きというわけではありませんが、部外者の私より彼のほうがよっぽど京アニに思い入れがあるでしょう。彼は一体どんな気持ちで献花したのかを推測できる立場ではないと自覚しておりますが、あの涙はきっと本物だと私は思います。それにしても運命はわからないもんです。日本でも中国でもなかなか才能が認められず、その上戦争についての発言で中国で炎上し、入国禁止まで食らったヤマカンが、逆に中国メディアにその思い入れの一面が映り、世界に公開されたわけです。

京都アニメーションは創立当初から、地元貢献を企業理念の一つとして運営してきました。今回の事件についても、八田社長は焼失した第一スタジオを取り壊し、記念碑を建てた公園にしたいとコメントしました。これほどの被害を受けても、従業員と彼らの家族への取り組みを最優先にし、そして自社の再建よりも地元民を大事に考えています。これほど尊敬できる企業はなかなか出会えません。そしてこんな尊敬に値する企業だからこそ、地元民のみならず世界中から支持を集めているでしょう。事件発生してから、従業員を頑張って救助しようとしている住民や消防隊、日本中から駆けつけた献花者、世界中から集まる義援金京アニに感動をもたらされた一人一人が自分でできる限りのことに尽力しています。

亡くなった方々は復活できませんが、それでも生き残った我々は自分の使命を果たし、世界をもっと美しくし、より多くの人々に夢を与えなければなりません。それこそが犠牲者へ捧げられる最大の敬意だと私は思い、明日に向けて生きていくと誓います。


※タイトルは京アニによってもアニメ化された作品「CLANNAD」の、ゲーム中BGMの一つのタイトルです。

LINE Developer Meetup(京都)#53 に行ってきました

お久しぶりです。転職ではないが東京に飽きて特に渋滞にうんざりしてしまって会社に「福岡行きたいです」って言ったら一人で福岡オフィス作った(と言う名のWeWork借りた)星野です。ちなみに福岡に移住したとは言え、iOS 系の勉強会がやはり少ないから、月一くらい東京の勉強会行くから旅費くださいって言えば出してくれる会社ですのでとても助かります。と言うわけで今回は東京ではなく京都に行ってくました:

line.connpass.com

LINE さん主催の勉強会で、一般公募登壇枠がなく全て LINE の社員による発表(しかも 3 枠のうち 2 枠は外国人社員による英語の発表)ですが、どれも内容がとても濃くて完全に吸収するのにはまだ少し時間がかかりそうです。と言うわけで復習も兼ねてこの記事で簡単にこれらの発表を振り返ってみます。

MVC @ IOS

speakerdeck.com

これは MVC パターンを綺麗にするための発表です

概要

  • 従来の (CocoaMVC パターンは VC(ViewController)が Fat になりがち
    • そのため MVP や MVVM などの設計が考案され、MVC はもう時代遅れと言う風潮になった雰囲気がある
    • しかし本当に MVC はそれほどダメなのか
  • iOS の VC と View は本来それぞれちゃんとした役割がある
    • VC は画面遷移、View のライフサイクルやイベントなどの管理を行う
    • 対して View は子ビューの階層構造、レイアウト、レンダリングやアニメーション等を行う
  • View を自作してみよう
    • 画面系のセットアップを VC から View に移行しよう、これで View のテストも作りやすくなる
  • VC から Model や Network などの要件もちゃんと分離しよう
    • これで Unit Test もやりやすくなる
  • 画面が複雑になってきたら子 VC の利用も検討しよう
    • 要件が単純化され、作りやすくなる
  • まとめ
    • MVC でも綺麗で読みやすい作りにできる
    • 汎用的で再利用しやすい UI を作ろう
    • 設計に銀の弾丸はない、ちゃんと自分たちで設計要件を検討しよう
    • もちろもちろん MVVM や Redux なども魅力的だよ!

感想

実は設計について、自分も去年こちらの本の執筆に参加しており、中でまさに MVC の章の執筆を担当しました:

peaks.cc

この章の執筆によって MVC の資料をたくさん漁って、実は今まで MVC に関する知識は間違っていた!?と言う反省を抱きながら、執筆に臨みました。そしてその感想として、やはり MVC でもきちんと設計を行っていれば綺麗なコードにはなるし、逆に何も考えずに Fat な VC を作っちゃうような人たちは、仮に MVVM や MVP とかの設計に転向したところで、Fat な ViewModel や Fat な Presenter を作ってしまうだけで終わりますので、やはりどの設計を選ぶか以上に、どの部品がどこまでの責務を持つかをきちんと考え抜いたほうが大事ですね!Fat VC を理由に MVC を拒まないようにしましょう、MVC も立派で偉大な設計パターンです。

Swift コードのための Swift プログラミング

speakerdeck.com

ちょっとわかりにくいようなタイトルですが、Swift プログラムで、Swift のソースコード(フォーマット)を綺麗にするための発表です

概要

  • SwiftSyntax と言うツールがある
    • これを使うと、特定なキーワードでワーニングを出したり、ソースコードを機械で生成/編集したりできる
  • SwiftSyntax はコンパイラ内部で使う libSyntax を利用し、構文を抽象化して解析したり作成したりできる
    • 具体的にはどんな型があって、中にどんなプロパティーがあって、どの protocol に準拠してるかだとか、様々な構文情報がわかる
    • それによってプロパティーの書き換えや場所の移動、private などの attributes の追加なども簡単に実現できる
    • 構文の解析には SyntaxVisitor を利用する
    • 構文の編集は SyntaxRewriter を利用する
    • 構文の生成は SyntaxFactory を利用する
  • 具体的な操作は上記のスライドを参考に

感想

実は今年の try! Swift Tokyo にもありました SwiftSyntax のネタですが、try! Swift の時は 5 分しかない LT だったので最低限のイメージの紹介しかできなかったが、この発表では時間がたっぷりありますので、具体的にどう言う風に使えばいいかだけでなく、実際にそのツールをすでに作って& OSS 化したので、より使いやすくなったと思います。特にチームで開発する際に、フォーマットの平準化にも役に立ちそうですので、いつか導入したいですね。今のところ唯一の懸念点は、どうやってコミットを実行済みの結果に保証するかの仕組みを考えないとですね…

Networking shouldn't be so hard

speakerdeck.com

これはネットワーク処理(リクエストやレスポンス)についての、非常に詳しい発表です

概要

  • ネットワーク処理は簡単か?
    • 理想論ならとても簡単
    • でも現実世界ではなかなかそうシンプルにはいかない
    • しかし本来ならばそう難しくなるべきでもない
  • 大昔のネットワーク処理は今と比べるとちょっと煩雑だった
    • NSURLConnection とかを使っていた
    • セッション管理とかキャッシュとか自力でやる必要があった
    • ただ別にそれでも特に難しくはなかった
  • 今はさらにいろんなラッパーライブラリーがある
    • URLSession とか Alamofire 使えばもっとやりやすくなっている
    • Client を作ってリクエストとレスポンスをセッション通じてさらに管理しやすくできる
    • レスポンスの面倒な (data: T?, response: URLResponse?, error: Error?) はさらに Swift 5 の Result<T, Error> でまとめられる
    • よってネットワーク処理は本当に(理屈上は)簡単
  • しかし現実世界はそう単純にいかない
    • リクエストのコンテンツは JSON Body なのか URL Query なのかだとか
    • 正常でないレスポンスが返ってきたときのハンドリングとか
    • ネットワークがつながりにくい時のリトライや Token が古くなった時の更新だとか
    • 現実世界で起こりうるシナリオの多さは問題を難しくしている
  • でも問題を単純化することは可能だしそうすべき
    • 各々の責務を細かく抽象化して分けよう
      • リクエストならリクエストを作る責務を抽象化して、内容に応じた具体的なリクエストの作りをその部品に任せよう
      • レスポンスなら意思決定ベースで continue restart errored done に抽象化してそれぞれの動作を実装しよう
    • リクエスト駆動でやることをリスト化する
  • 問題を細かく抽象化して対処すれば難しくない
    • 部品が小さくなるので見通しが良くなる
    • 副作用を排除したのでテストがしやすくなる
    • protocol の活用で実際のケースに応じた柔軟な対応がしやすい
    • 意思決定を基にした拡張性の確保
    • リクエスト駆動による操作性の向上
  • 結論:現実世界でもネットワーク処理は難しくないはず

感想

なかなか濃い内容で、これだけでも京都に来た甲斐はあったと思えるくらいのボリュームです。ネットワーク処理をどう単純化すればいいかなど、細かいところまでカバーしてたので今後の開発に参考にできるものも非常に多いです。ちなみに Speakerdeck に上がっている資料は 133 ページもあるのですが、発表者の @onevcat 氏によるとこれでもすでに初稿から 20 ページも削除したそうです…

あとがき

どうしても日帰りで福岡に帰りたかったので残念ながら懇親会はほんの少しだけしかいられなかったけど、久しぶりに京都勢に会えたので今度はぜひみんな福岡に来て欲しいw

try! Swift 2018 レポート的な何か

あらすじ

年に一度、日本で開催される Swift 関係で唯一の国際カンファレンス:try! Swift Tokyo へ今年も行ってきました。1 日目と 2 日目はトーク、そして 3 日目は各種ワークショップやもくもく会など、盛りだくさんの内容で賑わう 3 日間でしたので、今回の参加で気になった内容をまとめようと思い、この記事を書くこととしました。最初は Qiita で書くかこちらで書くか迷いましたけど、みんな Qiita で書くと try! Swift 関連の記事で TL 荒らしになりそうな気がするのでこちらにしました(笑)。

1 日目

裏 Swift Tour

speakerdeck.com

最初の発表。普段何気なく書いてるあのコードも、実は裏ではこんなことをやってるの!?みたいな解説もあって、とても興味深かったセッションでした。トリッキーな動きをするコードはあまり積極的に買うべきものではないですが、その動きを把握することはデバッグすることにおいてとても重要ですので、把握しておいて損はないです。ちなみに個人的に一番興味深かったのは、宣言が Stored Property のように見えても、didSetwillSet 入れただけで、実は裏では setget を利用する Computed Property になります。Computed Property と Stored Property は、特にマルチアクセスがあるときの動作は結構違いますので気をつけましょう。

レスポンダチェーンを知ろう

※公開スライドなし

iOS の開発しかやってないとあまり意識したことがない Responder Chain ですが、チェーンをカスタマイズすることで途中で好きな処理を挿入できたりして、例えば Delegate を使ってた処理とかも、Responder Chain の途中で好きなオブジェクトを挿入してハンドリングしてもらうこともできるそうです。個人的にはまだあまりその旨味を実感できてませんが、これからはこれを意識して使い道を探してみようと思います。

関心の分離と単純化のためのSwiftコードの最適化

speakerdeck.com

我々はソースコードを書くことよりも、倍以上の時間を費やしてソースコードを読んでます、そのためコードレビューなどではコードの読みやすさはとても重要です。そんな中、コードの中に「What」と「How」を分離することは、コードの読みやすさに大きく貢献しています。例えば UTF16 で文字数を数えるソースコードで、.utf16.count を使うわけですが、このコードだけでは .utf16.count を使っていることはわかっても、なぜ utf16.count を使っているのか、これはプログラム上ではどういう意味を持っているのかはわかりません。そのため、String を拡張して、var countUsingBackendPolicy: Int { return utf16.count } を定義することによって、「これはバックエンドのポリシーによる文字数の数え方だよ」ということが読み取れます。この発表はこのようなユースケースをたくさん紹介して、実務ではどのようにソースコードを改修してきたのかを説明したとても為になるセッションでしたので、スライドも定期的に読み直したいですね。

SwiftyPi

speakerdeck.com

実はこのトークの時間、自分は前の前のセッションの Ask The Speaker のコーナーにいたのでその場で聞くことはできぜ、あとからスライドを眺めることしかできませんでしたが、内容自体はとても気になりました、なぜなら実は自分も去年ラズパイに Swift 入れようとして Ubuntu 入れるところまで行ったけどそれ以上の進捗がなく止まってました。このトークによりますと、どうやら現状 Swift 4.1 はまだ ARMv7 の対応がなく、使うときは Swift 3.1.1 を利用すべきらしいです。また、GPIO を操作するときは GPIO の番号を使う必要があって、それが物理の PIN 番号とは違うので要注意です(そして GPIO 番号はボード上ではバラバラに配置されています)。また、このトークでは Vapor も利用しており、クライアント側/サーバ側/組み込み側が全て Swift で作られているので、Swift 信者としてはとても気持ちいい構成になってますので時間あるときに是非とも深く研究してみたいと思います。

👾

speakerdeck.com

去年からゲーム開発ネタをぶち込んでくる自称ゲーム開発者の iOS エンジニア兼 fastlane コントリビューターの giginet さんの発表です。去年はマリオを Apple Watch に移植したことを発表しましたが、今年はさらにエスカレートし、Xcode を「統合ゲーム開発環境」だと訴えました。まあ確かに Xcode だけで RPG のマップとか作れるけどさー。自分も前職がゲーム会社だったこともあって、リリースまでは持ち込めなかったものの、ゲーム開発用の SpriteKit や SceneKit は確かに色々触ったこともありましたので、3D は専門外ですが 2D なら確かに SpriteKit を使えば結構手軽にいろんなジャンルのゲームが作れます。そして SpriteKit は唯一 Apple Watch に対応しているゲームエンジンだということもアピールし、自作の RxSpriteKit の宣伝もしっかり入れました。凄まじいゲーム愛を伺えます。

AST メタプログラミング

speakerdeck.com

なかなか高度の話題で、少なくとも自分としては今まで全く触ったことのない分野の話でした。構文解析された Abstract Syntanx Tree の中にさらに独自の処理を入れることによって、普通に自力でソースコード書くととてつもなく大変なものがテンプレートを使うのと同じ感覚ですぐ書けちゃうのがとても魅力的で、生産性が上がるだけでなく重複労働が省かれるためヒューマンエラーも減りそうな予感です。この発表では発表者の岸川さんが作った強力なアサートライブラリ SwiftPowerAssert を最後に紹介しましたが、真面目な話、自分が作ってる NotAutoLayout もメタ的な視点で見ると重複してるコードが沢山ありますので、是非とも導研究してみたい気分です。

2 日目

超解像 + CoreML + Swift を使ってアプリの画像データ転送量削減に挑戦する

speakerdeck.com

通信、特に画像や映像が頻繁にサーバとやりとりするアプリでは、通信量の削減は常にホットな話題の一つです。削減法は沢山ありますが、例えば画像の場合、圧縮比の優れたフォーマットを利用する方法もありますが、もっと直接で乱暴な方法として画像の解像度を減らすというのもあります。しかし低解像度の画像をそのまま表示されると見栄えがさすがに悪いので、どうにかローカルで解像度を上げないといけません。そんなとき、我々アニオタならまっ最初に頭に浮かぶのは waifu2x ですが、それはアニメ画像用にチューニングされたものですので、直接漫画に適用すると、漫画のトーンが潰されたり、文字が滲んだりする問題があります。そのため、DeNA ではマンガボックスというサービスのために、ローカルで解像度を上げた画像を手軽に利用するための SRCNNKit を公開し、その解像度を上げるための独自の学習モデルを開発しました。さすが漫画データを用いた学習済みモデルだけあって、漫画トーンもとても綺麗に出てかなり良かった感じです。

Swift 5 の Ownership に備える

speakerdeck.com

Swift 5 では新しい機能として「Ownership」が導入される予定だというのはもうニュースではありませんが、このトークは実際 Ownership 導入されたら今までのコードにどんな影響をもたらすのか、我々エンジニアにとってどんなメリット/デメリットがあるのかについて軽く紹介した内容です。Swift は値型である structenum を大幅にパワーアップし、今まで参照型である class にどうしても頼らなくてはいけない多くのものは、値型の structenum でも十分カバーできるようにし、暗黙な参照を減らすことでより安全なコーディングを可能にしました。しかしその反面、値型のデメリットであるコピーコストはどうしても避けては通れない道でした。今まででも Copy on Write という仕組みで、値型はコード上コピーされても、実際の動きは修正が入ってから初めてデータがコピーされることによってある程度のパフォーマンスの問題をカバーしてきましたが、それをより高度なチューニングを可能にしたのが Ownership です。moveonly struct による定義や shared 修飾子による引数宣言で、プログラムは今までと同じ安全性を保ちつつも、明示的に参照だけ渡すことを可能にしたことで不要なコピーコストをさらに減らすことが可能になります。またすでに Ownership を導入した Rust では学習コストが高く、Ownership を使いこなす必要がありますが、Swift では Ownership はあくまでチューニング用の機能であり、使わなくても今までと同じコードで開発可能だそうです。

Codableが導く型安全な世界

speakerdeck.com

Xcode 9 がもたらす最も嬉しい機能の一つと言っても過言ではないであろう Codable ですが、多くの人はこれを JSON データとの相互変換にしか使っておらず、それが大変もったいないということを再確認させてくれるトークです。CodableJSON だけでなく、ありとあらゆるデータのエンコード/デコードは理論上可能であり、その必要があれば自前の XxxEncoderXxxDecoder さえ作れば OK です。そして、発表者は実際にそういったエンコーダ/デコーダを作った MoreCodable ライブラリーも公開し、JSON 以外でもより手軽に Codable が使えるようになりますので、ぜひ試してほしいライブラリーの一つです。

3 日目

今年の try! Swift Tokyo は 3 日目にハッカソンがなく、代わりに様々なワークショップがあります。そんな中で自分が参加したのはこちらです↓

Swift の値型を極める powered by SWIFT QUEST

参加した、というのは間違いないですが、さらに正確にいうとアシスタントとして参加し、ステップバイステップに手を動かしたわけではなく、むしろ参加者が手を動かすのを手伝う立場でした。

前述 2 日目の Ownership の話にもあった通り、Swift の値型はとても強力で、このワークショップはその値型の振る舞いをマスターするためのものです。そのために使ったのは主催者が作った SWIFT QUEST という誰もが知っている(であろう)あの RPG をモチーフにしたゲームです。このワークショップを通じて、如何に値型の struct だけで、安全なプログラムを構築しながらも手軽なデータ修正を行うという、Mutable Class と Immutable Class 両方のいいとこ取りをするのか体験できます。

After talks 2 日目

公式のプログラムが終わった後には、さらに非公式な関連イベントがいくつか開催されており、この After talks もそのうちの一つです。また、とても光栄なことに、自分も当時 try! Swift に出した CfP が落ちたものの、「この CfP が聞きたい!」という声があったためここで発表する運びとなりました。

初めてのターミナルプログラム

speakerdeck.com

当日は仕事の都合によりほとんどのトークが聞けず、なんとかギリギリ自分の発表順番が来る直前に会場にたどり着いたわけですが、そこで発表したのがこちらです。Swift はアップルが主導で開発している言語であり、また Swift を使った開発の多くは iOS 開発でしょう。しかし Swift はあくまで汎用プログラミング言語であり、iOS だけに使うのはもったいないです。せっかく我々は Mac を使って iOS 開発しているので、ついでに Swift で Mac のターミナルで使えるプログラムも開発してみようではないか、という思いで出した CfP でして、また発表自体ライブコーディングを交えつつ簡単なズンドコプログラムをその場で作りました。ターミナルプログラムの開発はとても手軽にできちゃいますので、ぜひともたくさん作ってみてほしいと思います。

まとめ

本記事が完成した時は既に try! Swift の開催から2週間も過ぎたのですが、今年も多くの収穫があり、特に Ask The Speaker コーナーは今年自分初めて利用し、そこでアップル社の中の人ともお話ができてとても嬉しかったです。限られたリソースの中、アップルとしても Swift をより汎用的なステージに送り出そうとしているようですので、Swift 大好きな筆者としてもぜひこれから iOS、ひいてはアップルのエコシステム以外での Swift の活躍をお祈りしたい気分です。

そうだ。浜松、行こう。

これは、今年行ってよかったところ Advent Calendar 2017 3 日目の記事です。

ものすごい遅くなって大変すみませんでした。冬コミの原稿の進捗がかなり思った以上にやばくて、Advent Calendar の執筆が遅れてしまうことになりました。そしてどうせならついでに宣伝します。冬コミ 1 日目、12 月 29 日に、東キ-11b にて、自作 iOSフレームワーク「NotAutoLayout」の解説本:「レイアウトを、もっと Swifty に」を出します。表紙入れて全 48 ページで、当日現金価格 1000 円です。また、昨年と同じく一部電子マネーによる支払いも受け付ける予定ですが、対応する電子マネー及び電子マネー用の価格はまた後日発表いたします。

それでは、本編に入ります。

なぜ、浜松へ?

筆者は大学時代は宇都宮で過ごしていました。そういった意味では浜松に対してはある意味ライバル視な気持ちがあります。餃子の街として。

ところが、今年に「ガヴリールドロップアウト」というアニメがありました。とても面白かった。そしてそのアニメの舞台となっているのが浜松でした。聖地巡礼大好きな筆者として行かねばと思いました。

準備

準備と言えるほどの準備なんてしませんでした。いつもなら行く前に一応最低限の下調べして、どのシーンにどこが映ったかとかを把握した上で行ってます。でも今回はあまり時間がなかったので、とりあえず公式聖地巡礼 HP にも載っている「舞天島」こと「弁天島」に行くことだけ決めました。そして運転するのが大好きな筆者として、せっかくだからタイムズレンタカーのマツダロードスターを借りることにしました。初めて乗りましたけど、ロードスターはいいぞ

マツダロードスター

別にステマやってるわけではありませんが、マツダロードスターは本当にいい車ですのでここで少し場所を借りて宣伝してみたいと思います。そして「マツダロードスター」って名前なんか長いのでここからは海外名の「MX-5」を使います

意外と知ってる人少ないようですが、MX-5 は実は全世界で一番売れている 2 シーター 2 ドアオープンカーです。MX-5 がこれだけ売れてる理由は実はとてもシンプルで、馬力こそそんなに高くないものの、非常に高い操作性を持ち備えながら誰でも純粋な運転の楽しさを気軽に感じられ、日常の中でちょっぴりな非日常をリーズナブルな金額で味わえられる車だからです。200 も行かない馬力しかないですが、たった 1 トン程度の重さに、完璧たる 50:50 の前後比重、そしてスポーツカーの王道である FR 駆動方式、ダントツな助手席に彼女を載せたい車 No.1 間違いなし(筆者調べ)です。(なお彼女(ry

そんな MX-5 ですが、MT 車もタイムズレンタカーで取り扱っており、興味ある方はぜひ一度借りてみてはいかがでしょうか?以上宣伝です。

f:id:elhoshino:20171225152246j:plain
今回借りた MX-5 です

弁天島

弁天島はガヴドロでは主にいわゆる「海回」の第 4 話で登場した舞台です。天使と悪魔たちの楽しい楽しい海でのお話です。混ざりたい。

f:id:elhoshino:20171225154049j:plain
駐車した MX-5 に、弁天島のあの有名(?)な鳥居
f:id:elhoshino:20171225154605p:plain
参考にアニメに登場したあの鳥居
f:id:elhoshino:20171225160759j:plain
弁天島の海辺
f:id:elhoshino:20171225154734j:plain
現地のお店にもガヴドロのポスターが貼られたりしてます
f:id:elhoshino:20171225160330j:plain
というわけで入ってみた

浜松市

せっかくなので一応市内にも行って来ました。駅の観光案内所にもガヴドロの巡礼マップ配布してると聞いたので(ry

f:id:elhoshino:20171225161731j:plain
ヴィーネちゃんが律儀に 2 時間も待った場所
f:id:elhoshino:20171225161912p:plain
アニメ
f:id:elhoshino:20171225161934j:plain
原作
f:id:elhoshino:20171225162228j:plain
観光案内所からもらったガヴドロ聖地巡礼マップ
f:id:elhoshino:20171225162601j:plain
一応ライバル心燃やして夕飯餃子頼みました。

以上、短くて何も伝えなかったが浜松でした。今度チャンスあるときに是非ともまた行きたいです。夏に。できれば彼女と(ry

そして、新しいゲームを。

ブログ開設して早々、2 記事目でいきなり転職記事を書くのも、転職記事書くのにブログ開設した人除けば多分自分が最速なんじゃないですかね。

はい、今回は転職記事です。タイトルではわかりづらいですが。

ちなみにこの記事公開した時にはもうすでに現在いる会社の最終出社日が終わった頃になるはずですが、執筆している今現在は、TVアニメ「NEW GAME!!」最終回最速上映イベント終了直後です。

はい、色々と感無量です。とりあえずイベント直後は、両手が赤くなったくらい沢山拍手しました。キャストの方々が嗚咽しながら頑張って喋ってたの本当にこっちまで泣きそうでした。涙をこらえるの大変でした。

NEW GAME! について

現在の会社を詳しく説明する前に、まず NEW GAME! という作品について触れてみたいと思います。

ご存知の方も多いかと思いますが、最初は「今日も 1 日がんばるぞい!」という 1 コマでなぜか大ブレイクし、原作者の得能正太郎先生もこのブレイクに驚きを隠せなかった芳文社さんが出版した 4 コマほのぼの社畜漫画ですが、そのブレイクを皮切りに TV アニメ化をはじめ、ラジオやゲーム化などのメディア展開がされており、多くのファンの心を掴みました。

そんな素敵な作品に、筆者がゲーム化作品の NEW GAME! -THE CHALLENGE STAGE- にちょっとだけ参加できたのは、本当に今までで指 5 本入るくらい嬉しかったことです(小ネタ挟むとプログラマにとって指 5 本では 32 まで数えられるがここは普通に 5 を指します)。なぜかこの作品は、自分と重ねられてしまう部分が沢山あります。まず自分も大卒とは言え一応新卒で憧れのゲーム会社に入り、原作でリーク情報の回を読んだ時ちょうど会社も同じようなリーク事件が発生してしまい、そしてその直後に東京ゲーム展の話が出てきますが、アニメでこの回を放送した週は自分も青葉ちゃんたちと同じくビジネスデーの企業パスでゲームショウに行き、他にも色々業界ネタで胃が痛くなった挙句、まさかアニメ 2 期が終わる頃に、自分も会社から退職するとか、この 2 年近くを振り返ってみると本当に感慨深いです。

では、このゲームに自分はどういう風に参加したのかというと、まあクレジットはアシスタント P という肩書きで載せていただきましたが、やってたことは主に収録への立会いで「ここはこうして欲しい」とか「ここ誤字あったので後でスクリプト直そう」とかの仕事をします。アニメの 1 期をご覧になられた方でしたら青葉ちゃんの収録の立会いの回を思い出すかもしれませんが、まさにそんな感じです。もちろんそこには自分だけでなく、音監さん以外にも立会いの人が沢山います。ですので自分のやったことは他のスタッフの方々と比べると本当に「ちょっとだけ」です。他にも一応ゲームの制作定例会議には出席しておりましたがまあそんな大したことはしてません。なので本当にクレジットに乗せていただいてとても恐縮でした。それでも「移植」や「多言語展開」ではなく、「原作ゲーム」では初めて自分の名前がクレジットに載ったので、ものすごい嬉しかったです。そして私に「史君好きそうだから参加してみない?」と声をかけてくださった木村 P には本当にしきれないほど感謝しています。おかげさまで本当に入社して一番楽しかった 1 年ちょっとを過ごすことができました。

もちろん、アニメと一緒に成長してきた fourfolium の皆さんの輝かしい姿も、上から目線に見えるかもしれませんが見ててとても嬉しかったです。繰り返しになりますがそんな NEW GAME! の TV アニメ第 2 期と一緒に、八神さんと同じように私も会社から退職してしまうなんて、感慨深すぎてどんな言葉でも今の私の気持ちをうまく表すことができません。

現在の会社について

上記の紹介でもう気づいた方もいると思います(というより筆者を知ってるなら知ってるはずです)が、私が今いる会社は、STEINS;GATE とか、古い作品ですとメモリーズオフとかを作った MAGES. という会社です。ゲームのブランド名 5pb. Games. の方がもしかすると比較的に知名度高いかもしれません。いろんなご縁があって、まさか自分が憧れな会社で働くことができるなんて思ってもみなかったから本当に嬉しかったです。そして入社した後も、たくさんの先輩にご迷惑をかけながらもいろんなお世話になって、自分にとってかけがえのない4年間でした。

ところが気づいた方もいるかもしれませんが、筆者は iOS のネイティブ開発者です。なのになぜコンソールゲームの開発会社にいるかというと、これはまたねねっちと同じような「コネ入社」です。最初はメモリーズオフiOS 版移植などを作った Mtrix という会社でバイトをしてましたが、ちょうど卒業する頃に色々と事情があってほぼ新卒で MAGES. に入社することになりました。しかも入社当時は筆者はプログラマではなく、iOS 移植のディレクターとして入社したのです。そもそも筆者はその時 iOS 開発経験なかったし、プログラミング経験と言っても中学校で BASIC をちょっとだけ独学したのと、大学で C 言語入門の授業を取ったのと、卒業研究でバリバリ CUDA やっただけです。なので最初は自分の仕事はただ単に「ここはこうして、あそこはああして」などの指示を実際の移植開発会社に伝え、そして出来上がったものを確認すると言った感じの仕事でした。

そして時は 2014 年 6 月に移り、この時に何があったかというと、アップルがその年の WWDC を開き、iOSmacOS 開発のための新しい言語 Swift を発表したのです。そしてちょうどこれと同じくらいのタイミングで、社内の方針転換により、移植プロジェクトを内制でやることになり、自分が iOS 開発者になったのです。

最初の頃は本当に大変でした。社内に他に iOS 開発者もいなかったので、話が聞ける先輩もいなければ、当時 Swift がまだ beta 版だったこともあって何かあったとしてもそれが Swift の問題なのか自分の問題なのかも神のみぞ知るでした。でも「まあとりあえず何か作ってみようよ」という非常に曖昧、言い換えれば自由なオーダーのおかげで、本当に色々と自由に研究することができました。昔の移植開発会社が作った iOS 移植作品のソースコード参照しながら Swift でそれを書き直してみたり、参考書を買ってきて何かしらのアクセサリーアプリを作ってみたり、話が聞ける先輩がいないことも言い換えればなんでも自己裁量でやってしまうことができました。自慢になってしまいますがその 2 年間は凄まじい成長ができた自負があります。iOS 開発の勉強会の常連にもなって、登壇して初心者たちにアドバイスすらできるくらいになったのです。

ですので、言い換えれば、今回転職することができたのも、本当に今まで自由にやらせてもらったおかげで圧倒的成長ができたから他ありません。なので今の会社にも当然とても感謝しております。

感謝といえば先ほど木村 P の話出てきましたが、他にも松原 P にもたくさんお世話になりました。私の「将来プロデューサーになりたい」の一言に、「このコンシューマ化企画もし通ったらとりあえずまずディレクターからやってみない?」と声をかけてくださったのが松原 P でした。残念ながら最終的にその企画自体がボツになってしまいましたが、やりたいことがあればなるべくそれを叶えようとしてくださるプロデューサーさんたちに本当に感謝極まりないです。

ちなみにちょっとずれた話になりますが、先ほどのクレジットの話にも出てきましたが、「移植」や「多言語展開」ならすでに何回か自分の名前をクレジットに載せたことがあります。「移植」は当然ディレクターの経験あったからですし、「多言語展開」は一部作品の中国語版や英語版の翻訳マネージメントも担当したことがあったからです。なので実は今の会社で iOS 開発以外にもいろんな仕事経験があります(一番レアでアレな経験は 1 回だけ音監も担当したことありますがそれはまた今度機会あれば話しましょう)。

ならばなぜ転職するのか

NEW GAME!! 最終回では、八神さんの退職理由は「海外に行ってもっとたくさん勉強したい」だということが明かされました。これは自分の転職理由の一つでもあります。確かに今まで好き勝手にやらせてもらった結果圧倒的成長ができたし、一人でなんでもこなしてきたから並みの iOS 開発者よりは圧倒的広い分野を経験してきたかもしれません。ですが今の環境ではとうとう天井が見えてきました。自分の成長できる限界が見えてきました。八神さんが今まで以上に成長するために海外行くことを選んだのと同じように、私も違う会社に転職して、もっと違ったたくさんの刺激を受けることを選びました。

ただ、転職理由はこれだけに尽きる、というのはあまりにも絵空事すぎです。残念ながら現実は NEW GAME! みたいに、職場に行ったら全員可愛い美少女なわけありませんし、人々が転職する理由も八神さんみたいに前向きな理由だけってわけでもありません。自分も同じく、もちろんさらなる成長をしたいというのも大きいですがそれだけではありません。もう一つ大きな理由があります。ズバリ給料です。

NEW GAME! をご覧の皆さんでしたら大体想像はつくかと思いますが、青葉ちゃんは新卒で給料が低くても実家通いのため家賃の負担がなく、比較的に楽な生活ができますが、すでに何年か経験がありながら部屋借りてるはじめさんはそううまくいかず、欲しいフィギュアを買うのにもたくさん躊躇って最後「仕事にも使うから」と自分に言い聞かせてようやく決意ができるのです。筆者も同じような感じです。ただ違うのは、自分の仕事はゲーム製作に直接な関係が薄く、あくまで iOS ネイティブ開発です。なので結局最終的に会社との需要と供給のミスマッチもあって、会社にとっても私が扱いづらく給料を上げにくいし、私にとっても給料が少ない上やりがいを感じにくいです。

そして転職に振り切った決定的な理由がもう一つあって、それは開発スタイルの違いです。

弊社はあくまでコンソールゲームの開発会社であり、SDK 非公開で、資料やノウハウは基本社内開発陣のみに共有されている非常にクローズドなコンソールゲーム開発と、SDK 公開の上毎年公式非公式たくさんのカンファレンスや勉強会があっちこっちに開かれ、資料やノウハウもネットでたくさん公開されておりとてもオープンなスマホアプリ開発とでは空気が全然違います。先ほど説明した通り私はそもそも iOS 開発者になった時他に話聞ける先輩がいなかったので、勉強会やネットの資料がとても手助けになりました。その代わり、知らずうちに社内の開発チームとはとても空気感の違う開発スタイルになってしまいました。そういった空気感の違いがだんだんストレスにもなり、それがきっかけで「むしろ転職すべきでは」と初めて転職すべき理由を考え始めました。

次の会社はどんな会社か

有休消化もありますので、ちょっと時間空いてしまいますが 11 月からゆめみという会社に正式入社することになります。主な仕事は受託開発の会社ですので、実は面接の時も人事の方に「自社サービスの会社に入りたいので正直に申し上げますと御社は第一志望ではありません」と馬鹿正直な告白をしたのですが、人事の方からの「でも逆に言うと弊社に来ると転職せずにいろんな業界の仕事が体験できるよ!」との言葉がとても刺さっており、それ以外にも勉強し放題などのユニークで面白そうな社内制度がある上、自分が言い出したたくさんのわがままな条件を全部受け入れてくれて一番最初に内定を出してくださいました。執筆時点ではまだ入社手続き等も終わっていないので具体的な感想はまだありませんが、とても面白そうな会社だと思いますし、レベルもとても高い会社(のはず)なのできっとここでならさらなる圧倒的成長ができると思います。そして、次のステージへ向けた、新しい社畜キャリアという名のゲームへの第一歩になることを祈ります。

これから就活/転活する人へ

SHIROBAKO を見てアニメ業界を志望しました、これが声優!を見て声優業界を志望しました、そして NEW GAME! を見てゲーム業界を志望しました、と言った方々がたくさんいると思います。そんな方々に一言だけアドバイスをするのでしたら、「この業界は、人々に夢を見せるのが仕事であり、自分が夢を見てはいけません」。もちろん、夢があるのはいいことですし、この言葉も別に何も「この業界では夢が叶いません」なんて意味ではなく、あくまで「毎日夢ばかり見てそれを行動に移さないというのはダメ」です。むしろ宮森さんや青葉ちゃんたちの輝かしい姿を見て、自分も同等以上の努力をせねばならないと考えなくてはいけません。なにせ、この業界は作品で描かれているように甘くありません。

そして、この業界を志望しなくても、一番憧れの職につきますように。