快適な開発環境の構築のためにQEMUのVMをLAN内に置いたり、DNSサーバーを建てたりリバースプロキシを構築したり

技術

やったこと

  • PPPoEに切り替える
  • バーチャルブリッジ作って全部そこにつなげる
  • 独自ドメイン買ってラズパイでDDNSする
  • ポート開放(いつもの)
  • 内部用のDNSサーバーをdnsmasqで建ててローカルでもドメイン名でアクセスできるようにする
  • リバースプロキシをnginxで作ることによって複数のドメイン(サブドメイン)を同一IP上でホストする

開発環境について

今まではローカルにいちいち開発環境を構築していたが、マシンごとに環境が違っていたりせっかく性能の良いマシンが家にあるのにノートのスペックが足りず満足行かなかったりした。企業のサマーインターンに伺った際に vscode で ssh を繋いでそのマシンの中で開発ができることを知り、まずはそれを自宅のマシンで実現するために ssh 接続を便利にできるようにした。さらに適当に使っても良い開発環境を用意するために、元々用意してあったQEMUのVMをネットワークブリッジを作成することでLAN内からアクセス可能にし、Raspberry Pi 4B を踏み台として外部から接続できるようにした。

やったこと

PPPoE に切り替える

最近引っ越したばかりなのだが、新居では IPoE で接続していたのでポート開放ができなかった(設定画面上でできているように見えても接続できなかった)。これを解消するためにPPPoE接続に切り替えることが必要だった。レイテンシや速度を多少犠牲とするようだが、元々大した数値じゃなったから実用上問題は無かった。今時わざわざログインIDやらパスワードやら入力してPPPoEで接続するよりIPoEで回線認証したほうが楽なのでPPPoEユーザーはあんまりいないのかもしれない。

バーチャルネットワークブリッジを作成し、VMのネットワークインターフェースを変更

QEMUでエミュレータを作成した際はデフォルトで作られていた virbr0 というネットワークブリッジを指定していたけれど、これだとVMのホスト以外からアクセスすることができない。どうもVMのホストのネットワークの中にある扱いになるようなので。なので新たに br0 というブリッジを作成した上でこちらを外にも繋げてしまうことでルーターから直でローカルIPアドレスが振られるようになって、LAN内の他のデバイスからもアクセスできるようになった。原理については正直よくわかっていない。 実現方法は様々あるようだが、セットアップの際に systemd-networkd で全ての設定を済ませているので今回もそこをいじることにした。 元々は 50-wired.network で enp4s0 インターフェース(有線LAN)を下記のように設定していた

[Match]
Name=enp4s0

[Network]
DHCP=yes

(/etc/systemd/network/50-wired.network)

これを

[Match]
Name=enp4s0

[Network]
Bridge=br0

(/etc/systemd/network/50-wired.network) (enp4s0 の部分は使っているネットワークインターフェース名 ip a とかで見れる)

というように変更する。ブリッジは

[NetDev]
Name=br0
Kind=bridge

(/etc/systmed/network/bridge0.netdev)

で設定。最後に

[Match]
Name=br0

[Network]
DHCP=yes

(/etc/systemd/network/bridge0.network)

というように設定すると br0 に DHCPサーバーからIPアドレスが降ってくるようになる(んだと思う)。これでルーターのデバイス一覧からもVMが確認できるようになり、もちろん他のマシンからもアクセスできるようになる。sudo virsh edit からインターフェースを変更するとVMのインターフェースを切り替えられる。MACアドレスを設定している行とかよくわからんの色々あるけど、ああいうの設定ファイルに書いてなくても自動で生成して付け足してくれるから気にする必要なし。

WakeOnLan の設定

現在持ってるマシンはこんな感じ。

  • Raspberry Pi 4B RAM 8GB
  • メイン機
    • CPU: Ryzen9 3900X (12C24T)
    • RAM: DDR4-3200 32GBx2
    • GPU: NVIDIA RTX3080 8GB
  • サブ機(元メイン機) 今回の話には関係ないけど
    • CPU: Ryzen5 2600
    • RAM: DDR4-2666 16GB
    • GPU: NVIDIA GTX1660ti
  • ノート
    • CPU: Ryzen7 5700U
    • RAM: 16GB
    • GPU: 内蔵のやつ

メイン機はメモリをガン積みしCPUも良い感じなので基本的に性能面で文句はない。ノートPCも普段使いには全く問題ないのだが、開発のためにVMやモバイルエミュレータを立ち上げたりし始めるとメモリがだいぶ厳しくなってしまい快適とはあまり言えなくなってしまうこともある。自宅のメイン機に接続して開発したくなってくるわけだけど、起動しっぱなしにするには電気代や部品の耐久性という点で少々不安が残る(Mini-ITXなのでなおさら)。そこで今回は Raspberry Pi を常時起動のサーバーとして、使いたくなったときはそこから WakeOnLan でマシンを起こしてあげるという方法を取ることにした。 メイン機は Arch Linux で動いているので、比較的簡単に WakeOnLan を設定できる。wol-systemd という AURパッケージを用いることでとても簡単に実現できる。BIOSの設定でWoLを有効にした上で

yay -S wol-systemd
sudo systemctl enable wol@enp4s0
sudo systemctl start wol@enp4s0

(enp4s0 の部分は使っているネットワークインターフェース名)

というようにすることでWoLの設定を永続的にすることができる。この上でRaspi上から

sudo apt install wakeonlan
wakeonlan {メイン機MACアドレス}

とするとラズパイからメイン機が起動できるようになる。ラズパイの消費電力は大したことないので、これでだいぶ電気代を節約できる。このラズパイに外部から接続できるようにすれば、外部からメイン機の電源が入れられるようになる。

DDNS設定

PPPoE にしてポート開放してさて ssh で繋ごうと外部から接続しようとしてもどうも上手くいかない。どうも1日毎程度の頻度でグローバルIPアドレスが変わっているようだ。実家ではそんな頻繁に変わるものでもなかったのでサボっていたけれど、ここまで頻度が高いと設定するほかないのでDDNSを設定することにした。 まずは Cloudflareでドメインを購入し、DNSレコードを追加してドメインと自宅のIPアドレスを紐づける。ここで Proxy をオフにしないと上手くいかないので注意。nslookup とかで自宅のIPを示していることを確認したら、外部から ssh がドメイン指定でも繋がることを確認する。LAN内からだと上手くいかないので(後述)、テザリングなどで接続するのが良い。次にラズパイに ddclient を導入し、IPアドレスが変わっても自動的に Cloudflare のDNSレコードを変更してもらうようにする。

zenn.dev

この記事を参考にすれば大体上手く行くが、ddclient のバージョンの問題は現在解決しているので気にする必要はない。ちゃんと設定できているかは sudo ddclient -v -force などとすると確認することができる。cron が好きではなく systemd が好き(なんとなく)なので sudo systemctl enable ddclient && sudo systemctl start ddclient としてデーモンとして走ってもらうことにした。sudo journalctl -xeu ddclient と打つとログが見れて5分おきにIPアドレスを更新しに行ってる様子が見れる。最悪の場合5分のダウンタイムが発生するが、そもそも個人宅のサーバーで運用するようなサービスは5分落ちようと大した問題にはならないだろうからまあいいだろう。

内部用のDNSサーバーを建てる

LAN内からドメイン指定でアクセスしようとしてもうまく行かないのはドメインがローカルのアドレスを指していてルーターに行っちゃったりするからだった気がする。内部のものは内部で解決してあげるのが都合が良い。/etc/hosts にドメインとローカルIPアドレスの関連を書いてあげればうまく接続することができるけど、何個もあるマシン全部の /etc/hosts をいじるのも微妙だし統一するのも微妙なので今回はDNSサーバーを建てることにした。 自分で持ってるドメインは自分で解決して、それ以外を 1.1.1.1 とか 8.8.8.8 にお任せすればよろしい。これをうまいことやってくれる dnsmasq というソフトがあるので、これをラズパイ上で走らせる。

sudo apt install dnsmasq
sudo vim /etc/dnsmasq.conf

コメントアウトを剥がしたりして

domain-needed
bogus-priv
resolv-file=/etc/resolv_dnsmasq.conf
strict-order

などとして /etc/resolv.conf を

nameserver 127.0.0.1

/etc/resolv_dnsmasq.conf を

nameserver 1.1.1.1 (お好みで)

などとしてあげる。ルーターでラズパイのIPアドレスをDNSサーバーとして指定してあげたり、メイン機のresolv.confにそのIPアドレスを指定したりするとラズパイをDNSサーバーとして使ってくれるようになる。解決したいドメインは /etc/hosts に記載する。IPアドレスとドメインを空白区切りにした行を追加して sudo systemctl restart dnsmasq すると設定が反映されてローカルからホストしてるドメインにアクセスしてもちゃんと接続できるようになる。

nginx を使ってリバースプロキシを構築し、複数のドメインを扱う

サブドメインは何個作っても無料なのでなるだけ使いたいという気持ちになるが、普通にやろうとすると1ドメインに対して1IPアドレスしか指定できないので上手くいかない。そこで nginx を用いてリバースプロキシを構築し、ドメインごとにマシン分けたりポート分けたりするとうまいこと複数のドメインを1つのグローバルIPアドレスで扱うことができる。 眠いので詳細は後日追記するけど、ドメインごとに設定ファイルを作ってそれぞれlistenしてるドメインごとに proxy_pass に別のマシンのIPアドレスなりポートなりを設定すればうまいことできる。/etc/hosts では全てラズパイを指定する。DNSのレベルでは全てラズパイに集められて、そこからリバースプロキシで様々なマシンやポートに分配していくという形になるので。開放するポートも一旦ラズパイに流すよう設定すれば良い。 例として、hi.takabayap.com と hello.takabayap.com を同じマシンの別のポートで扱ってみた。こんな感じになる。

上が実家のラズパイ、下が自宅のラズパイ。どちらの場合も上手くいってることがわかる。

こうすることによって例えば ssh.example.com を ssh 用に使ったりとかそういうちょっと贅沢なことができるようになる。それ以外でも色んなサブドメインを一つのマシンで使えることは結構嬉しい。アプリのテスト用サーバーを用意するときなんかに使うことになると思う。

ドメインを追加するとき

/etc/hosts にドメイン名を追加して dnsmasq を再起動するとローカルから解決できるようになる。Cloudflare のDNSに登録し、nginx の設定ファイルを/etc/nginx/sites-available に作成し /etc/nginx/sites-enabled へリンクを張って nginx を restart することでリバースプロキシが動作するようになる。飛ばす先でサーバーを動作させれば無事接続することができるようになる。

おわり

DNSなどのネットワークまわりは一旦了解しても時間が経つとわからなくなりがち。定期的にTCP/IPに入門したりしないとこういうところで苦労するようになるので、こうやって苦労したことは書き残していこうと思った。QEMUをまともに走らせるのにも結構苦労した覚えがあるから、まだギリギリ記憶があるうちに history から書き起こしていきたい。明日からはどこにいようと自宅のマシンに接続して開発ができるので、作業が進みそうだけど、もしかしたら勉強する前に勉強机を丁寧に掃除したりするのと同じ心理が働いているだけかもしれない。今後注視していきます。

Enablement Internship for Gophers (6/21～6/23) に参加しました

技術 インターン

早稲田大学基幹理工学部表現工学科3年の@takabayapと申します。このたびナレッジワーク社のEnablement Internship for Gophersに参加してきました。

なにしてきたか

プログラミング自体は小学生の頃からやっており、今11年目(！)。Goは高校のときにちょっとだけ触って、本格的に勉強しはじめたのは2021年なので2年目くらい。ハッカソンやアプリ開発で利用しています。

github.com

技育CAMP vol.9で作ったウェブアプリ。参加記録を書こうと思ってもう半年が経ったため、引用するブログ記事がありません。

takabayap.hateblo.jp

リリースしたアプリ。バックエンドは全部Goでできてます。

Goはシンプルで、好みが分かれがちではありますが私はかなり好きです。今回のインターンシップはピッタリでした。

Enablement Internship for Gophersとは何か

Enablement Internship for Gophersとはナレッジワーク社が実施してる3daysインターンシップです。
ナレッジワーク社はtoBのクラウドサービスを展開している企業で、2020年4月創業とまだ創業して間もない企業であるにもかかわらず製品は誰もが知る日本を代表する企業に導入されています。

knowledgework.cloud

メインとなっている製品はセールスイネーブルメントに焦点を当てたものですが、会社としてエンジニアイネーブルメントにも取り組んでいます。イネーブルメントとは直訳が難しいけど「ひとりひとりの成果・能力の向上」のようなニュアンスでナレッジワーク社は特にGoに力を入れており、今回のインターンシップもその活動の一環と言えるでしょう。

prtimes.jp

今回はGoの主要な機能の1つである並行処理をメインテーマとしていて、講義を行ったあとに個人でOSSとしてなにか1つ関連したものを作るという内容のインターンシップでした。

参加するまで

元々ハッカソンで登録していたサポーターズさんから今回のインターンへの招待が来ていたことが切っ掛けで申し込みました。まず面談を実施し、コーディングテスト、面接を経て参加という流れでした。
面談では会社や製品の概要、大事にしている価値観など丁寧にお話し頂いて大変良かったです。インターンの面接自体初めてだったので緊張していたけれど、初めてがこれで本当に良かったと思っています。ただエンジニアが少数精鋭という雰囲気で非常にレベルが高そうで、今回のインターンシップもGo上級者向けと銘打っているので要求されている能力に対する自分のレベルが少し不安になりました。
実施されたワークショップの動画を見てコーディングテストに備え、コーディングテストは相変らず締切3時間くらい前に開始。内容は聞いていたようにかなり難易度が高く、正直落ちても全然不思議ではないと思っていました。
面接を受けたらまた自分の勉強不足を実感し、ここでも落ちてても全然不思議じゃないという手応えでした。合格できて良かったです。初めてのインターン合格でした。

なにしたか

  • 1日目
    • 講義
    • チーム開発
    • 発表
  • 2日目
    • 講義 sync.Onceのruntime.Goexit()での挙動やGoDebugの話など
    • 個人開発
  • 3日目
    • 個人開発
    • 発表
    • 懇親会

チーム開発

課題

チーム開発で選べる課題は2つあって、1つがsync.Onceに関連するもの、もう1つがcontext.AfterFuncに関連するものでした。うちのチームはせっかくなのでより難しそうなcontext.AfterFuncのほうを選びました。

github.com

Dialしてnet.Connを得るときにcontextを渡してcancelできるように、DialWithContext関数を実装しようという課題です。まずGo 1.21で追加予定のcontext.AfterFuncを利用して実装し、これが出来たので次にAfterFuncを使用しない実装を試みました。シンプルにctx.Done()を受けとってnet.ConnをCloseするようにしていただけだったけれど、これだとWithCancelのcancelを使わずにDialWithContextで得たnet.ConnをCloseするとctx.Done()を監視しているgoroutineが終了することなくリークしてしまう。そこでcancelFuncを返すようにしてconn.CloseしたあとこのcancelFuncを呼び出すと監視しているgoroutineを終了できるようにしました。実装としてはcancelFuncが呼び出されるとDialWithContext内で開けたchanをcloseします。この終了を伝えるchanをctx.Done()と並行して監視し、returnしgoroutineを終了するようにすることでgoroutineリークを無くすことができました。runtime.NumGoroutineを関数実行前後などで呼び出し、goroutineの数が正しく元に戻っていることが確認できました。

func DialWithContext(network, address string, ctx context.Context) (net.Conn, func(), error) {
    conn, err := net.Dial(network, address)
    if err != nil {
        return nil, func() {}, err
    }

    done := make(chan struct{})

    go func() {
        select {
        case <-ctx.Done():
            conn.Close()
        case <-done:
            return
        }
    }()

    return conn, sync.OnceFunc(func() {
        close(done)
    }), nil
}

(tenntennさんからのご指摘により一部コードを修正しています)

感想

まずモブプログラミングという手法を体験するのが初めてでした。自分が理解できたことがなかなかつたわらないともどかしいし、かといって自分が書く側に回ると自分が書きたいコードを勝手に書くわけにもいかないというところに難しさを感じました。結果的には人に説明することで自分の理解も深まるし、書く側が理解できていなかったとしても書く過程で理解が要求されるのでチーム内の理解を半ば強制的に同じ水準まで引き上げるという効果があり、長期的な生産性の向上に繋がるのだろうと納得しました。
GoのRelease Candidateなんて入れたことなかったのでそこも新鮮でした。そもそも普段開発してるときにバージョンほとんど意識してないですし。goroutineの数を意識した開発もしたことがなかったので勉強になりましたが、自分が作ったサービスのコードのどこかでgoroutineがリークしてたらどうしようとちょっと怖くなったのでこれから手を入れていきたいです。

個人開発

github.com

課題

個人開発の課題は以下の3つのいずれかです。

  1. 並行処理のテストツール
  2. Goroutine/channel の可視化ツール
  3. 同期ライブラリ

まず自分で実際に使うようなものを作ろうという気持ちがあり、そこから考えていきました。
テストツールで並行処理の順番を制御し全ての組み合わせでテストして実行順に関係なく動作することを保証しようとしたけれど、goroutineの動く順番のみならず内部の処理の順番も制御しなくてはならず、関数の外側から気軽にテストするものはできそうになく悩んでいました。tenntennさんに相談したところ全部列挙してテストすることに拘らなくても良いのではないかという助言を受けたので、可視化ツールとして1回1回の実行順を可視化する方向を考え始めました。実行順によって問題が発生しそうなものを考えてみたらいいんじゃないと言われたときに、Mutexのロックとアクセスを可視化できたら便利かもしれないと思ったのでMutexの可視化ツールへと舵を切りました。授業でロボットを作り、ロボットのフィールド上の位置を状態として持ちMutexを用いて管理する予定だったので、自分で使うようなものを作るという目標にも適しています。
可視化するにはどうすればいいかというのも問題でしたが、他の方のワークシートをチラチラみていったらGraphvizという便利そうなものを知れたのでそれを使うこととして一旦可視化は後回しに。Mutexのインターフェースを持ち、追加でRead/Setを持つMutexVisualiserという構造体を用意してこの構造体に関する全てのアクセスのログを取り可視化に用いることにしました。

type Mutex[T any] interface {
    sync.Locker
    Set(T)
    Read() T
}

type MutexVisualiser[T any] struct {
    m       sync.Mutex
    actions []action
    value   T
}

どんな型でも値に用いたかったのでジェネリクスを初めて使うことに。Mutexのアクセスを全部持っておくのはそこまで難しくなくて、runtimeから呼び出し元の関数名やgoroutine IDを取得したりtimeを取ったりと結構順調でした。可視化の段階に入って、go-graphvizを使おうと思ったけどこれがなかなか難しく、rankの設定やsubgraphの使い方がドキュメントになかった上に使っている人も見つからなかったので使うのを諦め、他にも色々ないか探したうえで結局graphvizが使いやすそうだということになったのでtemplateを用いてgraphvizを直接書いていくことにしました。ここにかなり時間を使って、なんとか上手く可視化できたところで開発時間が終了しました。

生成されるグラフ

感想

発表ではグラフの見た目が特に評判が良かったです。クラフトマンシップを感じると言われ、拘ってよかったと思いました。メンターの方には手が速いという評価を頂き、自分は手が遅いほうだと思っていたので結構自信に繋がりました。ワークシートに事前に必要そうなナレッジを表として整理した上で計画的に調べ物をして、最後にコーディングをしていくという手法がかなり強力だったので、これからも使っていこうと思います。今までは無計画に調べ物をして満足してしまうことが多々ありました。 他のチームの方で時間内に丁寧なREADMEを書いていらっしゃる方がいて、READMEを含むドキュメントに全然力を割いていなかったので、そこの重要性を再確認しました。

まとめ

全体を通して大変楽しかったです。講義で触れられるものは知らないことばかりでしたし、歩くGoDocことtenntennさんはあらゆる質問に答えてくれるという安心感がありました。気軽に質問できる体制が整っており、コミュニケーションコストが高いというオンラインのインターンシップの弱みがだいぶ薄れていた印象です。
懇親会も含め話した参加者の方は全員修士課程在学中でした。普段Goを書かないという人も参加していましたが、急速にGoを吸収していっていたのでレベルはやっぱり高かったです。

完全オンラインで仕事をするというのがどんな感じなのかというのも体感できて良かったです。基本的に自室で一日が完結してしまうのでストレスに感じてしまう人もいらっしゃるでしょうが、私にとってはとても快適でした。メンターの方も含め会社の方も非常に話しやすく、安心して取り組むことができました。次回も是非参加したいですし、特にGoが好きな方にとてもオススメできるインターンシップでした。

Go + Flutter でモバイルアプリを開発しリリースした話

技術

この度所属している大学の大学生向けアプリを開発し Apple の App Store と Google の Play Store にリリースしました。

play.google.com

マイルストーン

マイルストーン

  • MILESTONE HENSHUKAI, GENERAL INC. ASSOCIATION
  • 教育
  • 無料

apps.apple.com

アプリのダウンロード数などのグラフを示している。合計DL数が3800程度。

リリースから1週間経った時点でのアプリストアでのダウンロード数などのグラフです。自分が思った以上に使われていますね。

思えば生まれて初めてこういった形で自分の書いたコードで実際に人に使われるものが作れたなと感慨深いです。この記事ではアプリの開発の裏側、利用している技術や開発過程などを説明していきます。

マイルストーンとは

マイルストーンエクスプレスは、早稲田大学の非公認サークル「マイルストーン編集会*1」が発行している学生向け雑誌で、学生からのアンケートに基づいた授業の評価をまとめた逆評定を掲載しています。

今回作製したアプリでは、マイルストーンエクスプレスに掲載されている逆評定のデータを検索し、お気に入りに登録することができます。ただし利用には書籍購入時に付属しているシリアルコードをアプリで利用するアカウントに紐付ける必要があります。

iOS、Android双方で利用可能で、開発期間は去年の9月頃から始まり、3/10の書籍発売に合わせリリースできました。相方はコードはあまり書けないのですが、サークルに連絡を取ったり、リリースに必要な文章や利用規約の準備等事務作業を全て担当してくれました。そもそもアプリの制作という話をサークルに持ちかけたのも彼なので、彼無しでは完成しなかったどころか始まってすらいなかったでしょう。バックエンドは全て私が担当し、フロントエンドのデザインは相方に任せそれ以外を担当しました。

利用している技術

OpenAPI(Swagger)

今回最も使ってよかった技術の一つです。アクセスポイントをyamlやjsonで定義することができるのですが、このファイルをもとにしてコードの自動生成が可能になります。またここに記述したサンプルを返すモックサーバーが簡単に建てられるので、フロントエンドとバックエンドを並行して開発することが用意になります。今回は私が両方やってるので恩恵は受けられませんでしたが、このようにしてAPIを定義しておくことで大変管理がしやすくなりました。

Go

なんだか流行ってますよね、Go。コードがわかりやすいし、速いので大変好みです。

中高では Javascript をメインで書いていたのですが、いかんせん node.js が好きじゃなく代替を探したときに出会ったのが Go でした。といっても当時は殆ど先に進むことはなく学ぶのを辞めてしまったのですが、その経験があるので大学でバックエンドサーバーを何で書くか迷ったときに真っ先に候補に挙がったのが Go でした。実際に触ってみると非常にシンプルで、コードが複雑になりにくいところが大きな利点であると感じました。他の言語と大きく異なり、エラーが例外ではなく値によって返却されるという点も好みでした。無論 err!=nil がコードに大量発生するという汚点はあるのですが、わかりやすさはこの欠点を上回ります。

学習するにあたり Go言語実践開発入門と Go Programming Blueprints を読みましたが、他の言語での開発経験がある場合は不要だと思います。ネット上の文書が大変充実しているのでそもそも技術書を買う必要は無いと言う人もいますが、私は書籍の消化が得意なのでスピード重視で書籍を購入し、結果的に買って良かったと考えています。使用したパッケージなどを説明していきます。

Clean Archiecture, DI (wire)

コードを書く際には依存性を分離することを意識し、また依存性の注入(DI)を行うことで単体テストをしやすくしています。具体的にはDBなど外の要素にアクセスするレイヤー(infra *2 )、これを組み合わせてやりたい操作を実現するレイヤー(usecase)、さらにサーバーへのアクセスを解釈し usecase を用いて望みの操作を実現するレイヤー(handler)を用意しそれぞれ1つ下のレイヤーにのみ関心を持つことでコードの複雑さを下げています。DI は wire を用いて一括で行っています。

あんまり覚えてないですが、確かツイッターで「企業の面接を受けたらアーキテクチャの話をされて全然わからなかった」みたいな記事を読んだのがきっかけでアーキテクチャについて調べ始めて、意識するようになったはずです。思い返してみればそれまではほんとにスパゲッティコードを書いてたので本当にありがたい出会いでした。

Testing (mockgen, gotests, kin-openapi)

依存性を注入した部分のテストには mockgen を利用しています。使うのにちょっと手間がかかるので gotests と組み合わせて、mockgenを利用するための準備の部分を自動生成できるようにしています。DBにアクセスする部分のテストはモックを用意するのが面倒だったのでシェルを叩いて毎回テスト用にDBを用意するコードとサンプルデータを入れるsqlファイルを用意しこれらをテスト実行時に走らせてテストしていました。ポコポコDBを作ったり消したりするのあんまり良くないんじゃないかという気がしてるので別の方法を考えています。APIのレスポンス検証をkin-openapiを用いたテストで行っています(後述)。

ORM (sqlboiler, sql-migrate)

ORMには sqlboiler を採用しました。当初は GORM を利用していたのですが、テーブルを JOIN する際に手間取ったり、struct を自分で用意するのが面倒になったので既存のDBスキーマから自動でマップする構造体などを生成してくれる sqlboiler へと乗り換えました。これにより事前に生成されたコードを用いるのでGORMより速く、 JOIN や複雑なクエリの発行も GORM に比べて簡単に、また殆どの処理を型安全に書くことができるようになりました。DBスキーマは sql-migrate を利用して管理し、もしスキーマが変更されコードを書き直す必要が生じた場合は再生成後静的解析により警告が表示されるようになります。この移行は結構手間がかかりましたが、やって良かったです。DIを行なっていたために他のレイヤーのコードには一切手をつけることなく移行が完了したので、コードを丁寧に書いててよかったと思いました。

Handling errors (標準のerrors)

エラーハンドリングにはカスタムエラーパッケージを用意し、error を Wrap するごとに呼び出し元の関数の情報を追加していったり独自のエラーコードを用いて発生したエラーによる条件分岐を可能にしたりしています。基本的には上の階層に受け渡されていき、一番上の handler 層で適切な HTTP Status Code と共にエラーとしてクライアント側に返却されます。独自エラー型はIsメソッドを持っておりerrors.Isの際にエラーコードが同じかどうかで比較をしています。エラーコード型はエラーコードの文字列を返すメソッドとステータスコードを返すメソッドを持っており、必ず403を返すerr403とエラーコードの文字列の組み合わせなどで表されています。呼び出し関数の取得はruntime.Callerから得られた文字列を/や.で区切っていじることで取得しており、もう少しきれいなやり方はないかと思いつつ動いてるのでまあいいかとそのままにしてあります。

API (oapi-codegen, kin-openapi)

oapi-codegenを利用しており、定義したAPIを自動でサーブするためのインターフェースを用意しパラメータを自動でパースしてくれたり返却する際JSONにMarshallするための構造体も自動で生成してくれるので大変助かりました。テストはkin-openapiのレスポンス検証を使っており、もし定義と異なるレスポンスが帰ってきた場合はテストが通らないので定義通りに実装されているかが確認できます。

認証

GoogleとAppleでのソーシャルログインに対応しています。外部の認証サーバーからトークンを受け取ってこっちのサーバー側で検証したらそのサービス固有のIDと一緒にユーザー登録してJWTを発行しています。このときJWTに所持している本の情報も入れているため以後アクセストークンが有効であればユーザーDBアクセスなしで検索可能*3となります。アクセストークンの有効期限は15分ほどで切れた場合はリフレッシュトークンを用いてリフレッシュすることが必要です。この際に外部サーバーのトークンが有効かどうか確認することでアプリの利用を停止されてないか確かめています。

Flutter (フロントエンド)

フロントエンドには Flutter を採用しました。iOS と Android 双方で利用できるようにする必要があったのでクロスプラットフォームなフロントエンドフレームワークを探したのですが、まず私がWeb技術、特にHTMLとCSSが苦手なため React Native などの Web技術ベースのフレームワークは却下となり、他のフレームワークと比較した結果情報量が多く、また個人的に C より Java に比較的馴染みがあるので Flutter を採用することにしました。

実際に使ってみるとプラットフォーム間の差異を殆ど気にすることなく開発を行うことができ、ツールも充実しているためかなり満足度が高いです。普段は Linux を用いているのですが、Linux ネイティブでも Android エミュレータと同じものが動くことに大変驚きました。今回のアプリ開発では私が Mac を持っていないために最後のひと月以外は全て Android のみで動作確認していたのですが、全く問題なく iOS でも動作してくれました。

Flutter の経験は1週間程でしたが、随分その経験が活きたように思います。

github.com

2021年12月末から翌年1月、大学1年の冬休みは Flutter と Go を書いて過ごしていたのですが、大学が始まってから全く触っていないので本当にこのレポジトリにあるものが全てです。

状態管理 (riverpod)

上に出したレポジトリではChangeNotifierを用いてMVVMっぽく書いていましたが、現在は Riverpod 2.0の Code Generationを用いています。中身はNotifierProviderとAsyncNotifierProviderで、特にAsyncNotifierが非同期処理を扱う際にはとても便利です。殆どのWidgetをStatelessにしてViewModelで一括でステートを保持しています。ChangeNotifierを使っている部分もあるためすべてRiverpod 2.0に統一したいです。

最初はMVVMっぽくだいたい全ての画面に対応するViewModelを用意していましたが、最近は無駄が多い気もしています。ルーティング用のProviderを用意したらVMは取っ払っちゃって今その一個下にあるレイヤーを画面から直接呼んじゃうのもありかなという気がしています。そうなるとGoでやってる階層構造とあんまり変わりませんね。

DI, Routing (GetX)

一番下のレイヤー、RepositoryのDIとルーティングにGetXを用いていますが、全てRiverpodに統一できるはずなので置き換えようかな〜と思いつつも特に困ったことがないためそのままになっています。色々見てるとちょっと評判悪いみたいです。置き換えて比べてみようと思います。

API叩く部分 (openapi-codegen, dio)

openapi-codegenでdioのコードを自動生成しており、通信部分は全く自力で書いていません。めちゃめちゃ楽で定義を更新して再生成すると静的解析により対応が必要な部分がわかるのも大変良いです。あんまり情報が見つからなかったのが難点といえば難点でしょうか。

認証

ログイン処理では外部のOauth認証サーバーにアクセスし、もらってきたトークンをバックエンドに送り有効であると確かめられた場合にトークンが返却されるのでそれをSecure Storageに保管しています。Flutter側でもトークンの情報を活用することは考えましたが、トークンの形式を変更するかもしれないことを考えてFlutter側では完全にノータッチで、仮にJWT以外に置き換えたとしてもフロント側のアプデは一切必要ないようにしています。

トークン有効期限切れで403エラーが返ってきた際に時にdioのinterceptorで上の階層から見えないようにトークンをリフレッシュしてリトライする処理がちょっと難しかったです。リポジトリのディスカッションなどを参考に実装しました。

DB (PostgreSQL)

特に文句ありません。現在は基本的な機能しか使っていないので当然といえば当然ですが、これからpg_bigmを用いた類似度検索などを実装しようと思っているので、そこで高機能さにお世話になるかもしれません。

DB設計なんてもちろん初めてだったので達人DBを読みました。日雇いのバイトに持ってって休憩中に読んでたら社員の人に褒められて、後でジュースとお菓子おごってもらいました。達人DBはめっちゃわかりやすくてかつ読みやすいので超オススメです。読んだことなかったら騙されたと思って買ってみてほしいです。

Deploy (render.com)

日本ではあまり知名度がないみたいですが、使いやすいPaaSです。友達が使ってたので使ってみたら本当に便利で離れられなくなりました。無料枠もあるので気軽に試せますし、GitHubのレポジトリを選択するだけでデプロイができます。無料版であってもPR previewというプルリクエスト毎にプレビュー版をデプロイしてくれる機能もあり、コミットがあれば自動でビルド・デプロイしてくれます。難点といえば日本サーバーがなくシンガポールサーバーを使わざるを得ない点ですが、そこまでレスポンスは悪くないので問題ないかなと思います。DBもこのサービス上にデプロイしていて、24時間毎の自動バックアップには助けられました。

コード管理 (GitHub)

コードは基本GitHubで管理していました。途中まではバックエンドとフロントエンドで分けていましたが途中からリポジトリを合体させモノレポにしました。これは開発中に出てたハッカソンで友達が同じようにモノレポで収めていたのを参考にしてやったはずです。Issueを立ててバグの原因特定してそれがバックエンドでもフロントエンドでもブランチ切って同じリポジトリで対応できたり、ある時点でのフロントとバックのコードが簡単に取得できたりとメリットが多かったです。ブランチはリリース前は初期状態のmain、developと都度のfeatureブランチのみで、リリース時にreleaseブランチを切って調節した後にmainにマージしてmainブランチをrender.comでデプロイしました。今はgit flowのとおりに基本的にはやっていて、リリースバージョンごとのタグもつけいます。バグや機能追加毎にIssueを立ててブランチを作り、マイルストーン*4によって次に出すバージョンに含める機能を管理しています。依存性を分離することで複数のファイルを編集することをあまりせずに共同作業ができたので、フロントの見た目だけをいじる相方と裏のロジックをいじる自分でコンフリクトを多少避けることができたのも良い点でした。ただ結局見た目のコードもかなり手を入れたので、コンフリクトしてたことも多々ありめんどくさかったです。

今後やりたいこと

まずフロントのエラーハンドリングが適当なので改善したいです。ずっとGoのerror as a valueを扱ってた結果例外をthrowするDartに慣れないままとりあえず動く状態にしてリリースになんとか間に合わせたという状況なので、全然エラーをうまくハンドルすることができていません。実際エラーが出ないことでストアのレビューに低評価が出てしまったので早急に対応したいところです。

あとユーザーに関係ない部分になってしまいますが、管理画面を作ろうと思っています。サービスリリースして初日にユーザー数を確認しようとSQL叩いたら、ミスってDBのユーザーテーブルを全部飛ばしてしまったのでなるべく生で触りたくないです。

機能の追加も随時やっていきます。今はリリースに必要な最低限の機能だけでリリースしているので、所持している本を確認したりより詳細な検索条件を設定したり、シラバスを参照できるようにしたり、記事を配信できるようにしたりとやりたいことはたくさんあります。あと忘れちゃいけないのが広告で、例えば早稲田通りでティッシュ配ってる企業なんかはこういう早稲田生しか使わないようなアプリに広告出したいんじゃないかな〜と思うのでうまく広告を取り入れて費用を回収していきたいですね*5。

最後に

アプリを使ってくれている人々、どうもありがとうございます。科目登録期間に旅行に行くことになってしまったが、アプリのおかげで旅行先に本を持っていかなくて良くなったという声や、弟・先輩の友達が実際に使っていたなどの話も聞けて大変嬉しく思っています。初めてのアプリ開発でしたが、無事にリリースできてまずは一安心です。

設計からリリースまで全部やったのはとても良い経験になりましたし、めちゃくちゃ大変でしたがその分大きな自信に繋がりました。これからもアプリに限らず色々作って、色々やっていくので、応援よろしくお願いします。 ;) 

*1:マイルストーン編集会とは – e-mile

*2:こう呼んでいますが、これが一般的かはわかりません 他も同様です

*3:ただし、トークンが発行されたあとにシリアルコードを紐付けると反映に時間がかかる

*4:アプリではなくGitHubの機能の方

*5:今は無給！！

SFにおける存在しない技術の扱いについて

本 SF

　この記事は存在しない技術アドベントカレンダーの8日目の記事です。

adventar.org

SFと存在しない技術の関わり

　世間的にSFと呼ばれる作品には様々な存在しない技術が存在する。例を挙げると世界最古のSFと位置付けられることも多いメアリー・シェリーの「フランケンシュタイン」ではフランケンシュタインが怪物を作る技術が存在しない技術であるし*1、ディストピア小説の名作1984に登場するテレスクリーンもそう、タイム・トラベルものと呼ばれるジャンルではそもそもタイムマシン及びそれに準ずる技術が現時点では存在しない。

　そこでこの記事では様々なSF小説を紹介しつつ、存在しない技術の作品内における扱いとジャンルの関係性について見ていきたいと思う。前者がメインであることは言うまでもない。

 

　まず存在しない技術や科学を物語の根本に起き、それがないと成立しないような物語が典型的なSFとして挙げられるだろう。そのようなSFはハードSFと呼ばれる。

ハードSFとは

(1)主流あるいは「本格」SF作品(ハードコアSFともいう)

(2)ストーリーやプロットの骨格として科学がベースにあるアイディアを置いている作品

引用: https://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%BC%E3%83%89SF

　ハードSFとはSFと呼ばれるジャンルのサブジャンルであり、引用で「主流」とあることからもわかる通り「SF小説といえばこういう小難しいものだよな」というジャンルのSFである。科学技術を作品の根幹に関わる形で存在し、その理論的な説明に多くの労力を割いていることが特徴として挙げられる。こういう作品を想像しSFを敬遠している方も多いだろうが、ハードSFというサブジャンルが確立されているということは、無論そうではないSFも多数存在することを意味しているので安心してほしい。

 

星を継ぐもの [J.P.Hogan] (1977)

　星を継ぐものはシリーズ4部作の第一作でホーガンのデビュー作でもあり、私の最も好きな作品だ。近未来、月面で真紅の宇宙服を身に付けた身元不明の遺体が発見され、炭素年代測定によりそれがなんと5万年前の死体であることが判明する。チャーリーと名付けられたその遺体は、一体誰なのか？現代人類との繋がりは？謎を解き明かすため科学者達があらゆる可能性を検討し、調査を重ねていく……。ここで少しでも心を惹かれたならば、ぜひブラウザバックしてそのまま本を購入してほしい。ちなみに創元SF文庫で最も売れている本らしいですよ。

www.amazon.co.jp

作中に登場しない技術は次のようなものが挙げられる。

・トライマグニスコープ

主人公のヴィクター・ハント氏が研究開発していた、ニュートリノを用いて物質を透過し観察する装置。作中ではチャーリーの体や手記の解析で活躍する。

・惑星間宇宙船、月コロニーなど

舞台は近未来なのでそれに合わせた舞台装置として研究用の惑星間宇宙船や月のコロニーが登場する。

・チャーリーの所持品

超小型原子力電池等、現代どころか作中の世界でも一般には存在しないとされていた技術。

・ガニメアンの遺構

木製の衛星、ガニメデで発見された異星人の宇宙船。巨大な宇宙船本題や電気を食う謎の機械など、こちらもワクワクする品物が勢ぞろい。

　しかし、星を継ぐもののメインは月の遺体の謎の解明で、いわば科学ミステリーのような形で物語が進行していく。存在しない技術というよりも存在しない架空の理論の解明に向けて登場人物たちが存在する技術に基づいた考察を進めていく、まさに空想科学小説である。1つの大きなIFを入れ、そこから本当にそういったことがあったかもしれないと思わせる作者の技量が素晴らしい。生物学者が「別の惑星で進化した全く人類と関わりのない生命で、偶々人間に姿が似ているだけではないのか？」というと「平行進化にしては似すぎている。例えば人間の腸の構造は二足歩行に移行したからこそこのあまり効率的ではない構造なのであり、これは進化の偶然によるものだ。」と返ってきたりと、とにかく架空の理論に対するディテールの詰め方が物凄くリアル。どんどん新たな謎が出てきて、それまでの仮説に綻びが生まれる。その繰り返しで真実に迫っていく様子は、まさに科学そのものだ。

    存在しない技術は物語のディテールを深めるために用いられ、物語の根本にある存在しない理論、過去を解き明かしていく過程を彩っている。

 

    ところで本作の続編「ガニメデの優しい巨人」にはゾラックというスーパーコンピューターが登場する。異星人の宇宙船に備えられた対話可能なコンピューターである。かなり面白い性格をしており、例えば学習データとしたイギリスの映画の台詞をジョークとして用いたりする。私は結構好きだ。このようにSF小説にもよく存在しないIT技術*2が出てくるのだが、例えばAI技術が出てくるSFを読んでいると違和感を覚えることが多い。安直にAIに自我をもたせる描写がどうも科学的にあまり正しくないのではないかと気になってしょうがないのである。存在しないIT技術をそれらしく描くことは難しいのではないかと考えてしまうが、これは私が少し情報科学に親しく物理にあまり明るくないからそう感じるのか、それとも私の想像力が貧弱で情報技術をメインにしたSFも発想によりどうとでもなるのか？気になる。

 

    ハードSFの反対語としてソフトSFという用語もある。と言っても例の如く定まった定義はなく、曖昧な用法で使われている。私は社会的な事柄を扱うものをソフトSFと呼ぶことにしており、次に挙げるのはソフトSFと言えるだろう私のお気に入りの小説である。

 

アルジャーノンに花束を [ダニエル・キイス] (1966)

　アルジャーノンに花束をはSFファンでなくてもご存知の方は多いだろう。それってSFなの？という話をする前に、まずは物語の概要を説明しておこう。

　本作は知的障害者である主人公のチャーリイ・ゴードンによる経過報告、日記のような形式になっており、英語版ではスペルミスが多く、日本語だと漢字が使われていない。しかし人工的に知能を高める手術の動物実験がハツカネズミのアルジャーノンで成功し、主人公はその手術を世界で初めて受けることになる。知能が高くなっていくうちに文章も洗練されていき、それと同時に周囲の人々との関わりも大きく変化していく。

　本作はSF的な存在しない技術を「人工的に知能を高める手術」のみに絞り、この手術を受ける様子を通じて知能や人間の価値について問いかけるものとなっている。逆に、例え科学的な事柄を主題としているのではなくても、それを描き出す土台に科学技術があったらSFと言えると考えられる。またこの小説は人工的な知能向上という存在しない極端な技術を通じて、現代に存在する技術、例えば安楽死や出生前診断など知能と本人の幸せに関わる技術の是非を問うているとも捉えられる。

   技術自体に焦点を当てるのではなく、それを通じてまた別のものを描き、ときに問いかける作品もまたSF小説に多くあり、科学一辺倒ではないところもSFというジャンルの面白さである。

 

銀河英雄伝説[田中芳樹](1982)

　銀河英雄伝説はジャンルで言えばスペースオペラである。スペースオペラというのは

主に（あるいは全体が）宇宙空間で繰り広げられる騎士道物語的な宇宙活劇のこと

スペースオペラ - Wikipedia

である。Wikipediaの記事でも述べられているように、スペースオペラでは技術的な詳細は枝葉末節であり省かれることが多い。銀英伝も例に漏れず、ワープや超光速通信、重力制御などのテクノロジーは特別な説明なしに作品内に登場する。ハードSF的な思考からするとツッコミどころが多いが、重要なのはそこではない。この作品でメインとなっているのは艦隊戦と政治だ。主人公のヤン・ウェンリーは「魔術師ヤン」と呼ばれる天才戦略家/戦術家で、民主主義制を取る自由惑星同盟として、銀河帝国の軍事の天才ラインハルト・フォン・ローエングラムと宇宙規模で対立することになる。宇宙空間で宇宙艦隊や宇宙要塞での艦隊戦が繰り広げられるが、用兵学の基礎は地上のそれと同じものである。補給線の重要性や城攻め、銀河系には特に詳しい説明もなく交通の難所とされる廻廊と呼ばれる領域が存在し宇宙船が自由に行き来できないなどがそれである。そもそも宇宙空間での戦闘だというのに戦場は専ら平面に描写され、上下方向の広がりはほとんど意識されない。

    だがそれで良いのである。

    本作の面白さは科学的な考証ではなく華麗な戦術や荘厳な宇宙艦隊同士のぶつかり合い、至るところでめぐらされる権謀術数なのである。例えば作中にはゼッフル粒子という爆発性の粒子が登場し、これを空間に満たすことで銃火器が使用できなくなるために宇宙船内でトマホークを使った戦闘が繰り広げられることとなる。科学的な説明は一切なく*3、ただ白兵戦を描きたいがために導入されたと言える。このように存在しない技術は宇宙での戦いを(都合よく)可能にする道具として用いられている。ハードSFを期待して読むと全く異なるテイストに衝撃を受けるかもしれない。しかし宇宙を舞台とした架空戦記としては大変に面白く、本編が10巻に外伝が5巻の計15巻も苦もなく読めてしまう、いやむしろこれだけで終わってしまうのかという寂寥感すら覚える作品となっている。

    本作では自由惑星同盟の最悪の民主主義と銀河帝国の最高の専制政治の対立や戦争の意義などのテーマも扱っている。戦争での死者より次の選挙での得票率を考え不必要な出兵を命じられたヤン・ウェンリーがなぜ自らの軍事力と人気を用いてクーデターを起こさず、戦いに赴き勝利を収め、帝国側で死者や孤児や未亡人を量産したのか。その本人の苦悩や信念も描かれており、この面を切り取ればソフトSFと言えるかもしれない。

三体[劉慈欣](2006)

    最近話題のSF小説といえばこれ一択。オバマ大統領もインタビューで愛読していると答え、今年ようやく三体三部作の3つ目「三体Ⅲ 死神永生」が翻訳され本屋でもよく見かけた。私のお気に入りは「三体Ⅱ 黒暗森林」だ。大変おもしろいので未読の方は悪いことは言わないので今すぐ読むのをやめて本屋に駆け込んでほしい。読んでないのが羨ましい。

    一巻目の三体は中国の文化大革命から幕を開ける。人気のSF小説と聞いて手に取ると文化大革命の描写から始まり少々面食らった覚えがある。本作では文化大革命時の中国と現代の中国、そしてVRゲーム内での三体世界と3つの舞台を行ったり来たりしながら物語が進んでいく。

   何が面白いかといえば一巻目はやはりハードSFちっくな雰囲気から登場する智子(ソフォン)だろう。太陽の電波増幅機構など、ハードSFなのか……？と段々怪しくなってきたところで異星人が11次元から2次元に展開した陽子に回路を書き込んだスーパー“粒子”ソフォンが登場するのである。存在しない技術の極みだ。エエッー！！そんなのあり！？そういうSFだったんですか〜？となってももう遅い、既に劉慈欣ワールドに取り込まれていて続きを読まずにはいられなくなる。三体シリーズの面白さはこういったそれだけで短編小説がかけそうなアイデアがポンポン惜しみなく投入されている点にある。徹夜で全巻読んだ。

    さらに憎めないのが三体Ⅱに登場する黒暗森林理論は科学的にも興味深い点だ。この理論はフェルミのパラドックスに対する筆者の解答であり、同時に三体Ⅱの核となる部分に当たる。ハードSFが好きなので、こういった要素は評価せざるを得ない。未読の方は今すぐ読んでほしい(2回目)。ちなみに三体Ⅲでは時間のスケールが10^n倍になっていきます。

    劉慈欣は今までの記述からもわかる通り、ハードSF作家ではない。短編集*4も読んだが、例えば異星からやってきた氷の芸術家が地球の海を凍らせて芸術作品を作る話や中国詩に感動した宇宙人が全ての漢字の組み合わせを実現し全ての漢詩を生み出す話など、荒唐無稽なアイデアをベースに大真面目に話が展開していく独特な作風が大変面白い。日本語でも短編集が出ているので、そちらを読んでみるのも面白いかもしれない。

 

   あんまり真面目にではないが、色々な存在しない技術のSF小説での扱われ方を見てきた。厳密に空想科学を扱うハードSF以外にも、都合よく舞台装置として存在しない技術を用いるスペースオペラ、或いは社会に問を投げかけるのに存在しない技術を用いるソフトSF、さらに荒唐無稽な存在しない技術をベースに物語を進めるものまで、様々なSF小説が存在する。堅苦しいものばかりではないので、尻込みせずに是非手にとって読んでみてほしい。布教のコーナーでした。

 

*1:フランケンシュタインは怪物を作り出した博士の名前であり、怪物に名前はない。

*2:どうでもいいけどIT技術って情報技術技術でちょっと気持ち悪いですね。

*3:どこかにあったら申し訳ない。計15巻をこのためだけに全てを読み通す気力は起きなかった。

*4:To Hold Up The Sky [LIU CIXIN]. 多分未邦訳。

美術館に行く 1

美術

 

　全く知識のない状態から、美術館や展示に足を運んでみた経緯と感想。結論から言うと、なんにもわからなくても恥ずかしがらずに美術館に行ってみると面白いかもしれません。

 

美術・美術館について。

　子供の頃から美術館はあまり好きではなかった。親が好きでたまに連れて行かれていたのだけれど、子供の落書きのような絵や裸婦画を大人が黙ってさも「自分はわかっていますよ」 と言いたげな顔で眺めている空間は、幼い私には堪らなく退屈だった。立ちっぱなしで疲れるし。シンガポールでアンディ・ウォーホール没後25年記念の企画展*1に連れて行かれてたときは、最初から最後まで意味がわからなかった。

 そのせいか年を重ねても美術に関心を抱くことはあまりなかった。手先が器用だったので美術の授業で絵を描いたりなにかを作ったりするのは好きだったが、美術は難解だし縁がないものだと思っていた。実際美術館に行ったあと人に美術館の話をした反応を見る限り、大抵の同年代の人は同じように美術館なんて縁がないし自分が行っても楽しめないだろうと思っているようだ。

 

　しかし同じ芸術でも音楽は好きだ。幼い頃からピアノをやっているし、それ以外にも色々な楽器に手を出している。自室はそもそも狭いこともあり面積の1/3を楽器が占めている。色々な音楽を聴くうちに、ものの良さを理解するにはある程度知識が必要だということがわかった。知識というのは教科書に乗っているような知識だけではなくて、音楽だったらその曲や似たジャンルの曲を聴き込むこと、料理なら様々な料理を食べること。逆に言えば、とにかく色々なものに触れてみることで今まで良さがわからなかったものの良さがわかるようになるということではないか。よくわからない音楽を聴き込んで良さを理解しようとしてきたように、色々なものを食べたら自分の好みがわかってきたように、色々な美術作品に触れてたら今までよくわからなかった美術の世界に少しでも踏み込んで、見える世界を広げられるのではないか。そういう考えから、全く美術がわからない状態でも嫌いだった美術館に行ってみようという思いを持っていた。それに、趣味が美術館巡りなんてかっこいいじゃないか。

経緯

　実際に美術館に行くことになったきっかけはたまたまテレビでやってた絵画を紹介する番組だった。

www.bs4.jp

　様々な「怖い絵」の実物を見ながらその絵の背景や注目ポイントを教えてくれるという回で、自ら殴り殺してしまった息子の亡骸を抱く「イワン雷帝とその息子」といったわかりやすく怖い絵から、一見綺麗だけれど言われてみると怖い「そして妖精たちは服を持って逃げた」など様々な絵が「怖い」というわかりやすい切り口で紹介されており、美術にほとんど親しみのない私でも楽しく見ることができた。その中でも特に印象に残ったのが「レディ・ジェーン・グレイの処刑」である。PAUL DELAROCHE - Ejecución de Lady Jane Grey (National Gallery de Londres, 1834).jpg

By Paul Delaroche, Public Domain, Link

　イングランド初の女王となったジェーン・グレイは、僅か9日で女王の座を追われ、投獄された後に改宗を拒み処刑される。*2*3レディ・ジェーン・グレイの処刑はまさにその処刑の瞬間を描いており、何より私が感銘を受けたのは肌の質感である。画像は Wikimedia Commons を埋め込んでおり、リンク先では4K解像度で眺めることができるのでよく見てみて欲しい。美術には殆ど興味が無かったが、16歳という若さで処刑されようとする少女の断頭台を手で探る様子や、暗い処刑場、嘆く侍女と白く輝くジェーン・グレイその人との対比が素晴らしいと思った。トマト缶やマリリン・モンローのカラバリ*4の良さはわからないけど、これなら自分でもわかる。

　そんな話をしていたら、高校時代の先輩が自分が挙げた絵の殆どを知っていて話が盛り上がり、二人で美術館に行くことになった。開催されてた企画展の候補から選んだのが渋谷Bunkamura ザ・ミュージアムの企画展「ポーラ美術館コレクション展 甘美なるフランス」であった。

訪れた美術館/展示

渋谷 Bunkamura ザ・ミュージアム ポーラ美術館コレクション展 甘美なるフランス(2021/9/18〜2021/11/23)

www.bunkamura.co.jp

　展示は印象派からエコール・ド・パリまで。チケットを渡しギャラリーに入ると目の前に展示の目玉の一つであるモネの睡蓮が飾られている。そこからルノワール、ピサロに代表される印象派からフォービズムやキュビズムなどに広がっていく。

　まるで元から知っているかのように書いているが、実際は美術の教科書で用語を見かけた程度である。そもそもこの企画展を選んだ理由が印象派の作曲家であるドビュッシーが好きだからであり、印象派の画家など一人も知らなかった。

　それでも、74枚ある絵画とその説明を3時間ぶっ通しで見続けるとわかってくることがある。例えばルノワールの「ムール貝採り」「レースの帽子の少女」に見られる複雑な色を巧みに組み合わせた繊細な色彩が素晴らしい。
f:id:takabayap:20211113114325j:image

Girl in a Lace Hat - 1891 — Pierre-Auguste Renoir

この絵は企画展の広告にも使われているので電車や看板で目にした人も多いのではないだろうか。題名にもなっているレースの帽子は白を基調にし、オレンジやグレーなど様々な色を重ねつつも柔らかなニュアンスを漂わせ、肌も計算された色使いで陰影と質感を表現している。近づいてみてみると全く別の色なのに遠くから眺めるとそれぞれが調和して一つの表現となっているのはモザイクアートのようだ。

　もちろん面白い作品ばかりではない。まずモネの「睡蓮」からわからない。有名な絵画なので見たことはあるが、一体どこが素晴らしいのか。白い靄は水面に見えないし、全体的におどろおどろしい。しかも作品説明によると晩年のモネは30年連作として睡蓮を書き続けたらしい。何がそんなに彼を駆り立てたのか。200点ほどあるそうなので、おそらく教科書で見た睡蓮とは別の絵だろう。ルノワールだって「エッソワの風景、早朝」はよくわからない。木も空もボヤボヤしてるし、これといって心惹かれる部分もない。一緒に行った先輩とは目を合わせてわからないねと言い合っていた。PierreAugusteRenoir-1901-Landscape of Essyes Early Morning.png
By Pierre-Auguste Renoir - 『ポーラ美術館コレクション-モネからピカソ、シャガールへ』TBSテレビ、2016年、ISBN978-4-906908-16-5, Public Domain, Link

　ここで私がやっていて面白かった絵画の鑑賞方法を紹介しよう。それは絵の書かれた年代に注目することである。同じモネの作品でも「セーヌ川の支流からみたアルジャントゥイユ」(1840)や「花咲く堤、アルジャントゥイユ」(1877)は好きだ。「散歩」(1875)も悪くない。一方「睡蓮」が描かれたのは晩年、1899年からで、今回展示されているのは1907年の睡蓮である。睡蓮を書き初めて10年、私が良いと感じる絵画からまた一歩二歩進んだ表現を模索した結果なのだろう。ルノワールでも「レースの帽子の少女」(1891)や「ムール貝採り」(1888-1889)よりも「エッソワの風景、早朝」は1901年と10年進んだ作品である。

　展示では何らかの意図があり展示の順番を決めているが、時系列には沿ってない場合が多い。晩年に描かれる作品が有名になることが多いことが理由だろうが、鑑賞する際は有名無名気にせずに自分が気に入る作品を見つけるのが良いと思う。そうしていると、次に来たら今度は有名な作品が気に入るかもしれないし。

　さて、最初の15枚がモネとルノワールで、展覧会には74点の絵が飾られている。つまりこれで全体のたったの1/5である。74枚の作品を鑑賞するというのは想像以上に大変で、10時半に会場に入り出てきたのが13時半だった。再入場不可、椅子もないので体力勝負である。途中からは足が棒のようになりながらただひたすら絵を見る。実は東京都立美術館のゴッホ展にはしごするか迷っていたのだが、よほど体力がない限りそんなことはできないだろう。チケットを取らなくて良かった。

 

　初めて自分の意志で行った美術館だったが、とても楽しかった。全然わからない作品のほうが多いし、特にピカソやゴーギャンなんてわからない作品しかなかったと言っても過言ではない。*5しかしわかったこともたくさんある。特に、制作された年を作品からピタリと言い当てることができたときには、自分の頭の中に今まで見てきた絵がたしかに知識として蓄えられているという実感があり大変嬉しかった。人生で初めて図録を買って、今はその図録を見ながら文章を書いている。残りの59枚についても色々書きたいことがあるけれど、この記事が途方もない長さになってしますので一旦切り上げ。気が向いたら別の記事に書くかも。

 

東京都渋谷公園通りギャラリー 語りの複数性(2021/10/9〜2021/12/26)

inclusion-art.jp

死に関する話題があるので、苦手な人は読み飛ばしてください。

　これはたまたま存在を知っていた展示で、渋谷へ楽器を見に行った際に近くにあったので寄ってみた。金髪の二人組が座り込んでタバコをふかしてる脇を抜けてアートに触れられる街、東京バンザイである。入場無料で、そこまで作品数は多くないので気軽に入ってみると良い。かくいう私も時間の都合でじっくり見ることができなかった作品があるので、また足を運ぶことになるだろう。余談だが、日本で一番大きいだけあって様々な芸術に気軽に触れられるのも東京という街の良いところで、気軽に東京アクセスできる土地に居た為に上京することに人は夢を抱きすぎではないかと思っていたが、最近はこういった環境を求めて上京してくるのも悪くないと考えるようになった。

　この展覧会は額縁に絵が飾られている典型的な展覧会ではなく、映像作品や音声作品、絵画もあればミニチュアも楽譜も写真もある。扱っているテーマはアウトサイダー・アート(アール・ブリュット)で*6、生、死、障害をテーマにしている作品が多い。お気に入りの作品は小島美羽の「終の棲家」と百瀬文の「聞こえない木下さんに聞いた、いくつかのこと」だ。

　故人が最期の時を過ごした部屋。一見明るい何気ない部屋に見えて隣に展示されていたゴミ屋敷との差異に首を傾げたが、作品の前をうろついて椅子の上の黒いシミに気づいたときは周りの空気が一気に重くなった。気づいてしまうとどうしてもそこに目が行ってしまう圧倒的な存在感を示す黒いシミは、そこで過ごした最期を否が応でも想像させる。

　小島美羽は特殊清掃業に携わりながらミニチュアで孤独死の実情を表現している。近頃は単身者が増え、テレビやSNSで孤独死の話題を目にすることも増えた。長期間放置された遺体はしばしば「黒いシミ」と呼ばれる目も当てられない状態で発見され、鼻が取れるほどの独特の臭いで見つかるそうだ。特殊清掃では様々な技術・道具を駆使し、そういった現場の原状復帰をしている。小島さんが所属する遺品整理・特殊清掃クリーンサービスのツイッターアカウントでは実際に使用しているテクニックや出てきた遺品を紹介していて興味深い。

twitter.com

　「聞こえない木下さんに聞いたいくつかのこと」は作者の百瀬さんが研究者の木下知威さんと会話する様子を記録した映像作品で、会場では0分と30分に上映が始まる。木下さんはろう者で口唇の動きを読み取ることによって言葉を「聞き」取り、自分では聞き取ることができない声を発することで会話が行われる。木下さんの読唇術は大変素晴らしく、殆どの文章を聞き逃したり聞き間違えたりすることなく会話が進んでいく。その後百瀬さんがある試みを会話の中で行っていくのだが、パンフレットの作品紹介にもここから先は記載されてないので書かないことにする。欠けた情報を補完しつつ行われるコミュニケーションを通じて、普段私達が何不自由なくできていると考えがちな意思疎通の難しさと可能性をも示していると言える。

　ここで紹介した作品以外にも面白い作品が多くあるので、足を運んでみてほしい。行ってみて面白いものが一つでもあれば良いし、よくわからなかったらそれもそれで良いと思う。

 

アーツ千代田3331 サウンド&アート展(2021/11/6〜2021/11/21)

muse-creative-kyo.com

　もともと好きな音楽と美術との繋がりに興味があったので、行きたいとツイートしたところ藝大に通っている友人と訪れることになった。楽器の実物がおいてあり、実際に様々な楽器を演奏し体験できるブースもある。友達と遊びに行っても面白いだろう。

f:id:takabayap:20211114031306j:plain

バシェの音響彫刻。アンテナのような部分の後ろに弦が張ってあり、その振動が伝わることで音が出る仕組み。

　作品はわかりやすいものからわかりにくいものまで様々で、例えばオタマトーンで有名な明和電機のセーモンズⅡは肺に見立てた風船からの空気を声帯を模した機構に送り込み音を出す作品で、同じ機構で音を出しているからか聞いてみると人間の声に近くて面白い。

セーモンズⅡ | 明和電機 – Maywa Denki

　ホームページにある紹介の動画をみると雰囲気がわかるだろう。私のお気に入りはマーティン・リッチズのThinking Machineだ。

Thinking Machine *** Honourable Mention Prix Ars 2008 *** from Masahiro Miwa on Vimeo.

　動画の通り、複雑な機構で転がる球のルートを制御し音を鳴らす機械で、機構の状態と球の個数・入れる位置で一定の音楽を半永久的に奏でられるという点が好きだ。初期状態からアルゴリズムに基づいて音楽が展開されていく様子も、その機構自体も大変興味深い。

　アーツ千代田3331という場所自体も特殊で、廃校となった中学校を改修し芸術空間として利用している。企画展用のギャラリースペースの他にそれぞれの教室に色々な企業や集団のギャラリーや作業場があり企画展以外も面白い。音楽が好きな人はこちらもオススメ。秋葉原から徒歩で行ける。開催期間が短い(11/23まで)のに注意。

 

行ってみて。

　美術についての知識がほとんどなくても楽しめた。自分にはわからない、という思い込みを排除することさえできれば、色々な楽しみ方ができるはず。

　また今どきはインターネットが発達しているんだからウェブ上で画像で見れば良いじゃないかという思いもあったが、行ってみてその考えも変わった。例えば油絵の話をすると、油絵は絵の具の特性で絵筆の運びなどが立体となる。これを画像データにすると細かい曲線や色が失われるのはもちろん、Z軸方向の情報まで失われてしまうわけである。そこまで高さはないが、次元が一つ下がっているというのは大きな情報の喪失だ。図録も買ったが、やはり実物の絵には叶わないと思う。

　体験としての美術館という面もある。普通に生活してて、黙って、スマホを見ずに、3時間ひたすら絵と向き合う時間を取ることはまずないだろう。映画館で映画を見るのと似ていて、美術館側がセットした最高の環境で本物の絵画を鑑賞するという体験は、現地に足を運ぶ理由になると思う。

　美術館は安い。学生なら高くて1500円で世界最高の絵画を思う存分見れるのだから驚きだ。今度の休日、もしくは学校にいった帰りでも、思い切って美術館に行ってみるのはどうだろうか。もしかすると、自分の人生に彩りを添える新たな趣味を見つけられるかもしれない。

*1:

Andy Warhol: 15 Minutes Eternal Exhibition at ArtScience Museum | SENATUS

時期的にもおそらくこれ。当時は小学4年生。

*2:参考 https://www.sankei.com/article/20171005-JEXZSBWSDRL5DKL6OI2J3WB6LM/

*3:このときレディ・ジェーン・グレイを処刑させたのはメアリー1世、Bloody Mary なのだそうだ。Bloody Mary は言ってみれば「海外版のトイレの花子さん」として、小学校での怪談として有名(Bloody Mary (folklore) - Wikipedia に詳しい。)なので知っていた。父は離婚を繰り返しついにはカトリックから離れイギリス国教会を創立したヘンリー8世。日常生活とも歴史とも繋がりがある、新しい物事を知ることは有機的な繋がりを広げることでもあり、楽しい。

*4:アンディ・ウォーホルの代表作「キャンベルスープ缶」「狙撃されたマリリン」。題名を調べるついでに記事を読んでみると、作品の意図がちょっとわかってしまって悔しい。

*5:唯一、ピカソの「母子像」はピカソらしくない“普通の”絵で良かった。

*6:展示会のアンケートに「アウトサイダー・アートに興味がありましたか？」といったような項目があったので、おそらくそうであろう。もちろんそんなものは全く知らなかった。

東大不合格体験記

受験

合格体験記と言っても、これを書いている時点では東京大学の合否は出ていませんが、やることもないので先に合格体験記を書いてしまうことにしました。手応えは微妙なので、合格発表に番号がなかったら指差して笑ってください。

東京大学、不合格でした！

以下は個人の感想です。

 

 

自己紹介

ツイッターで @Takabaya_P というアカウントで活動しています。趣味は読書と楽器です。その他にプログラミングに手を出してたりします。

 

使った教材など

国語

現代文

もともと本が好きで現代文も得意だったので自分はほぼ過去問演習しかやっていませんが、記述対策をする上で上級現代文はなかなかおすすめです。解説が丁寧で、順番に解いていくと言い換えや理由説明など記述の現代文で求められるスキルが一通り身につくようになっています。

古典

古典はすごい苦手意識を持っていて定期テストで40点台を取ったりしたのですが、ある先生に教わるようになってから飛躍的に実力が伸びました。古文はまず単語がとっても大事、単語帳に乗ってるものはもちろん、解いた文章に出てくるわからない単語は調べてメモしておくと良いです。自分は古文単語315を使いました。古文も漢文も問題を解いて、調べて、質問してをひたすら繰り返しました。

数学

まず基本的な解法を頭に叩き込もうと Focus Gold の例題をやりました。ただ解くだけじゃなくて、なんでそれで解けるのかを意識するといいんだと思います。その後新数学演習を進めましたが、これは難易度高いので解けなくてもあまり気にしないほうが良いです。たまに解けるとめちゃくちゃ嬉しい。これを一通りやったおかげで難しげな問題でも物怖じせず色々試せるようになりました。あと入試数学の基礎徹底を共通テスト1ヶ月前くらいにやってたと思います。演習を積んだあと、計算練習ついでに思い出す感じで。

過去問演習は東大数学で一点でも多く取る方法がおすすめです。解説が丁寧で面白い！

理科

物理

重要問題集をやりました。と言っても多分まともに解いたの熱力学と波動くらいで、基本は授業で配られた入試問題演習のプリントをやっていました。

化学

これも重要問題集をやりました。A問題を一通りやると共通テスト対策にもなると思います(高分子とか)。化学の新研究は賛否両論ありますが読み物として面白く、単純暗記が嫌いな自分でもこの本で理由を知ることで覚えられることがありました。ただ重いのであんまり持ち歩かず、どちらかというと資料集を重宝しました。写真がたくさん載ってるので視覚的に覚えやすいです。

英語

暇なときに英語のドキュメンタリーを見てました。科学的な知識に触れつつ英語の勉強もできるので一石二鳥です。あと英語のYouTuberを見たり、英語で小説を読んだりもしていました。英検1級のパス単も少しやりましたが、結構これで触れた単語が小説で出てきたりするので侮れません。

桐原書店の頻出英文法1000は文法対策に有効です。帰国子女の人なんか特に、なんとなく文法問題解いてる人は触れてみるといいです。

その他

受験期はずっと Focus To-Do というスマホアプリを使っていました。これは25分集中し5分休憩するサイクルを繰り返すポモドーロ法を実践できるアプリで、このタイマーベースで勉強時間を記録できます。タイマーを動かしている間は Twitter を見ないなどのルールを自分で決めて取り組むのがおすすめです。勉強をするハードルを実際に勉強することからタイマーの開始ボタンを押すところまで落とすことで勉強しやすくなりました。下はこのアプリの記録をもとに作った勉強時間の円グラフです。

記録をつけることで自分がいつ勉強できるのか、何をどのくらい勉強してるのか知ることができ、分析と改善に繋げられます。同時に現実を突きつけられたりもしますが

f:id:takabayap:20210309113048p:plain

12月~2月の科目別勉強時間

 

 

中学生

私は都内のとある中高一貫校に通っていました。中学受験をした理由は色々有りますが、今思うと親に言われたからが一番大きく、それ以外の理由は後付です。後付の理由には地元の公立中学校が合わないだろうとか、周りに勉強するのが好きな人がいたほうが楽しいだろうとか色々ありますが、そもそも小学校にしか通ったことがない小学生が教育環境の重要性を理解できるはずがなく、当時は「どこ行っても大して変わらないだろうけど、親が怖いので従っておこう」と思っていました。そんな動機だったので当然勉強に身が入らず、入れられた塾の自習室でゲームをする毎日でした。通っていた塾の自習室は9,10番ブースの後ろが壁となっており、職員の監視の目が届かなかったのです。iPad で Hopscotch という Scratch から派生したプログラミング言語に初めて触れたのもこの時で、これがきっかけでプログラミングに興味を持つことになります。

www.gethopscotch.com

勉強しなかった中学受験はなんと一番下の滑り止めにしか引っかからず、選択の余地なしに進学することが決まりました。この体験もあって勉強に真面目に取り組む気にならず、中学時代のテスト期間はアニメ消化週間と化していました。成績はというと、授業を割と真面目に聞いていたのでそこまで悪くなく、定期テストでは100人程いる同級生の中で上から20番目くらいを維持していましが、模試では何故か上のコースを含めても最高2位とかなり良い成績を取っていました。一つズルい点があるとすれば英語で、海外のインターナショナル・スクールで小学校生活の一部を送っていた故に周囲と比べてかなり英語を得意としていました。そもそも授業を英語で受けていたのだから当たり前です。そんなこんなで勉強しなくてもなんとかなってしまい、中学生生活が終わりました。

高3まで

高校生になったからと言って勉強に対する態度は変わるはずもなく、趣味に打ち込む日々が続きました。ただ高校生になり模試の結果がより詳しく出るようになって、どうやら自分は結構良い位置にいるらしいということに気づき始めます。高入生を入れても順位はだいたい1桁で、もちろん勉強していなかったので不思議な気分でした。

 このときから勉強してたら受験期にきちんと勉強できていたのかなと思う気持ちもありましたが、後の祭り。それに加えて勉強をやらない代わりに色々なことに手を出していて、これもかなり楽しかったので良しとします。

 

志望校決定

志望校を決めるに当たって、大まかに言うと条件は2つありました。

・国公立大学である

・情報系

まず国公立大学であることですが、私は兄弟が複数人いるので家計に優しくしてくれという親の要望が理由です。迷いなく理系を選択した私ですが、理系私立大学の学費を見てみると国公立との差は歴然です。一人暮らしをしたとしても国公立のほうが安くつきます。情報系を選んだ理由は一番興味があったのが情報系だったからで、PCを自作したり、簡単なゲームを作ったりしてた自分は情報系以外に進むことをあまり考えていませんでした。これを踏まえ、下の4つの候補に絞りました。

 

・東京工業大学情報理工学院

ロボコンで存在を知り、「東京大学にはない『工業』の2文字があります！」といったような言葉が印象的でした。Twitter で繋がった方々にもちらほらおり、最初に志望していました。情報理工学院だけ倍率がバカみたいに高いです。

 

・筑波大学情報学郡情報メディア創成学類

プログラミングをやってきたとはいえ、競技プログラミングに真面目に取り組んできたわけでもなければ Web サービスの開発運用をしているわけでもない自分の強みを考えたときに、情報と芸術(特に音楽)との融合に興味があることに気付きました。筑波大学には落合陽一氏の研究室もあり、自分が思っていた分野にかなり近いです。

 

・九州大学芸術工学部メディアデザインコース

フォロワーさんに九州大学に通っている方がいて、情報と芸術の融合を学べるような学部はないかというツイートをしたところ存在を教えて頂きました。芸術工学部、まさに求めてたものそのものって感じの名前！

 

・東京大学理科一類

言わずと知れた東京大学です。ツイッター見てても面白そうな人たちが一杯いるし、学祭にお邪魔したこともあり興味がありました。一つ上の親しくしていた先輩が進学したのも大きいです。

 

この4つで迷った結果、最終的に「一番上を目指しておけばどこでも行けるし、それでいいや」という適当な理由で東京大学を第一志望に設定しました。どこの大学に行っても国語は必要だと思い込んでいたので、国語の有無で迷うことはありませんでした(東大と京大以外では国語が要らないと知るのは高3の真ん中くらい アホ？)。

高3

正直受験期になったら真面目に勉強できるようになるだろうって思ってたんですが、6年間勉強してこなかったのにいきなり勉強できるようになるわけがなく、5月でエンストし6~9月は日平均1.2時間しか勉強できませんでした。

夏休みに1日1時間しか勉強してない東大志望ウケる。東大を第一志望にしたものの、どうせどこかで志望校を変更するんだろうな〜という思いがあったのは確かです。

ダラダラしながらも駿台模試で初めて東大形式の問題に触れ、受験計画を真面目に立て始めます。

第一回 駿台東大実戦模試

英語 81/120

数学 23/120

国語 35/120

物理 17/60

化学 2/60

東大 理一 D

東大 理二 C

 

ひどい成績ですが、前述の通り勉強していなかったのでほとんど応えませんでした(最悪)。これを受けて立てた受験計画は

 

英語 100/120

数学 60/120

国語 40/80

物理 30/60

化学 30/60

 

を目指せば、どこかでコケても合格最低点に届くだろうというものでした。英語で殴るのを基本方針としています。実際東大形式の英語の問題を解くのは東大実戦が初めてで、しかも体調不良で途中退出したのに80取れてるのはかなり希望を感じました。見ての通り理系のくせして理系科目がひどいことになってますが、これは文理選択のときからわかっていたことなので理系科目の強化を基本方針として勉強に励むことにします。

10月に入ってから、1日5題 Focus Gold の例題を解きツイッターに上げることを自分に課したのが功を奏してだんだん勉強できるようになっていきます。

 この勉強法はとてもおすすめです。このブログを読む大抵の人はSNSをやっていらっしゃるでしょうから、試して見てはいかがしょう？人によって合う合わないはあるでしょうが、習慣化はかなり強力な武器になると思います。

 

第二回 駿台東大実戦模試

英語 88/120

数学 11/120

国語 35/80

物理 17/60

化学 5/60

東大 理一 D

東大 理二 D

 

結構数学頑張ったつもりだったんですが、数カ月でなんとかなる程度のものではありませんでした。当時は化学2.5倍取れた！とか言ってネタにしてた気がします。勉強しないで過ごした6年間で培った勉強してないのに溢れる謎の自信は相当なものになっており、この程度では揺らがなかったようです。

 

共通テスト

さて東京大学といえば足切りがあり、理科一類は700点±20点くらいで推移しています。8割ほど取らないとそもそも試験が受けられない上に、取ったとしても二次での配点は5分の1という頑張らなきゃいけないのに頑張っても点数上そこまで得をしないという嫌〜な感じの試験ですが、ここで取れなければお話になりません。しかし私は11月の駿ベネ共通テスト模試で724点とちょっと不安になる点数を取っており、心のどこかでここで東大志望はおしまいだと思ってました。

12月後半以降は駿台のパックVで解けない問題を無くすことを目標に一旦2次は無視して復習に注力し、またようやく自習室を利用するようになったことで結構集中できるようになりました(意地を張らずに自習室を活用するのがおすすめです、マジで)。本番は現実的には720点取れれば良い方であると思って臨みましたが……

 

国語

 論説 50

 小説 47

 古文 45

 漢文 50

数学

 IA 75

 IIB 95

理科

 物理 84→87

 化学 72→77

英語

 リスニング 96

 リーディング97

倫政 85

合計 796→804

 

勝因は国語、IIB、物理、倫政が上ブレたことです。化学はなかなか難しく思ったように点が取れなかったのですが得点調整が入り結果オーライ、演習の自己ベストを大幅に更新して9割に肉薄する点数が取れました。安心して東大2次の対策ができます。

思い出せる限り科目別で意識したことを書いていきます。

国語

これは東大の記述の国語対策をやってれば殴れると思います。答えを一から書く記述に比べると、選択肢があるなんてなんて楽なんでしょう！解く順番と時間配分は

漢文15分

古文20分

小説20分

論説25分

を意識して演習していましたが、10分から15分程余ることが多かったです。

192点なんて取れるとは思っていなかったので、自己採点をした2日目の夜には手が震えて大変でした。

数学

そこまで受験を意識してなかった高1のときの模試でIAは9割取れてましたがIIBは毎回60点台で、これが足を引っ張っていたのでIIBの処理速度を上げる努力をしました。満点を取ろうとして難しい問題に時間をかけ、その結果時間が足りなくなることが多かったので、時間をしっかり意識して、満点より8割を意識して演習を重ねました。

これが功を奏したのか奏さなかったのかはわかりませんが、本番初っ端のIAで焦りに焦って過去最低点を叩き出すもIIBで自己ベストを更新する95点を取り、数学全体として目標点の170点を取れました。想定ではその内訳は IA 90 IIB 80 だったんですけどね。

理科

化学は授業内で結構共通テスト演習にも触れていて、10分見直しに使える速度で解くことを目標にしていました。一方の物理は共通テスト演習はほとんどしていなかったので不安を抱えていましたが特に対策はしませんでした。2次の対策してれば共テ取れる理論。対策は化学の重要問題集のA問題を12月までに全部解いた事くらいですが、多分普通の東大志望なら高2の時点でこれを終えているので参考になるとは思えませんね。物理で取れたのは相性が大きいです。

英語

帰国子女なので✝英語力✝で殴りました。リスニングの声色聞き取り試験には参りましたね、もしかして声色聞き分けるのって思考力が測れたりしますか？

倫理・政経

共通テスト直前期まで特に対策はしていませんでした。直前期はパックVの解説をすべて、正解した問題もそうじゃない問題も読み、わからないところを調べまとめました。これが一番効きました。倫理が簡単だったのもありますが、調整前の得点では物理と化学より点数高いんだから驚きです。ほんとに理系なの？

最終東大本番レベル模試

ムズかったです。

 

英語 91

現文 16

古文 9

漢文 12

数学 41

物理 14

化学 16

 

理一 E

理二 E

 

結構良くてもE判が出ると聞いていたのでそこまで落ち込みませんでした。

直前期・私大

もともと国公立一本で行くつもりだったので前期東大後期北大しか考えてなかったのですが、担任に2浪を覚悟しなくてはいけないスケジュールだと言われ、親にも早慶なら学費を出してやらなくもないと言われたりなど色々あった結果人並みに私立も受けることになりました。

 

共通テスト利用 

独自試験

 

共通テスト利用は取れればラッキー程度のノリでしたが、蓋を開けてみればほぼ確実な点数だったので中央大学の共通テスト併用入試は受けに行きませんでした。法政大学の共通テスト利用C方式は5教科見てくれる上に、入学金振込を後期まで待ってくれるので万が一のために出願しておくと安心できます。

 

また入試スケジュールの把握には東進の共通テスト合否判定システムが有効です。判定自体はあまり当てにならないかもしれませんが、下のように出願締め切り・入試日・合格発表日・1次手続き締切日をカレンダーに表示してくれます。

f:id:takabayap:20210306114031j:plain

合格したとしても入学するためには1次手続締切日までに入学金を振り込まねばならず、これがだいたい20〜30万円なので滑り止めの受け方はよく考えないといけません。私は理科大と中央を共テで取れましたが、早稲田の手応えがかなり良かったので結局入学金を払わず、2/20,21は宙ぶらりんになってしまいました。思いがけず慶應に受かっていたのですぐにこの状態は解消されましたが、合格が途切れないようにするに越したことはありません。

 

東京理科大学 工学部 情報工学科

B方式独自試験科目は数学・英語・物理の3科目でそれぞれ100点、去年の合格最低点は213/300です。

数学の構成はマーク式小問集合が1つで50点、残り2つが記述の穴埋めで25点ずつですが、記述の穴埋めは結構難しく(1)しか取れなかったので小問集合をどれだけ落とさないかがポイントです。私はそれすらあまり取れず全体で小問単位で正答したのは8/15でした。

物理はマーク式と記述式穴埋めが混在する大問3つ構成です。マークだからと侮ると痛い目を見る選択肢の数でおなじみです。正答は回答欄24個/34個でした。計算が複雑な部分もありますが、そうでないところを見極めて拾っていくと良いと思います。

英語は文法が多いですが難しくありません。2ミスでした。

慶應大学 理工学部 学門B

英数各150点、理科2科目合わせて100点で去年の合格最低点は309/500でした。といってもこの数字は理工学部の学門A~Eの平均なので、実際は学門により上下します。今年は倍率を見るとBACEDの順に人気だったようなので、合格最低点も電気・情報系の学門Bが一番高いと考えられます。

あと問題に直接関係はないのですが、慶應の問題冊子はホチキス止めされていないので切り離すことができ、真ん中のページが丸々計算用紙に当てられているのでそれを独立して使うと解きやすくおすすめです。

数学は大問5つですべて記述の穴埋めです。難易度は標準的なものが多く取れる人はかなり取ってくるでしょう。私は1完3半でした(数弱)。x^2021を割る問題が理科大とかぶってて笑っちゃいました。物理でも理科大で出た問題に似たものが出たりしたので、私立の受験の復習をするのは個人的にはおすすめです。ただ、出来が悪くて引きずってしまってもいけないので人次第ですね。物理は力学が1ミスでほかもまあまあだったのですが、問題は化学で解答は3割しか合ってませんでした。有効数字3桁の計算を穴埋めでやらされるので、基本的な化学の知識に加えて計算力も重要になってきます。東大みたいに立式だけして逃げるのもできないし。英語は文法が多くて嫌な感じでしたが8割取れました。環境情報も受けて、早稲田に比べて慶應は文法とか語彙が好きだと感じましたね。基礎は大切です。

試験の順番は理科→数学→外国語なのですが、難化した化学で撃沈したと思いこんでメンタルやられて数学でほんとに撃沈した同級生がいたので、メンタルにも気をつけましょう。

早稲田大学 基幹理工学部 学系Ⅲ

早稲田は英数120、理科が合わせて120で去年の合格最低点は210/360でした。慶應と違って理工の中でもきちんと分けて合格最低点を公表してくれているので、難易度差がわかりやすいです。基幹理工・創造理工・先進理工の3つそれぞれの学科のうち最も高いのは先進理工の物理学科で、なんと去年の合格最低点は一番低い電気・情報生命工学科と34点差の230/360なので、一口に早稲田の理工と言っても難易度は変わってきます。あと、基幹理工の学系Ⅲと創造理工では得意科目選考という合格点に達していなくともある科目で特に優れた能力を示した受験生を合格とする制度があるのですが、学系Ⅲでは去年2人しか出てないのでこれを狙いに行くのは厳しいものがあります。そもそも、ずば抜けてできる科目がある受験生は普通に合格点が取れているという話もありますが。あと試験には直接関係ないですが男子トイレめっちゃ混みます。当日は同校の人たちとすいてるトイレ情報を交換してました。

早稲田の理工は英語が難しいことで有名で、そもそも論文の内容が難しく、科学的な知識がある程度なければ英語ができても読めない気がします。本番ではたまたま内容がわかった……気になっていましたが、今調べたらちょっと勘違いしてたみたい。語彙だけ6ミスでした。

数学は東大とほぼ同じ空欄の解答用紙にガリガリ記述していく方式なので東大志望は戦いやすいでしょう。今年は去年に比べて難易度が落ちたみたいで、過去問よりかなり取れて4完2半でした。ほぼ毎年出る数Ⅲ微積が出なかったのは学習が遅れている受験生への配慮……？

物理はある程度解く事の難易度はそこまで高くないんでしょうけど、とにかく分量が多いです。大問3つ全て問10まであるので、完答を目指すのではなく取れるところをあちこち取っていくのが良いでしょう。私は符号ミスと公式ミスで6問落としました……。

早稲田の化学といえば小問集合です(？)。1問3個のマークで、予備校の分析では完答で初めて得点だそうです。2個あってる問題は結構あるのですが、完答は3問でした。鉛筆転がしても得点は厳しそうです。分量が結構あるので予定通り30分使ったのですが、物理も分量が多く大問2の理論に回す時間がありませんでした。3の有機が2ミスだったので、物化でなんとか3割は取れました。

慶應義塾大学 環境情報学部

SFCです。文理融合のキャンパスで、なかなかおもしろそうなことをやっています。SFCは環境情報学部と総合政策学部の2学部ですが、両方数学・英語もしくは外国語のみと小論文を課しています。英語は長文→語彙・文法→読解の3セットで、量が結構あるのでスタミナが必要ですし、難易度も高いです。環境情報はやはり科学的な文章ばかりが出題されるので、過去問の語彙を確認するのが役に立つでしょう。私は7割でした。

なにより特徴的なのは小論文で、これは傾向がないのが傾向とも言えます。キャンパス紹介文を読まされたかと思えば絵から物語を書かされたり、とにかく何が出てくるかわかりません。去年受かった先輩には対策をするなと言われていました。ただ基本的にアドミッションポリシーにある日常の中で課題を発見し、それを解決する能力を問うものが多いです。今年の世の中の不条理を15個挙げ、そのうち3つについて解決策を提示しろ、なんていうのはド直球で対策をしていた受験生にとっては簡単だったでしょう。私はほとんど対策をしていなかったのですが、常日頃考えてたことをなんとかひねり出して書いたら受かってました。
・行政の支援を受けるためにも知識が必要で、支援が必要な弱者に支援を受けるための知識を得るという負担を更にかける仕組みになっているのは支援をしたい行政・支援を受けたい社会的弱者双方にとって不利益である
という内容をベースに
・行政システムの電子化
・収集したデータに基づく受けることができる支援の一覧表示ができるサービスの構築
・そのサービスのスマートフォンや市役所などのタブレット端末で使えるようにする
という解決策を書きました。定量化して示せ、とか問題文に書いてあったみたいですがガン無視してましたね。解決策の提示は1つしかまともにかけてなかったので全く自信なかったどころか不合格を確信していました。

国公立

共通テスト終わってから気が抜けてしまいあまり勉強できていなかったのですが、流石に東大は直前に過去問を2年分解きました。ここで2020年の数学は傾向がかなり違ってびっくりしました。去年の過去問は早いうちに解いておくことをおすすめします。あと国公立直前期はツイートがよく伸びて楽しかったです。受験生はコンテンツ力が高い。

問題はよく覚えてないです。何を隠そう今まで受けてから一回しか開いておらず、解答速報も英語しか確認していません。1日目は国語でまあまあかな〜と思ってたら数学で爆死しました。落ちたら数学のせいです。あと昼休みに箸を忘れたFFとエンカしました。

安田講堂前の広場は入試本番とは思えないほど賑やかで、やっぱ東大は違うな！と思っていました。人のこと言えませんが。帰り道、数学爆死したので不合格でもメンタルに問題ないからと慶應SFCの合否を見て、受かってて思わぬショックを受けました。

2日目、理科は相変わらず解けなかったけど、英語は良かったです。法文2号館の広めの教室に当たって、ハズレかと思いましたが最前列だったのでリスニングの音声がよく聞こえ、おかげで満点が取れました。2日目の昼休みは早稲田の合否を見たあと別のFFとエンカしました。のんきなもんです。

東大受験生は再現答案を書いて予備校に送ることで図書カードがもらえるので、私もそれで漫画を買うつもりだったのですが、受け終わるととてもそんな気力残ってないしそもそももう問題冊子を開きたくなかったので再現答案用の答案用紙はまだ本棚で眠っています。後輩にあげようと思っています。ここから3/10までは生殺しで、ゲームやアニメで気を紛らわしていました。

結果

1年間お疲れ様でした！