Voice User Interfaceとかウェアラブルデバイスとか

最近、Amazon Echoをよく使ってます
あと、この記事を書いている昨日にApple Watch(Gen3)が届きました(今日、学校に着けて行った)

ちょっと前にバズった(と思ってる)VUIとウェアラブルバイスというやつですが、今はそんなに話を聞かなくなりました
まぁよくある

  1. 革新的なものが出る
  2. バズる
  3. あれ?これ実はそこまで良くないのでは?
  4. 廃れる

の流れだと思いますが、世の中そんなもんだと思います
(むしろ未だにAIだのシンギュラリティだの言われ続けてるのがめっちゃ不気味に感じる、怖い)

ただ、自分も「ウェアラブルバイス?何ができるの?」「VUI?精度とかどんなもんなの?」と思ってたんですが、 ここ半年ほどで意見が変わったので、それについてちょっと書きます

VUI

Amazon Echoはかれこれ半年ほど使ってるんですが、2ヶ月ほど前にSpotifyに登録してからめっちゃ使うようになりました
もともとAmazon Music使ってたんですが、色々あってSpotifyに乗り換えました

SpotifyはUXがすごくて、ただ音楽を聞いてるだけなのにめちゃくちゃ楽しくなる素晴らしいサービスと思っていて、 今まで使用したサービスの中で一番すごいと思うサービスを上げてくださいと言われたら、SpotifyとG SuiteとSoundCloudを上げます

そんな感じでSpotifyに引かれるようにAmazon Echoを最近よく使うようになったんですが、音楽を聞く以外にも

  • 今日の天気を聞く
  • アラームをセットする
  • ちょっとしたtodoリスト
  • ラジオを聞く
  • 上田麗奈の時報

とかでEchoをよく利用してます

「いや、天気もアラームも全部携帯でできるじゃん」…はい、それはそう
そうじゃなくて、それを声だけで操作できるのがいいんですよ

部屋でコード書いてるときに、

(小腹空いた…コンビニ行くか…あ、でも外寒いかな…)
「(コードを書きながら)Alexa、今日の気温は?」
『今日のxxxの気温は…』
(うーん、寒そうだしいいや)

というのができます
もしこれが携帯なら、確実に一度作業を止めないといけません

まぁこれはあくまで一例なんですが、こういった「何かをしながら、ふとちょっと気になったこと」というのをやるのに声というのは本当に向いてると思うんです
すごく細かいことではあるんですが、こんな細かいこと一つ一つが楽になると、ストレスがすごく減ります
「そんな細かいこと…大して変わらんでしょ」と思ってる方、自分もそう思ってましたが全然変わります

精度に関しては、人間的な柔軟さを求めなければ大丈夫なレベルと思います
少なくとも、半年ほど使った今まで誤検知とかはないです(サードパーティ製のアプリはたまに聞き間違える)
そもそも、音声ユーザーインターフェースであって会話志向インターフェースではないんですよね、VUIって

「コマンドを音声で認識させて操作するもの」という捉えると、VUIは日々の細かなストレスをなくしてQoLを上げてくれる素晴らしいものと言えると思います

ウェアラブルバイス(というかApple Watch)

こっちはこの記事を書いてる今日この一日Apple Watchを使っただけなのでかなり薄っぺらいんですが…
とりあえず「腕を見たら時間が分かるのはめっちゃ便利」と思いました

あと、携帯への通知を腕に振動で伝えてくれるので、通知の見逃しが格段に減るなぁという感じ
運動量や消費カロリーを出してくれる機能は「まだ22だし適当に生きてても体調崩さないしなぁ」という
あ、今聞いてる音楽のタイトルが腕見るだけで分かるのはすごい良いなと思います

これらも「別に携帯でできるじゃん」案件なんですが、さっきのVUIの話もそうですけど「こういった細かいことを、より容易にできるようにする」っていうのは、小さいようで実はすごい便利に感じました

で、何が言いたいの?

極論、今の御時世なんでもスマートフォンがあればできると思うんです
ただ、スマートフォンは超汎用デバイス的なところがあって、細かいケースでストレスを感じることが多々あります
そういう細かいことをストレスなくできるようにすることで、全体として充実した生活につながるのかなぁとか思いました

VUIもウェアラブルバイスも「できることはスマホと変わらんが、特定のケースにおいてスマホよりほんのちょっと便利」というものって感じだと思ってます
こういった「細かいことを、よりストレスなくできるようにする」というのは、なんでもスマホだけでできるようになった今、とても重要なポイントなのかなぁとぼんやり思いました

待って!そのデプロイ本当に大丈夫?✋

全国100万人のエンジニアの皆さんこんにちは、デプロイしてますか?
この記事は、本番環境でやらかしちゃった人 Advent Calendar 2019の5日目の記事です

予想以上にこのアドベントカレンダーが注目されてて、書きながら「これ炎上しないよね…」「なんかマズイこと書いてないよな…」と胃が痛くなってます
自分みたいなザコメンタルにはつらい…めっちゃやむ…

この記事はただの不注意が原因のやらかし話です
過度な期待はしないで下さい

追記

さすが3000人以上に購読されてるアドベントカレンダー、アクセス数がすごいことになってますね…怖い…

いくつかコメントや言及を頂いたので、追記というのをしておきます

  • テスト環境ないの?
    • あります
    • タスクAに関してはテスト環境での動作チェックが不十分だった
    • タスクCに関しては焦ってて動作確認せずに出しちゃった(「まぁこれくらいの変更なら大丈夫でしょ」というやつ)
    • あと、アクセスの数%だけが来る本番とは別の本番環境なんかもあるんですが、タスクAのエラーはここでは引っかからなかった
  • CI環境ないの?
    • あります
    • タスクAに関してはテストは通ってたので、テストが十分でなかったということになりますね
    • タスクCに関しては焦ってて(ry
  • レビューした人がマージすれば/デプロイ担当の人を用意すれば
    • これに関しては「うーん…」って感じですね
    • 1日に数十回のマージ/デプロイが走ってるので、それをやろうとすると担当の人の負荷がすごいことになりそうです
  • レビュー通ってないpull reqはマージできないようにしないの?
    • これが本質な気がしてきた
    • 説明するのが面倒&本質じゃないので省いたんですが、実は使ってるのはGitLabなのでpull reqestじゃなくてmerge request
    • GitLab、調べたらapproveもらわないとmergeできない機能は有料版しかないみたいですね
    • うちはどうやら無料版(GitLab Core?)を使ってるみたいです
      • とはいえ、再発防止という面では「システムを改善する」という方向のほうが大事ですよねー
      • お金が絡むのですぐには無理ですけど、ここは改善すべき点ですね

背景

  • いわゆるWeb系のサービスをやっている会社
    • PHPとかRubyとか (この記事ではPHP)
    • 落ちたりするとTwitterで騒がれるくらいには大きいサービス
  • 自分はフルリモートでアルバイト中
    • 自宅と会社が400kmくらい離れてる
  • デプロイは1日に数十回走っている
    • 基本的にpull req出した人がマージ&デプロイ
    • masterへのマージと本番へのデプロイは基本的にセット

アルバイトでもドンドン挑戦させてもらえる素晴らしい環境だと思います

事案発生

  • その日、2つのタスク(タスクA, タスクB)を進めていた
  • タスクAの実装が完了して、pull reqを出してレビュー依頼
    • これは罠で、稀に特定のパターンでエラーとなることが後で分かった
    • PHPUnit通ってるし大丈夫でしょ」←大丈夫ではない
    • 単純に動作確認が足りてなかった
  • その後タスクBの実装も完了したので、こちらもpull reqを出してレビュー依頼
    • こっちはちゃんと動作するコード
  • レビュー待ちの間に、以前やっていた別のタスクCの後処理をポチポチ
    • かなり大きいコード削除をやって、その後変なところでログが上がってないか確認するという感じ
    • タスクAは、その以前やっていたタスクCの続きだった ←これが後の<やらかし>の遠因に
  • タスクC絡みの変なnoticeが少し上がっていたので、直してpull reqを出した
    • これも罠で、プログラムとしてそもそも動かないコードだった
    • 「ちょっとnotice解消するぐらいだし、大丈夫やろ」←はい慢心
  • レビュアーがタスクBのpull reqのレビューOKとのことで、そのままマージすることに
  • ここでタスクBのははずが、間違えてレビュー通っていないタスクAのpull reqをマージ→デプロイしてしまう
    • この時、エディタ3つとブラウザ2つのウィンドウが開いていてごっちゃになっていた
    • そう、タスクAのpull reqは特定のパターンでエラーとなるコードです
    • 直前に関連するタスクCをやっていたのも混乱の原因に
  • 大量に上がるエラー、急いでrevert&rollback
    • この時点では、マージするpull reqを間違えたと気がついていない
    • ここで気がつけばまだ「間違えました、すいません」で済んだ(と思う)
  • 焦って「次こそは大丈夫」とぶっ壊れているタスクCのpull reqをマージ→デプロイ
    • ここでもマージするpull reqを間違えていると気がついていない
  • さっきより酷い状態に
    • 荒れ狂うエラーログとアラート
    • 数分間、関連サービスがすべて500エラーで真っ白になる
    • ここで自分の頭も真っ白になる
      • 半泣きになりながら、とりあえずrevertしてrollbackはした
    • 普通ならここで周りの人に助けを求めるのが正解だと思うが、フルリモートなので周りには誰もいない

全部revert&rollbackして、落ち着いてゆっくり振り返りながらエラーを修正して後日改めてやり直しました

なぜ起こったか/二度と繰り返さないために

  • 自分のキャパシティを超える量の並行作業
    • 複数のタスクを受け持つのは良いけど、順に一つづつやろう
    • ただでさえ自分は凡ミスが多いのに、そんなことをしたらダメになるのは当たり前
  • 作業する際は、関係ないウィンドウを閉じよう
    • 単に作業領域の整理整頓をちゃんとしようという話
    • 「後で見るから…」はだいたい見ない、今見てないなら一旦消す
    • ブラウザのタブは後で履歴から開けばいいし、最近のエディタは開いたら以前のタブを復元してくれる
  • 待って!そのデプロイ本当に大丈夫?✋
    • マージするブランチ間違えてない?
    • デプロイ先間違えてない?
    • それ本当に意図した操作?
  • やらかした後は、落ち着いてちゃんと確認を行う
    • 焦ったらアウト、とりあえずrollbackして深呼吸
    • これ以降、デプロイ前後に小休止を入れるようにした

今回は1つ1つは些細な要因だけど、組み合わさって大変な事になりました

  • 操作ミス
  • 確認忘れ
  • 焦り
  • 慢心

あと、フルリモートなので周りにヘルプを出せないのもつらいですね

これを機に、いかにミスなく効率よく仕事をこなすかというのを少し意識するようになりました
プログラミングとは違うと思うんですがこれも立派なエンジニアリングですし、こういう「仕事をちゃんとこなす」というのは面倒だけど大事ですよね

最後に

事故は誰にでも起こりえます
皆さんお互いに気をつけましょう

明日はsoh1945さんのやらかしのお話です
「おとぎの国のデスマ中に起こった事を少し」とのことですが、人間は焦るとやらかしがちになるので気をつけたいですね
どんなお話か楽しみです

フルリモートでバイトをしていて感じること

前置き

今年(2019年)の春から、今のバイト先でバイトしています。
住んでるのは大阪で、オフィスは東京なのでフルリモートです。
かれこれ4ヶ月ほどたったので、その間に感じたことや今感じていることを適当に書いていきます。

環境について

会社は結構大きな自社サービスを持ってる、いわゆるWebの会社です。
仕事内容も当然Web系。(今の所、主にPHP)
古いコードのリプレースや、バグを潰したり、テスト回り直したり、またテストツールや静的解析ツール導入したりとかしてます。
(コードの品質を上げていくお仕事と認識してます)

会社から良いパソコンを支給してもらったりもしましたし、お給料も仕事の内容も不満はなくとても居心地が良いです。

リモートでよく言われることについて

進捗の確認や管理が大変

直接的な仕事の内容に関しては全くそんなことないです。
というのも、メンターの人からタスクをもらって、もしくはタスクを見つけて、自分はできる時間にそれをこなすというスタイルでやってますが、 今の所それが自分に合ってるのかなと言う感じです。

ただし、直接的に仕事に関係がない点。
例えば勤怠の管理や、本当に仕事しているのかの確認という点に関しては若干不安があります。
今の所、勤怠や「本当に仕事しているのか?」という点に関してはすべて自己申告なので、実はサボろうと思えばなんとでも出来ます。
いや、しませんが。

そこに関しては、おそらく自分のことを信じてくれてるんだなぁと感じるので、それに応えられるように頑張ってます。

自分のモチベーション管理が大変

ないです。 全くないです。

もちろん「そもそも働くのは嫌だ/苦痛だ」という大前提がありますが、それは仕事なので言っても仕方ないです。
ちゃんと自己申告した労働時間分はきっちり仕事しますし、働けなかったら後からちゃんと時間を引いてます。
自分的にはそれは当たり前という認識なので、そういう点に関しては特に不満や問題はないです。

もちろん、働かずにお金もらえるならそれに越したことはないんですが。

目指せ不労所得

孤独を感じるって聞いた/コミュニケーション大変そう

めっちゃ寂しいですし、コミュニケーションもけっこう大変です。
仕事は、家にいるなら自室かリビング、学校にいるなら研究室でしてるんですが、正直めっちゃ寂しいです。
頼めばHangout等で通話を繋ぐことも出来ますが、常時繋ぐのもなんか違うなぁと思うので…。 (どうしても文面だとやり取りが難しい時に通話を繋いでもらったりはする)
「自分はこの組織に属してるんだ」という一体感を得られるのがSlackしかないので、Slackにはめっちゃ張り付いてます。

また、コミュニケーションにかかる時間が長いという問題があります。
接点がSlackしかないんですが、Slackでメンション飛ばしても返事が来るのが10分後…とかザラ。
ちょっとした質問にもかなり時間かかったりしますし、待っている間は「相手が今どんな状況か」「そもそも今ってPCの前にいるの?」とかが分からないですし、とても不安になります。
とはいえ、そこは「リモートだししょうがない」と割り切って、心とスケジュールに余裕を持って動くことで今の所乗り切ってます。

つい最近に東京のオフィスに行く機会があったんですが、その時に

  • 自己紹介をしたら「あ、いつもSlackで見る人だ」と言われた
  • 「Slackでよく見かけるけど、誰か全く分からなかったので会えてよかった」と言ってもらえた
  • 「よくSlack見かけるので社員かと思ってた」と言ってもらえた

ということがあって、めっちゃ嬉しかったです。

僕は一人じゃなかった…

心がけていること

基本的に、リモートで働くのと普通に働くのとは勝手が違うというのを常に前提として動いてます。
そもそも普通にオフィスに行って働いたほうが円滑だと思いますし。(それはそう)
あと、相手と自分は居る環境が違うというのも常に意識しています。

なので、

  • 省略せずに、冗長でも正確に言う/聞く
  • わからないところは聞く
  • やり取りに時間がかかるのはしょうがないと割り切る

といった点を頭の中に入れて仕事してます。

後は、Slackの通知は常に受け取れるようにしてます。
唯一の接点がSlackしかない以上、そこが切れると連絡が取れないという事態に陥ります。
なので、後述しますがベッドでぼーっとしてる時や音楽を聞いている時もSlackにはすぐに反応できるように心がけています。

リモートで良かった点

普通にバイトするんだったら絶対に無理なことができるのが最高です。

10時から働く予定を入れている時に、9時55分に起きて何か食べながら仕事を始めるという超怠惰ムーブが出来ます。
また、自分はお風呂と睡眠が好きなので、バイトが終わったら即風呂に入ってさっぱりしたり、即布団に入って睡眠が出来たりします。
最高。

後は、他の人の作業を待ったり、Slackでメンション飛ばして返信待ちの時間とかに、家事したりちょっと休憩したり出来ます。
もちろん他の仕事があるときはそっちをやるんですが、ちょっとしたリフレッシュができるのでとても良いです。
テストを回している間の待ち時間(5分くらい)はベッドに寝転がってTwitter見たりぼーっとしたりとか。
なんならベッドの上で仕事出来ますし、外出先でちょっと仕事の続きをやるというのも出来ます。 (社外秘の情報等、そのへんの管理はもちろん気をつけないといけないですが)

あと、自分は音楽や声優ラジオも好きなんですが、自室で好きな音楽や撮り溜めてたラジオを聞きながらやる仕事はとても捗ります。

これから

リモートで働くというのに慣れてきましたが、そういう時に限って何か問題が起こるものです。
なので、メリハリをしっかりして集中する時はちゃんと集中して働かないといけないなぁと思ってます。
まぁリモートとか関係なく当たり前ですが…。

実際に、仕事に慣れてきた時に凡ミスでサービスを全部止めてしまうというのをやってしまったことがありました。
あれはめっちゃ焦った。
もう二度としないよう心がけてます。

なにはともあれ、ちゃんと働いてしっかり貢献していけたらいいなぁと思ってます。

2019年7月18日

11頃にTwitterでニュースを見た。 その時はまだ、少し心配する程度でそこまで大事だとは考えてなかった。

その日は家でリモートでバイトをしていた。 なのでガッツリとTwitterに浸るわけにも行かず、休憩中にちょくちょくTLを眺めてた。 TLに少しずつニュースが流れてくる。 死者が出たという話を、確か15時頃に見た。 だんだんと嫌な感じがしてきたのを覚えている。

夜は京都のクラブでDJをする予定だったので、バイトを切り上げて電車で京都へ向かう。 電車内でTwitterとニュースを見ていた。 そのときには、すでにたくさんの死者がいるらしいことが報道されていた。

乗り換え駅につく頃だった。 ニュースで「10人以上の遺体が2階で並んで横たわっていた」という文面を見かけた。 その時、自分の中で何かが駆け巡って、いても立ってもいられなくなった。 あんな良い作品を作る人達がこんな最期を迎えるなんて酷すぎる。 どんな思いで最期を迎えたんだろう?どんなことを最期に思ったんだろう。 どうしてなんだ。

電車のドアにもたれかかりながら、生まれて始めて眼の前が真っ暗になって倒れそうになるという経験をした。 でも自分は部外者でただアニメが好きなだけだけのオタクで、頭の中では無関係なんだから怒るのは門違いと分かっていてた。 分かってる。 部外者がどうこう言うことじゃないし、変なことを言って炎上するのも嫌だ。 けどやっぱり悲しいし、許せないし、悔しい。 色んな感情が浮かんでくる。 考えていることと感情がバラバラになって気持ち悪くなって、駅につくなりトイレに駆け込んで吐いた。

別に「ご冥福をお祈りします」とか「犯人は絶対にゆるさない」とか、そういうことが言いたいんじゃない。 いや、もちろん、今回被害に合われた方々や亡くなられた方々には心よりお悔やみ申し上げます。 また、犯人には法の下に正当な裁きが下されるべきだろう。 (まぁよっぽどのことが無い限り死刑だと思う)

ただただ、あんな綺麗な作品を作る人達がこんな最期を迎えたということにただただショックを受けていた。 今も感情の整理がつかず、いろんな思いが浮かんでは消える。 自分の感情が分からない。

何故たくさんの人があんな死に方をしないといけないんだ。 しかも、まだまだたくさんの素晴らしいものを作れる人達が。 ありえない。 訳が分からない。 こんな酷いことがたった一人の人間によって起こされたという。 どうして? 何があったの?

おそらく、今後5〜10年は影響が出るレベルの惨劇だと思う。 いや、もしかしたら二度と以前のクオリティの素晴らしい作品は出てこないかもしれない。 たった一度の、たった一人の人間の仕業によって。 自分はあの会社が作る綺麗なものを、もっともっと見たい。 いや、見たかった。 もう見れないかもしれない。 また気分が悪くなってきた。

3年間働いたバイトをやめて、就活を終えた話

この記事は何

いわゆる、退職エントリと就活の記録の両方が合わさった話です。

3年間働いたバイトをやめた話

退職エントリです。 ちょうど、この記事を書いている今日が最終出勤日でした。

就活支援やキャリア支援のサービスをやっているベンチャー(以降、S社)でバイトをしていました。 自分のツイートを普段から見てる人は知ってると思いますが、賃金が大阪府最低賃金(2019年4月現在、936円)でその点は非常に不満でした。 が、それ以外は自由かつ柔軟で非常に働きやすい会社だったと思います。 おそらく、これはバイトとして働いていたからであり、実際に正社員として働いているとまた違うと思いますが…。

勤務日の前日に急に「明日休みます」と言って普通に通りますし、逆に「明日行けるようになったんで行きます」とかも柔軟に対応してもらいました。 また、勤務中も堅苦しくなく良い雰囲気でのびのびと働けましたし、実際の仕事に関しても与えられた仕様に対してどんな実装方法でも良いといったレベルの裁量をもらっていました。 そのおかげで、自分の好きなように使いたい技術を投入することができ、とても楽しかったです。 (本当に、給料さえ上がれば...)

また、S社はいわゆる「エンジニアリード」といった雰囲気ではなく、むしろ体育会系の営業さんが強い会社でした。 が、営業さんたちが無理やり押しかけてきてラグビーをする…という雰囲気ではなく、ある程度の良い距離感をもって仕事ができていたんじゃないかなと思います。 決して「今を時めくイケてる会社」という感じではなかったですが、のんびりと好きなことができる、自分的にはすごく良い会社でした。

S社に入ったきっかけは大学入学時まで遡ります。 ちょうど大学に入ってすぐの頃、DMで「梅田でエンジニアのバイトしませんか?」というめっちゃ胡散臭いメッセージが飛んできました。 自分はあんまり気にしない質なので「まぁ話は聞いてやろう」という感じで実際に話を聞きに行き、そこで簡単な面接も行いました。 記憶が曖昧であんまり覚えてないんですが、確か即日で採用!って感じだったと思います。

S社で働き始めた時はデザイナーの方が一人居るだけで、正社員のエンジニアが一人もいないという状況でしたが、 1年、2年と経つ内にエンジニアがjoinして、自分以外のバイトも入ってきて、いつの間にかITチームが10人以上というそれなりの人数になっていました。

技術スタックも、最初はFTPで本番サーバに接続して…という状況から、Vagrantを使ったりDockerを使ったりして、WordpressからLaravelやrailsへといった感じで少しずつ良い感じに。 自分はサーバサイドをメインでやっていたのでサーバ側の話がメインになるんですが、次のプロジェクトはVue+railsでDockerでインフラ構築とかいう話でした。

そんな感じなので、「1からサービスの技術面の構築をして成長させる」という貴重な経験をすることができました。 この経験は本当に大きくて、のちに就活で話のネタとして生きてきます。

なぜそんな仕事をやめたかというと、やはり「これだけやったのに給料は最低賃金のままなのか」という不満点と、 就活を終えて内定先でバイトをさせてもらえる目途が付いたというのが理由です。 もし給料が順当に上がっていたら、他に不満が無ければ働き続けていたかもしれませんし、それでもやはり内定先でバイトをするという選択をするかもしれません。 給料が低かったという不満点はあるものの、それを差し引いてもいい職場でしたし、決してネガティブな理由のみではないって感じです。 ただ、就活を終えたし、会社的にも自分ができることはあらかたやり切れたのではないか…とキリの良さを感じたので退職を決意しました。

自分が言ったことをそのままやらせてもらったMさん、いろいろとご迷惑をおかけしたTさん、 最初期からずっと一緒に仕事をやらせてもらったYさん、バイトのオファーをかけてくれた先輩。 本当にありがとうございました。

就活を終えた話

就活記録です。

自分が就活らしいことをし始めたのは大学3回生の春頃で、Twitterにたまたま流れてきたサマーインターンに応募したところから始まりました。 当時は就活なんて全く考えていなくて、単に「お、なんか面白そうだし行ってみるか」というモチベで応募したのを覚えてます。 「なんや、GitHubのアカウント出せばインターン行かせてくれるのか」という感じでフォームに入力して送信したらそのまま通って、 2018年の夏インターンとしてピクシブさんとクックパッドさんのところでお世話になりました。 その時の記事はこちら

kiridaruma.hateblo.jp

kiridaruma.hateblo.jp

で、そんなこんなで夏を終えて、そこから秋ごろにかけて少しづつ就活を意識し始め、逆求人系のサービスに登録して逆求人イベントとかに招待されたりしました。 そこでいろんな企業さんのお話を聞いたりして、その中で中の人と仲良くなったりしてディナーに連れて行ってもらったり、インターンに誘ってもらったりしました。 そこから2018年11月の段階で志望先を決定、12月頃には内定が出そろって、そこから内定後インターンに行ったりして迷って考えて、 最終的に2019年3月末に受諾先を決定という感じでした。

面接やインターンでいろいろと企業の人とお話したりしましたが、よくTwitterで見かける圧迫面接やよく分からないマナーとかを求められたりはせず、 むしろ面接官の方と雑談してるような感じで話が進んで、そのおかげで「就活つらい」というのは全く感じませんでした。 しいて言うなら、自分は大阪に住んでいて、志望先はすべて東京の会社だったのでオンライン面談がちょっと面倒だったり東京に行かないといけないのがつらかったです。

書類等もESとかは書いたことがなく、やったことと言えばGitHubのアカウントとTwitterのアカウントを提出したくらいでした。 Twitterのアカウントが知られている状態だったので、インターンに行くとライブ円盤の鑑賞会に誘われたり、某ゲームの記念日にケーキを食べさせてもらったり…ということがあったりしました。

Twitterアカウントがバレてるので、もちろんうかつななことは呟けません。 が、自分は普段からうかつなことは呟かない超健全なTwitterアカウント運用をしているので無問題ですね。大丈夫です。

そんなこんなで、自分の就活は、いろいろと知り合いが増えて楽しい思い出という感じで終わりました。 みんながこんな就活をできるとは言いませんが、少なくとも自分よりも実力ある人はこれくらいの感じで就活できるのではないかなと思います。 決してつらいだけでなく、楽しい就活もあるんだよ(少なくとも自分はそうだったよ)というのを残したくて、この記録を書きました。

願わくば、誰かの就活の助けになれば。

理由あって、インターン!〜アカツキさんで2週間インターンした話〜

インターンに行ってきました

縁あって、アカツキさんのところで2週間インターンに行かせてもらいました。 この記事は、その成果報告と感想を兼ねた記録です。

「理由あって」というタイトルですが、そこまで深い意味はないです。

前日譚

別の機会で東京に来たときに、アカツキのエンジニアの方とイベントで知り合い、その縁でインターンとして2週間お邪魔しました。

aniben.connpass.com

ちなみに、その時やったLTです

www.slideshare.net

そこから自分の就活も始まって、色々と縁があって今回のインターンに繋がりました。

さて、アカツキさんといえば八月のシンデレラナインやサウザンドメモリーズといったオリジナルタイトルや、 その他にも共同開発で数々の大規模タイトルのゲームを開発している会社さんです。 ハチナイはアニメ化も決まりましたし、他にも自分が遊んでいるゲームがあったりします。

そんなところでインターンができるということで、ワクワクしながら準備したり色々調べたりしていました。

インターン

初日

自分の配属はある大規模ゲームタイトルのサーバチームに決定。 事前の面談で「実際にやる内容は当日に決めよう」ということだったので、 インターン初日に「じゃあ何をしようか?」というところからスタートです。 結果、現段階で出来そうなタスクの候補の中から面白そうと思ったものをやらせてもらえることに。

色々話し合った結果、タスクは

  • 検証用の環境のローカル化
  • 負荷試験を行うための環境の構築

の2つをやることになりました。

前半(1週目)

初日は事務手続きと開発環境のセットアップ、 2日目はコードを実際に読むだけといった感じでした。

インターンの前半1週間は、検証用の環境のローカル化をやっていくことに。 現状、サーバの検証は、AWS上に作られた検証用環境に検証用クライアントで接続して行っていました。 ただ、その場合だとサーバへの操作が思わぬ形で他の検証用クライアントに影響を与えてしまう可能性がある他、 複数クライアントが一斉に同じサーバへアクセスするので、何かあったときにログなどから原因をトレースしにくいと言う問題があります。

そのため、サーバ全体をコンテナ化して手元の PCで動かせるように調整と変更を行っていくことに。 現状、AWSの機能に依存した構成となっている箇所がいくつかあり、完全にローカルで動かすのは無理ですが、 とりあえず動かせる状態にすることが出来ました。 また、検証用コマンドを発行するための仕組みが必要とのことだったので、各種コマンドを打てる検証用ターミナルも作成。 実際に検証を行う方に使っていただいたところ、課題点や改善点もあったものの好評価をいただけました。

この手の、いわゆる内部ツールというものは直接的にユーザーさんには関係ありませんし、そもそも知られることもありません。 ただ、こういったツールのおかげで安定した質の良いゲームやサービスが成り立つわけで、外からの光が当たらないところとはいえとても重要です。 自分はこういった「地味で目立たないけど、裏から支える」という考え方はとても好きですし、 自分のスキル的にも働き出したらそういう箇所を担当することがほとんどでしょう。 実際にそういったツールを作って、色々と体験できて非常に良かったです。

休日

2019/3/9,10は、アイドルマスターシャイニーカラーズの1stライブがありました。 残念ながら現地ではないのですが、LVで参戦。 非常に良かったですが、ここでは「アイマス最高!」とだけ書いておきます。

その他、関東に住んでいる知り合いと色々飲みに行ったり、 同じ大阪に住んでる人と何故か東京で会ったりと、楽しい休日を過ごせました。 インターンくらいでしか東京に遊びに行ったりできないので、とても良かったです。

後半(2週目)

土日を挟んで、後半は負荷試験環境をECS上にCloudFormationを使って自動構築していくというタスクをやりました。 CloudFormationはAWS上のリソースやその構成をyamljsonで記述して、 それをもとに自動で環境の構築ができるというサービスです。 生のyamljsonをダーッと書いていくのはなかなかつらいですし、 そもそも大規模な環境となると大変以前に無理ってレベルなので、kumogataというRuby製のツールを使っていろいろやってました。

github.com

自分は趣味でVPSを借りてサーバを建てて、そこでDocker上で色々動かしたり、 最近はお試しでGAEとかGKEとかを触って「すげー」とかは普段やってます。 が、AWSをガッツリと触るのは初めてですし、個人とは全く違う規模の構成を見て実際に触ることも出来てとても楽しかったです。

細かい内容は内部的な話になるので書けませんが、 本番と同じインスタンスタイプのマシンを台数を減らして配置して、試験用に設定を変更した状態でデプロイを行う…という感じです。 既存の設定や構成を読んで手を加えて改良するというのは、好きまではいきませんが嫌いじゃないところなので、面白さと楽しみのあるタスクでした。

その他

ランチに誘ってもらったりして、色んなお話が聞けました。 あのゲームの「実は…」とか、あのイベントの「本当は…」とか、1人のオタクとしてめっちゃ面白かったです。

あと、オフィスがすごい綺麗でした。 自分は画像フォルダがオタクか肉/ラーメン/寿司の写真かクソリプに使える画像しかないという感じなので、写真は撮ってないです。 が、めっちゃオフィスめっちゃきれいです。 こんな環境なら快適に働けそうだなぁって感じでした。

最後に

前々から「大きなサービスのインフラってどんな感じになってるんだろう」というのが気になっていたので、 今回はそういったところに関わることが出来てとても良かったです。 また、決して表には出ませんが、検証ツールというとても重要なものの開発もできました。

すごく学びの多かった2週間であり、楽しい2週間でした。 期間中、様々な形で関わってくださった方々、ほんとうにありがとうございました。

なぜ自分がシャニマスにこだわるのか ~一人の技術者として、一人のアイマスPとして~

はじめに

ポエムです。 個人的に思ってることをつらつら書いただけです。

また、技術的な話のところは筆者の知識不足と、分かりやすさ重視から来る間違いや単語の誤用があるかもしれません。 話の大筋として合っているならご容赦ください。 また、明らかにこれは間違ってるという箇所があれば教えてください。

2018年2月7日、未来を見た日

前々からアイドルマスターの完全新作シリーズの知らせは告知されていましたが、この日ついに詳細が発表されました。 (自分は生配信は見れなかったので、タイムシフトで後から見ました)

「これは絶対流行る、シャニマスは既存のアイマスコンテンツと並ぶ大きなコンテンツになる」

そう確信した瞬間でした。

自分がシャニマスにこだわる理由

自分は一応、アイマスは全シリーズをザッと追ってるんですが、 特にシャニマスに関しては他のコンテンツとは少し違うこだわりがあります。

ここまで書いておいて何ですが、一人のオタクとして見ればシャニマスは数ある中の一つのアイドル系コンテンツです。 正直、今やアイドル系コンテンツはたくさんありますし、コンテンツ的にみればシャニマスは目新しい点は全く無いと思ってます。 今もそうですし、たぶん今後もそんな感じだと思います。

ただし、アイマスPとして見たときには少し変わってきます。 一人のアイマスPとしてのシャニマスは、アイマスの「定番」と「革新」を良い感じにミックスして、今までのアイマスとはまた違う、 まさに次世代を感じさせるコンテンツです。 そろそろサービス開始1周年と1stライブも控えている現在も、それ変わりません。

なぜそう思ったのかと細かいところを挙げるとたくさんありますが、例えばキャラクターのビジュアル。 今までのアイマスのキャラクターたちと違って、非常に線が細くて繊細かつ美麗という印象を受けました。 他には、例えばゲームシステム。 今までのアイマスの細かいネタや定番を拾いつつ、フルボイスかつ稠密なシナリオで魅せるという雰囲気を感じます。 自分がオタクとしてアイマスPとしてシャニマスを一言で表すなら「繊細」「美麗」「緻密」という単語を使います。

まさに、「シャニマスは文学」

また、シャニマスに関してはオタクとしてアイマスPとして以外に、一人のWeb系の技術に携わる技術者として、「未来」を感じています。

なぜシャニマスに未来を感じるのか

ここからはオタクとしてではなく、一人の技術に携わる者として話をしていきます。

突然ですが、この記事を読むのにどんな端末を使っていますか? OSはスマホならiOSAndroid、PCならWindowsmacOSだと思います。 ここでLinuxBSDなんかを挙げる人は「ソフトウェアの自由」の話は分かってると思うので回れ右をして大丈夫です。 (Androidも一応Linuxではありますが...)

例えば、急にMicrosoftが「WIndowsを使ってる人から、明日から毎月9万円取るよ」と言うかもしれません。 Microsoftが急にそんなことを言うとは思えないですが、まぁ可能性としてはあります。 理由はともかく、急にあるメーカーのコンピュータを使えなくなるとどうなるでしょうか?

今のところ、例えばiOSがダメならAndroidに移行という選択肢があるかもしれません。 ただし、これがWindowsならどうでしょうか? 間違いなく、世界中で大混乱が起きます。 それまで動いていたソフトウェアは一瞬でただの0と1の記号列になり下がり、 それに伴って影響範囲は経済、通信、情報...。 Windows上のソフトウェアを他の環境で動くようにしなければいけませんが、それには天文学的な資金と労力が必要でしょう。 おそらく人類的な損失になると自分は思います。

要は、日々便利に使っている端末やそれを動かしているOSは、単一の存在によって独占されると、 非常に危険な状態になりうる可能性があります。 それだけでなく、単一の存在によって独占されることによって競合がいないことから、 その存在の利益を優先して良くないことを企むかもしれませんし、 そうなればプライバシーを侵されたり、利益最優先の不必要で不便な機能を押し付けられるかもしれません。 全ての会社がそんなことを考えているとは思えませんが、基本的に権力や権益というのは時間がたてば腐ります。

ソフトウェアの世界ではここ40年ではありますが、そのような独占しようとする力と戦う文化があります。 自分もその流れにおおむね賛成です。 独占に対抗するには、ただ対抗するだけではなく、技術の力を用いて 「独占を許さない」「独占されにくい」「独占されても問題がない」 そんな仕組みを作る必要があります。 そして、その流れの中で誕生し、今もなお成長を続ける分野としてWebがあります。

普段何気なくしているTwittermastodonなんかのSNSや、AmazonNetflix、メルカリといったサービスは、 PCでもスマホでも、その端末が何であれ、そのOSが何であれ基本的に同じように動作します。 これは、Webの世界が「単一の存在に支配されないように」「支配されても大丈夫なように」と努力を続け、 事前に決めた技術的要件を守っている限り、どんな環境でも同じように動く ということを目指して成長してきたからです。

その結果、独占に対抗するというだけではなく、様々な環境でいろんなコンピュータを持つ人々が同じように利益を受けることができるという、 思わぬ利点もありました。 シャニマスは、そんなWebの技術の上に成り立っています。

シャニマスを技術的に見ると、enzaというHTML5をベースにしたプラットフォームの上で作られています。 HTML5は2010~2015年くらいに流行ったバズワードでもあるんですが、要は 「Webのプラットフォーム上でネイティブのアプリと同じような表現力を実現しよう」 という取り組みであり、それらの技術的要件の決まりの名前です。

そう、シャニマスはまさに「独占と戦うプラットフォーム」の上に成り立っていると言えますし、 どんな端末でも同じようにアイドルに触れ、プロデュースができる自由な場と言えるのです。 それだけでなく、ある企業が 「わが社の基準としてはπタッチなんて機能のあるゲームは...」 なんて言っても、Webというプラットフォームの上ではそれを気にしなくて良いわけです。 権力を持った関係ない第三者ではなく、ユーザーのために本当に必要な価値を提供できる。 Webはそんな技術であり、思想であり、世界です。

HTML5は最初の仕様が2014年に策定されて、まだそこまで時間がたっていません。 2019年現在、いまだに新しい仕様が追加されて行っています。 シャニマスはそんなHTML5を基盤として 「まだまだブラウザ上でネイティブみたいなゲームなんて無理だろう」 という認識だった自分の固定概念をぶっ壊して、Webの、技術の、アイマスPとして未来を見せてくれたゲームであり、コンテンツです。

だから、自分はシャニマスに他とは違うこだわりを持っているのです。

最後に

たいそうなことをツラツラと書いてきましたが、要は風野灯織は最高という話につながります。

www.youtube.com

👇優勝後コミュです。ネタバレ注意👇

www.youtube.com

いまだにAランク取れない雑魚なんで、Trueはまだです。 早くTrueコミュ見れるように頑張ります。