リクルートホールディングスのインターンシップに参加しました
はじめに
リクルートでのインターンシップがようやく終了したのでそれのまとめです。職種はデータサイエンティストというやつで,以下の2つのコースに参加していました。
- 夏インターンシップ
- リクルートホールディングスのサマーインターンシップ。2週間で集中してやる。
- 就業型インターンシップ
いちおう両方に参加していたというのと,なんだかんだ学びはたくさんあったので,ちょっとずつ書いていこうと思います。
なんかいっぱい書いてたら長くなってしまったので,主に「まとめ」というところだけ読むといいと思います。
サマーインターンシップ
サマーインターンシップは2週間の集中コースでした。データサイエンティスト職の学生が5-6人,これまた5-6チームくらいに別れて各タスクに取り組んでいきます。タスクは様々で,各グループ会社から与えられた案件をそれぞれ解く感じです。
2週間という比較的短い期間なので,どうしても「もっとやりたかった感」は出てしまうのですが,なんとか最終日までに仕上げて発表することができました。データ解析系のインターンでときどきある「データが整形されていてほとんどやることが決まっている」ということはなく,ある程度は整形されているけれど どうやって解析していって,どこをどう改善するか も学生側で自由に決められるのでよかったです。ただしあまり手取り足取り教えてもらえているというわけではなく,むしろほとんど野放しでした。
また,我々データサイエンティスト()が提案した施策の良し悪しを事業部の方々にヒアリングしたり,最終プレゼンテーションも彼らの前で行ったりと,かなりビジネス色もつよいものだったといえます。
ただしはたらく環境はかなりよく,あんまり毎日時間どおりに出社しろというのは求められませんでした。MacBookProとモニタが貸与されて,大きめの会議室を貸し切ってみんなでがりがりやる感じです。椅子がそんなにいいやつではないのでちょっと大変です。途中で用事があったら1日2日休んでもいいし,朝も何時に来てもいいので最高でした。お菓子とか飲み物もいっぱい置いてありました。日当はそれほど高くはありませんが,懇親会は銀座の高級店で🍣とか🍖とかを食べられます。
↑銀座の🍣すごくて,なんか1コずつ出てくる。
まとめ
- 期間は2週間,5-6人で行う
- 学生にかなり主導権がある,研修とかはほぼない
- データサイエンスをがりがりやるというよりビジネスもする
- はたらき方は自由
実践型 長期インターンシップ
サマーインターンシップ後,希望者は実践型の長期インターンシップに進むことができます。ぼくはサマーインターンシップで若干の心残りがあったので,少しテーマが似ているものを選ぶことにしました。インターンシップ自体はリクルートホールディングスのものですが,実際にはグループ会社に配属されてインターンシップをすることになります。そんなわけでぼくはリクルートライフスタイルの配属になりました。期間はだいたい2-3ヶ月くらいです。
待遇と環境
時給はかなりもらえて,リモートも可です。でもあとから書きますが出社はした方がいいです。13インチ,メモリ16GBのMacBookProが1台貸与されます(残念ながらJISキーでした)。出社するといちおう机もあります。ただし大きいサービスということもあって,データ分析基盤はかなり快適にきちんと整っているというわけではありませんでした。
契約上は業務委託ということになっていて,給与計算をするときに「じぶんが働いた時間」を勤怠つけると終了後にお金がもらえるという形です。結構もらえたのでiPad ProとかGoogle Homeとか色んなガジェットを買いました。
長期インターンシップならではのこと
長期インターンシップならではのこととして,じっくり分析に取り組める,ということがあると思います。じゃああれ試そうかとか,これ1回じっくり見てみようかとか,かなり色んな経験が積めたと思います。ただし数ヶ月で結果を出そうとすると実はなかなか忙しいです。またチームメンバーが必ずしも同時に出社しているわけではないので,どういう風にじぶんの分析を引き継ぐか,などもなかなか大変でした。
最初に「この数字をいい感じにデータサイエンスで改善してくれ!」みたいな課題が与えられるのですが,それは「実際に解けるかどうか」はわかっていない課題です。もちろん完全な無理難題が与えられるということはないのですが,適当にやっているとなかなか解けない課題だとは思います。普通に期間中は何度も暗礁に乗り上げたし,これ結局できんのかな…みたいに弱気になったことは何度もありました。
サマーインターンシップのときと同じく,それほど手厚く手取り足取りメンターの指導が受けられるというわけではありません。聞けば教えてくれますが,結構どうするかちゃんと探していかないといけないので結構大変でした。とはいえぼくのプロジェクトはなんだかんだうまくいったので,数ヶ月かけただけの達成感は得られました。じぶんたちでやり切ったぞ!という実感は心地のいいものです。本当によかった…。
まとめ
- 2-3ヶ月,チームで行う
- がっつりと時間をかけて分析できる
- わりとふわっと課題が降ってくる
- 学生に主導権があって好き勝手できるがたまに暗礁に乗り上げる
- そのぶんうまくいくと達成感はある
- 待遇はそこそこいいけど基盤はちょっと厳しい
学んだこと
いちおうはじめて「データサイエンティスト()」という肩書きで働いたので,長期と短期を通して学んだことを書いていこうと思います。
データサイエンスはお金稼ぎである
これはデータサイエンスというよりリクルートという会社の性質であるような気はしますが,常に「それがきちんと利益を生んでいるか」ということは求められます。アルゴリズムがイケていたり,思わぬ分析結果が得られたり,というのももちろん大事なのですが,それよりも利益の方が重視されているんだなという印象は持ちました。もちろんそのへんちゃんとしないとなかなか利益に結びつかないものでもあるのですが。
データは普通に汚い
普通にデータサイエンスをやっているとわかると思うのですが,生きているデータは普通に汚いです。インターンシップとかKaggleとかをやるとある程度データはクレンジングされているのですが,現場だとそうではありません。前処理とかテクニックとか,なかなか大学や教科書では学べない,現場感のあることができたのはよかったのかなと思っています。
また今回のインターンシップを通して「データ分析基盤」はものすごく大事であるとともに,作るのはすごく大変だなと思いました。データがあちこちにあったり,拾ってくるのに時間がかかったりするとなかなか思うように分析ができずストレスが溜まります。ちゃんとわかっている人がそのへんを整備することの大事さは痛感しました。データはただ「ある」だけでは意味がないんですね。
解ける問題に落とし込んでいくことが大事
我々は学生気分なので,とりあえず雑に分析して機械学習でドーンすればいけるでしょ!とか思ってしまうことも少なくはないのですが,実際にはそういうわけにもいきません。分析しても特に優位な差が出るわけではないですし,そもそもそこから機械学習に持っていくのも一苦労でした。なにがわかっていて,なにがわかっていないのか,どこまでは分析できて,どこからは予測しないといけないのか,そのためにどのデータが必要で,どのモデルを使用しないといけないのか,などなどですね。
あとは「現場でも必ずしも精度だけを向上させる必要はない」というのも大きな学びのひとつでした。たとえばアンサンブル学習を行うと必ず精度は上がりますが,予測にも時間がかかるし実際の施策に対してはそこまで有効ではないといったことも多いです。闇雲に精度だけを上げていくのではなく,ある程度のスピード感を持って進めていく方が大事,などもなかなかアカデミックでは学べないことかと思います。
けれどそういうプロセスをちゃんと経ていくうちに,これだったら解けるかも!というのが見つかってくるものです。それを実際に試すとなんだかんだうまくいくもので,そのときの喜びはひとしおでした。逆にそういうところをちゃんと設定していかないと,山ほどあるデータと分析手法に呑まれて,無駄にリソースばかり消費してなにも結果が得られない…ということになってしまいます。
見せ方は大事
これもかなり大きな学びのひとつですね。データサイエンスはデータサイエンスだけで完結するわけではなく(当たり前ですが),実際には企画職の人からお金を取ってきてもらったり,分析結果を施策に落とすときにエンジニア職の人に実装してもらったりしなければいけません。そういうときにちゃんと「見せる」ことはものすごく大事だなと思いました。
数字や数式,一見わかりやすそうなグラフを並べていても,実際そこまで意味があるわけではないんですね。どの数字がどう変わったかということ,それにはどれくらいのコストがかかったのかということ,そもそも解きたい課題はどれだったのかということ,あたりですね。ただ単に分析をして数字を上げればいいだけでなく,きちんと伝えることの大事さは痛感しました…。
リモートではたらくのはむずかしい
今回はじめてリモートワークで働いてみたのですが,やっぱりむずかしいですね。 これは以前もツイートしたのですが 「じぶんのやれることとやれないことをきちんと理解しつつ,ある程度ひとりで調べつつ作業を進められる人」じゃないと普通に出社した方がいい場合が多くて,学生だとそれできている人はぼくを含めてほぼいません。これは首都圏で働けるからこそだということは理解しつつ,普通に出社した方がいい場合が多いなと思いました(少なくともぼくは)。ちゃんと詳しい人にときどき聞きながらの方がいいです。
また,今回はチームメンバーもリモートだったので,情報の共有はかなり大変でした。GitHubにissueいっぱい立てて,SQLと分析結果を貼る,場合によってはJupyter Notebookも,というのを思いついてなんとかしてはいました。しかしながらお互いにDMは何度も送信したし,結局対面の方がいいよねと言って集まったのも何度もあります。リモートワークでチーム開発,かなりむずかしいです。
やっぱりコードが書きたい
これはじぶん自身に対する発見というところなのですが,やっぱりコードを書いているのも楽しい人間なんだな,というところは実感できました。もちろんJupyterでコーディングはするのですが,なかなか切羽詰まってきてよくないコードを量産してしまいましたし,周りのいわゆる「データサイエンティスト」はそれほどコードが書ける人たちというわけでもありませんでした。でもじぶんはやっぱりコードレビューを受けたいし,周りのコードレビューもしたいんですね。そのへんのことがわかったのも大きかったのかなと思っています。
もちろんデータ分析や機械学習も楽しいので,データサイエンティストとしてそのへんばっかりするだけではなく,きちんとコーディングもしていきたいな,ということを思いました。
まとめ
ちなみに今回ディープラーニングはまったく使いませんでした。XGBoostはいいぞ。
- データサイエンスとはいえお金は稼がないといけない
- データは普通に汚い
- 腕力でエイヤっとやらなければいけないときもある
- 解ける問題に落とし込んでいくことが大事
- ディープラーニングってやつでなんとかなるわけではない
- 見せ方は大事
- みんなデータサイエンティストではない
- リモートではたらくのはむずかしい
- やっぱりコードが書きたい
さいごに
これだとただの感想なので,どんな人にオススメするかというのを書いておこうと思います。ちなみにチームメンバーはみんな優秀でした。
- こんなことやりたい人にオススメ
- 好き勝手やりたい人
- 実際のデータを使ってデータ解析したい人
- データ解析を使ってビジネスっぽいこともしたい人
- 有名サービスで大量のデータを使ってデータ解析したい人(キレイであるとは言ってない)
- こんな人には向いてない
- 手取り足取り教えてほしい人
- 最新の手法を使って研究っぽいことがやりたい人
- ディープラーニングしたい人
- がっつりコードを書きたい人
終わりだよ〜
Japanese Traditional Big Companyのインターンシップを2日で辞めるということ
はじめに
この夏に,とある日系企業,いわゆるSIerでインターンシップをしてきたよという話です。結局のところ「合わなかった」という話なのですが,コレは企業の側に落ち度があったとかいう話ではなく,単純に色んな出来事が重なって「ぼくとは合わなかった」という話です。また当たり前ですが,このタイトルに書いているような日系大企業一般に当てはまるということもなさそうなので,まあこういう人もいるんだなくらいに読んでおいていただけるとありがたいです。
なぜ受けたか
そもそも「お前は絶対にSIerには向いていないからやめとけ」と言われたのに受けたのには理由があります。 Web系ばかり見ていて少し不安になった というのが大きいと思います。
ずっとWeb系でインターンやアルバイトをしていて,じぶんはこのままWeb系に就職するんだと思っていました。でもやっぱり新卒というのは不安になってしまうものなんですね。まだまだ入る会社に対して中立になれる立場ですし,少しは今まで見てきた業界を離れてみるのもいいかなと思って行ってみることにしました…。今思うと行かなくてもよかったなという気はしますが。
どんな会社?どんなインターン?
いわゆるSIer,システムインテグレータと呼ばれる会社ですが。ITもコンサルもやっているのでITコンサルといったところでしょうか。超大手だし秘密保持契約を結んでいるのであんまりは書けないのですが,流通とか金融とかがつよいところだと思います。給料が高いことで有名です。(そのぶん激務らしいですが)。
インターンの内容としては,実際の業務を体験しよう!みたいな感じの5daysインターンでした。2,3人でグループになって,会社の各部署に配属されるというものです。ITナントカコースと書いてあったので,いちおうIT系の仕事をすることが想定されていたようです。
日程 | 内容 |
---|---|
1日目 | オリエンテーション・配属決定 |
2-4日目 | 現場配属 |
5日目 | 成果発表・打ち上げ |
だいたいこんな感じの日程です。5日間のうちの2日目で辞めたということになりますね…。
選考は?
Web系とはまったく違う選考でした。なんかしゅっと決まるかなと思ったら意外とめんどくさくてびっくりしたことを覚えています。
- SPI試験
- わざわざ試験場に行かないと受けられないので少しだるい
- 面接
- なんかどんなことしてきたかとか,どんなことしたいかとか聞かれた気がする
- あんまりプログラミングできるかとかは気にされてない感じだった
- グループディスカッション
- とある会社の事業戦略を決めるとかだった気がする
- 時間が少ないので色々と強引に仮定しないといけない
- ぼく以外のチームメンバーはなぜかみんな女の子だった
面接で「どんなことやってきたか」と「どんなことしたいか」を聞かれたといえば聞かれたんですけど,あとから書きますがその希望に配属されることはありませんでした。ただ今思うと「あんまりプログラミングとかする感じではないし,プログラミングとかは滅多にしないと思う」とはそれとなく伝えられていたような気はします。そこでやめろよという話はありますが,わざわざ試験場まで出向いて受けたSPIを無駄にするのも嫌だったし,受かってから考えればいいかなくらいに思っていたような気がします。
1日目
オリエンテーション
大手町の本社に9時集合とかだったので朝早いなあと思った覚えがあります。この時間設定だと通勤ラッシュと被るので勘弁してくれと思っていました。なんか明確に服装規定が書いてありましたが,そう書いても就活生はみんなどうせスーツで来ると思うのでもうスーツで来いと書いてくれればいいと思います。服装規定に抵触しないような服装で行ったのですが,スラックスとシャツで来ていたのはぼくだけでした…。
なんかそのあとは軽い会社説明会と各種書類の記入をしたあと,チームメンバーの自己紹介をしました。たしか6人チームで, 情報系をやっている人はひとりもいなかった と思います。大学としては早慶や旧帝大,関関同立MARCHといった感じでした。
印象的だったのは,
「大学ではディープラーニングというのを使った研究をしています」と言ったら
「ああ!教育系なんですねー私もアクティブラーニングを」
みたいに言われたことですね。いちおうIT系を目指しているはずなのにそれで大丈夫か。
当たり前ですが特に技術でがりがりやりたいという人は少なく,ITだと今後安定してそうだし会社も大手だし給料もいいしとりあえず会社見てみるかみたいな人がほとんどでした。意外と女の子も多かったです。
ただし,技術がすきみたいな人はぜんぜんいませんでした。一般的に高給だと言われてるし,なんか今後IT業界まだまだ伸びていきそうだからIT見てみた!みたいな人がほとんどでした。
パスタ立てるやつ
制限時間内にパスタタワーをどこまで高く立てられるかみたいなやつをやりましたた。なんと優勝でした。
グループワーク
いい感じにオリエンテーションをこなした後は,なんか「ITコンサルの仕事を体験しよう!」みたいなやつでした。とある架空の会社があって,そこの現在の状況を書いた資料があるので,色んな分析をしつつ可能な限りでソリューションを提供するとかいうやつです。
技術力すごいね!かしこいね!みたいなことをチームメンバーから言われてなんか嬉しかったのを覚えています。順位はつかなかったけど色々とがんばったらかなり高評価だったので,こんなもんなのかーと思っていました。
部署紹介と配属先決定
そのあとは部署の紹介でした。やっぱり金融だったり物流だったりのシステムを動かしている大きな会社なので,部署ごとにやっているスケールが大きかったなとは思いました。金融の人たちが「ぼくたちは◯千億円動かしています」とか「うちは品質に定評がある」とか「社会の基盤を作っている」とか「業界最大手としての責任」とか色々なこと言っててすごいなとなりました。
そんなこんなで配属先が決定しました。上に述べたイケイケの部署ではなくて,情報セキュリティ系のことをやっている部署のようです。周りを見てみると,プログラミングは未経験だったけど気合でがんばるぞみたいな人たちが多く配属されているようでした。いちおう面接でコンピュータサイエンスを専攻していること,Webアプリケーションと機械学習やデータサイエンスの開発経験があることは伝えましたが,特にそれでなにか配属をしているということはなさそうでした。
2日目
配属先オリエンテーション
ぼくを含めて3人がその部署に配属されていました。いちおう情報系といえば情報系の方々だったようですが,特にセキュリティが専門というわけではないようでした。軽く部署と,実際に行う業務の紹介をされました。
どのような業務なのか簡単に言うと,とある規格を取得したいソフトウェアがあるが,いちいちチェックして作っていなかったので,規格の仕様書と見比べながらひとつひとつチェックしていってほしいといったものでした。簡単に言うと調べ学習です。なんだこれはというのが正直な感想でした。
合わないメンター
案の定,与えられたマシンはレッツノートでした。机もそんなに広くはなかったです。ぼくは机の上にごちゃごちゃ色んなものを出して仕事をするのが好きなのですが,机の上は綺麗にしてねとか,他の人の領域にはみ出してるよとか(境界線があるわけではない),服装がラフすぎるよとか(書いてあった規定は守っている),スマートフォン机の上に出してるけど遊んでるのとか,色んなことを言われたような気がしています。普通にぼくが悪いですね。
辞めることを決意
とりあえず1時間くらいぱらぱら仕様書とソフトウェアを眺めてみて,これは少なくともコンピュータサイエンスを専攻している学生がやる仕事ではないし,この仕事をするために朝早く大手町に来ることで得られるものはじぶんにあるのだろうかと考えました。考えて考えて考えて,それでも,得られるものはないなという結論だったんですね。
与えられた仕事を途中で投げ出すのは人間としてあるまじき行為ですし,この選択肢が正しかったのかとは今も疑問に思うことがあります。でも,それでも,これ以上続けるのは無理だな,という結論に至りました。さすがに精神面での消耗が大きすぎました。
思うように仕事ができなかったり,本質的ではない(と思える)部分を注意されたりするのってかなり精神的にダメージを受けるんですね。チームメイトには申し訳なかったと今でも思っています。
面談アンド面談アンド面談
そうして決意をしてから,とりあえずメンターに「合わないのでやめたいです」と伝えました。彼はそれほど驚く様子もなく「まあ君は合わないと思っていたけど,ぼくだけでは決められないので,とりあえず人事と話して」と言われました。急遽人事トップとの面談です。
面談では,
「じぶんが与えられるものも,得られるものも特にない」
「この配属はミスマッチではないのか」
「周りの学生のレベルが特に高いとも思えない」
「選考の時点でどのような業務をするのか伝えてほしかった」
といったようなことを伝えました。彼は,現在の業務が忙しくどうしてもインターンシップの内容が直前になっても決まらないこと,配属される学生のレベルがわからないためそれほどむずかしいタスクをまかせるわけにはいかないこと,君のような優秀な若者にぜひ会社の今の体制を変えていってほしいということ,などを伝えられました。
会社としてもいわゆる「虎の威を借る狐」というか「会社の威を借る若手社員」に対しては一考の余地があるということでした。会社の社会的名声が大きいので,自ら会社を変えようという社員が少なく(いてもやめていってしまう),とりあえず入っていっぱい稼ごうみたいな社員が大多数ということでした。そしてそこには技術は関係なく,ひたすらに体育会系のノリと人手でのがんばりがあるだけでした。会社としても国内SIer事業が尻すぼみであることは明確であって,なんとか持続可能な事業を生み出し続けなければならないが,会社全体の流れとしてはそうではないのが嘆かわしいということでした。だからこそ君のような人に入社してほしい。君には負担をかけると思うがということでした。
どれくらい本気で言っていたのかは不明ですが,この話を聞けたことでこのインターンシップに行った意味もあるように思えました。
まとめ
給料
5日間すべて出勤しないと報酬は支払われないということでしたが,後日振り込まれました。
Japanese Traditional Big Companyについて
今回はたまたまぼくの例がこうだったというだけであって,すべての日系大企業がこうであるとは思いません。ただし,Web系に慣れていると少々つらい職場であることも事実です。SIerとはいえトップ企業であれば少しは違うのかなと思ったのですが,あんまりそんなことはなかったです。中の人たちはものすごく頭が切れる人たちばかりなのは事実です。
さっさとやめよう
今まで色んなインターンシップに参加してきたのですが,つまるところこれがいちばん大事だと思っています。インターンシップは所詮インターンシップなので,色々と言ってきますがそれほど大したことを会社側も要求していません。我慢して消耗するくらいは,これはやばいぞと思ったらさっさと辞めた方がいいです。
合わせて読みたい
質問
Twitter とかでこっそり聞いてください。
「君みたいな人に入ってほしい」と言われつつその後なにも連絡はないので(他の人にはセミナーの連絡とかがあった)まあ実質出禁である
— 開発室Graph (@studio_graph2) 2018年1月20日
Twitterアカウントが凍結された話
はじめに
色々とネタにはしてきたけれど,実はわりと落ち込んでいます。丸8年を目前にして,tweet数も10万を超えたけれど,こういう形で終わってしまうのは悲しいですね。
というわけで 開発室Graph は凍結されました。
凍結されるまで
凍結されるまでの流れを簡単に書きます。
突然の凍結
朝起きたら夜中に届いた通知を見返すというのが日課になっていたのですが,なんだか朝起きたらTLは見られないし,どうやら様子がおかしいみたいでした。寝ぼけながら「なんでかなあ」くらいにしか思っていなかったのですが,Twitter for iPhoneに「Your account is suspended.」みたいなメッセージが出てきて,凍結されたことがわかりました。
凍結されたことを伝えるメール
Twitterに登録しているメールアドレスに上のような内容のメールが届きます。この画像は下が切れてしまっているのですが,すべての「これを破ると凍結されるよ」というルールが列挙されており,自動送信メッセージみたいですね。
色々と検索して情報を集めてみると,ここではどのtweetが規約違反だったのかを示されて「警告」で済む場合がほとんどのようです。
しかしながらぼくの場合は一発で凍結されました。
凍結に関する異議申し立て
下の方に「異議申し立てをする方はこちら」というリンクがあるので押すと,凍結に対して異議申し立てをすることができます。つまり,Twitter運営側に「この凍結はおかしいので凍結を解除してほしい」という異議を申し立てるということです。
申し込みはすぐに受理されて,2~3日待つように言われます。受理確認メールは来ませんでした。
永久凍結へ
永久凍結 | 異議申し立て |
---|---|
2~3日経って「あなたのアカウントを永久凍結します」というような,以下のメールが来ました。どうやら異議申し立ては受理されなかったようでした。お疲れ様でした。
いちおう「異議申し立てへの異議申し立て」という形で英語で申請フォームを送っていますが,たぶん解除されることはないと思います。
凍結されてから
現実を受け止める時間
思えばほぼ丸8年ほとんど毎日Twitterをして育ててきたアカウントを一瞬にして失うというのは悲しいものでした。色々とネタにしていますがわりと落ち込んでいます。
とはいえ3日も経つと意外と大したことないように思えてきます。もちろんフォロワーのみなさんと過ごしたことは貴重すぎる時間ではあったのですが,これもまた人生といったところでしょう。
アカウントの作成
凍結されるとフォロー/フォロワー情報がすべて失われるので大変です。アカウントに対する通知画面は見られるようでした(謎)。Twitterクライアントに残っているキャッシュやら,twilogやらに残っているキャッシュを探し出してなんとかフォローを再現していきます。
凍結される恐れのある人はフォロー/フォロワーをバックアップしておきましょう。
ぼくの場合は 開発室Graph2 という新しいアカウントを作りました。予想以上にフォローの復元ができず,元のTLを再現することはむずかしかったですね。
なぜ凍結されたのか
凍結される基準
おそらくここが気になる人が多いと思うのですが,先に結論を書くと「わからん」といったところです。凍結というのは突然に来ます。どのtweetがダメだったのか,どの規約に反していたのかは伝えられません。これは予想ですがおそらく機械的な処理がなされているのだと思います。
今思うとアレがダメだったのかとか,アレをこうしておけばよかったのかとか,色々と考えてしまうことは多いのですが,コレもまた無駄なのでしょう。
おわりに
今後は凍結されないようなtweetを心がけていこうと思います…。
DeNAのサマーインターンシップに参加してきました
DeNAのインターンに参加してきました。新規サービス開発コース というコースです。なんだかんだ勝てなかったので非常に悔しいのですが,せっかくなので書いておこうと思います。将来キャリアとかインターンを探す人のために少しでもなりますように。
なんでDeNA
キュレーションメディアの信憑性など,DeNAのサービス作りが色んなところで問題になっていました。とは言うものの,実際のところはどうなの?って思ったのが最初の始まりです。あとは
- 3日で終わる
- 優秀なエンジニアが多そう
- 選考がそこそこ重かったので
- 参加するだけで10万円もらえる
的なところが大きかったです。
やったこと
とあるお題が与えられるので,それに対する新たな体験となるサービス(スマートフォンアプリ)を作るインターンシップです。3日間ヒカリエに缶づめになってひたすら開発するという,一見するとハッカソン形式の内容でした。学生3人+メンター1人の4人チームが7チームありました。開発した成果を最終日に発表します。
サービスを開発するということ
こういう「短期間でサービスをガッと作ろう」みたいなインターンは,先にある程度で企画を決めてから実際に作りだします。
お題については公開することが禁じられているので詳しくは話せませんが,ふだんじぶんがあまり触れていない分野についてのサービス開発ははじめてなので大変でした。われわれ開発側が「これはいいかも」と思って作ったものが,本当に使われるのか,本当にユーザがいいと思うのか,ぜんぜん自信が持てないんですね。実際に使う側のことがなかなか想像できないからです。
そんなこんなでぼくらのチームのチームの企画決めは困難を極めていました。コアとなる機能はどこなのか,なにを届けたいのか,どこを一番見せたいのかなどなど,なかなか決まらなかったことを覚えています。なんだかんだで企画的な仕様が決まったのは2日目の午後だったことを覚えています。大変でした…。
技術的なこと
この章は技術的なことなので軽く読み飛ばしてもらっていいです。
ぼく以外のチームメイトは2人ともiPhoneアプリエンジニアでした。サーバーサイドエンジニアはぼくしかいませんでした。基本的にはアプリエンジニアの求めるAPIをどんどん生やしていくだけです
ひとりで好き放題できるのでちょっと触ってみたかったAWS Lambdaを使ってみようかなと思っていたのですが,ここまで開発時間が限られている中であんまり慣れていない技術を使うのは危険だろうと思い,けっきょくよく慣れていたRuby on Railsを使いました。
Rails 5のAPIモードは便利です。Scaffoldで雑にモデルを作っていったあと,ちょこちょこ必要なロジックを足していきました。特に詰まることなくざくざく開発していけたのでそのへんはとてもよかったです。あと噂に聞いていた Ridgepole を使ってみました。導入も楽だし,テーブルの構造がどんどん変わっていってしまうハッカソンのような開発にはかなり向いている気がします。早く本家RailsにもMergeされてほしい。
なにを見せてなにを伝えるかというところ
結局このインターンで学んだいちばん大きいところはここだったような気がします。
技術的にがんばっているとか,なんかこだわりがあるとか,色々な機能がもりもりであるとか,もちろんこういうことは大事なのですが,必ずしもそればっかりじゃないよね。っていうところです。
こういう新規サービス開発ハッカソン形式のインターンでは,やろうと思ったことを全部丸ごと実装することなんて到底できません。そのため「なにがもっとも大事なのか」ということと「それをどうやって見せるか」というところが最も大事であるように思えました。もちろんこれはインターンに限らないことです。
新しくサービスを作るときは,なにもわからない人にきちんと伝えて,興味を持ってもらわないといけません。そのために最も大事なところに絞ってきちんと伝える。そういうことの大事さを学べたんじゃないかな,と思っています。優勝したり評価が高かったりしたチームは,きちんとそういうものを作っていたように感じます。
環境とか待遇とか
ここが気になる人が多そうなので書きます。
参加報酬だけで3日10万円,というだけでもかなり魅力的なのですが,それ以外もかなりの高待遇でした。渋谷開催なのに全員が渋谷駅直結のホテルに宿泊できたり,懇親会は美味しいものを食べられたり,叙々苑弁当や鰻の出前が来たり,RedBull飲み放題だったりと,待遇にはまったく文句がなかったです。そのぶんきちんと作ろうね,っていう感じはしましたが。
うなぎを食べる pic.twitter.com/wkSCziAf8z
— 開発室Graph (@studio_graph) 2017年8月19日
焼肉弁当を食べる #叙々苑 pic.twitter.com/9X57LZu3F3
— 開発室Graph (@studio_graph) 2017年8月19日
虚無感 pic.twitter.com/uDXUxml3DT
— 開発室Graph (@studio_graph) 2017年8月19日
さいごに
ずっと長期インターンをしていたのですが,正直なところ新規サービスの立ち上げだったり企画だったりっていうところにはあんまり携わって来られませんでした。しかしながら,どうやって初期ユーザーを囲い込むかとか,人々に使ってもらおうと思うサービスを作れるかなど,色々と学ぶところは多かったんじゃないかな,と思っています。
まだまだ将来どうするかは決まっていませんが,ちょっとずつがんばっていこうかなあ,と思いました。他にもリクルートホールディングスのインターンに参加していたので,それはまた書きます。
学歴コンプを供養したい
思えばこのブログを作ってから結構な時間が経つ。過去のじぶんの記事というものは,見返してもあまりいい気持ちのするものではなくて,できればそうしたくないものではあるけど,せっかくいい機会なので見返すことにした。
大体このブログは2012年頃から書かれていて,かなりの期間を空けつつも更新は続けられ,今に至っている。最初の受験が終わってすぐ作られたということになる。
京都大学は2回受験したけど,けっきょく2回とも落ちた。
けっきょくもちろん一度目より二度目の方が点数は高かったけど,けっきょく落ちた。浪人の時期のことはけっきょくブログに書かなかった。受かったとしたら書こうと思っていたことはたくさんあって,受からなくても書こうと思っていたことは少しあったけど,書いているうちに気分が重たくなってきて,途中まででぜんぶ投げ捨てている。
そんなわけで,ぼくは早稲田大学に進学した。最初は気分が重たかったのをよく覚えている。なんだかんだ高校まではすべて第一志望に合格し続けてきていて,第二志望以下に進学するのは初めてのことだった。「じぶんは本当はこの大学に進学するような人ではなかった」などという無意味なプライドを持ちながら,喜び勇んで入学してきた推薦入学組を,表面上には出さずとも,心の奥底では見下していたのだと思う。
ここでいう《学歴コンプ》というのは,「いちばん行きたい大学に行けなかった」という事実から生まれるものを指す。ことばの定義は色々あるだろうけど,本質的にはこういうものだと思っている。そこに大学のランクはあまり関係ない。むしろ「世間からはいい大学とされている大学だけどじぶんは行きたくなかった」という事実は,《学歴コンプ》をより根深いものにしていく。じぶんでは満足していない大学名を他人に誉められる度に,その不一致がストレスになるからだ。
中学〜高校にかけて,人生のリソースの大部分を注いできた「勉強」が最終的には報われなかったという事実は,志望校に落ちてしまった受験生の上にずうんと重くのしかかる。基本的にぼくらは「たくさん勉強をして,いい大学に行く」ことが最良の自己実現かつ人生のあるべき姿だと思っているし,それしか知ってこなかったからだ。
《学歴コンプ》を消すことはできない。
ずっと消そう消そうと思っていたけれど,けっきょく消すことはできないものなのだ,と思うようになった。京都大学に行ければどれだけよかったかと思うことは今でも何度もある。ぼくは幸運にも学歴ロンダリングに成功したが,それによって《学歴コンプ》が解消することなどなかった。けっきょく4年間を無駄にしてしまったのだとか,ここで上手くいくならなぜあのときとか,多少は軽減されるとしても,消えることはない。
そういうわけで,けっきょく《学歴コンプ》とは一生付き合っていくしかない。大学に落ちてしまったのだという事実は覆せないし,浪人や再受験という選択は,今の日本においてはそれほど楽な選択肢とも思えない。そんな意味で今回は「供養」という言葉を使った。消せないし,書き換えられないけれど,なんとかずっと付き合っていかないといけないもの。そういうような意味だ。
けれど,《学歴コンプ》を持ち続けているのはものすごくかっこ悪い。たぶんこの文章を読んだ人もそう思うはずだ。第一志望に落ちてしまって,第二志望の大学に通っているじぶんが悲劇の主人公だと思ったとしても,そんなこんなで不合格になった受験生はものすごい数になるだろう。第二志望の大学が第一志望だった人もいるのだから,なんてことは言わない。けれど,せっかく母校になる大学なのだからひねくれていない方が大学生活もきっと楽しくなるのだと思う。第二志望の学生たちで傷を舐め合っていても仕方ないし,外の人から見たらみんな同じ「早稲田生」でしかない。
つまるところ,学歴は「高い方がいい」くらいのものなのだな,とさいきんは思うようになった。学歴が高い人の方が色んなことに成功する可能性が高いけれど,それは必須のものではない。高校生のときのぼくは「高学歴」になることしか人生での自己実現の方法を知らなかったけれど,そのための方法はいくらでもある。大学の勉強をきちんとするとか,バイトをがんばるとか,インターンで結果を出すとか,サークルで友達をたくさん作るとか,それはなんでもいい。そういうものを見つけると,少しずつ気持ちが楽になっていった。
そんな意味で,さいきんはようやく《学歴コンプ》ときちんと向き合えるようになった。毎日がうまくいかないと,その原因を「不合格だったこと」に帰着させがちだったけれど,それをやめた。けっきょくはじぶんでじぶん自身をなんとかしていくしかないし,過去にぐちぐちこだわっていても仕方がない。というのに,もう少し早く気づきたかった。おわり。
スマートウォッチを買って変わったこと
そういえば少し前にスマートウォッチを買いました。常に身体に身に着けて使う,いわゆるウェアラブルデバイスというやつです。
ちょっとお金に余裕があったから買ったので,それほど期待していたわけでもなかったのですが,なんだかんだ日常ががらっと変わったので,ちょっとそれについて書いてみようと思います。
Pebble Time
つけているとよく「それApple Watch?」と聞かれるのですがそうではなく,Pebbleという会社が出している「Pebble Time」というスマートウォッチで,Apple Watchに比べるとかなり安いのが特徴です。だいたい12,000円くらいでした。使い方や特徴についてはあとで詳しく書きますが,ざっくり言うと「スマートフォンの通知を受け取れる」ものです。
デザインから高級感あふれるApple Watchと違って,見た目も少しチープです。
主な特徴
- iOS, Android双方で使用できる
- バッテリーのもちが非常にいい
- 通常使用でも5~7日くらいもつ
- 通知を振動で教えてくれる
- スマートフォンで受け取れる通知ほぼすべて
- カレンダーの閲覧・リマインドができる
- ライフログのデータを取得できる
- 歩数・睡眠時間など
大体こんなところです。夢のようなデバイスかと思いきや,できることは意外と多くはありません。Bluetoothでスマートフォン本体と接続して使うので,スマートフォンがないとただの時計と同じです。
ぼく自身も,コレがものすごく必要だから買ったというよりは,多少お金も余っていたし,前々から興味はあったから買ってみるか,といったようなところです。
スマートフォンは高性能すぎる
スマートウォッチを買ってから,このことをよく考えるようになりました。
選択のパラドックスのような話にもなりつつありますが,現代において我々は,常にたくさんの情報,選択肢にさらされて生きています。特にスマートフォンやラップトップPCなんかが,それを実現してくれますよね。
でも,常にあらゆる情報を入手し続けることが果たしてしあわせなのかというと,そういうわけでもなさそうです。それまでは,なにか別のことをしていても,常にスマートフォンやその通知が気になってしまっていました。特に通知は来ていないけど,なぜだかスマートフォンを見てしまって,集中は途切れるし,無駄な時間は使ってしまうし,という感じでした。まさに情報に踊らされてしまっている感じです。
どうやら,
- 常につながっていたいということ
- そこからあらゆる情報にアクセスできてしまうこと
この2つが原因であるみたいです。
「すべて」の情報を「常に」受け取る
スマートウォッチは,スマートフォンに来る通知を基本的に「すべて」受け取ることができます。そしてそれは基本的に「常に」左手に身に着けているものです。これって一見すると,スマートフォンと変わらないじゃないか,と思うかもしれません。でも,使ってみるとわかるのですが,それらは異なる体験でした。
「『すべて』の情報を『常に』受け取る」ということは,見逃す心配がない,ということだからです。スマートフォンが少し身体から離れているだけで不安で, なにも通知なんて来ていない はずなのにスマートフォンを見てしまっていたあの頃と比べて,無駄にスマートフォンを見ることは減りました。
また,「すべて」の情報を「常に」受け取る生活を続けていると,ぼくらのスマートフォンに届く通知のうち「本当にすぐ見なければ,返答しなければいけないもの」は本当に少ないことに気づきます。ほとんどの情報は放っておいたってよく,とりあえず届いていることさえ確認できればよいのです。そのためにはブルっと来たら手首をチラッと見ればよいだけで,作業を中断する必要はありません。
すべての情報を常に受け取ることで,情報に縛られなくなるというのは,かなりびっくりしたところでした。スマートフォンを見る時間は,明らかに減ったと思います。
必要最低限である,ということ
先にも述べたようにPebble Timeはかなりチープで,できることは限られています。Apple Watchと比べても,タッチパネルではないし,液晶も電子ペーパーで解像度も低く,マイクだってありません。でもそこがものすごくうまく作ってあるところで,それで十分なんですよね。
電子書籍はスマートフォンではなくタブレットで見るように,テキストメッセージの返信はスマートウォッチではなくスマートフォンで行います。最近ではノートブックがタッチパネルを備えてタブレットに近くなったり,スマートフォンが大型化してタブレットに近くなったりと「なんでもできる」デバイスが増えているように思います。
でも,ウェアラブルデバイスに対してはその「なんでもできる」ということは必ずしもいいことではありません。腕時計の小さな画面を見るくらいなら,さっとカバンやポケットからスマートフォンを取り出した方が快適だからです。常に身につけておくのは,本当に「最低限の機能」でよいのです。
Pebble Timeはその「最低限の機能」により,常に画面がついているにも関わらず,フル充電で5~7日というバッテリーの保ちを実現しています。Apple Watchは腕の上げ下げを判断して画面をつけたり消したりしますが,「時計」と名がついているのに常に時間が表示されていないというのも,なんだか変な話ですよね。
ウェアラブルであるということ
はじめて買ったウェアラブル(=常に身につける)デバイスが,ここまで生活を変えてしまうとはあまり思っていませんでした。けれど,これからの世の中は,もっともっとウェアラブルな方向に動いていくことでしょう。今までのような「オールマイティーなデバイスを1つ持つ」というのではなくて「特化したいくつものデバイスに囲まれる」という生活が,これから始まるのかもしれません。
ウェアラブルであるということは,意識せずに情報をやり取りできるということです。まさに情報をまとうかのように,じぶんに必要な情報を得たり発信したりできる世界も近いのかもしれません。
また今回は「情報を得る」ことを主に書きましたが,身につける「センサ」としてのウェアラブルデバイスの機能も注目すべき点です。活動,歩数,睡眠,脈拍なんかをトラッキングして,なんらかの形で可視化し,ぼくらの生活に指針を与えてくれるかもしれません。
そんなわけでスマートウォッチ,おすすめです。
東京大学大学院 情報理工学系研究科 創造情報学専攻に合格しました
はじめに
色々あって院試に合格しました。東京大学大学院 情報理工学系研究科 創造情報学専攻2016年度の夏入試です。じぶんが受けるときにほとんど情報がなくて困った覚えがあるので,あとから受ける人のために色々と情報を残しておこうと思います。受けたのは自大の内部進学(早稲田大学 基幹理工学系研究科 情報理工・情報通信専攻)と東大だけで,両方とも合格をいただくことができました。 内部進学についてはたくさん情報が揃っているので今回ここでは書きません。
受験先の選択について
大学院,特に他大学を受験するはたくさんの選択肢があります。専攻を決めるのも一苦労だし,専攻を決めたあとも受験科目や研究室など,たくさんのことを じぶんで決め なければなりません。 たとえばぼくは情報科の人間でしたが,東大だと情報理工学系研究科に加えて,学際情報学府や工学系研究科,新領域創成科学研究科を受験される方もいるでしょう。とはいえなかなか受験先を選ぶのはむずかしいので,ぼくはこんな感じの指標を用いたぞというのを以下に示しておきます。
- 自身のやりたい研究と一致しているかどうか
- 専攻の内部率/外部率
- 必要な科目
- 問題との相性
などでしょうか。それではひとつずつ説明していきます。
自身のやりたい研究と一致しているかどうか
自身が学部で所属していた研究室にそのまま進むのと比較すると,他大学の院試を受け直すということは「もう一度研究テーマを決める必要がある」ということになります。院試の出願をする段階でじぶんの将来像や研究テーマが描けている人は少ないと思いますが,HPや説明会,研究室訪問などで自身のやりたい研究と合っているかどうかよく考えるといいと思います。 本当にやりたい研究をしたいのか,いわゆる学歴ロンダ,院ロンダをして「東京大学大学院」の学歴をほしいだけなのか,というのをよく考えないといけません。
専攻の内部率/外部率
東京大学の大学院の入試は一般にはむずかしいと思われがちです。厳しい学部の試験をくぐり抜けてきた内部生と戦わなければいけないからです。しかし,そんな東大にもいわゆる「入りやすい研究科」というのは存在します。 「直属の学科がない研究科」が基本的には「入りやすい研究科」ということになりそうです。これはどういうことかというと,たとえば昔からある研究科と専攻は 工学部電子情報工学科←→情報理工学系研究科電子情報学専攻 や 工学部システム情報学専攻←→工学系研究科システム創成学専攻 といった感じですね。 しかしながらこういう対応を取ってない新設の研究科も多くあります。創造情報学専攻もその1つですし,新領域創成科学研究科や学際情報学府などがそこにあたるでしょうか。 このあたりやこのあたりの情報を見ておくと,なんとなくわかるかもしれません。
必要な科目,問題との相性 については以降で述べます。
院試までのスケジュール
- 4月: 外部受けるかと思う
- 5月: 教科書を買った
- 6月: どの専攻を受けるか決める
- 7月: 自大の院試と並行して勉強する
- 8月:
- 1週目: TOEFL-itpを受ける
- 2週目: 過去問をちょっとだけ解く
- 3週目: 院試を受ける
- 1日目: 筆記(一般教育科目)
- 2日目: 筆記試験(専門科目)
- 3日目: 口頭試験
という感じでした。概ね分野がかぶっていたので自大用の勉強はあまりせず,東大用の勉強をしつつ足りないところを補う,という感じでした。勉強時間だとおそらく3週間やったかな?というくらいです。
基本的な勉強方法としては,かなりギリギリになるまで過去問は解かず,教科書を読んでいました。あまりにも解けなさすぎて嫌になったのと,創造情報学専攻はそこまで細かい知識を聞いてくるわけではないので,ざっと頭に入れておくとよいだろうと思っていたのとです。
おそらく自大の中で他大受験をする人はそれほど多くはないと思うので,スケジュールや計画はある程度ガバガバでもいいのできっちり把握しておきましょう。英語受け忘れた……なんてことは避けたいです。
筆記試験について
いちばん大事そうな筆記試験について詳しく書きます。創造情報学専攻の夏入試で必要な科目は英語(TOEFL),数学orプログラミング,専門科目の3つです。 英語:数学orプログラミング:専門科目 = 1:1:2
の重みづけがされているという噂がまことしやかに囁かれていますが,本当かどうかはわかりません。
外国語(英語)
英語はTOEFL-iBTのスコアシート提出が基本的であり 「やむを得ない場合のみ」東京大学で集団受験するTOEFL-ITPのスコアを利用することができる ,と書いてありますが,願書にマルをつけ,行って受けるだけです。
- TOEFL-iBT
- 受験料が高い(2万円くらい)
- Listening, Readingに加えてSpeaking, Writingがある
- TOEFL-ITP
- 受験料は大学院の受験料に含まれている
- Listening, Readingのみ
という感じです。ぼくは東大でTOEFL-ITPを受験しましたし,かなり多くの人がTOEFL-ITPを受けて英語のスコアとするようです。英語は元からそこそこできたので,まったく対策をしないまま受験の2日前くらいに以下の本をさっくり読みました。問題形式や解答のポイントを簡単におさえることができます。
- 作者: 高橋 良子,クレイグ・ブラントリー
- 出版社/メーカー: ジェイ・リサーチ出版
- 発売日: 2011/01/25
- メディア: 単行本
- クリック: 1回
- この商品を含むブログを見る
院試において英語は軽視されがちですが,それなりに対策すると他の人の1.5~2倍の点数を取ることもむずかしくはないため,やっておくといいと思います。差がつきやすいです。 ただし一般教育科目や専門科目がある程度できていれば「英語が悪いから落とされる」ということはないようです。きちんとした例なのかはわかりませんが,TOEICが400点台の早稲田の同期は電子情報に受かっていました。
一般教育科目(プログラミング)
創造情報学専攻のみ,出願時に数学またはプログラミングを選択して受験することができます。ぼくは数学がそれほど得意ではなかったし,復習するのも大変だったのでプログラミングで受験することにしました。年による難易度の差がそれほど大きくなく,そこまで難問奇問は出題されないため,対策しやすいと思います。
簡単なレギュレーション
- 大問1つで構成。例年(1)~(6)くらいまである
- プログラミング言語は自由。
- インターネットへの接続は不可だが,マシン内のライブラリ,コード片は自由に使用できる。
- リファレンス(物理)を1冊に限り持ち込み可能
本番は2.5時間かけてがりがりコードを書き,コード集を各自に配られるUSBメモリに入れ提出。その後マシンを置いたまま退室し,午後に1人ずつ動作チェックと試問を受ける,という形で進みます。
プログラミング試験の対策
競技プログラミングはそこまでやったことがなく,慣れていた言語ということでRubyと迷った末にPython2で受験することにしました。リファレンス(物理)は持ち込まず,dumpしたPython2.7のリファレンスを参考にしました。 例年競技プログラミング系のむずかしい問題がそこまで多く出題されることはなかったため,Project Eulerを1日1題ずつくらい解いていました。ただそこまで対策としてはよくなかったと思います。本番も4割くらいしか解けませんでした。 ふだんプログラミングするときは,書き方がなんとなくわからなくなったらぐぐる,という感じでだらだら書いていました。しかし本番のレギュレーションはそれと大きく異なっています。そのため
- 時間を決めて解く
- Googleではなくリファレンスを参照して解く
あたりのことを意識して対策を行うとよさそうです。また普段ファイル入出力に触れることはあまり多くありません。 .txt
や .csv
の入出力は簡単に見ておくか,まとめシートを作っておくと時間の節約になると思います。書籍ですが,かの有名な蟻本が必要なほどではないので,いわゆるTLE本をやっておくのがいいと思います(ぼくはやりませんでしたが)。後で述べるアルゴリズム問題の対策にもなると思います。
プログラミングコンテスト攻略のためのアルゴリズムとデータ構造
- 作者: 渡部有隆,Ozy(協力),秋葉拓哉(協力)
- 出版社/メーカー: マイナビ
- 発売日: 2015/01/30
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (5件) を見る
専門科目(創造情報学)
続いては専門科目についてです。創造情報学専攻の夏入試では専門科目として,創造情報学以外にもコンピュータ科学,数理情報学,システム情報学,電子情報学,知能機械情報学のうちいずれか1つを選んで専門科目とすることもできます。ぼくは創造情報学で受けました。理由としては,
- ソフトウェア関連の問題が多い
- アルゴリズム関連の問題がほとんど
- ハードウェアが苦手だった
- 知識を問う問題が少ない
- 幅広い分野への基礎知識をベースに答えていく問題
- きちんと頭を使って解けば答えが出る問題
などが挙げられます。先にも挙げたようにアルゴリズムや情報システムに関する問題が多く出題されており,逆にハードウェアに関する問題はそれほどまで多くはありません。要項にも
ソフトウェア・アルゴリズム,コンピュータハードウェア,情報システムなどに関する問題が出題される.3問解答する.
と書かれていますね。ぼくはアルゴリズム,ハードウェア,(後で述べる)語句説明の大問3問を解きました。
また上にも書いてあるとおり きちんと頭を使って解けば答えが出る問題 が多く出題されるように思います。見たことのない設定の一見するとむずかしそうな問題でも,よく読むと簡単じゃんみたいな問題が多かったように思います。このあたりは東大の学部入試の問題にも少し似ていますね。
アルゴリズム
ぼくは競技プログラミングをそこまでちゃんとやったことはありませんし,アルゴリズム系の問題はどちらかというと苦手でした。他の様々なブログを読むとオススメされていた以下の本をやりました。薄い割にきちんとまとまっていていい感じです。 この本を1冊きちんと読み込めば,どんなアルゴリズムが出てきても大体はどうすればいいかわかると思います。この本で基本的な概念を抑えつつ,一般教育科目(プログラミング)の勉強と合わせてがりがり実装する,というのがいいでしょう。最初の方は擬似コードをきちんと手書きしていましたが,途中からめんどくさくなってやめました。
- 作者: 五十嵐健夫
- 出版社/メーカー: 数理工学社
- 発売日: 2007/10
- メディア: 単行本
- 購入: 14人 クリック: 122回
- この商品を含むブログ (10件) を見る
アルゴリズム関連の問題は,一般教育科目(プログラミング)にも関連しますし,毎年ほぼ必ず出題されるのできちんとやっておくといいと思います。必須です。
ぼくはやりませんでしたが,アルゴリズムイントロダクションなんかを読んでおくのもよさそうです。
アルゴリズムイントロダクション 第3版 総合版 (世界標準MIT教科書)
- 作者: T.コルメン,R.リベスト,C.シュタイン,C.ライザーソン,Thomas H. Cormen,Clifford Stein,Ronald L. Rivest,Charles E. Leiserson,浅野哲夫,岩野和生,梅尾博司,山下雅史,和田幸一
- 出版社/メーカー: 近代科学社
- 発売日: 2013/12/17
- メディア: 大型本
- この商品を含むブログ (6件) を見る
ハードウェア
ハードウェアはあんまり得意ではなく,できれば捨てたかったのですが,そうもいかないので以下の2冊の教科書を読みました。
コンピュータアーキテクチャ
コンピュータアーキテクチャの本にはかなり助けられました。非常に詳しく書いてあるし,章末問題が解説も含めかなりきちんとしているので,1冊丸ごと読むとコンピュータアーキテクチャはほとんど問題なくなると思います。コンピュータアーキテクチャに加えて,いわゆるオペレーティングシステム的な話まで広げて書いてありました。
コンピュータアーキテクチャ (電子情報通信レクチャーシリーズ)
- 作者: 坂井修一,電子情報通信学会,電子通信学会=
- 出版社/メーカー: コロナ社
- 発売日: 2004/03/01
- メディア: 単行本
- 購入: 8人 クリック: 75回
- この商品を含むブログ (2件) を見る
論理回路
論理回路はみんな勧めていた坂井修一先生の教科書をざざざっと読みました。コンピュータアーキテクチャの本もですね。余談ですが著者の坂井先生は創造情報学専攻の教授です。当日に解いた問題の構成がほとんどこの教科書の章と同じで驚きました。もしかしたら坂井先生が問題を作られていたのかもしれません。 組み合わせ回路からの出題が多く,順序回路はあんまり出題されないイメージです。
- 作者: 坂井修一
- 出版社/メーカー: 培風館
- 発売日: 2003/10
- メディア: 単行本
- 購入: 9人 クリック: 112回
- この商品を含むブログ (3件) を見る
用語問題
過去問を見ればわかるのですが,8つの用語が書かれていて,そのうち4つを選んで説明しなさい。といった形式の問題が毎年出ます。
これは色んなところでも言われているのですが,対策としてはひたすらwikipediaを見ていました。とはいえ,出そうな範囲はなんとなく絞れてきます。過去問を解きつつwikipediaで調べて,その項目の中にわからない単語が出てきたらまた調べる,といった具合です。wikipedia各項目の「概要」をまとめるといい感じです。個人的にはここは点取りどころだなと思っていました。
得点開示
東大院試の得点は,情報理工学系研究科の場合は情報公開室というところに行くと開示することができます。もろもろの手続きで1ヶ月近くかかるので困ったところなのですが,せっかくなので開示することにしました。
外国語科目(TOEFL-ITP): 547/677
一般教育科目(プログラミング): 60/200
専門科目: 208/300
プログラミングがなんともひどい点数ですね。むずかしかったから仕方ないかなあという気もするのですが。このあとの配点の重みづけが謎なところですが,大体5~6割くらいは取れたかなという感じだったので,採点はそんなに厳しいということはなさそうです。