東京大学大学院 情報理工学系研究科 創造情報学専攻に合格しました
はじめに
色々あって院試に合格しました。東京大学大学院 情報理工学系研究科 創造情報学専攻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割くらいは取れたかなという感じだったので,採点はそんなに厳しいということはなさそうです。
数式アレルギーの人たちへ
数学者でプログラマの結城先生の《数式アレルギー》に関する文章を読みました。ぼく自身も理系の端くれですし,色々と思うこともあるのでちょっと書いてみようと思います。
先生の言うように,数式っていうのは,われわれ理系にとってはものすごく大事なものです。それこそ「ことば」であったり,「共通語」であったりするかもしれません。数式はほとんどすべてを厳密に表現できるし,だれが見ても基本的には同じ情報が伝えられるからです。
でも,そうであっても,それが
何を怒っているかというと「私は数式アレルギーでして(てへ)」といってる(自称)大人に怒るのだ。勉強不足を恥じろよ。若者を自分のレベルまで落とそうとするなよ。文系ですからなんていうなよ。きょうび文系でもしっかり数式はよむぜ!若者を自分のレベルまでおとしめようとするのに腹が立つのだ。」
だと言っていいことにはならないと思うんです。
漢字が読めない若者を怒るでしょう?英語を読みたくないという若者を叱るでしょう?数式はそれと同じだ。
たしかにそうかもしれないなあ,って思います。でも,英語や漢字と数式とでは「生きるために必要かどうか」っていうことが,かなり根本的に違ってくるような気がします。数式にまったく触れなくても生きていける人は数多く存在するけれど,英語と漢字に触れなくても生きていける人は,数式のそれに比べると圧倒的に少ないんじゃないか,ということです。 加えて,漢字や英語は「生きているだけで自然に」身につけていく人もいるものです。数式はきちんと教育を受け,トレーニングを重ねないと読み書きすることはできません。
というような文章を書こうと思っていたのですが,どうやら先生が伝えたいのはそういうことではないようですね。
自分が使える武器を磨こう。武器とは言葉だ。日本語も英語もプログラムも数式も、あなたの武器だ。
氏はこのようにも述べていて,
大人は真剣に勉強しよう。真剣に考え、真剣に学ぼう。
最後にはこのように締めくくっています。
全員が数式を数学者のように読めと言っているのではない。そうではなく、歴史的な《知》に対する敬意が感じられない発言に腹を立てているのだな、私は、きっと。
けれど「大人が数式を学ぶ」っていうのも,そう簡単にいかないんじゃないかな,とも思うんです。なぜかというとそれは,先生が述べるように 歴史的な知 であるからです。数学とは(数学だけには限らないことですが)本当に気の遠くなるような先人たちの知恵の結晶の積み重ねの上に,成り立っているものだからです。
たとえば高校2年生の終わり〜3年生くらいで習う「微分と積分」は,(諸説ありますが)実際に生み出されたのは17世紀です。つまり,1+1から始まって,がんばって高校生まで数学を勉強したとしても,300年も前の数学に追いつくのが精一杯だということです。
「お,数式なんだかおもしろそうだな」とか「数学ちょっとやってみようかな」と思って,実際に楽しくなるまでには,積み上がっているものがどうしても大きすぎるのです。数学の歴史が積み重ねの上に成り立っていたように,数学の教育も同じように積み重ね上に成り立っているからです。微分と積分がわかるためには,Σの計算と極限がわかっていなければならず,Σがわかるためには数列が,数列がわかるためには方程式が,といった具合です。
受験とか教育とかではよく言われていることですが,これが数学のむずかしいところであり,数学が得意な人と嫌いな人をわけてしまう大きな要因の1つでもあります。ある地点でつまづいてしまったとすると,そこからいくら学んでも,それは基礎の悪い建物を作るようなもの。積んでも積んでも崩れていってしまうばかりです。
そこで「つまづいてしまったところ」まで戻って,そこからまた積み重ね直す,っていうのもなかなか時間的にむずかしいことです。だからこそ《数学アレルギー》になり,とりあえず見なかったことにしてしまうのかもしれません。
そんなわけで,《数学アレルギー》もなんだかんだしょうがないのかもね,というお話でした。とはいえ,結城先生の「数学ガール」なんかは,また今までと違った切り口で数学を捉え直しているし,前に書いた「積み重ね」をそこまで意識せずとも楽しめる,とてもいい本なんじゃないかな,とは思うんですけどね。
そう思うと,比較的歴史が浅く,始めてから数年で仕事に使えるくらいのレベルに達することができる英語やプログラミングなんかは,なかなか「真剣に勉強しやすい」のかもしれませんね。とはいえプログラミングも「なにがどうなっているのか」をしっかり理解しようとすると《数式アレルギー》を克服しなければならないのですが。
だれのためになにをつくるのか
Webエンジニアとしてのアルバイト
さて,ここには書かなかったのですが,Webエンジニアとしてアルバイトを始めてからそろそろ1年くらいになります。なんだかんだ3つの会社を渡り歩いて来て,色々と思うこともありました。1つ目は大手IT企業を脱サラした2人が立ち上げたガチガチのスタートアップベンチャーで,2つ目は社員50人くらいのそろそろミドルに行きたいベンチャー企業,3つ目は社員数400人くらいのメガベンチャーでした。
ぼくがしていた仕事は,ちょっとむずかしく言うと「バックエンドWebエンジニア」という役割です。ものすごく大ざっぱに言うと,Webページの見た目を作るのではなくて,ユーザーごとに異なる動作をするとか,データベースを操作するとか,そういう「裏側」を作る人のことですね。 具体的にぼくがどんな仕事をしていたかというのは今回ほとんど関係がないので,まあそんな仕事もあるんだなくらいに思っておいてもらえば問題はないです。
今回はこのあたりにからめて なにかをつくるとはどういうことか ということを書こうと思います。
マニュアルを読めば
1つ目の会社で作っていたWebアプリは,主に官公庁や古くからある企業むけのものでした。基本的には「今まで紙ベースで行なっていたものをWebベースにしよう」という姿勢のもので,具体的には業務支援サービスや勤怠管理システムのことを示します。 そこでは ユーザーのことを考える ということは,残念ながらほとんどありませんでした。 「どうすれば使いやすいか」を考える暇があるならマニュアルを書けばいい といったような感じで,悪く言えば殿様商売といったところですね。
ここから先はぼくの邪推だけれど,開発者とユーザーの間にはこういう心理があるのだと思っています。
- 開発者
- どういう風に使っても案件が決まってしまえば使ってもらえる
- ユーザー
- どれだけ使いにくくても結局それを使うしかない
というもので,もう少し言い方を変えると,両方とも「天から降ってくる」ようなものだといえます。 ユーザーにとってそのサービスは, 天から降ってきたのだから仕方なく使うもの であるし,開発者にとってそれは 天から降ってきた案件なのだから最低限の仕様さえ満たしておけばよいもの でしかないということです。
こんな風に書くとSIerとか業務アプリといった業界を批判しているかのように見えるかもしれないけれど,そういうわけでもないのです。そこにコストをかける必要がないのであれば,そこにコストをかけないのはごく自然なことだからです。 そのシステムではそれは求められていない。
見たところ使いにくいなあ,と思っていたシステムではありましたが,それを使いやすくするためには時間もコストもかかります。まだまだ下っ端エンジニアだったぼくは「これはこういうものだ」と言い聞かせ,ひたすら上に言われた通りにプログラミングをしては,マニュアルを書いていました。 ほとんど「ログアウトボタンを押すとログアウトできます」なんてことが書かれたマニュアルを作らなければいけないことはそれなりに悲しくはあったのですが,そういう仕事なんだと思うしかありませんよね。学生アルバイトができることなんて,本当に微々たるものなのです。
新しい技術を取り入れていくべきか
その会社で使われる技術は,お世辞にもそこまで最新のものとはいえませんでした。ぼくはそこそこギークな人間で,はてなブックマークやらなんやらで「流行り」を追っかけるということが好きです。その会社ではその記事でもう時代遅れだと批判されているような技術やフレームワークがまだまだ現役でした。 そこにはバージョン管理という概念はなく,全員が本番サーバにターミナルからSSHでログインし,vimで直接ソースコードをいじるといったような環境です。
けれどこれも,それが必要とされていないから,変わることはないんですね。いわゆる「技術力が高い」と言われるITベンチャーなんかだと,最新の技術やフレームワークをどんどん取り入れていきます。
なるべく少人数でスピーディーに開発できるシステムを用いれば,人件費を下げることができます。どんどん効率化していかないと,競合するサービスに敵わないからですね。また頻繁な新機能の実装とテスト,セキュリティの維持,バグの修正,負荷対策などなど, 様々な問題をその高い技術力で解決していかなければいけません。
けれど,二回目になりますが,ぼくがかつて作っていた業務アプリケーションでは,そういうことは必要とされていなかったんです。いわゆる「作りきり」でお金もぽーんともらえるので,最新の技術を使う必要はないし,使われる場面も限られていますから,新機能が追加されることもほとんどありません。セキュリティだってお世辞にも強化されているとはいえませんでした。
まったく毛色の違う2つの会社で働いてわかったことは,結局 技術力は必要とされなければ高まらない ということでした。今となっては当たり前のように思えますが。新しい技術をどんどん取り入れていくことは,一見するとすばらしいことのようにも思えます。しかしそこにはドキュメントが少なかったり,開発できる人が少なかったり,導入コストが高かったり,色んな障壁も存在するのです。
なぜ技術が必要か
結局のところ技術力って「だれのため」のものなんでしょう。また「なんのため」にあるんでしょうか。 ぼくは結局それは 「ユーザーのため」であり,最終的には「エンジニアのため」 なんだと思っています。
エンジニアには大きく分けて2種類の人がいると思っています。技術が大好きって人と,ユーザーが大好きって人ですね。ぼくは残念ながら前者ではなくて,後者のエンジニアです。 じぶんの作ったものをなるべく多くの人が楽しく使ってくれたらうれしい。そういうエンジニアです。
結局そのために技術は必要なんです。 ユーザーに合わせて,速いスピードでプロダクトを評価,改善していって,どんどん使ってもらう。そういうことを繰り返していかないと,ユーザーに価値なんか提供できません。ユーザーから挙がってくる「ここは使いにくいな」とか「ここがもっとこうなるといいのに」ということを無視していたら, なるべく多くの人が楽しく使って くれることはないからです。
ぼくにとって技術は,ユーザーを喜ばせたいエンジニアのためにあるものだ,ということです。
なぜエンジニアなのか
ひとことに技術技術と言われるエンジニアがどんなことを考えているのか,一例としてなんとなくわかっていただけたんじゃないのかなと思います。
ぼくはエンジニアのすごいところ,おもしろいところは
少数の力で速いペースで世の中を良くすることができること
なんじゃないかなと思っています。医者とか政治家とか教師とかに比べて,圧倒的速いペースかつ,小規模のチームが世界に大きな影響を与えてきました。
これがぼくがエンジニアを選んだ理由でもあります。世の中にたくさん仕事はあるけれど,エンジニアならなるべく多くの人をなるべく早くハッピーにできる,と本気で考えているからです。
もちろん技術を使って仕事をする会社はたくさんあるのですが,やっぱり「なにか作ってだれかをしあわせにする」っていうことからは離れたくないな,といつも思っています。
予告みたいなもの
さて今回はいつも通りビジョンばかり書いて終わってしまいました。3つの会社を経験してきたことがあんまり活かせていないので,今後はそのことを書いたり,もう少し「はたらくとはどういうことか」ということを書けたらいいなと思っています。
数値化できないこと
ぴゅあだった頃の夏の話
専攻を語ってください
ぼくと大人と新幹線と
*1:「あの人たちは、私の知らない楽しみ方を、心から知っている」というのは、私にとって「大人」を感じるのに充分な事実でした。