はじめに
この記事は、東京大学2018年五月祭でeeicの企画として開かれていたプログラミング教室（以下、ピ教）の開発に関する僕の「お気持ち」を書き連ねたものです。長いので全部読みたくない人は最後の「第五章」と「あとがき」だけどうぞ。
また、ページがhttps://2018.eeic.jp/programmingに公開されているので、良ければ遊んでみてください。
あと、プログラミング教室でデスマーチをしたのに転生できなかったお話[技術編] - どやの情弱克服ブログに技術系の話があるのでこちらも是非。
本記事には、以下の要素が含まれます。
- なろう小説っぽい表現
- ライブラリへの愚痴
- 開発への愚痴・反省
基本的に書いてるネガティブな内容は、反省と自らの戒めへの意味で書いています。
謝辞
開発メンバーはみんなよく頑張ってくれて、みんながいなければ完成には至らなかったと思います。この場をお借りして、お礼を言いたいと思います。ありがとうございました。いや、僕別に責任者でも何でも無いのでかなり何様感ありますが。
第一章：全ての始まり
全ては2月、3Aの試験が終わった頃から始まった。
プログラミング教室開発陣による初顔合わせである。この場で、今年のプログラミング教室で何をするのかを話し合うのだ。eeicの錚々たる顔ぶれが集まり、このメンバーであればどんなものでも、それこそデウス・エクス・マキナでも作れるのではという予感があった。
その場で話し合いが始まり、僕は皆に問うた。
「今年、何やります？ 去年の使いまわしじゃダメですかね？」
間をおかず企画の副責任者が反論した。
「いや、去年遊びに来た人もいるし今年も１から作ろう」
なるほど。確かに、去年遊びに来た人が今年も同じ内容だと退屈してしまう。
そこから今年の教室の内容を話し合う。そもそも去年と同じくゲーム形式にするのか、ゲームにするとしたらどのようなジャンルにするのか。会議は踊り、されど進まず。
皆の顔に疲れが表れ始めた頃、僕は意を決して手を挙げた。
「……迷路とかどうでしょう」
PMが無言のまま続きを促す。それに頷くと僕は続けた。
「ブロックでキャラクターに指示を出して、迷路を解くんです。去年のアクションゲームとは違うジャンルですし、やりやすいかなと思うんですけど」
考え込む一同。しかし、これ以上の案も出てこないと思ったのか、次々と賛同の声を上げる。軽い気持ちで提案した僕は、内心で冷や汗をかく。
え、こんな簡単に決めちゃっていいの……？
内心不安がる僕を置き去りにあれよあれよという間に議論は進み、とりあえずは迷路ゲームの方向性で行くこととなった。最後に、
「今後、集まれる機会があるかも分からないし、早めに企画書を固めるべきでは？」
という提案が出た。まあ、迷路ゲームを提案したのは僕だし、ここは僕が企画書のたたき台を作るのが道理だろうと自ら名乗りを上げ、一両日中に企画書を上げることを約束した。そうして、その場は解散した。
思えば、これが始まりだったのだろう。
第二章：enchantjsとの邂逅
なろう風に書くの飽きたのでここからは普通に書きます。
なーにが、
思えば、これが始まりだったのだろう。
じゃ。プログラミング教室開発陣が一番最初に集まって話し合った場なんだから、始まり以外の何物でもないだろ。
閑話休題。
まず、blockly*1を使うことは確定していたので、残りはゲーム側のライブラリを決める必要があった。 誰一人としてWebブラウザでゲーム開発をしたことなどないので、「ライブラリなんかいいの無いの？WOWOW」となってから議論が全く進まなかった。痺れを切らした僕が適当に調べて、一番日本語の記事が多く出てきたenchant.js（以下、enchant）というライブラリを使おうと提案した。
これがかなり間違いだったことに後で気付く。
enchantとかいうライブラリ、日本語のレファレンスがあるから良さげかと思えば随所にアレな箇所が散りばめられていて、開発しながらかなり[削除済み]な気持ちになった。もし来年も1から開発するなら、enhantじゃなくて別のライブラリ使った方がいい。
言語は当然javascriptが想定されていたが、僕と副PMの希望でtypescript*2を使うことにした。まず開発を進める上でプロジェクトにおける最低限の開発環境を整えなくてはならないのだが、これがかなり大変だった。 まず、enchantもblocklyも型定義ファイルが公式に存在しないのだ。typescriptで既存のjavascriptライブラリを扱うには型定義ファイルが必要なので、それがないととても厳しい世界観になってしまう。しかしまあ地球上には同じことを考えている人間が一人以上は存在しているらしく、適当に「enchantjs types」とかで調べると有志が型定義ファイルを作っていたのでこれを拝借することができた（blocklyも同様）。 勝手に拝借しておいてあれだがenchant、blocklyともにかなり不完全な型定義ファイルで、使えるようにするのに結構色々と手を加えることになった。
何故かよく分からないが、僕はプロジェクトの中で「typescriptが出来る人」みたいな扱いをされてしまっていたため、初期セットアップや型定義の導入などをもろもろ請け負うこととなった。ぶっちゃけ、typescriptを完全に理解している人ではないので非常につらいお気持ちで作業をしていた。副PMにめっちゃ助けてもらった。 なんとかかんとか開発を始められる段階になったので開発を始めるわけだが、初期設定をしたのは僕なので僕が全体のベースとなるような部分を書いていくしかなかった。そのため、一人で黙々と進捗を生やしていた。後ほど述べるが、これはかなり良くない行為である。
第三章：進捗、進捗、そして進捗
「いや、言うてお前そんなにコード書いてないやろ」とかいわれると悲しい気持ちになるが、ピ教レポジトリのinsightsを見てみると、
とかなってるし、結構頑張ったんじゃないかな……
一応ゲーム開発人員は僕を含めて4人（最終的には5人に増えた）いたので、適切に仕事を割り振れればデスマーチが起こらないと考えていた。適切に仕事を割り振れれば、だが。
僕はこの開発を通じて気付いたのだが、僕以外の全ての人間は僕と違う。僕が時間があるからと言って他の人間にも等しく時間があるとは限らないのだ。僕の場合、
24時間ー（睡眠10時間＋食事風呂トイレ等2時間＋授業やミーティング（あれば）2~3時間＋通学時間往復2時間）＝ 7時間
の計算式で、一日平均約7時間が自分の自由に使える時間になっていた。日によってはインターンやお遊びをぶち込んでいたためこれよりも少なくなっていたが、土日も含めるとまあ一日平均7時間はフリータイムがあったと言って差し支えないだろう。とすると、週約50時間のフリータイムが存在するわけだ。僕はアニメを週20本ほど見るので、24(min) x 20 ＝ 480(min) = 8(h)を差っぴいても、42時間の自由時間が残る。生命、宇宙、そして万物についての究極の疑問の答えだ。
すごい本筋から逸れるが、塾講師をやっていた際にこの計算を生徒に教えたらドン引きされた。「人の一日の時間はそんなに簡単に足し算引き算で計算できるものじゃない」とのことだ。僕はこの計算式で生きているので、あまり納得できないがそういう人もいるらしい。
話を戻そう。42時間のうち多分15時間ぐらいをピ教に割いて、コンスタントに進捗を生んでいたわけだが、他の人にもどこかでそれを期待していた。しかしそうはならなかった。 これは完全に僕が悪い。
自分が入ったプロジェクトで、何の説明もなく他の人がガリガリ開発を進めていたらあなたはどう思うだろうか。どこか参加のしづらさを感じるのではないだろうか。「自分はどこをやればいいのか？」「自分が触っていいのか？」といった疑問を覚えはしないだろうか。僕なら思う。僕はPMでも何でもないただの平開発メンバーだったので、人に仕事を振る意識が無かった。自分が適当に進捗を生やしていれば、他の人も進捗を生やしてくれるという雑な感覚でいた。
昨年も一昨年もピ教は一人で開発していたと聞いて、今年こそは複数人でしっかり分担するぞと意気込んでいたのに、僕自身がそれに歯止めをかけるような開発の仕方をしてしまっていた。今まで僕が開発をリードすることが無かったが故の失敗だった。 途中から仕事を振るようになったが、やはり僕が期待していたほどの分担は出来なかった。人に仕事を振ることは難しい。
ネガティブな話ばかりでもあれなので、逆に個人的にやって良かったなと思ったことを話そう。それは、slackにconsultationチャンネル*3（何でも相談チャンネル）を立てたことだ。このお陰で、「分からないことを一人で悩んで時間を浪費する」という状態をかなり削減できたように思う。このチャンネルは最後まで活躍していたし、相談や報告の心理的障壁を下げられたのはかなり良かったと思う。
第四章：そしてデスマーチへ
参考文献『デスマーチからはじまる異世界狂想曲』（2013年, 愛七ひろ）によると、デスマーチをすれば異世界に転生できるらしい。*4
しかし、僕は転生が出来なかった。もしかしたら今世での徳がまだ足りないのかもしれない。
僕はゲームの完成締め切りを4/30に設定した。どうせ後々バグやら仕様修正やらをしなければならないことは目に見えていた（実際そうなった）ので早いうちにある程度形にしておきたかった。しかしこの締め切りは守れなかった。僕が抱えていたissueを全て解決できなかったのだ。そのとき、僕は大量のUI作成やら機能作成やらをしており、かなりキャパっていた。慣れないUI作成作業に手間取っていた。そうして一度超過した締め切りはずるずると後ろ倒しになっていく。
それに加えて、春から研究室生活が始まり、開発メンバーが開発の時間をとれなくなっていった。やっぱり「研究室が忙しい」とか「時間が無い」と言われると無理には振れないし、「そうか…なら比較的時間がある僕がやるか…」となってしまう。それはある種正しいが正しくない。
開発中に一度「人員の増加が必要か？」という話になったが、僕が現状のペースで全員が開発を進められればちゃんと終わると考え、独断で増員を断ってしまった。思えばこのとき増員をしておくべきだったと深く反省している。僕が時間がとれるから他の人も時間がとれるだろうという考えは身勝手すぎる。
結局、ある程度完成と呼んでいいものができたのは五月祭1週間前とかだったと思う。それでもなお大量のissueが残っていた。デスマーチだ。最後の方は研究室が同じだった同期にも頼んで開発を手伝ってもらったりしていた。
issueが全部片付いたのは、結局五月祭前日の夜11時だった。
「ああ、これがデスマーチか…」と、思わず笑ってしまったのを覚えている。
第五章：未来の人たちへ
一人で抱えても碌なことにならない。相談チャンネルを立てた僕自身が、誰にも相談せずにぽんぽんタスクを抱え込んでいたのは最高に皮肉が効いている。もっと早いうちから周りを頼るべきだし、周りに投げるべきだった。 プログラミング教室で小学生に「デスマーチはしちゃだめだゾ☆」なんて教えたくないだろ？
最後にこれだけは言いたいが、今回プログラミング教室がデスマーチしてしまったのは僕の責任だ。twitter上ではへらへらしているが、実は結構反省している。
あとがき
最後に良かったこと・悪かったことをまとめておきたい。
良かったこと
- slackに何でも相談チャンネルを導入して相談の障壁を下げたこと。
- 途中からは積極的に仕事を振ったこと。
悪かったこと
- 仕事を振り始めるのが遅かったこと。
- すぐに一人で抱えたこと。
- 他人と自分が同じだけ時間を確保できると過信したこと。
- 実際に集まる機会が少なかったこと。
