むだそくんについて
僕は今でこそ、企画を作って生きていますとか気楽なことをほざいているのですが、学生時代は結構真面目にコンピュータサイエンスを学んでいました。
プログラミングを学ぶのはそこそこ楽しく、ボチボチ真面目に勉強していたのです。
しかし、あくまで「ボチボチ真面目」というレベルで、僕はプログラミングに圧倒的に没頭できるタイプではありませんでした。
よく映画に出てくるような、暗い部屋で一心不乱にキーボードを叩くあのタイプではなかったのです。
したがって、成績もまあ高からず低からず、といった感じだったのですが、一度だけ圧倒的な成果を出したと言える講義がありました。
その理由は、スキルとか勉強量とかじゃなくて、ものを作る人間としてのある心がけでした。今日はそのことについて書いてみます。
鬼の「プログラミング第三同演習」
僕は、慶應義塾大学の理工学部情報工学科というところにいました。
慶應のこの学科には、看板科目がありました。
地獄のような難易度を誇るプログラミング第三同演習です。
その難度は伝統的なもので、教授いわく、
とのことでした。
僕は、
と驚愕したものです。
この科目、実に7割の学生が「D」の評価（いわゆる「不可」）で、単位を落としてしまいます。
更に言えば、単位を取った学生の内のほとんども「C」の評価で、「A」や「B」が取れる人はほんの一握りしかいません。
そしてこの科目で、僕は「A」を取りました。
じゃあ僕のプログラミング能力がことさら秀でていたのかと言えばそんなことはなく、ある仕掛けがあったのです。
その仕掛けについてお話する前に、プログラミング第三同演習がなぜこんなにも難しい単位なのかを説明しておきます。
テストの時間が全く足りない
プログラミング第三同演習のテストは、「実際にプログラムを作って動かす」という試験になります。
最終的には作ったものを提出して終わりです。筆記試験のような要素は一切ありません。
さて、このテストの何がヤバいって、とにかく時間が足りないのです。
おそらくは教授の「プログラマーなんて納期守ってナンボだろうが！」という思想にもとづいているのでしょう。凄まじい量の問題を処理しなければなりません。
膨大な量のプログラムをゼロから書き上げなければならないので、めちゃくちゃ厳しい条件でした。
特に、プログラミング第三同演習はC言語という、少々昔風のプログラミング言語を扱う講義だったので、「セグメンテーション違反」というバグがよく生じて苦しい思いをすることになります。
このバグは修正に少々時間を要するので、テスト中にこのバグが出ようものなら
となること間違い無しの、かなりスリリングなテストでした。
このテストを攻略できるのは、圧倒的な速さでプログラミングできる技能を持った人間だけのように思われました。
そして、僕にはそんな技能はありませんでした。
かといってテストに白旗を上げるのもやりたくありませんでした。
だから、裏ワザが使えないか考えたのです。何かもっと別の角度から作戦を立てられるんじゃないか、と。
テストのルール
さて、このテストですが、「時間が全然足りない」ということ以外に「やたら明確にルールが決まっている」という特徴がありました。
持ち込み自由
テストは持ち込み自由です。
何を持ち込んでも良いし、プログラミングの講義なので当然PCも使えます。
インターネットの使用及びその他の外部との交信の禁止
ただし、インターネットへの接続は厳禁というルールでした。
事前に作成した作業用ディレクトリのみでの作業
大学のPCはLinuxというOSで動いており、その特徴上、普通に作業していると作業の様子をPCの中から覗けてしまいます（インターネットに繋がなくても、同じ部屋の奴の作業を見られるのです）。
クラスメイトの作業を覗く奴が出るのを防ぐために、覗けない作業用のディレクトリ（PCの中の場所）でだけ作業するルールもありました。
等、細かくは覚えていませんがかなり明確なルールが並んでいたはずです。
周りのクラスメイトはこのルールを見て「まあ妥当だよね」と受け流していたようですが、僕はある点が気になっていました。
ルールの中に、楔を打ち込める！
さて、僕はこのルールを見て、思いました。
テスト中にインターネット上や、別のディレクトリからソースコードを持ってくることは禁止されていましたが、最初から入れておくことについては何も言及されていません。
気づいた僕は、テスト前に使えそうなありとあらゆるソースコードを作業用ディレクトリの中に入れておきました。
テストの傾向自体は過去問から分かっていたので、使えそうな文字列処理のためのプログラム等をかき集め、必要な部分は自分で書いて、作業用ディレクトリに入れておきました。
テスト当日
テスト当日、僕は周りに比べて随分余裕がありました。
周りは全ての問題に対してゼロからソースコードを書いていましたが、僕は
と、探すところから始まり…
と、与えられた仕様に対してちょっと書き換えるだけで良かったのです。
当然、効率は段違いです。僕はこの戦略で無事、全問回答し、バグも取りきり、完璧に動くものを提出しました。
成績は当然「A」をいただきました。
ズルい！と思われる方もいるでしょうが、僕はこの戦い方で何も反則はしていない（禁止事項に抵触していない）です。
そしてむしろ、この戦い方に到達するために設けられた試験だったのではないかとすら思います。
僕が勝手に考える、試験の意図
車輪の再発明をしないように
エンジニアの世界で広く使われる言葉で、車輪の再発明という言葉があります。「既にあるものを、また一から作ってしまう」という過ちのことです。
効率を重んじる開発の場合は、「既にあるもの」は十分に活用すべきであり、もう一度ゼロから作るなどという手間をかけるべきではないのです。
今回のテストもまさにその条件に当てはまっているのではないかな、と思います。
自分の能力を圧倒的に越える量のコードを書かなければいけないなら、どうにかして既存のものを利用する必要があるはずなのです。
ルール（要件）をしっかり読み込むこと
今回の僕の戦略は、試験のルールを読み込んだところから始まりました。
あれ？これ、最初からソースコードを入れておいても良いじゃん、という気づきは、真摯にルールと向き合ったから生まれたのです。
「そんなことは当然やってはいけない」と勝手に決めつけている人間からは、新しいアイデアは生まれません。
エンジニアの使命は、どんな手段を使ってでも要件を満たすものを作り上げることです。
それ以外のことは重要ではありません。「えっ！そんなのあり？」というようなやり方であったとしても、要件を満たしたものをきちんと作れれば、それで勝利なのです。
僕は、明らかに自分のキャパを越えるテストだったから、新しい発想で攻略しようとしました。
無理そうだな、と思いながらも無策でテストに挑むやつの方が、むしろエンジニアとして怠慢なのではないでしょうか。
しっかりルールを読み込んで、問題を解決する意外な方法を生み出すところまでが、テストだったのかもしれません。
まとめ
ということで、自分のカンニングすれすれの行為を正当化する、という中々すごい記事になりましたが、僕は割といい勉強になったなーと思います。
そしてこのテストの意図も、案外僕の考える通りなのではないかな、と思います。
実際、教授が僕の「色んなソースを詰め込んだディレクトリ」を見ても何も言わずに通過していった辺り、僕の行為は違法ではなかったのでしょう。
無理なテストがあるなら、それに応じた攻略法を考えてみるのもまた乙なものかもしれません。
それと、慶應情報工学科の諸君。これはあくまで僕の私見なので、今年のテストで怒られても責任は持ちませんよ。悪しからず。
関連記事
大学の「情報工学科」は、プログラミングを学ぶ場所ではないという話。
ロボットの首をテープで止めたりしながら卒論を3日で書き上げた話。
地獄のようなWebサービスを10日で作ってリリースした話。
