卒業後の進路について

2018年8月21日

最近はインターンで毎朝6時30分に起床して東京に行き、23時には寝る規則正しい生活をしている。勤務先が東京なので大体ドア２ドアで片道1.5時間はかかっている。新卒の頃の通勤時間に匹敵するが、幸いつくばエクスプレスの末端同士の駅を利用するため、座って通勤できるのでまだラクだ。新卒の頃は１時間近く立ったまま紙の本や新聞を読むとかしていたが、あれが平気だったのはまだ若かったからだろう。

電車の中ではpc開いて何か作業しようと思っていたのだが、とてもじゃないがpcを開いていられないほどの混雑ぶりのため1日目にして挫折した。変わりにkindleでずっと本を読んでいるのだが、久々に読んだこの本が面白かった。

未来の働き方を考えよう　人生は二回、生きられる (文春文庫)

70年代頃から2010年代頃までの仕事に対する価値観の推移や年齢構造の変化などを例に挙げた上で、2010年代以降の働き方を提案する内容となっている。作者の主張として面白いと思ったのが「40代を境に仕事人生を2分する」というもので、40代以降の生き方について改めて考えてみようというもの。「とにかく転職しろ！」「企業しろ！」みたいな極論一辺倒の論調の本も最近は増えているが、そうではなく「本当に自分がやりたいことは若いうちの方がやりやすい。だからできるうちに（精神的/体力的にキツくなる前に）やりたいことをやれる働き方を考えてみてはどうか。もちろん今の自分の働き方を続けるのがベストという結論ならそのままでもOKやで。」というもので、とにかく考えることを読者に求める。これはものすごく大事だと自分は思う。実際に経験しなくても想像するだけでも色々と気づきはあるもので、自分なんぞは「もし自分がgoogleに入ったら何ができるか」「エンジニアじゃなくなったらどうするか」みたいなことばかりをよく妄想しているが、それそれでいろいろと気づくことがある。

この本を読みながら卒業後の進路を考えるなどしている。卒業はたかだか1年と7.5か月後であり、実際に研究に使える時間のリミットはM2の12月が限界だろうから実際には1年と4.5である。そしたらまた働きに出なければならない。正直、今の時間は休暇期間だとは全く思っていないので、卒業後に１か月ぐらいフラっと出かけたいという気持ちもあるが、一方でお金がないという現実もあり、ガチ無職期間を経ずに働かなければならない状態である。

卒業直後の2020年4月では34歳になっている。どんなに無理しても決して若者に分類されることはない見事なオッサンである。そこから何をやるか。インターン先ではそれなりに年数を経て大規模になったコードをメンテしているが、年齢的には今のところは全く衰えを感じていない。それどころか、コードを読んで全体構造を理解するスピードや、どこから手をつけるべきか当たりを付けて、適度な粒度のタスクを積み上げて一個ずつ潰していく能力は働いていた頃と同じか、当時よりも上がっているような気すらする。とすると、コードをガリガリ書くおじさんとしてはちょうど今ぐらいの年齢が能力的にピークなのかもしれない。なので34歳になってももう少しの間は「コードガリガリおじさん」でも食っていけるのかもしれない*1。

しかし、個人的には卒業したら全くやったことがない仕事をしてみたいという思いもある。とはいってもソフトウェアの領域であるため１年もやれば「よく知ってる領域」になってしまう可能性もあるのだが、少なくとも、卒業後５年間は今は全くやったことがない領域をやりたい。で、40歳になった時に「webサービスのバックエンド系開発に関すること全部」と「それ以外の領域」で２本柱を持てるようになりたいと考えている。40歳以降もガリガリさんが必要ならガリガリさんをやるが、若者の育成や組織の開発体制の強化にまつわることなんかも並行してやれたらよいなと思っている。自分は若いころは指導してくれる先輩にあまり出会うことができず独学だったり怒られたりしながらヒーヒー言いながら育った身なので、若者にはもっと効率よく成長できるパスを用意したいなという気持ちがある。一方で、バックエンド系開発はサービスメッシュという概念が登場し、かつての分散並列処理システム（ちょうど前期にやってたやつだ）を支えた技術トレンドが復活しそうな気もしていることもあり、前職で触れたマイクロサービスを用いた設計からさらに洗練された考え方を学ぶ必要があると思っている。一度勉強したからといってアップデートを止めると一瞬で置いていかれるのがこの業界である。卒業してもこの心構えは忘れずにいたい所存。大学にいるとついつい新しい技術よりも研究や単位を取るのに必要な技術ばかり目が行ってしまうが業界の流れもチラ見しながらついていきたい。

で、話は戻るが具体的にもう一本の柱は何をやるか。。というのは未定なのだが、今薄っすら考えている候補は

• ラズパイなどのデバイス上で動くソフトウェアや特定のCPUのためのコンパイラを書く
• 深層学習のモデル実装を極める
• 量子コンピュータのためのコンパイラを書いたりする（そんな仕事があるのかはさておき）
• 学部時代に卒論でやった農業 + 機械学習でなんかやる
• Halideみたいな実行環境に応じて最適化されたコードを吐くコンパイラを書いて特に組み込み分野で使える最適化されたコードを抽象表現から生成できるようにする

という感じか。結局、機械学習を用いたプロダクト開発か、用途特化のデバイス上で動作するソフトウェアの開発か、コンパイラみたいなコード最適化や低レイヤを触る、といった辺りが今まで全くやったことがなくてかつ興味がある分野という感じである。そんな仕事あるんかいなというのはさておき、何がやりたいかを知っておくことは重要だとちきりんも言っていたので、今後も情報を集めつつ自分でも手を動かしつつ考えていきたい所存。

*1:ガリガリさんって発売されてそうでされてない

春学期振り返り（本音編）

2018年8月3日

4月にスタートした春学期も来週で終わりである。集中講義に一個出てレポート出して終わりである。 このブログはなるべく本音を書くようにしているのだが、今日はちょっとネガティブなことを書くので苦手な人はリターンしていただきたい。（別に何か問題になるようなことを書く訳じゃないけど）

進捗無

2018年7月23日

このブログ更新するのいつ振りだろう。あまり覚えてない。

春学期はABCの3つのtermに分割されているが、そのうち春A,春ABに実施された講義の単位が出そろった。 幸いなことに１つも落としていないしA+の単位も何故か取れた。もちろんBの単位もあるのでGPAはそこまでよくない。
A+を取るというのがどれぐらい価値があるのかよく分かってないが、一番いい成績なので秋学期も狙っていきたいところ。 まだ開講中の春Cの講義もあるので頑張っていきたい。

一方で研究は殆ど成果が出ていない。専門としている人が周りにいないため誰のサポートも受けられず、完全に手探り状態である。
やはり無理なテーマを選んでしまったのではないかという後悔を徐々に感じているが、仕事と違ってそこまで締め切りに厳しくないのが大学の良い所ではあるので、完全に詰むまでは突き進んでみるしかない。かなりしんどいしストレスも溜まって毎日イライラしているのを自分で感じるが、仕事ではもっとストレス溜まって毎日就業時間中にオフィスを抜け出してビルの屋上で叫びたくなるような時期が普通に何度もあったので、それに比べればまだ遥かにマシだ。自分で大体の状況をコントロールできるという点でもかなりマシな状況である。

とりあえずV100を積んだマシン上でChainerで組んだモデルを自由に実行できるようにはなったが、肝心の畳み込みLSTMで実装した レーダーエコーデータの降水予測モデルの訓練にアホほど時間がかかって終わらない問題が生じている。

nVidia visual profilerで確認するとCPU<->GPU間のデータ転送時間が支配的となっており、 GPU2枚でデータ並列でminibatch size 4で1iteration回すのに50秒とか冗談みたいな時間がかかっている。 一方でcudnnの関数はどれも1秒足らずで終わっているのでこちらはボトルネックになっていない。 そしてGPUのメモリを28GB allocateしており、これ以上inputの1 instanceのデータサイズを増やすと破綻することが予想される。 ちなみにConvLSTMレイヤーの畳み込み層のchannelサイズを小さくすることでGPUメモリ使用量がアホほど減ることから やはりモデルのパラメータサイズが大きいことが直接の原因らしい。

そのため、以下について原因を調べなければならない。

1. CPU<-> GPUのデータ転送が生じているのは正常な挙動かどうか（自分の実装ミスではないかという可能性）
2. GPUのメモリ使用量がめちゃくちゃ増える理由

レポートの締め切りが重複しまくる問題と出されたレポートの種類について

2018年6月26日

最近は殆ど研究に関する作業が進んでいない。大量のレポートで手も頭が回らなくなっている。 どれぐらいレポートがあったかをgoogleカレンダーで確認すると、少なくとも最近だと下記がレポートの締め切りとして登録されている。*1

• 6月13日
• 6月22日
• 6月28日
• 7月2日
• 7月4日
• 7月6日
• 7月8日

6月後半から7月第一週への集中攻撃が半端ない。告知から締め切りまでが短いやつだと「締め切り来週な！」みたいなのもあるのでだいぶつらい。なお4月にも5月にもこれよりは少ないがレポートはあった。
なぜこの時期に集中するかと言えば春学期の最終週が先週だったので、春学期の講義の成績をつける為にどの講義もラストミッションとしてレポートを課すのだ。レポートがない講義は変わりに期末試験一発勝負であり、それはそれで戦々恐々としながらテスト勉強している。 それぞれのレポートを作成するのに１つ当たり大体5時間～15時間程度はかかっている。なぜそんなに幅があるかというと、講義内容だけでは全然足りなくてゼロから調べないとどうしようもないものがあったりするため、その調査時間がかかっているからである。実装が入るとさらに増加する。最近はGlusterFSをVagrant上で動かして動作検証をしていたし、7月8日締め切りのレポートも実装が必要なので今ちょうど設計作業をしている所である。

大学院のレポートは、レポートと一口に言ってもいくつかのパターンが存在する。自分が春学期に受けた講義については以下のいずれかの形式であった。

• 演習問題を解いて提出する
• 問題が提示されてそれについて論述する*2
• 講義内容の要約
• 指定された論文要約*3
• 仕様が指定された実装を作って仕様と振る舞いについてレポートを添えて提出する

演習問題を解いて提出するというのは自分の学部時代でもよくやったやつで、普通に問題をレポート用紙に手で書いて提出した。アルゴリズム系の講義だったのでDPテーブルや樹形図を手で書いて解答を書いた。これは大変だったが普通に楽しかったし、エンジニア時代は全く歯が立たなかった論理系のジャンルを少しだけ理解できた気がした。

論述するやつは、例えば「XXXがZZZな時YYYが成り立つかどうか論ぜよ」とか「XXXについてYYYという観点で説明せよ」みたいな問題について解答をまとめるタイプ。難易度はモノによってマチマチだったが、答えはすぐ分かるのだがそれをどのように論理的に説明するかについて悩むものがいくつかあった。どちらかと言えば論理的に説明するための文章展開を考えるのに時間がかかった、という感じである。要するに論文を書くトレーニングなのだろうと思われる。

講義内容の要約はある意味一番ラクだった。基本的には講義の板書と、足りない部分を別途本で調べて補足したものをまとめて提出する。ちゃんと講義に出てさえいれば書けるやつであり、単純作業なので面白くはなかった。復習にはなったが、すでに知っている知識がほとんどの講義だったため、まぁなんというか本当にまとめるだけの作業になってしまった。

指定された論文要約は、全く専門外の論文を必死こいて読んでいてかなり厳しかった。翻訳は出来ても用語のニュアンスが分からないという感じで、それこそ関連論文もセットで読まないとうまく要約できなかった。今学期だと一番時間がかかったのがこのタイプで、すでに提出したが少なくとも論文を読んでまとめるのに15時間はかかった。かなり大変だったがお陰で専門外の論文に立ち向かう根性と自信は付いた気がする。

仕様通りにソフトウェアを実装してその振る舞いとパフォーマンスをレポートにまとめて提出する。これこそが自分が求めていたCS専攻らしい課題だと勝手に思っているものであるが、残念ながら春学期は一個しか出なかった。寂しい。OCaml処理系をOCamlで書いて来い、みたいな講義を受けてみたいものである。

*1:実際の締め切り-1日をカレンダーに設定しているので実際には論理締め切りである

*2:設問は「Discuss about~」みたいな形式が多い

*3:当たり前だが英語であり実質的に英文精読タスクも発生する

大学の先生との付き合い方

2018年6月23日

14年前、岩手大学に入学したばかりのころのオリエンテーションで「大学生活のいいところ」みたいな話をしてくれた先生がいて、いくつか列挙してくれた上で、最後に大学教授という変人を観察できることを挙げていた。詳しくは説明してくれなかったので何のこっちゃいと思ったし、実際岩手大学で自分が講義を受けたり事務処理でお世話になった先生方は、今考えてもみんなまともだったように思う。変わった人はいたが「お、変わってるな」ぐらいの感覚だった。自分が卒論で指導を受けた先生も、その他の同じ研究室内の先生も、今考えても大人としてまともだったように思う。指導教官については新卒で会社員として働いていた期間があるのでそのバックグラウンドも関係しているかもしれない。よって、大学の先生 ∈ {准教授、助教、教授、講師}はそこまで変な人じゃないしまぁふつうの人だよねという印象を持っていた。

一方、大学を出てから10年後に筑波大学で過ごしていて感じるのは、その考えは10年ぶりに微修正しなければならないということである。筑波大学も相当デカい大学であり、大勢の先生がいて、自分が接しているのはそのうちのごくごく一部に過ぎないということを分かっている。分かってはいるが、その狭い狭い観測範囲の中であっても、「それはどうだろう」という対応を、自分よりも10歳も20歳も年齢が上の人に対して感じるケースが、週に数回はある。自分に対してだったり、他の学生に対してだったり。そういう対応にイラ立って学生の間で愚痴っている場面には研究室内でもその辺の教室でもしょっちゅう出くわす。イラ立つだけならまだいいが、放っておくと鬱になって休学してしまう学生もいるらしいので、そういう先生の対応っていうのはもう少し大学側はケアをすべきではないかという気もしなくはない。ただ、大学というのはその辺の大企業以上に巨大で複雑な組織であり、個別の学生のケアにまで手が回らないのが実情だと思う。だからこそサークルに入ったり友達作ったりして上手くストレスを解消するための場所を用意しておく必要があるんだな、と10年振りに思った。自分も学部時代はギターアンサンブルのサークルに所属し、大学生協で学生にPCを教えるバイトなどをしていた。そこでの人間関係は確かにストレスからの退避場所として重要だったのだなと今にして思う。

話が長くなった。大学教授との付き合い方について書こうと思っていたのだ。油断すると昔話をしてしまうのはおっさんの悪い癖だ。
結論から言えば、自分は諦めている。
40歳、50歳にもなってこの状況であれば恐らくそこから性格や考え方を変えるのはもう不可能だと思っている。だから、そういう人間なんだなぁと思って真に受けずに、会話するときは必要なことだけを淡々と話し、必要以上の接触は極力避ける。それしかないのだ。どうせたかだか2年程度の付き合いなのだ。

それ以前に、せっかくの修士課程2年間を人間関係で悩んで潰したらもったいないというのが自分の考えで、自分にとって必要だと思うことに取り組まないとせっかくの時間がもったいないと思っている。俺の場合、自分の金と親からの援助で勝ち取った2年間である。無駄にはできないのだ。

一方で、そういう対応ができるのもある程度のおっさん力がある故になせるワザでもあるので、もし先生との人間関係で悩んでいる学生がいたら、「ああいう人は社会に出たら寧ろ少数派だから、ああなっちゃいけないっていう対象として見とくんやで」とケアできたらなぁと思っている。

大学院講義のレポートについての所感

2018年6月16日

また間が開いてしまった。しかし特に特筆すべきことはなく、日々講義と研究をしている。 大学生活というのは誠に平和であり、会社と比べるとイベントは非常に少ない。非常に淡々としている。 毎日イベントがあったら学業どころではないので理にかなっていると言える。

しかし、身近なところではイベントと言うか頭を悩ませることは多い。 特にレポートで、正直苦労している。書けないということはないが、時間がかかる。そのために研究に割ける時間も減る。長時間稼働するので疲労が溜まる。ちょっと悪循環に入りつつある。

内容は理解できるが、問題はレポートの体裁で、どのように、どの程度書けば単位がもらえるものか皆目分からないものが多い。 同じ講義を取っている同じ研究室の学生にチラ見させてもらったりして何となく体裁は分かっているのだが、 果たしてどのぐらい詳しく書けば単位が取れるレポートになるのか分からない 。レポートは大体枚数が決まっているので書きすぎるのもよくない、しかし書かなすぎるのも良くない。 絶対的な評価基準はなく、先生事に基準は異なる。 全ては「先生のみぞ知る」らしい。勉強のためにレポートを書いているのであって先生のためにレポートを書いている訳ではないのだが、 大学として成績をつけなければならない以上、何らかの先生なりの基準を持って評価してもらうしかない。 学生と先生の間で推理合戦が行われるのである。

「これこれというコードを書け」というレポートなら大体どんなものでも無双する自信があるが、春学期に提出したレポートは 9割ぐらいが「ほげほげについて論ぜよ」という記述式のレポートである。具体的には、そのほとんどが「講義の内容を要約せよ」というものである。 コードは提出物としては一行も書いていない。 ナップザック問題をDPテーブルを書いて解け、という課題で検算のためにc++でDPを書いたぐらいである。

個人的にはこのレポートの形式ばかりなのは衝撃的だった。 CSの大学院ともなれば毎週のように実装課題が課せられるに違いないと思っていたが、どうもそういうのは 筑波大学では学部（学類）でのみ行われるらしい。 ちなみみに、他大学のCS系専攻を卒業した知り合いによれば、偏差値が高い大学に行くほど結構そんなもんらしい。 東大は最近python入門の講義とか始めたけどこれは珍しいらしい。

rui ueyamaさんのスタンフォード大学院に関するブログ記事を読んで、 大学院に入ったからにはあらゆる分野のブツを何でも実装しまくる気でいたのだが、 これは大学によって大きく異なるらしい。 なおスタンフォード大学院は今世では絶対行けないだろうなと思うぐらいの学費である。 グーグルも加入している企業向けの割引プログラムを使えれば１つか２つの講義履修ぐらいはワンチャンあるかも知れないが、グーグルに入ること自体がもう同じぐらい厳しいのではないかという気もする。

∃とか∀の意味が分からないだけでも思考が止まる

2018年5月22日

しばらく間が空いてしまったが、相変わらず講義に出て研究を進めている。

近況

気が付けば入学から2か月近くが経ち、筑波大学でいうところの「春A」期間が終わった。
通常、講義は春A+春Bというセットで構成されているため殆どの講義はそのまま春B期間（7月2日まで）まで継続される。ので特に節目という感じはしないのだが、まぁ暦上はそうなっているということである。

今週締め切りのレポート3つを提出し終えてかなり気が楽になった。大学生活が久しぶり過ぎてレポートにおいては問われている問題についてどの程度まで詳しく説明すべきか良く分からなかったが、少なくともこう書けば自分は100%理解できる、という所まで説明する感じで書いた。

例えばアルゴリズム関連のレポートでは3-SATをクリーク問題に多項式時間変換する過程の説明をしたりもしたが、通常、数学における証明では具体例はあまり書かない気がするが、具体例がないと自分がアホなので上手く説明できないので「例えばx1が真でx2が偽の時にこの式は充足可能である。ので、、」みたいな感じの説明をつらつら書いたりしていた。多項式時間変換は感覚的には分かってもちゃんと証明することが難しい。

集合論が全く分からないことに気づいた

にしても、やはりCS系の講義というか工学系の講義を一切取ってなかったために色々前提知識が足りていないと感じる部分があった。

その中でも一番やばたにえんなのが集合理論の記号の意味が分からないことで、例えば講義資料や先生の板書の中で

∃∀x, y, x ∈ Z, y ∈ Z

みたいな定理が出てきても最初は全然分からなかった。
∈ は含む というのは分かるが、カタカナのヨみたいなのはなんだろうか。。どういう意味だろうか。。あとZはなんだろうか。。*1

そういうことを考えているとその時点で思考が止まって講義の内容に全くついていけなくなった。ヤバい。
実際、数理系の講義はちょくちょく途中で式の意味が分からずにフリーズしてしまい、講義後に先生に聞きに行ったりしていた。が、やはり「あのカタカナのヨみたいなのはなんですか？ガンダムのシリーズみたいなやつ（∀）は？」とはさすがに聞いちゃいけない気がしていてその辺の質問は避けていた。

この手の記号が集合論関係ない定理の証明とかでもふつうに出てくるので知らないとホントにヤバそうに見てきた。*2

そんなある日、自分が知りたい数学の記号の意味をうまくまとめた資料(pdf)を偶然見つけた。記号の意味だけでなく、大学数学における前提知識が端的にまとまっている素晴らしい資料である。

果たしてこれは何かと思ってURL削ってみたら、立命館大学の数学学修相談会というサイトのサブテキストの１つだった。なんでも立命館大学では学生の有志が数学の学習をサポートする取り組みを行っているらしい。素晴らしい。

筑波大学にもこういうのがあると助かるのだが、さすがに集合論を一切やらずに大学院にやってくるアホなんてのは想定してないだろうし仕方がない。足りない知識は自分で勉強していくしかない。

今の自分に足りてないもの

離散数学の基礎知識

上述の集合論も含めて、代数、グラフ理論、アルゴリズムなどをひっくるめた分野として「離散数学」というのがあるらしい（全く知らんかった）。どれも勉強したことがない内容なので、どうも自分はこれを学部生時代にやってないせいで多くの前提知識が抜け落ちているらしい。 CSを勉強している学部生にとっては基礎みたいなもんらしく、学部生向けのテキストが充実してるのでこれを使って独学できそうである。

とりあえず離散数学の入門書としてamazonで評価が高かった以下2冊を読んでいる。

やさしく学べる離散数学

応用事例とイラストでわかる離散数学

また、前述のアルゴリズム関連の講義も取っていたがやはりいまいちよく分からなかったというかちゃんと勉強したいので数理最適化に関する本も一冊買った（これは普通にレポート書くための参考書として使った）

IT Text 数理最適化

制御工学

春Bから始まった新たな講義で「制御工学」が出てきたのだが、これもやってないので全く分からんということで大変危機感を募らせている。。 しかも状態方程式は微分方程式として表現されるので微分方程式も解けないとマズそうである。。こっちも12年前に勉強して以来全く使ってないので知識が綺麗に揮発しているため勉強しないといけない。。

これも講義で紹介された本を読まねば絶対ついていけない気配が濃厚である。

アドバンスト制御のためのシステム制御理論 (システム制御情報ライブラリー)

フィードバック制御の理論―ロバスト制御の基礎理論

ただ自分には入門書の方が必要な気がするので先にそっちを探した方がよさそうなので明日図書館を漁ってみることにする。独学のための教材費が結構高くなってきた*3

*1:今思えば∃は感覚的に分かるもんではなく、さらに∃の意味が分からないと式全体が何を主張しているのか分からなくなるので知らないとヤバい記号ナンバーワンな気がする

*2:haskellをちょっといじってたおかげでリスト内包表記は理解できた。

*3:図書館にないやつはできるだけamazonマーケットプレイスで買っているがそれでも定価の半額以下にならないつらみ