就職活動奮闘記
こんにちは、絶賛春休み中のじゅぎのんです。（そろそろ終わる）
今回は、前回にも言及していた就職活動について満を辞して書き記そうと思います。
実は就活の記事は結構前に書いていて、めちゃくちゃ長文を書いた挙句「これ見るやつはなにを見せられているんだろう…ってなりそう」とふと思って全部消しました。
そんなわけで、今回は自分が「これをやっていてよかった」とか「これをもう少しうまくやればよかった」と思った就活の要点？的なものをまとめておこうかなと思います。
就活プロフィール
まずは自分がどういう業界のどういう職種をやることに決めたのか、プロフィール的な感じでまとめます。
- 2022年 電気通信大学大学院卒業予定 現在情報学専攻の修士1年生
- 志望業界はいわゆるWeb系企業 エンジニア志望ではあるがデザインにも興味があった
- 本選考に入った企業は全部で4社 うち1社一次面接落ち、1社選考辞退、2社内定
- 一番早い面接…11/9 内定1社目…12/14 就活終了…2/19
- 面談の回数…40回弱 面接の回数…9回
こんな感じですかね？ 夏にインターンシップやってたりもするので、よければそちらもご覧ください。
では、就活やってみた所感など書き連ねていきます。
軸を見つけることを最優先にする
でましたね軸。就活のセミナーとかにいくと「軸を持とう」という言葉を耳に胼胝ができるほど聞かされると思いますが、実際その通りです。
面接って自分をアピールする場所であることは当然のことで、「自分はあなたの会社にとって力になる存在なんですよ」ということを示す場所です。
また、それに加えて会社の人にとってはできるだけ長く働いて、速く成長して会社に利益をもたらしてほしいと思うのは当然のことです。
面接に挑む側は結構そのことを忘れがちで、「なんでもいいから俺を雇ってくれ」とか内定がないときは思うんですが、会社にとってはなんでもよくはないんですね〜（当たり前）。
その環境で長く働ける・速く成長できる人というのは、その環境に素早く馴染むことができるとか、その環境にいて苦痛ではないことが大前提になります。
じゃあどうすればその会社が自分にとって馴染める環境であるか、苦痛ではない環境であるか判断できるのか？それが就活の軸なのです。
「軸」という言葉で聞くとすごく堅苦しいイメージで、「会社のビジョンがうんちゃらかんちゃら…」みたいなことをイメージしがち（僕がそうだった）なんですが、これって意外となんでもいいことを面談をして知りました。
僕は軸を大きく3つに分けて、その中で細かく重要度に分けて決めていました。
軸1: 人間関係
まずは人間関係についてです。面接でも何度も言っていましたが、僕は人間関係が仕事をする上で一番重視したい要素でした。
今までの人生の経験上、人間関係が面倒なことになっている環境では自分の力がうまく使えない（周りの人に話しかけることができない・憂鬱な気分になる）ことがわかっていたので、少なくとも仕事に対してマイナスな感情を持っている人のいない環境がいいと思っていました。
まあそんなことは全人類そう思っていて、かつそんなことを面接で聞いたところで会社のやばいところを教えてくるような会社はあるわけないんですが、それでも結構面談や面接で「この企業に勤めていて『ここは変えて欲しいな』とか思うことってあったりしますか？」という質問はけっこうしました。
意外とそういうことを聞くと素直に答えてくれる面接官は多く、素直だとそれはそれで会社の印象もよくなったりしました。
軸2: 技術
次に技術についてです。エンジニアを志望する以上、技術については最低限「これをやりたい」という軸は持っておくべきでしょう（持論）。
僕は今までフロントエンドエンジニアとして夏のインターンシップや長期のインターンシップをやってきて、ユーザーの目に直接触れるクライアント側の処理を書くことにとても面白みを感じていました。
ただ、僕は「プログラミングをやりたいからプログラミングをやっている」というよりかは、「こういった問題があってこれをどうにか改善したいから、その手段としてプログラミングを使っている」という気持ちが強いです。
これは別にどっちがいい悪いの話ではなく、好みの問題だと思います。
機械学習がすごく面白いからMLエンジニアになりたいという人ももちろんいるだろうし。
なので、僕は会社として技術に対して「問題を解決するための一つの手段」である、という考え方をしている企業を選びました。
結構そういった類のスローガンをビジョンやミッションに掲げている企業は多く、わかりやすくてよかったです。
また、先程のクライアントサイドをやっていたというのもあり、「ユーザー志向」というワードは就活でとてもよく使いました。
今までの経験上、僕のプログラミングのモチベーションは「作ったものを使ってくれたユーザーからの声」であることが自己分析（と言えるのかわからないけど）でわかりました。
なので、そういったユーザーボイスドリブンで開発しているような環境だったら自分の力を精一杯注げそうだな、と思い「ユーザー志向」を軸にしました。
軸3: 組織
最後に組織（というか企業自体）についてです。
プロフィールのところで面談の回数40回弱と書きましたが、Web系の大企業からかなりの小規模な企業までいろいろな規模の企業と面談をしてきました。
そこでの感触としては、「多分自分は大企業には合わないな」でした。
大企業は収入も（おそらく）安定していて、教育もきっとしっかりされてエンジニアとして堅実な道を歩めるかもしれなかったんですが、やはり上二つの軸に当てはめた時に不安が残ることが大きかったです。
まずユーザー志向な開発はおそらくほぼまったくといっていいほどできないと思いました。
大体業務内容として聞くものは保守・運用が多く、ユーザーとはほど遠い位置で開発をする環境であることがわかりました。
なので、持っていた軸としては「100人〜数100人規模の企業で、これから成長する見込みがある企業」という感じでした。
また、自分は今後エンジニアもやりつつマネジメントの方に舵を切っていきたいとも考えているので、そういったルートにいけるような会社という面でも選んでいました。
こんな感じで軸を作って面談をすると、「あ、この会社は多分違うな」というのが肌感でわかるようになります。
そうすることでミスマッチな会社の本選考に入ることがなくなり、企業にとっても自分にとってもいい時間になると思います。
本選考って想像以上に精神力使うので、何十社も受けてるような人は本当に尊敬します。
人に相談する
僕の中で就活を満足して終わらせられた要因の一番大きいものはこの「人に相談をたくさんした」ことだと思っています。
4月から就活イベントでお世話になっていたサポーターズのアドバイザーの方、陸上部の卒部生であり現Web系企業エンジニアである先輩、研究室の後輩、一緒に就活をしていた陸上部の同期、両親、面談を設けてくださった企業の方など、本当にいろいろな人に相談しまくりました。
とくにWeb系に勤めている20卒の先輩にはマジでちょくちょく相談をして話を聞いてくださったのでありがたかったです（寿司も奢ってもらったし）。
さきほども言ったように僕は面談を40回弱やったと言いましたが、実はそのうちの13回は内定を出していただいた2社との面談です。
その2社は先程言った3つの軸で当てはめてもばっちりの企業で、内定をもらった直後ではどうしてもどちらにするか決めることができませんでした。
そういう時は自分で考えていてもしょうがないので、とにかくいろんな人に「どっちにしようか迷ってるんだけど、ここはこっちの方がよくてここはあっちの方がいい」など本当に思ったままのことを相談していました。
もちろんそれは内定を出してくれた企業にも正直に言いました。
どちらの企業も本当に親身になって話を聞いてくださり、僕を会社の人材としてではなく一人のエンジニアとして人生相談に乗ってくれていたな、と感じます。
特に、僕の中で一番響いたのは陸上部の先輩が言っていた「どの仕事をしていてもつらいときはあるけど、自分がやりたい仕事やってればそこまで苦に感じないのでは」という言葉です。
そこからサービスへの愛着が僕の中で一番の論点になり、「今の自分は、自分に近い身の回りにいる人たちの助けがしたいんだ」ということをはっきりさせることができてどちらにするか決めることができました。
僕も後輩にいいアドバイスができるようになれればいいなと思います。
面接は結局慣れ
今年はどの企業もすべてオンラインでの面接だったので、多分リアルで面接するよりかは緊張もそこまでなかったのかもしれませんが、それでも1社目の1次面接はクッソ緊張しました。
正直言ったことも汎用的なことで、あまり面接官の印象に残らないまま1社目は1次面接で落ちました。
そこでかなり落ち込みましたが、やっぱり何回も面接を繰り返していけば余裕も出てきて素直に質問に答えられるようになったなと思います。
特に僕の中で印象が強かった面接は、先日基本情報技術者試験をうけるきっかけになった面接
そして、内定を承諾した企業の1次面接です。
その企業はiOSアプリエンジニアとして応募していて、Swiftはほとんど触ったことはなかったものの「一応少しだけ触ったことがあります」と言いました。
そうするとそれに対する質問として、「SwiftはJavaScriptと比べてなにが違うと思った？」ということを聞かれ、その時はマジでなにもわからなくて固まりました。
少し考えていいですか、と聞いて考えましたがやっぱり何も出てこず、これは素直に答えるしかないと思い「すみません、それについてはわからないので答えられません」と言いました。
この時点で半ばこの会社は諦めかけていて、あーあと思っていたらその日に面接通過の連絡がきました。
後日面談でそのことを聞くと、「わからないものはわからないと素直に答えているのが逆に好印象だった」と言われ、わからないことがあってもいいんだな、と思うようになれました。
たしかに実際に働くことになって、わからないものをわからないと言えないようなやつに仕事を任せて全然進捗ない、ってよりかは普通にわからないって言ってくれた方がいいですよね。
あとはその面接で、「デザインに興味があるならデザイナーにはならないの？」と聞かれたとき、デザイナーがどんな仕事か他社の面談で聞いていたこともかなり良ポイントでした。
どの面談も無駄じゃないな、と思えた瞬間でした。
もっと他の企業があったんじゃないか
就活をしているときに常に感じていた不安として、「自分に合っている企業は単純に僕の目に触れていないだけなんじゃないか」ということです。
サポーターズのアドバイザーにいろいろな企業の推薦をしてもらいましたが、どの企業も正直あまり惹かれる部分はありませんでした。
しかし、その推薦をみて「自分の知らない企業ってこんなにあるの…？」とも思いました。
実は今自分が選考を受けているよりももっと自分にあった企業が実はあるけど、単純に時間がなくて会社をみることができず、見つけられていないんじゃないか、ということをずっと思っていました。
これに関してはなるべく早くからいろんな企業をみて回る以外になく、時間の問題だなぁと思います。
会社のことをよく知るためには企業サイトだけではなくブログも読まないといけなかったりするので、結構骨が折れます。
就活関係なくいろんな企業のサイトはみておいて損はしないな、と思いました。
総括
まとめとして言いたいことは、てきとうに「この会社でいいや」で決めるんじゃなくて、よく考えた方がいいぜってことです。
正直夏の時期は「就活はなんの苦労もなく一瞬で終わらせたいな」とか思っていたんですが、そんな楽をしてもいいことは正直あまりないです。
結局未来の自分を苦しめることになると思うので、研究もそこまで忙しくない今の時期にたくさん自分のことで悩めたのはとてもいい経験だったなと思います。
ということで、最後まで読んでくださった方に向けてお知らせになりますが、わたくしじゅぎのんは2022年新卒で株式会社ZOZOテクノロジーズのiOSエンジニアになります。
今まで触れたことのない言語を仕事にするということで若干の不安はあるものの、この1年でどうにか力をつけていこうと思います。
プリズムの煌めきと一緒にがんばるね。
基本情報技術者試験を受けた
こんにちは、就活が無事終わりましたじゅぎのんです。就活に関しても記事はあげようかなと考えていますがかなり長くなりそうなのでまた今後。
今回は3/1,2に受けてきた基本情報技術者試験についてレポートしていこうかなと思います。
結果
先に結果を挙げると、まだ正式な合格通知はきていないものの、午前試験は86.25点、午後試験は全体正答率91%取れたのでおそらく合格したんじゃないかなと思います。
改めて結果通知がきたら公開しようと思います。
すごい今更だけど基本情報技術者試験受けてました！ 正式な結果はまだだけど目標だった8割越えはできた！！ pic.twitter.com/9CKovGAMFk
— Jun Ogino (@juginon) 2021年3月2日
※ 5/10 追記
先日合格発表があり、無事合格していました。
また、郵送で午後試験の得点が通達され、91.00点という結果でした。
全体正答率も91%だったので、意外と点数は均等配分なのかも…？
きっかけ
なぜM2になる今更、応用情報やスペシャリストではなく基本情報を受けたのか？
他に資格を持っていないからとか、もともと去年受けようと思ってたらコロナの影響で中止になったからというのも理由としてはあります。
2020年の抱負の記事に書いている通り、プログラミングに関する大きな目標として基本情報に合格することを挙げていました。
実はその時4月ごろに試験を申し込んでいて、春休みで勉強を少しづつやっていたんですが（卒業旅行にも参考書を持って行ったりしてた）残念ながらコロナウイルスの影響で2020年の前半の試験はなくなりました。
秋に優先で申し込みができる権利みたいなものをもらっていましたが、その頃にはモチベーションがだいぶ下がっていて受ける気にならず、結局申し込まないまま時はすぎていきました。
ではなぜ今受けたのかというと、就活の面接で自分の基礎知識のなさに気付かされたからです。
後に書くであろう就活レポートにも書く予定ですが、とある企業の二次面接での出来事です。
面接官：「Webに関する知識ってどれくらいありますか？」
じゅぎのん：「そうですね、大学で学んだことは大体基本情報技術者の範囲にはカバーしてると思います」
面：「なるほど、ではHTTPについて説明できるだけ説明していただけますか？」
じ：「（ファッ！？）えーーっと…そうですね、ブラウザがWebサーバーと通信するときのプロトコルなんですが…すいません、それ以上のことについてはあまり説明できることがありません」
面：「HTTPSとHTTPの違いについてはどうですか？」
じ：「暗号化されてるんだろうなー、くらいはわかるんですがそれ以上は…」
面：「なるほど、わかりました。Reactとか結構がっつり書いていてとてもいいと思うんですが、こういったWebに関する基盤になる知識もあるともっといいかなって思いますよ！」
じ：「そうですね…ありがとうございます」
結局この面接には通り、その企業からは内定をいただけたんですが「自分にはこんな基礎知識もなかったのか…」と思い知らされることになりました。
面接を受けたのが11月の下旬で、その後12月頃に就活が終わったら受けようと決意、3月の初めに受験という流れです。
実際基本情報を勉強したことでWebに関する知識（特にネットワークやセキュリティ）に関してはかなりついたかなと思っています。
基本情報って聞くと結構「なんで今更そんなの受けるの？応用情報ならまだわかるけど金の無駄でしょ」とか言われることが多いんですが、エンジニアとしての基礎知識を完璧に網羅できている人ってそう多くないと思います。
もちろん国家資格だし、エンジニア志望でもしっかり勉強しないと普通に落とされる試験なことに間違いはないと思うのでバカにするような資格ではないよな、と受けてみて改めて思いました。
使った参考書・教材
僕が勉強に使った参考書や過去問はこちら。
教本
- 作者:角谷 一成,イエローテールコンピュータ
- 発売日: 2020/11/24
- メディア: Kindle版
過去問
令和03年【上半期】基本情報技術者 パーフェクトラーニング過去問題集 (情報処理技術者試験)
- 作者:山本 三雄
- 発売日: 2020/12/21
- メディア: 単行本
教本は常に持ち運んで、大学でも勉強する機会がとても多かったので電子書籍で購入し、iPadで読みながらノートを書いていました。
また、よく参考書としてあげられるキタミ式や「かんたん合格」と謳われる教本
こういった参考書を使わなかった理由は、上でも言ったようにWebの基礎知識を一応すべて網羅できるように一周しておきたかったからです。
「基本情報技術者試験に合格する」ことを目的とするというよりかは、「Webに関する知識を最低限覚える」ことを目的として受けていました。
戦略としては単純で、章ごとにいつまでにその章を終わらせるか目標を立て、教本が終わり次第過去問を解き始めるといった感じでした。
僕が使っていた教本の各章はこんな感じの内容でした。
1章: 基礎理論（数学に関する知識・アルゴリズム）
2章: コンピュータシステム（メモリ・OS）
3章: 技術要素（DB・ネットワーク・セキュリティ）
4章: 技術開発（システム開発プロセス）
5章: プロジェクトマネジメント
6章: サービスマネジメント
7章: システム戦略
8章: 経営戦略
9章: 企業と法務
午前問題対策
はじめの章から順番に勉強していき、時間がなくなり次第過去問をやるようにしたため、最後のストラテジ系はかなり駆け足になってしまいました。
その分、1~3章の部分は純粋にページ数が多かったのもあり（3章までで教本の半分）、かなり細かいところまで勉強することができました。
実際、ストラテジ系は問題を解くというよりかは単語の意味を覚えているか、日本語がきちんと理解できるかを問われているような感じがしたのであまり勉強せずともある程度の点数は取れるんじゃないかと思います。
勉強していて僕が特に覚えることに苦労したポイントはこちらです。
RAIDの種類が覚えられない
RAIDとは、ディスク装置を複数台用いて高速または信頼性の高いディスク装置を実現する技術です。
全部で7つ種類があって、それぞれ名前がつけられているわけではなく単純に「RAID0,RAID1,...RAID7」と書かれているだけなのでかなりややこしいです。
過去問では「RAID0の特徴は…」とか問われるので、ちゃんと覚えておかないと死にます。
なんとか覚える方法はないかなと調べたところ、この記事の覚え方が一番しっくりきました。
RAID0,1,5の3種類しか問われないとのことだったので、0と1は記事のように数字の形で覚え、RAID5だけは「パリティビットがある」という覚え方をしました。
DRAMとSRAMの違いが覚えられない
RAMとROMの違いはわかるけど、DRAMとSRAMの違いが覚えられなくて苦労しました。
特に、「リフレッシュが必要なのはどちらか」と言われたときにパッと思いつくことができなくてミスった覚えがあります。
こちらも調べたところ、この記事の覚え方が一番しっくりきました。
かなり昔の記事ですが、みんなやっぱり覚えるの苦労してるんですね。
SQL文が覚えられない
DBの章ではSQLによるデータベース操作の記述が一気に説明されて、初めてSQL文をしっかりみるときはかなり混乱しました。
これに関しては午後過去問のデータベースの問いをやるのが一番覚えられました。問題として出てくるとどういった処理をしているのかが比較的簡単に読み取れたので、ここは覚えることに固執しないでさっと流す程度でいいと思います。
他にも、「秘密鍵と共有鍵の違いがわからない」「ディジタル署名方式がよくわからない」「ネットワークの通信方式がよくわからない」とか疑問はかなり多かったですが、一つ一つきちんと理解することで知識として定着させました。
午後問題対策
午後問題の対策は完全に過去問をやりまくるだけでした。
実際に過去問に手をつけたのは本番の1週間半前くらいからで、かなり短い間でやりました。
購入した過去問には1年分の予想問題と3年分の過去問題が収録されていて、とりあえずその過去問をすべて2周しました。
午後問題はとても文章量が多く、かなり集中しないと全然理解できないので本番と同じ時間と集中力で挑む必要があります。
だらっとしながら問題を解いていたら答え合わせでほとんど間違えていて「やべぇ午後で落ちるかもしれん…」みたいな気持ちになりましたが、集中して解いていくと意外と解くことができました。
また、戦略としては問2~問5の選択問題でどれを選ぶのかが重要になってくると思います。
とりあえず全問解いてみて当日もざっと目を通していけそうな部分から手をつけていました。
当日実際に問題を解いてみた感想としては、過去問は4年分を2周すれば十分対策になるかな、という感じでした。
ほぼ過去問そのままで出題された問が一つあり、そこに関してはかなり過去問があってよかったと感じましたが、それ以外の問に関しては問題の内容はかなり違くて純粋なアルゴリズムの知識が必要でした。
ここに関しては暗記をするというよりかは解き方を固めておく必要があるものなので、数回過去問を解くことで身についていくかなと感じます。
あとは当日やった戦略として、集中力の続く・時間に余裕がある一番最初にアルゴリズム問題とpythonの問題を解き、その後に残った時間をいい感じに分割して残りの大問を解いていきました。
こういった一つ一つの大問に使う時間とかもしっかり練習の段階で決めておければだいぶ楽になるんじゃないかなと思います。
受験当日
令和２年度秋期以降の基本情報技術者試験がCBT方式での実施になることが、IPA（情報処理推進機構）より発表されています。
会場を指定するとそれぞれの会場で受験可能な日にち・時間を指定することができ、午前・午後でそれぞれ好きな日にち・時間を指定することができました。
僕は3/1に午前試験、3/2に午後試験を受けるように設定しました（午前と午後を同日にすることもできました）。
僕が申し込んだ会場はとても小さく、受付にいくと左右に仕切られたPCルームがあり、それぞれの部屋に大体10台くらいコンピュータが置いてありました。
持ち物をすべてロッカーの中にしまい、準備ができるとPCの前に通されます。
受験開始のボタンを押してからはモニター上に試験問題が出され、その回答をマウスでクリックして進んでいくという流れでした。
紙の方がいい・CBT方式の方がいい二つの意見に別れると思いますが、正直どちらでも変わらないかなと思います。
CBT方式だと設問ごとにフラグを立てることができて見直しをするのが楽だったり、マークシートの判定漏れとかが確実にないという安心感もあったので僕はCBT試験の方が好きです（多分）。
午前試験はどの過去問をやっても6割は確実に超えていたので普通に解きすすめればよかったんですが、謎に緊張してマウスを動かす手が震えていました。
問題が進むにつれてだんだん慣れていき、大体1時間くらい残してすべての問題が終わったと思います。
途中退室もできたようですが自分は一応時間ギリギリまで見直しをしていました。
試験が終わった後、受付に戻って確認をとって午前試験は終了しました。
携帯の電源をつけるとメールですでに午前試験の結果が届いていて、午前試験に関しては100点満点中何点だったか・それぞれの分野で何%点数を取れていたかがわかりました。
紙の試験だと結果がくるまで1ヶ月はかかると思うので、結果がすぐわかるというのもCBT試験のいいところだなと思います。
午後試験も同様の方式で行い、試験が終わった後に送られる結果には点数ではなくそれぞれの大問で何%点数をとれていたかのみがわかります。
今回の結果としては、午前試験で86.25点、午後試験で全体の91%をとることができました。
午後試験は設問の難易度によって配点が変わるため確定で合格とは言えませんが、さすがにこれで落ちていたら納得できないです。
感想
資格の試験を受けるのは大学3年のTOEIC以来ですが、国家資格というのもありかなりしっかりした体制で試験が行われているなと感じました。
やっぱり基本情報とはいえしっかり範囲全体を勉強していないと合格はできないレベルの問題が設定されていて、たしかに「高度 IT 人材となるために必要な基本的知識・技能をもち，実践的な活用能力を身に付けた者」になれそうと思いました（小並感）。（でも正答率60%で合格ってちょっとボーダー低すぎではとは思った）
あとは情報学の内容しか出てこないので、純粋に自分の興味で勉強を進めることができたので勉強していて苦痛に感じることがまったくなかったのもよかったです。
TOEICとか真剣に勉強しても絶対こんな点数取れないと思うので。
正式な結果は4月下旬に出るとのことなので、楽しみに待っていようかなと思います。
応用情報とかスペシャリスト系も挑戦してみようかな…（研究しろ）
そういえばノンシュガー単独ライブ行ってきました。新曲5曲アツすぎだろ…
月川ちりのオタクになりました。
2020年の反省、2021年の抱負
こんにちは、10,11月とブログ更新をサボりましたじゅぎのんです。
2018年、2019年と反省・抱負を書いてきて、今年も無事に2020年が終わります。
去年はどんなことを目標に掲げていたんでしょうか？ちょっと見てみましょう。
2020年やったこと
フォーマットは去年とほぼ同じでいこうかな。
研究
間違いなく一番最初にくるイベントはこれですね。卒論。
2月7日に原稿の締め切り、2月14日に卒研発表です。2ヶ月後は間違いなく修羅場です。
3ヶ月後にこの記事を見てあのときはな〜〜って早くなりたいです。もうお正月も気が休まらない…
ただ、卒論を書き上げても僕は電通大院に進学するので、研究が終わることはありません。正直学部での研究テーマが微妙すぎてできるならやり直したいと思っています…
ということで、M1で新しい研究テーマをちゃんと決めたいなと思います。先輩には気を抜いてると一瞬で1年終わると言われたので、気を抜きたくないですね（フラグ）
嘘だッ！！！！！
まあ無事に卒研発表は終わりましたね。
僕は1月下旬に第1稿をあげて、結局4回くらい直したかな？ 僕が去年どれだけ心が荒んでいたかはこの記事を見ればわかります。
この記事、個人的にはこのブログで一番の傑作だと思っています。
やっぱり心がやられているあの時にしかこの記事は書けなかった。まじで書いてよかったと思ってるし、これを後輩に読んでもらって僕の同期がどれだけやばいやつだったか知ってもらうことができて僕は幸せです（にっこり）
研究テーマが微妙だから変えたい、と言っていましたが、今やっている研究は少し路線が違うものの卒研のころとほぼ同じテーマで続行しています。
夏にオンラインで学会発表をし、この研究の道筋というか今後なにをやっていきたいかを明確にできたと思っています。
これから実験をやって分析して、その結果を用いてシステムを作り、修論発表に向かう所存です。
一応なんとなく目処は経っているので去年よりかはスムーズに研究は進むんじゃないかなと思ってます。
ちなみに同期の研究はガチで何も進んでいません。
陸上競技
去年にあげていた目標はこんな感じでした。
この目標は残念ながら達成することはできませんでした。十種競技に出場できなかったので。
コロナウイルスの影響で春の記録会は全滅し、もしやれていたとしても公認記録にはなりませんでした。
27大学対校戦は参加できる大学数が大幅に減った影響で国公立大学対校戦へと名前を変え、十種競技も競技時間の関係上実施されることはありませんでした。
ということで、今年記録を残せたのは3種目、走高跳・走幅跳・110mHのみでした。
ただ、記録自体は悪くなく、走高跳はPB-1cmの195cm、走幅跳は6m91cmでPB、110mHはPB+0.23sの15.74でした。
純粋な短距離のメンバーの中で今年PBを出せたのは自分だけだったので、それは素直に嬉しいです。
ただ未だにどの種目も関東インカレ標準には一歩及ばずで、走高跳はあと4cm、走幅跳はあと19cm、110mHはあと0.21sです。
陸上に関しては今年は不完全燃焼の年でした。
プログラミング
プログラミングに関しては、今年は就活もあったことで大きな飛躍の年になったんじゃないかなと思っています。
今年の実績はこんな感じ。
夏のインターンに参加できたことは僕のエンジニア人生にとって大きな転換の出来事でした。
チーム開発を経験したい！というただそれだけの理由で申し込んでいた自分は今になって考えると何言ってんだろうって感じですが、それでも気持ちを汲んで採用してくれたVOYAGE GROUPの方にはとても感謝しています。
今考えると、インターンに参加するだけで12万円もくれるなんて会社からしてみればかなり力の入れた投資だよなぁ…って思います。
夏のインターンのおかげで、就活もかなりスムーズに進めることができています。
夏のインターンの記事はこちら。
就職に関しては今かなり迷っているところです。できることなら大企業にいきたいけど、それが本当にいい選択なのかわかりません…
ここに関しては今もまだ模索中ですが、自分なりの答えは出せました。今年1年間で面談をした会社は30社近くになり、企業の方とたくさん話すことで僕は自分なりの答えに近づいて行けたなと思っています。
就活に関しては確定したら記事にしようかな。
長期インターンに関しては、来年にかなり大きな仕様改修が待ち構えていて、それをやるのがとても楽しみです。
自分が卒業するまでにそれを完成させて、無事卒業できたらな、と思っています。
趣味
今年は趣味もかなり全力を注げたんじゃないかなと思っています。
新しいコンテンツを追いかけたい とも思っています。
去年の僕、見つけましたよ。アイドルマスターという新しいコンテンツを。
ライブに関してはコロナウイルスの影響ですべてオンライン開催になってしまいましたが、カラオケでライブ配信をみたり研究室の大画面の前でサイリウムを振ったりオンラインでもたくさん盛り上がれた年だったかな、と個人的には思っています。
でもやっぱり現地に行ってコールしまくって声枯らしたい…と切実に思っています。
今年のキモ・オタク活動はこんな感じ。
- ラブライブ！シリーズの視聴（1月〜2月）
ラブライブは無印がとてもいいストーリーだな〜って思ってたけど、サンシャインで二番煎じ感あってちょっとだけ萎えた。
- ミュークルドリーミーの視聴（1月〜12月）
初めてのサンリオ作品の視聴。今年一番幸せなアニメだと思ってる。ゆめちゃんかわええなぁマイラブ！
- アイドルマスターシリーズ視聴（10月〜12月）
いろいろな影響が重なって視聴を始めたアイマスでしたが、千早の約束を見て号泣、そのままシンデレラガールズとSideMも見ました。
今はどのCDを借りればアイマス楽曲を制覇できるのかがんばって検索しているところです。
- 増えたオタクグッズたち
去年の比じゃないくらいオタクグッズが研究室に増えました。
卒業したらこのグッズの居場所をどうすればいいのかすでに不安になっています。
RASは個人的に曲が好きすぎてバンドリじゃなくても追いかけたいバンドですね。
Sacred Worldの初回限定版に入っていた舞台RASのDVDを見て推せるな、と思いました。
あとオタクでやったことの大きいことは、アイカツスターズ!の早乙女あこちゃんのスクショを永遠に垂れ流すbotを作ったことですね。
RailsでWebアプリを作り、そこ経由でtwitterに画像を飛ばしています。
来年はWebの方でスクショをちゃんと見れるようにしたい！
2021年やりたいこと
研究
研究室同期のやる気のなさはきっと来年も変わらないですが、自分は自分で一生懸命頑張ろうと思います。
少しずつでも手を止めない、あとは何かにつけて期限を設けてだれることのないようにしたいです。
来年末は去年末よりも楽な心持ちで振り返りの記事を書いていたいですね。
陸上競技
陸上競技の選手としてトラックに経つのは来年がもしかしたら最後になるのかもしれません。
少なくとも大学陸上は来年で引退になるので、自分の悔いの残らないように記録と結果を出したいです。
具体的な目標を書いておくと、こんな感じかな。
本当に達成ができそうな目標はこの上記3つだと思ってます。そもそも大会や記録会が今年のように開催されなかった場合を考えると、これがまあ最低限かな。
最近は、記録として残すことも重要だと思っているけどそれ以上に大学陸上6年間のラストに相応しい部活にするにはどうすればいいのか、メンタルの面でいろいろ考えています。
せっかくなら記録以外でもなにか部活に貢献したいとか、どうすれば22年の卒部式で心置きなくお世話になりましたと言えるのかとか。
答えは今出るものではないので、1年かけて探し続けようと思います。
プログラミング
最近はもうお金稼ぎのために仕事をしていなくて、やらなきゃいけないからやっているという感じが強くなってきました。
研究が忙しくなるまでに、インターンの方はちゃんと大改修を終わらせられるようにしたいです。
あとは就活を無事に満足した、と終わらせて、次のステップに進むためのインプットを増やしていきたいです。
個人的な具体的な目標はこんな感じ。
新しいMacを購入したので、生産性爆上げでいきます。
趣味
今年はプリティーシリーズに加え、アイマスシリーズというかなり巨大なコンテンツにも手を出すことができました。
そしてプリティーシリーズではなんとアイドルランドプリパラという最強コンテンツが来年配信される予定です。
プリティーシリーズ・アイマスシリーズはしっかり追いつつも、他のコンテンツにも興味をむけて楽しみたいなー、というのが今の気持ちです。
オタク趣味の輪を広げることも継続してやっていきたいですね。あこにゃんbotももっと進化させよう！
総括
今年は異例の年になったものの、自分は自分なりにいろいろ頑張れた年だったなぁと思います。
好きなものは好きって言える、そんな環境を今後もずっと大事にしていきたいですね。
来年は学生最後の年でもありますが、あまりそこは強く意識せずに自分の楽しみたいことを存分に楽しみます！！
VOYAGE GROUPのTreasureに参加しました
またお久しぶりになってしまいました、じゅぎのんです。
8月上旬は授業が佳境に入り、テストがあったり提出物があったりで忙しく、研究も実験をちょっとだけやったりと忙しい日々が続いていました。
そんな8月下旬、ついにVOYAGE GROUPの夏のインターンであるTreasureが始まり、二週間+αの戦いの末無事生還して戻ってきたので、今日はその報告をしようかなと思います。
Treasureとは？
このブログを見ている人は大体みんな知ってそうなので特にかしこまって書く必要があるかは分かりませんが。。
Treasureとは、VOYAGE GROUPって会社が開催してる夏のインターンシップのことです。去年のレポートとか会社ブログ、そしてすでに今年の参加報告もちらほら上がってきているので、是非そちらも確認してみてください（きっと僕なんかよりいい文章書いてる）
うちのチームにいた人事のなみさんのテックブログ
今年、共にTreasureに参加した人たち
https://blog.takurinton.com/17
昨年のTreasureに参加した人たち（TAとして今年参加していただいてる人もいます）
今年は例に漏れずコロナウイルスの影響ですべてオンラインで、8/1, 8, 15の土曜日と8/17~28の計13日間（表記上は）の開催となりました。
去年までのTreasureのレポートをみて「オフィスきれいそうだし、お酒もタダで飲めるし、お菓子も食べ放題みたいでいいな〜」と思っていたので、そこがなかったのは少し（かなり）残念でした。。
でも、前回の記事でも書いた通り自分は普通だったらこの時期部活の大会・練習でこんなに時間がとれていなかったはずなので、このインターンに参加できただけで嬉しかったです。
あ、お菓子に関しては安心してください（？）、今も食べ切れていないほどのお菓子他の詰め合わせが段ボール二箱分配送されてきました。
そんなわけで、お菓子も気持ちも用意完了！いざTreasureへ :muscle:
前半戦（講義）
8/1, 8, 15、そして8/17はVOYAGE GROUPの方がフロント・バック・DB・インフラ・アイデアについて講義をしてくれました。
フロントエンドはJavaScriptの歴史からJSのtips（function関数とarrow関数の違いとか、bindについてとか）を学びました。
意外とずっと書いてきたのに知らなかったこととかがあって、フロントエンド講義も学びが多くあったなぁと感じます。
バックエンドはTreasure-voiceという1対1の通話サービス的なものを作りながらGolangを学びました。
Repository, Service, Controllerの役割やAPIのエンドポイント設計、WebSocket、WebRTCなどバックエンド経験ほぼ皆無な自分にとってはすべてが初めて聞く単語で、完全にコンフォートゾーンから外れた状態（むしろ体半分パニックゾーンに入ってる）でしたが、TAのらぴおさんが講義のあとに1対1で画面共有をしながら丁寧に教えてくださり僕は感涙にむせび泣きました。本当にありがとうございました…！
DB講義では実際にdbdiagramというDB設計ツールを使いながら、発表されたチームごとに実際の運用のことを考えながらDB設計をしていきました。
DBも僕にとっては初めての領域で、わからないながらも設計に関しては自分の考えをもって発言することができたんじゃないかなぁと思います。
インフラ講義では、今回チーム開発時にベースとなるTreasure-appのインフラ周りの部分についての解説を聞きました。
正直ここはまだあまり理解できてない…（しょうたさん、ともかつさんすみません）AWSむずすぎです。解説スライドをいただいたので、がっしりと読み返して学んでいこうと思っています。
最後にアイデア講義。僕たちのチーム開発は後述するようにアイデア出しでありえん時間がかかったので、今回のインターンで一番学びになったと言っても過言でもないのはアイデア講義で得たことでした。
フロントエンド・バックエンド共にわからないことがあったときは補講を開催してくださったり、個別に質問を受け付けていただけてとてもやりやすい環境でした。
ヤンウェイさん、バックエンドがわからなさすぎて初心者みたいな質問ばっかしてすみませんでした。僕もっと強くなります。
後半戦（チーム開発）
決起！
講義が無事に終わると、ついにチーム開発がスタートします。今回のTreasure参加者数は全部で24名、4名×6チームに別れてアイデア出しから始まります。
僕は大学院のテストの関係でチーム発表の場に居合わせることができませんでしたが、チーム名が無事ヱビスと決まり、サポーターさんにれぞさん、ちゅうこさん、なみさんがついてくれました。
チーム名の由来は「時間がなくなったからみんなの共通点ぱっと出したときにみんなヱビスビールが好きだったから」だそうです。
ごめん、僕お酒そんなに好きなわけじゃないんだ…
無事にチームが発表になった日の夜は決起会という名の飲み会がありました。
今回のインターンで得たいことを各々語り、チームとしてはこんな感じの目標が立ちました。
- DevopsとかCI/CDに興味があるから、テストを頑張りたい
- Treasure期間で作り終わってはいおしまい、じゃなくて、その先も作っていけるようなものが作りたい
- UI/UXに興味があるから、できればデザインも頑張りたい（僕）
- とりたい賞はいっぱいあるけど、やっぱりグランプリを目指したい
目標は高く、グランプリを目指せるような、将来性のあるサービス。
それを目指すためにみんなで決めたことは、「妥協しない」ことでした。きっとこの"妥協しない"があったからこそ、今回いいサービスが作れたんじゃないかなと思います。
そして、地獄みたいなアイデア出しが始まります。
アイデア出し前半
まず、僕たちヱビスチームのいっっちばん最初の目標日程を見てみましょう。
そして、次に23日（チーム開発残り5日）に変更された目標日程を見てみましょう。
おかしいなぁ…8/23までの4日間が消滅しているのはなぜだ…？
はい、アイデア出しで計4日間かかりました。今改めて最初の目標をみると鼻で笑えますね。
去年のレポートとかみても、どこにも「アイデア出しがつらかった」と書かれていないのでみんな記憶をどこかに置いていってしまったのでしょうか？
僕は絶対に忘れたくないし、多くの学びがこの4日間にはあったのでアイデア出しがどれだけ大変だったかをレポートしちゃいます。
アイデア出しと言っても、どうすれば価値のあるアイデアが出せるのか？ ただ単純に自分たちが使いたいから作る、というだけでは価値のあるプロダクトにはならないとアイデア講師のわーみーさんから教えられ、こんな手順でアイデアを出していくのがいいと言われました。
最近、社会に起きている「時流」を書き出す
ディスカッションをしながら内容を整理する
考える領域（市場）を決める
決めた市場にいるプレイヤーを書き出す
決めた市場と組み合わせて、面白いプロダクト案が思いつきやすそうな時流を選ぶ
選んだ時流に対して、今後発生していきそうな事象を書き出していく
実際に具体的なアイデアを考えていく
文字にすると簡単なんですけどね、これエゲツなく難しいんですよ。
まず時流がわからん。え、運動不足の人が増えたのは時流じゃないの？外出が減ったことも時流じゃないの？
どんなに自分で「これが時流だろう」と思ったことを書いても、「じゃあこれは何が原因で起こったの？」と言われる。
なんやかんやしながらも捻り出した時流たちがこれ。
時流を出したら、次は市場選び。「チーム開発なら自分がユーザーになれそうだし、意見もいっぱい出そうだからチーム開発を選んでみよう」
…え、ちょっとまってなんか全然アイデア出てこないんだけど
まず出てきたアイデア全然チーム開発関係ないし…（今振り返ると） 社会のゆらぎに「電子書籍が増えた」っていうちょっと意味不明なゆらぎを選んでみたことで面白いアイデアがでるかも、と期待したものの、意味不明なアイデアを量産する始末。
ちなみに先に言っておくと、全部でこのサイクルを3回やりました。
「やっぱり時流が足りないからゆらぎがでないんじゃない？」「じゃあちょっと一番最初に戻って時流考え直してようか」
これを3回。最初に見せた時流は完成形で、それまではもっと雑な時流が並んでいました。
市場選びもコロコロ変えながら、だんだんと「市場はオンライン趣味教室が良さそう」というところに落ち着いてきました。
アイデア出し後半
オンライン趣味教室に市場を決定した。そこまでは比較的スムーズに進みました。でも地獄はここからでした。
市場が決まってから実際にアイデアを出していき、「SNS上の有名人になにかを教えてもらうときって、聞くのはレベルが高すぎるよね」という話から、だんだんと質問箱のような質問サービスを作ろうか、という流れになります。
このときはまだアイデア出しは1日で終わらせなきゃいけない、早く実装を始めないと置いていかれるという焦りがあり、あまりアイデアとしてのまとまりがないまま決定しようとしていました（今振り返ると）
そしてなみさんから言われます。「ちょっと席外してて今までの流れわからなかったから、説明してもらってもいい？」
（えっと…なんでこういうアイデアになったんだっけ…）
サービスを使うユーザーは具体的にどんな人で、その具体的な人はどんな課題や欲求を持っていて、それに対してどんな解決をするのか。
それをちゃんと言えない限りはいいアイデアとは言えないし、このまま進んでも開発の途中で疑問が出てくる。ここから地獄のような「「「深掘り」」」が始まります。
アイデア講師のわーみーさんに相談。「ユーザーの抽象度が高すぎてポイントを絞れないんじゃないかな」ユーザーの抽象度ってなんやねん…
ユーザーを固定してみる。固定したはいいけどユーザーの抽象度がよくわかってないから固定できたのかわかんねえ…
これってシステムで解決できる問題なのか…？
ペルソナってどうやって出せばいいの…？
このままペルソナ一つづつやってたら時間溶けまくらない…？
亀のような進行度で議論が進み、だいぶみんなの頭が沸騰してたと思います。
答えに近づいていっているのかわからない、でも今更もどったら確実に時間がない、でもこれ以上アイデアが出ない。
わーみーさんの「あとほんのちょっとでいいアイデアが出そう」という言葉を信じて、自分はあとちょっと同じテーマでがんばりたいとみんなに伝えました。多分ここら辺がいちばんしんどかった。
全部立ち返るか、そのままのテーマで進むのかの選択はかなりの分岐点だったと思います。
そのままのテーマで進むことがきまり、具体的なペルソナを出すために身近な人にインタビューをし、改善点を探すもののシステムで改善できるような部分が見当たらない。
そこにれぞさんの「時間軸を変えて考えてみたらいいんじゃない？」という最強の言葉が投下され、今までの地獄が一変します。
まってなんかこれいけそう、みたいな雰囲気が流れ始めて、ついに、とうとう、満を辞して、アイデアが固まります。
ここまで丸4日。どれだけつらかったか、みなさんわかっていただけましたか？
コーディング開始！とはいかない
アイデアが無事出たら、うおおおおコード書くぞ！！！とはならないことはTreasure経験した皆さんならわかると思います。
ここにきて初めて、アイデアを固めることの大切さに気付きました。アイデアがフワフワしているとサービスに必要な機能が定まらないし、そのあとの設計に移れない。
僕たちは事前にばっこりとMVPを固めたことで設計にはそこまで時間をかけずに終わらせることができました。しかし、残された時間はあとたった3日。
妥協しないと決めたものの、時間内に終わらせるためには設計に優先順位をつけて最低限の実装を終わらせなければいけません。
頑張ればここまでいける、というラインを決めて、1日の目標を決めてコーディングに入りました。
爆速コーディング
実際にコードを書き始めてからは、チームメンバーがエゲツないスピードで開発を進めていきました。
外部サービスとの接続、credential管理、各画面とのつなぎ合わせ… 自分が小さなところで詰まっている間に、みんなが各自頑張ってくれました。
一番最後の最後までサービスとして成立するのか（最低限の機能が備わり、動く状態になるのか）が不透明だったものの、最終日前夜の深夜1時ごろにすべてがつながり、本番環境で動作した時は「マジですげえ…」としか言いようがなかったです。
結局最終日の朝6時までスタイルを当てたり実装が続き、なんとか見せられる形になって完成しました。1時間だけ寝て、発表資料を作って発表。
妥協せずに頑張ったかいがあり、無事にグランプリ・UI/UX賞・ニーズ賞というすべての目標を達成することができました。
Treasureで学んだこと
めちゃ長文になってすみません。ここからは個人的にTreasureに参加して、チーム開発を初めてしてみて勉強になったことを書いていきます。
「予定は往々にしてうまくいかないものなので」
これ最初に誰がいったのかもう覚えていないんですが、Treasure期間中に5回以上は言っていると思います。
最初のアイデア出しの日程もそう、設計の段階もそう、予定はつくったところで基本的には延びることになる。
その中でも本当に大切にしなきゃいけないものはなんなのか全体で共有しておかないと、すべてがうまくいかなくなる。
戻ることを提案する勇気
アイデア出しを始めて2日目、チーム内に「早くアイデアを決めないといけない」という焦りのある中で、まとまりのないアイデアに対して一旦考え直すことを提案できたことはとてもよかったなと思っています。
そして、今までやってきたことを自分の一声で無に返すのではないかという恐怖がそこにはあること、それでも戻ることが提案できればさらによいアイデアが出せることがわかりました。
チームメンバーに本音で話そう、とここで思えたのもよかったです。
フロントだから、バックエンドのコードは見なくていいわけじゃない
今までフロントエンドエンジニアと自分で名乗ってきたけど、今回Treasureに参加して、フロントエンドはバックエンドがわかった上でこだわれる領域なんだということがわかりました。
APIを叩いてうまくいかないとき、データをバックエンド側に送ったとき、DBやバックエンドのコードを読むことは避けられません。
今までサーバーレスのシステムばっかり触ってきた自分にとっては、このプログラミング初心者みたいな気付きをやっとできました。
人をいい意味で待たずにどんどん自分から実装していく、そんな姿勢を持っているチームメンバーを見てとても意識が高まりました。
チーム開発では指示待ち人間にならない
「指示待ち人間になるなァ！」って中学校の部活でよく言われていたんですが、チーム開発でもそうだと感じました。
APIがバックエンド側でできておらず、データが取れない状態だったとしてもフロントエンド側で理想のデータを作って表示させることくらいはできる。
個人個人が最速の動きができていれば、時間がなくても実装はできるんだなぁと感じました。
自分の得意な領域
開発の面ではチームメンバーがすごくてあまり自分の得意というものが見つけられたかは曖昧ですが、「チームで開発をする」という点では、自分は他の人の意見を聞きながらもそれをまとめて自分で次に進もうとすることが得意なんだなと気づくことができました。
これはきっと誰しもが持っているものではないし、これにさらに技術力がつけば最強のエンジニアになれそう、と自分で勝手に思ってます。
みんなで一つのものに向かって全力で取り組むのはやっぱり楽しい
チーム開発の醍醐味ですね。僕は今までチーム開発と言えるものをやったことがなかったので、本当にいい経験になりました。
僕ももっと勉強して、みんなと肩を並べるくらいの技術力を持って、今回作ったサービスの続きを是非つくりたいと思っています。
総括
いかがだったでしょうか。他の方が書くようなレポートというよりかは感想文みたいな感じになってしまいましたが、この記事を見て少しでもTreasureに興味をもってくれたら、是非参加してみて欲しいです。
アイデア出しではとても苦労しましたが、その分得られるものがとっても多くて、この1ヶ月でだいぶ成長することができたと思っています。
あと、僕の周りには高い技術を持った同年代の人が少な（特に研究室にはいない）かったので、参加するだけで刺激になりました。チームメンバーのみんな、ついていくことしかできなくてごめん。
僕は学会や部活の大会があるため他のインターンシップには参加予定はないので比較することはできませんが、Treasureは得るものだらけの間違いなくおすすめのインターンです。チームメンバーのみんな、サポーターのみなさん、一緒にTreasureに参加してくれたみんな、ありがとう！これからも頑張ります！
サマーインターン選考奮闘記
こんにちは、6月にブログ更新したいな…と思っていたけど授業が忙しすぎて結局更新できなかったじゅぎのんです。
ブログに書きたい内容は山ほどあるんですが、如何せん時間がない！中途半端な文量だったり内容の薄い記事は書きたくないので、これからもできるだけ時間を見つけて書ければいいな。
さて、今回の記事は表題の通り「サマーインターン選考奮闘記」です。この時期になるとエンジニア志望の22卒はそわそわしているんじゃないでしょうか？
割とほとんどの名の知れた会社は選考が終わっているものの、まだ選考中やエントリーができる会社も多くあるし、まだ間に合う！
22卒だけじゃなくてそれ以降に就職をする人にも備忘録としてまとめます。
応募しようとしたきっかけ
まず、僕は学部3年のころからとあるスタートアップの会社でフロントエンド開発者として長期インターンに採用されていて、今も仕事は続けています（だんだん高度になってきた）。
なのでそもそもサマーインターン自体に関してはそこまで関心がなかったんですが、応募しよう、となったきっかけはサポーターズというサービスを知ったことでした。
じゃあサポーターズをどこで知ったのかという話なんですが、それは研究室の先輩のおすすめでした。
卒研発表が終わって春休みに入り、一応進捗は出しておこうということで同期はいないけど先輩と一緒に研究室で進捗発表とかをやっていた時期があり、そのときに現M2の先輩と話しているときにおすすめされました。
最初は「なんか胡散臭そうなサービスだなぁ」みたいな感じに思ってたんですが、とりあえずプロフィール登録だけは別にしても損じゃないし一応しとくか、程度のノリで登録しました。
10社連続面談
サポーターズに登録したあと、正直そこから何したらいいのかわかんなかったので放置してたんですが、割とイベントやります！みたいなメールはちょくちょく来ていました。
そのとき偶然目についたのがこれでした。
急に呼び捨てにされたメールが届いたので、最初「は？」って思ってたんですがよく読んでみると特別招待らしく、これ参加すると追加で5000円あげます！って言われていました。
イベントの内容は企業10社と30分ずつで連続に面談して、今後の就活に生かそう！あわよくば夏のインターンの選考スキップしよう！みたいな感じです。
昼前から夜ごろまでかかるイベントでしたが、15kもらえるんだったら時給換算してもそこまで損じゃないなー、という感じだったので受けてみることにしました。ﾎﾟﾁｯ。
このメールを見たのが3月末で、4月中旬にイベントがありました。イベントでは最初に各企業の会社説明と夏のインターンに関する情報を聞き、その後一人一人別れて面談が始まるという感じです。
そのときのメモ書きはこんな感じ。
面談では、軽い自己紹介で今まで自分が何をやってきたのか概要に触れ、今後どうしていった方がいいのかとか、その会社のいいところとかを聞いていきました。
自分は学部3年からインターンをやっていますが、実際のところ真剣にプロダクト開発をしたのはReact Nativeによるネイティブアプリ開発だけだったので、そこを重点的に話し＋今（面接時点）Reactでポートフォリオを作っています、という話をしました。
最初面談と聞いていたので、どこの企業も自分に対して柔らかい物言いをしてくれるんだろうな、とか思っていたんですがぜんぜんそんなことなく、割と辛辣な意見も多く来ました。
自分の主観なのでわからないですが、正直他の参加者よりかは圧倒的に自分の開発力は低く、このままだと置いていかれそうだな、と思ったのが本音です。
ちなみに一番エンジニアとしてきつかったのは、A社からの「決してじゅぎのんくんに技術力がないといっているわけではないからね」と、C社の「じゅぎのんくんはいい意味でエンジニアっぽくないので〜〜〜」でした。
どちらの企業さんもネガティブな言葉ではないのは理解できているんですが、やっぱり自分はまだまだだなぁと感じ、そこで「今のままでインターンやっていてもあんまり成長できないのでは？」と思ったことがサマーインターンに応募しようとしたきっかけになるかな。
ちなみに、そのイベントでは企業さんから面談後にフィードバックで数行の文章と一番よかった点みたいなので4つくらいのカテゴリーにわかれて評価されるんですが、
こんな感じでした。
あと、自分が他の参加者に比べて最低レベルみたいなことを書いていましたが、一応このイベントは選考があったらしく、56人くらいから18人？選ばれていたみたいです。機会をくれたサポーターズに感謝。
サマーインターン選考スタート
無事イベントが終わり、今度は各企業のサマーインターンの選考フェーズに入っていきます。
結果から言うと、応募したのは5社、書類選考落ちが1社、面談で選考落ちが2社、自主辞退が1社、そして合格が1社でした。
予定的に自分は1社インターンに参加するのが限界で、もともとから1社受かった場合は他の選考を蹴ろうと思っていたので、自主辞退はその1社です。
選考が終わった企業に関してはもう大丈夫だと思うので、具体的にどの企業でどんなことが聞かれたのか覚えてるだけ書いておきます。
1社目 Sansan株式会社
Sansan株式会社は連続面談を受けたときにもとても印象がよく、インターンがあれば是非受けてみたいなと思っていました。
面談後にイベントに特別招待され、LT会にも参加させていただき、社員の方がどんな開発フローを採用しているのかとか、今の仕事をやっている経緯だとかを説明してくれました。
インターンの内容は基本的にバックエンド寄りで、それに付随してあるといい知識としてReactやSwift,Kotlinなど、と言う感じでした。
自分はバックエンドをその時はチュートリアルをやったくらいで正直知識が全くない状態だったので、それでも選考に進んで大丈夫なのかLT会のときに伺ったところ、キャッチアップが間に合えば問題ないとのことだったので選考に入ることにしました。
印象としては、Sansanが一番エントリーシートが長かったです。他の企業はESスキップでいきなり面談のところも多かったので。
書類選考を無事に通り、次に面談となり、面談では一人のエンジニアの方とお話しました。
その方は僕の通っている電気通信大学の学部卒で、結構話しやすくてよかったです。
でも、やっぱりバックエンドの知識がほぼ0に加え、インターンができる期間もそこまで長くない（自分の希望としては2週間だった）ので、もしかしたら厳しいかもね、という話をして終わりました。
Sansanの面談はそこまで技術的な面を聞かれるわけではなく、インターンに参加できる日程とかキャッチアップできそうか、みたいな話中心でした（あと自分がめちゃ質問してた）。
案の定落ちました。
2社目 株式会社DeNA
もともとDeNAは受ける予定がなかったんですが、部活の練習をしているときに急に電話がかかってきて、なんだと思ったらDeNAの人事の方で選考受けませんか、という内容でした。
受けるだけならタダだしと思って快諾、その週末に面談をしました。
結論、DeNAが一番技術的に強そうで自分には手が届きそうにありませんでした。
今まで面談しかやってこなかったので、とくに聞かれたことスラスラ答えれば問題ないでしょ、と言うイメージで面接に挑んだんですが、
- 今開発しているプロダクトで大変だった場面、それをどうやって切り抜けたのか？
- 今開発しているプロダクトはなぜその言語を使ったのか？技術選定のポイントは？
- 自分で問題解決に向けて具体的にやったことは？
- 今注目しているOSSは？なぜそのOSSに注目しているの？
- もしインターンに採用されたらどんなことを得て終わりたい？
基本的にこんな感じのことを聞かれ、OSSは「えっ…とぉ……AR.jsですかね…僕は近い未来スマホってなくなると思っててー、ARの技術って今すごく注目されているじゃないですか…もし眼鏡型デバイスとかになったとき、ARは今より大事なものになると思うんですよ…AR.jsはウェブでARが表現できるんですけど、まだ発展途上な部分も多くて注目してます」
という切り抜け方をしました。スマホがなくなるとはあまり思っていません。
DeNAの面接が一番緊張しました。でもこれらの質問がうまく答えられるくらい開発をいっぱいすれば、DeNAも夢じゃないのかもな、という若干の希望も持てたので面接してよかったです。
まあ落ちました。
3社目 DMM.com
書類選考で落ちました。
4社目 レアゾン・ホールディングス
面談イベントのときに、ここの方にじゅぎのんさんはうちにぴったりだと思う、ということで、React Nativeでのアプリ開発を唯一10社のなかでやっている企業がレアゾンHDでした。
React Nativeのつらいところとか、逆にコストが低くていいこととか共感する話ができてとてもよく、インターンの選考もメールで進んでいきました。
その後人事の方と面談があり、そこで「今選考中の他のインターンにいきたかったらそっちを優先してもらってもかまわない、うちは時期にかかわらずいつでも受け付けているので他の企業にいった方がいい場合もある」という話をされ、ちょうどそのとき選考中（合格した企業）だったので、一旦止めておいてもらいました。
その後、無事に別の企業の方で合格がいただけたのでそこで連絡をして夏期間でのインターンは辞退、ということになりました。
人事の方との面接は技術的なことは全く聞かれず、日程のことや業務内容のこととかのみのお話だったのでスムーズに進んでいた印象です。
5社目 株式会社VOYAGE GROUP
こちらの企業はイベント後にES提出が免除になる期間があり、そこで選考に混ざろうかな〜〜とか思って他の企業の選考に頭を回していたら、いつの間にかES免除の期間が終わっており、やべえ！！と思いながらもワンチャンこれメールすれば免除で大丈夫じゃないか？と思い、期限がすぎた翌日にメールでオナシャス！と送ったところ、快くES免除を受け付けてくれました（この時点で選考は本気で挑むと決めた）。
選考としてはエンジニアの方・人事の方と面談があり、その後適性テスト？アンケート的なものに答え、その後参加の可否を聞かれると同時に合格の通知が渡されました。
エンジニアの方はとても柔らかい感じの方（DeNAとかに比べると）で、僕が今まで作ってきたものに対して的確なアドバイスをしてくれました。
個人的には面談イベント前から作っていたポートフォリオサイトが完成していたことがおおきかったと思います。
1人目のエンジニアの方とは長期インターンでやってきた内容（React Nativeでアプリ開発をしてきたこと）を中心に、難しかったことや大変だったこと、よかったことなどを聞かれ、flutterというのもあるからみてみるといいよ、というアドバイスをいただきました。お恥ずかしながら自分はflutterというものをそのときまで知りませんでした。
2人目のエンジニアの方は、1人目の人と違う話をしていいよ、といっていたのでせっかくならと思いポートフォリオサイトを一緒にみながら自己紹介をしました。そのとき、自分はES免除だったものの多分サポーターズの自己紹介欄のところがまんまESとして渡されていて、当時開発中だったURLを向こうに送っていて、面談をやるまでは向こうのURLでは真っ白の画面が表示されていたっぽく、
「あ、ちゃんと表示されるように完成しているんだね！もしなにかしらエラーで表示できていなかったら今ここでペアプログラミングしようと思ってたんだよ」
と言われました。それはそれで面白かったかもしれないけど、完成したものを見せることができてよかったです（ポートフォリオに関してもブログ書いていないので書きたい）。
あと、自分が採用される決め手になったのか？と思う点は、「今まである程度複雑な開発をしてきているものの、チーム開発を経験したことがない」という点です。
ここのインターンでは講義と開発に別れていて、開発ではチーム開発が行われます。なので、結構チーム開発の経験が聞かれるんですが僕はそれがありませんでした。
そこを逆にアピールして、「このインターンだと今まで経験できなかったチーム開発が経験できるのでここがいい」といったところ、なるほどね〜、という感じで納得してもらえました。
2名のエンジニアの方と面談した後は人事の方と面接がありました。今までの他の企業とは少し違った質問をされました。例えば
- 今までで一番情熱を注いだものは？
- 今一番はまっているものは？
- 他人からみた時、あなたの短所はなんですか？
- なにかのリーダーになって動いたことはありますか？
など。幸いにも僕は陸上競技部で主将をやっていたし、陸上に情熱を割と注いでいたし、プリパラにはまっていたし（これはガチで人事にプリパラにはまってるんですよっていった）、比較的スラスラと答えられてこっちも楽しかったです。
プリパラの話をしたとき、あっやべぇこれはドン引きされたか！？と思いましたが、「え〜！すごい、そんな深いストーリーなんですね！みたくなりました！」（お世辞）といってもらえて嬉しかったです。
その後、適性テストというかなんか心理テストみたいな紙に記入してください！みたいなのがきて、その数日後に電話がかかってきました。
日程に確実に参加できるか確認された後、ではじゅぎのんさん、合格です！とテンション高めで言われ、僕もテンション高めでまじっすか！ありがとうございます！と返しました。
そのあと数時間（いや数日）はテンション高めでした。
総括
そんな感じで今にいたります。ということで、8月はサマーインターンに参加してきます！そこでは自分がまだ触れたことのない言語やチーム開発が経験できるので、確実に自分の糧になると思っています。
もしコロナウイルスのこの状況じゃなかったら、部活で夏のインターンには行けていませんでした。そのことを考えると、ポートフォリオを作れたことやインターンの選考に入れたこと、採用されたことはやっぱり巡り合わせだなと感じます。
今できることを全力でやっていくので、部活も研究も仕事も一切手を抜かずにこれからも頑張ります！
インターンが終わった後はきっと報告記事があがるので、乞うご期待です。長くなりましたが、応援よろしくお願いします！
【くどすぎる解説】深さ優先探索・幅優先探索【python】
こんにちは！お久しぶりです、毎月月末になると「あっ、ブログそろそろ更新しないと…」と思いギリギリで更新しているじゅぎのんです。
最近（4月から）AtCoderを始め、現在もう少しで茶色に到達できそうな僕です。
就活を始めるまでにはある程度の色に、アルゴリズムについては一通り大丈夫と言えるようになりたい！
AtCoder強者の友人達にいろいろと教えてもらいながら頑張っています（友人たち本当にありがとう）。
友人達の解説はすごくわかりやすいのに、ネットで調べるとあまりにも意味不明な解説とコードが多い（自分の読解力が足りなさすぎる）ので、
今回から【くどすぎる解説】シリーズということで完全に自分のための備忘録として復習がてらいろんなアルゴリズムのコードをクッソくどい解説文を入れながら書いていきたいと思います。
使用言語はpythonです。おそらく強者から見ると「なんでそこそんなコードで実装してんの」とか思われるかもしれないですが自分の備忘録なので指摘するなら優しくしてください（心が弱いので）。
深さ優先探索
DFSですね。くどすぎると言っても深さ優先探索がどんなものかはさすがに知っているので割愛します。深さを優先して探索するやつです。
具体的な問題だと、AtCoder Typical Contest 001 A - 深さ優先探索
ですね。これ解説付きなのでこれ見ろよって話なんですが（ていうかこっちの方が多分わかりやすい）。
入力
4 5 s#### ....# ##### #...g
"4"が縦の長さ、"5"が横の長さ。"s"はスタートで、"g"はゴール。"#"は壁で進むことができず、"."は道で進むことができます。道を通ってsからgまで行くことができれば"Yes"を返し、gまでたどり着けない場合は"No"を返します。
回答と解説
import sys
sys.setrecursionlimit(10 ** 9)
HW = input().split()
H,W = int(HW[0]), int(HW[1])
S = [input() for _ in range(H)]
reached = [[False] * W for i in range(H)]
def search(x,y):
#迷路の外か壁の場合は何もしない
if(x < 0 or H <= x or y < 0 or W <= y or S[x][y] == "#"):
return
#以前に到達していたら何もしない
if(reached[x][y]):
return
#到達した
reached[x][y] = True
#4方向を試す
search(x+1,y)
search(x-1,y)
search(x,y+1)
search(x,y-1)
for i in range(H):
for j in range(W):
if(S[i][j] == "s"):
StartX = i
StartY = j
if(S[i][j] == "g"):
GoalX = i
GoalY = j
search(StartX,StartY)
if(reached[GoalX][GoalY] == True):
print("Yes")
else:
print("No")
まず
import sys sys.setrecursionlimit(10 ** 9)
これですね。深さ優先探索をするときは再帰を使うんですが、なんかpythonだと再帰の回数が多くなるとエラーがでてしまうようで、それを回避するためにこのコードを入れています。sys.setrecursionlimit() で再帰回数の上限を変更することができます。まあとりあえず10の9乗にしとけば大丈夫だろ…ってやったら通りました。ここの数字は特に何も考えてません。
HW = input().split() H,W = int(HW[0]), int(HW[1]) S = [input() for _ in range(H)] reached = [[False] * W for i in range(H)]
入力です。"H"を縦、"W"を横の長さ。Sは二次元配列でH行読み込んでます。 reachedは探索を終えたか終えていないかをboolでいれておく二次元配列。
一旦関数の def search(x,y): を飛ばして、実行順で進んでいきます。
for i in range(H):
for j in range(W):
if(S[i][j] == "s"):
StartX = i
StartY = j
if(S[i][j] == "g"):
GoalX = i
GoalY = j
ここは単純にスタートの位置とゴールの位置を見つけるためのコードです。"i"が行、"j"が列で、二次元配列Sに"s"があればStartX,Yにi,jを入れる。同様に"g"があればGoalX.Yにi,jを入れる。
search(StartX,StartY) ここでsearch関数が呼び出され、先ほど飛ばした部分に入ります。
def search(x,y):
#迷路の外か壁の場合は何もしない
if(x < 0 or H <= x or y < 0 or W <= y or S[x][y] == "#"):
return
xにはStartXが、yにはStartYが入ってきます。コメントに書いてありますがここのif文は迷路の外か壁かを判定しています。
- 「迷路の外」…
x < 0 or H <= x or y < 0 or W <= y - 「壁」…
S[x][y] == "#"
ですね。ここで自分でもは？ってなったのが、xは縦軸、yは横軸となっている部分です。自分で実装してて意味わからなくなるのほんとバカなんですが、x軸は横でy軸が縦だから H <= y or W <= x じゃね？って思ってしまったんですが、さきほどのStartX,Yを見ると
"i"が行、"j"が列で、二次元配列Sに"s"があればStartX,Yにi,jを入れる。
としているのでxが縦でyが横で合っていますね。縦横とxyを合わせたい場合はStartXにj,StartYにiを入れるのがいいのかも（それだとこっちのコードがは？ってなってしまいそうですが）。
続きます。
#以前に到達していたら何もしない
if(reached[x][y]):
return
#到達した
reached[x][y] = True
コメントの通りですね。reachedは探索を終えたか終えていないかをboolでいれておく二次元配列なので、一番最初は全部Falseです。探索を行った部分は後ろのコードでTrueになるので、以前に到達していたらreturnされて終わりです。
#4方向を試す
search(x+1,y)
search(x-1,y)
search(x,y+1)
search(x,y-1)
4方向を試します。ここでやっていることは、例えば"s"が2行目3列目にあったとすると、
- 3行目3列目を探す
- 1行目3列目を探す
- 2行目4列目を探す
- 2行目2列目を探す
ですね。ここの順番は特に関係ありません（今回の問題は）。再帰なのでここで4つのルートに分岐して、また分岐した先で4つのルートに分岐して…と続きます。
ただ、再帰元の場所は少なくともすでに探索済みなので、reachedにTrueが入っておりなにも起こらないので、実質3つの分岐ということになります。
これで関数部分終了。最後に、
if(reached[GoalX][GoalY] == True):
print("Yes")
else:
print("No")
"g"が書いてあった部分がTrueになっていれば、探索し終わった=そこまで進むことができるということになり、"Yes"を返す。もしFalseだったら"No"を返す。
簡単ですね。さすがに書いてて「くどすぎるだろ…」と思いました。まだまだくどくいきます。
幅優先探索
BFSですね。くどすぎると言っても幅優先探索がどんなものかはさすがに知っているので割愛します。同じ階層を優先して探索するやつです。
具体的な問題だと、AtCoder Beginner Contest 168 D - ..(Double Dots)が最近で幅優先を使いました。
入力
4 4 1 2 2 3 3 4 4 2
一行目の左側の"4"が部屋の数、右側の"4"が通路の数。二行目以降は通路が繋ぐ部屋を指します。
つまり、この入力だと
こうなりますね。そして、部屋1以外のすべての部屋から、最短で部屋1に行く時、通るべき部屋の番号を各部屋に道しるべとして置きます。
つまり、上の入力例でいうと、
- 部屋2から1に行く時 : 直接1に行けるから、"1"を置く。
- 部屋3から1に行く時 : 3 -> 2 -> 1と行くのが最短なので、"2"を置く。
- 部屋4から1に行く時 : 4 -> 2 -> 1と行くのが最短なので、"2"を置く。
よって、出力は
Yes 1 2 2
となります（1にたどり着ける場合はYesを出力）。
回答と解説
N, M = map(int, input().split())
link = [[] for i in range(N)]
for i in range(M):
A, B = map(int, input().split())
link[A-1].append(B-1)
link[B-1].append(A-1)
visited = [False for i in range(N)]
result = [0] * N
Q = [0]
visited[0] = True
#Qに要素がなくなるまで
while Q:
#一番上の要素をpop
v = Q.pop(0)
for i in link[v]:
if visited[i] == False:
visited[i] = True
result[i] = v
Q.append(i)
print("Yes")
for i in range(1, N):
print(result[i] + 1)
N, M = map(int, input().split())
最初の行の入力。Nは部屋の数、Mは道の数。
link = [[] for i in range(N)]
この配列はすぐ下で解説します。
for i in range(M):
A, B = map(int, input().split())
link[A-1].append(B-1)
link[B-1].append(A-1)
ここでは入力と操作を一度に行っています。
M行を1行ずつfor文で読み込んでいきながら、入力の左の数字と右の数字をそれぞれA,Bにいれます。
先ほど作成したlink配列の、A-1番に要素B-1を、B-1番に要素A-1をいれています。
つまりどういうことかというと、道によって繋がっている部屋を添字番号によって管理しているということです（説明が下手）。
上の入力例では、link配列はこのようになります。
link = [[1],[0],[1,3],[1,2]]
- 部屋1（0番）は部屋2（1番）とのみ繋がっているので、link[0]には1が入る
- 部屋2（1番）は部屋1（0番）とのみ繋がっているので、link[1]には0が入る
- 部屋3（2番）は部屋2（1番）と部屋4（3番）に繋がっているので、link[2]には1と3が入る
- 部屋4（3番）は部屋2（1番）と部屋3（2番）に繋がっているので、link[3]には1と2が入る
といった感じです。番号が-1になっているのは単純に配列の添字が0から始まるからです。
visited = [False for i in range(N)] result = [0] * N
visitedは深さ優先探索の時と同じように、すでに探索し終わった場所をboolで保存しておく配列です。
resultは今回の出力（各部屋に置く道しるべの数）を保存しておく配列です。問題が変わればこの部分も変わります。
Q = [0] visited[0] = True
ここから幅優先探索のスタートです。まず、QはFIFOの動作をするいわゆる「キュー」で、探索する添字番号を指します。最初は0番（部屋1）からなので、Qに0をいれます。
visitedは先ほど言ったようにすでに探索した場所の情報を保存するもの。現在0番（部屋1）を探索したので、visited[0]にTrueをいれます。
#Qに要素がなくなるまで
while Q:
#一番上の要素をpop
v = Q.pop(0)
if文に配列を入れると、配列に要素がある場合はtrueを返すことを利用してQに要素がなくなるまでのループとして while Q を使用します。
pop(x)を使うと、xにある要素をpopすることができます。キューなので、先頭の要素を出し、vに代入します。ここでは、Q=0しか入っていないので0がvに代入されます。
for i in link[v]:
if visited[i] == False:
visited[i] = True
result[i] = v
Q.append(i)
v=0の状態で、for文に入ります。link[0]には、部屋1（番号0）に繋がっている部屋の番号（[1]）が入っているはずです。よって、iには1が入ります。
次に、探索を行ったか判定します。今回はvisited[0]以外はFalseになっているはずなので、if文の中に入ります。
visited[i] = True で探索済みとマーク。
result[i] = v とすることで、「部屋番号iから直接繋がっている部屋番号はv」という情報をいれることができます。つまり、「部屋2（1番）から直接繋がっているのは部屋1（0番）」ということになります。
Q.append(i) で、現在空になっているQ（キュー）にi（1）をappendします。こうすることで、今度は部屋2（1番）から直接繋がっている部屋を探索することができます。
ここまでくるとわかると思いますが、「直接繋がっている部屋」ごとに探索が行われているということは、各階層ごとに探索が行われるということです。
各階層ごとに探索ができるということは、探索する部屋の深さを知ることができるということです。こんな感じに書けば階層がわかります。
result = [-1] * N
result[0] = 0
#Qに要素がなくなるまで
while Q:
#一番上の要素をpop
v = Q.pop(0)
for i in link[v]:
if result[i] == -1:
result[i] = result[v] + 1
Q.append(i)
サイズNの配列すべてに-1をいれたものをresultとし、先ほどのvisitedと同じ役目を果たすようにします。
もし探索されていない（-1）だったら、そこにresult[v]+1を入れることで、先ほど探索された階層+1が現在の階層のノードに入ることになり、深さを調べることができます。
print("Yes")
for i in range(1, N):
print(result[i] + 1)
そして、最後に結果を出力します。問題文には「どの2部屋間も、通路をいくつか通って行き来できます」とあるので、道しるべが置けない部屋というのは存在しないので必ずYesを出力します。
最後に道しるべをいれたresult配列をprintすることで回答できます。
おわりに
いかがだったでしょうか。（というかここまで読んでくれる人はいるんでしょうか） 文字で起こすとやっぱり自分で理解できていない部分をもう一回確認できるのでとてもいいですね。これからもちょくちょくくどすぎる解説シリーズを更新してみようかなと思います。明日のABC頑張るぞ！
React Native v0.62.2でGoogle AdMobを設定する
Qiitaにも同様の内容の記事を載せています。LGTMﾖﾛｼｸ
AdMob難しすぎだろ問題
3月末くらいに、じゃあ次のタスクはということで渡されたのが「React Nativeで作成しているアプリにバナー広告を出したい」というものでした。とっても実務的ですね。
これを参考に進めてくれと言われ渡されたページを読んでも 何も理解できない 。大抵こういう全く触ったこともないものに触れる時は何も理解できなくて最初の数時間は本当につらいんですよね。。
React Nativeあるあるだと思うんですが、とりあえず新しい課題ができたら「React Native ○○」でググって特になにも出てこずに結局わからない。
今回は幸いいくつかの手段で実装している記事が存在したので、そちらを参考にしながら進めていました。
しかし、如何せんメジャーバージョンが未だリリースされていないReact Native。
バージョン0.5xと0.6xで全然挙動が違ったり、エラーコードがえぐい量きたりもう大変です。そろそろメジャーアップデートきてくれない…？
最初にv0.59.1で実装を進めており、iOSの方は無事表示することができました。
やったー！と思ったのもつかの間、長らくシミュレーターを起動していなかったAndroidを起動させようとするも、つかない。
エラーメッセージをとりあえず全部超スゴイ先輩に見せると、
Android studioのgradleのバージョンが上がってしまい、依存関係がおかしくなって起動しなくなっている。 ここから一個ずつ依存関係をみていくのは時間がかかるから、新しいReact Nativeのプロジェクトを作り直して設定とかコンポーネントを全部写した方がいい
と言われてしまいました。
そんなこんなで広告を追加しようとしたらReact Nativeのバージョンをあげることになっていたんですが、0.59.1から最新の0.62.2にあげるのにどれだけ苦労したか。永遠に現れる真っ赤な画面をため息つきながら直していく作業は全然楽しくなかったです。
なんとか中身を写し終えて、iPhoneとAndroid両方で起動が確認できてから、いざAdMobに取り掛かる。
が、しかし…！
最初と同じ方法でやっても実装できず。ここで完全にやる気がなくなって他のことをやり始めました。（それが先週）
そして週を跨いだ今日、やる気が戻ってきてもう一回みてみるか…とちょいちょいっとやってみたら無事実装できました。
その方法がこれだ！！
React NativeにGoogle AdMobを導入する際、情報が古かったり同様の方法でやってもうまくいかないことが多かったので、詳細に導入方法をまとめてみます。
Google AdMobを利用する際には現時点で2つ方法があります。
- react-native-admobを利用する方法
- react-native-firebaseを利用する方法
今回はreact-native-admobを利用する方法について説明します。
導入した環境
React Native 0.62.2（2020年4月時点最新）
iOS 13.3 CocoaPods
Android 6.0
実装した広告: バナー広告
iOS
react-native-admobのREADMEと同様に進んでいきます。
- npm or yarnでreact-native-admobをインストール
npm i --save react-native-admob@next もしくは yarn add react-native-admob@nextでインストールします。
今回はyarnを使いました（npmの方だとうまくいかない時があったので）
Google AdMob公式を参考に進んでいきます。
事前にAdMobアカウントを作成・アプリ登録を済ませたあと、対象のアプリケーションにMobile Ads SDKをインポートします。
pod 'Google-Mobile-Ads-SDK
をiosファイルの中にあるPodfileに書き込み、
pod install --repo-update
- Info.plistの更新
iosファイルの中にあるInfo.plistに GADApplicationIdentifier キーとAdMobアプリIDの文字列値を追加します。
<key>GADApplicationIdentifier</key> <string>ca-app-pub- 3940256099942544~1458002511</string>
- AppDelegate.mの変更
//新しく追加するコード
@import GoogleMobileAds;
@implementation AppDelegate
- (BOOL)application:(UIApplication *)application
didFinishLaunchingWithOptions: (NSDictionary *)launchOptions {
//新しく追加するコード
[[GADMobileAds sharedInstance] startWithCompletionHandler:nil];
return YES;
}
@end
自分の場合、すでに何行かコードが書いてありましたが、 @implementation AppDelegate の直上に @import GoogleMobileAds; を入れ、
UIViewController *rootViewController = [UIViewController new]; //ここに新しく追加 [[GADMobileAds sharedInstance] startWithCompletionHandler:nil]; rootViewController.view = rootView;
このように追加しました。
- react-native-admobをimportし、コンポーネントを配置
import { AdMobBanner } from 'react-native-admob'; とし、下のように配置しました。
render() {
return (
<AdMobBanner
adSize="fullBanner"
adUnitID="AdMobでアプリを登録した時に表示されるAppID"
testDevices={[AdMobBanner.simulatorId]}
onAdFailedToLoad={(error) => console.error(error)}
/>
...
このようにテスト広告が表示されれば成功です。
Android
- npm or yarnでreact-native-admobをインストール
iOSと同様にインストールします。
android/build.gradleの中に
allprojects {
repositories {
google()
}
}
があることを確認して、今度はandroid/app/build.gradleの中に以下のコードを追加します。
dependencies {
//追加
implementation 'com.google.android.gms:play-services-ads:19.1.0'
}
次に、android/src/main/AndroidManifest.xmlに以下のようにコードを追加します。
<manifest>
<application>
<!-- Sample AdMob App ID: ca-app-pub-3940256099942544~3347511713 -->
<!-- 追加 -->
<meta-data
android:name="com.google.android.gms.ads.APPLICATION_ID"
android:value="ca-app-pub-xxxxxxxxxxxxxxxx~yyyyyyyyyy"/>
</application>
</manifest>
GoogleMobileAds公式ページにはまだ下に手順が書かれていますが、追加するのはここまでです。
上記の方法でアプリをビルドしてみたものの失敗したので、解決策を探していたところこの方法で解決できました。
node_modules/react-native-admob/android/build.gradleを見ると、以下のように記述されていると思います。
...
dependencies {
implementation 'com.facebook.react:react-native:+'
implementation 'com.google.android.gms:play-services-ads:+'
}
こちらの下の段、admobのSDKが更新された影響で古いAPIと互換性が無いことでビルドが失敗していたようです。(参考)
現在の最新のadmobのSDKバージョンは19.1.0のようなので、以下のように書き直します。
implementation 'com.google.android.gms:play-services-ads:19.1.0'
- react-native-admobをimportし、コンポーネントを配置
iOSと同様の方法で配置します。
このように表示されれば成功です！
おわりに
ぱっと見そこまで複雑ではありませんが、自分はなぜか2週間くらい広告を表示させるのに手間取ってしまいました…
npmでreact-native-admobをインストールしたときに同時に古いバージョンのReactがインストールされてしまったり、podfileに記述することでライブラリをインストールしようとして失敗したり。
React Nativeで実装している記事が少なく、かつバージョンが変わるのがとても早いため、今回は備忘録としてまとめました。
現時点で最新のReact Nativeで導入する今回の記事が少しでもお役に立てれば幸いです。
