Category Archives: 論評

神楽坂一丁目通信局(TBN)のこと

今日は出身の東京理科大学の学祭に顔を出してきました。もっぱら、現役時代僕が所属していたサークル、神楽坂一丁目通信局の後輩たちに逢うことが目的でした。僕が卒業してからはや4年が経過し、メンバーはすっかり一巡してしまいましたが、それでも昔と雰囲気が変わらず、いきなり訪れた僕のうるさい技術トーク全開も嫌がらずに聞いてくれて、楽しく過ごすことができました。ありがとう。そしてごめんね!

このサークルと、そこで出会った仲間のおかげで今の自分があると思っています。そんな神楽坂一丁目通信局、通称かぐちょについて書こうと思います。

パソコン好きな高校生のみなさん、理科大の神楽坂キャンパスを受験予定のみなさん、理科大生でパソコン大好きでゲームとかWebとか大好きな人、入るサークルに検討したらいいんじゃないかと思います。

内部では、プログラミング、CG、DTM、パソコン自作の組に分かれていて、それぞれで活動しています。が、僕がいた頃は、それぞれの部門の垣根もあまりなく、部室に行けば、PCとゲームとWebが好きな人たちが集まっていて、技術トークで盛り上がっていました。きっと今もそうでしょう。

僕が1年生の頃、3、4年生の先輩方の技術力がとにかくすごく、その人たちと話がしたくて、授業をさぼったりすらしましたw
今は部員が増えた分、技術力は落ちたと聞きますが、ちゃんと、FPSライクな3Dゲームを作れる程度の能力はあるようですよ(←注:僕は作れなかった)

色々、現況の問題とかもろもろ聞きましたが、新人が入ると、1年間かけてC言語の基礎を教えることが精一杯で、なかなかレベルの高いことができないという、僕の頃と同じような悩みを抱えていました。

僕も2回プログラミング部門のリーダーをやりました。1年目、2年目を通じて僕が取った方針は「機会を与えるが、なるべく教えない」でした。hello, worldから、scanfを覚えたあたりで、「今まで覚えたことを使って何でも良いからゲームを作って」と課題を与えて、上がってきた作品に対してコードレビューやら、アドバイスやらをして、だんだん育ってもらうという方針を取りました。まず最初の課題を提出できるのが、10人入ってきて1人か2人、最終的にだいたい毎年1人しか残りませんでした。その一人に、「数当てゲーム」と称して、「200の話術を作ってあの娘を口説け」というゲームを作った奴もいましたが、彼には、printf、scanfベースで作ったCのプログラムを元に動くノベルゲームの簡易的なフロント的なものを作ってあげて、最終的に僕と彼でギャルゲ(とも言えない恥ずかしいゲーム)を作ってしまったのもネタとしてはよい思い出です。僕も僕で、Swingを覚えることができたし
、無駄にデザインパターンを試すことができたので良かったです。

このやり方こそ王道だと思っていたのですが、裏返しとして、少なすぎる部員に毎年存続の危機になづいました。この状況を打破してくれたのが、僕の次の部長でした。彼は10人くらいいる新入生をほとんど残し、それぞれが、当初は特出したレベルではないにせよ(うち一人は、その後急成長して、プログラマーとして活躍しているらしい)、みんながプログラミングを楽しんでいる、そういう状況を作ったことには驚きました。考えてみると、僕が反面教師?

その後部員の数は僕がいた頃の倍くらいになりましたが、みんながそれぞれ楽しみながらプログラミングなどの活動をする伝統は顕在しているように見えました。

部長のタイプとしては、僕みたいなスパルタタイプと、みんなでやろうなタイプとが、その後も出てきたみたいですが、良いじゃないか!楽しければ

そして、つい、OBとして、差し出がましいとは思いつつ、「これからは、こういうゲームをWeb上で、JavaScriptとCanvasでやるんだ!サーバはクラウドに置くんだ!僕はそのあたりを勉強しているけど、アイディアも、作業時間も限られている。もしよかったらその辺のノウハウについて情報交換の場を持とうじゃないか」なんてことを提案してしまいました。僕そんなに教えるほどできないじゃんwww

それはさておき、今日はまるで現役大学生の時みたいに、全力でハイテンションで技術トークができて楽しかったです。ああ、自分はこんな学生時代を過ごしたのだと思うと、嬉しくなりました。

完全に回顧ネタ、ともすれば自慢話にも読める今日のエントリですいません。また、現役のみんなには、いきなり来て迷惑だった上、こんな記事を書いて恥ずかしい思いをさせてしまってたらごめんね!

どうぞ、かぐちょこと、神楽坂一丁目通信局をよろしくお願いします。

現役の子一人が、このブログを検索で見つけて読んでくれていたみたい。名刺にいつもの似顔絵が書いてあるのを見て教えてくれました。嬉しいです。今後ともよろしくお願いします。

追記

調べてみると、Canvasの3D APIはWebGLが本命だけど、「まだ」だから、2Dベースに3D化するのが今のところはベターなんだね。正直WebGLのサンプル見てもう……て感じです。これでも昔Managed DirectXなんて地雷を踏んで(ry
まあ、あと1,2年もしたら、書店で本がワンサカ出たりするんじゃないかな?そしてから手をつけるだけでも良さそう。
とはいえ、Windowを表示するだけでWin32APIを(今更)覚えるのも大変だから、いきなりブラウザがあれば2Dでもグラフィックが書ける環境というのも悪くないんじゃないか?

新しい技術と信用と山とシステムと

学生時代登山をやっていて、社会人登山家の人とも知り合って一緒に訓練をさせてもらっりした。

その中である二人組の登山家がいた。年配の登山家と、30台半ばくらいの若手の登山家で、ともに海外登山を行う本格的な登山家だった。縁があって、一緒に雪山で訓練をさせてもらった。

その時、視界がホワイトアウトし、コンパスと地形図で場所を測定しながら、自分たちが来た道に目印として残した旗を探して歩いた。その時、年配の方の登山家が、残り3人のメンバーの観測に不満があったようで、自ら調べて、一人その道を歩いてしまった。と、言っても、数メートルなのだが、吹雪の中での数メートルは見えない。

さらに、その後雪も止んだので、斜面でザイル(ロープとも言う)の使い方を訓練することにした。ザイルの使い方も色々ある。まず大きく分けて「コンテ」と「スタカット」がある。前者は、隊員数名を一本のザイルで結んで、一人が滑落したら前後の人で止める。失敗したら全員滑落してしまうので危険だが、スピードが早い。例えるなら電車ごっこだ。後者は通常2名で行う。行動するのは常に1人ずつ。例えるなら尺取り虫である。安全だが遅い。ちなみに山でスピードは大事だ。行動は日没とのタイムトライアルなのだから。なぜこんな細かいことを説明するのかというと、より、臨場感を増すためなので理解いただきたい。本題には本当は関係ないのだが。

この時は「コンテ」のやり方について練習した。「コンテ」のやり方も色々である。伝統的な方法として僕が先輩から習っていたのは、ザイルを片手にぐるぐる巻きにして持ち、滑落を止めるときは、ぐるぐる巻きを地面に投げつけて中心にピッケルを刺すという方法だ。その時のメンバーでも、それがまず前提だったようなので、多分標準的な方法なのだ(筆者は確かに山岳部出身だが、それほど優秀な部員ではなかったので、それなりの理解しかないこともご了承ください) しかし、近年、色々な方法が研究されている。この時は「大阪府岳連方式」と、名前を忘れてしまったが海外の方で研究された方式を試した。なるほど、やってみると、ザイルの摩擦の使い方がこれらの方が優れている優れているかもしれない。より、クリティカルなシチュエーションでは、こういう新しい方式を使ったほうが望ましいだろう。が、問題があった。慣れていないことと、今まで当たり前のようにしてきた、人と人のあいだの距離の調整がこれら新しい方式ではできないのだ!(←本当にそうか不明。筆者ザイルワークの初心者)そこで、結局、年配のリーダー格の人は決定した。

新しい方法も確かに良いが、今回は、伝統的な方法を採用しよう

              • -

後日、若手の登山家の方から呼び出された。

「○○さんとは、あまり付き合わない方が良い」

そうはっきりと言われた。理由は、前述のように、彼は、「古いやり方を変えない」「自分の判断に固執して仲間と合わせない」という癖があるからとのことだ。他にも何度かそういった場面があったらしい。

「彼のようなやり方でも、国内で仲間を連れて登る分には問題ないかもしれない。でも、それで海外は通用しない

というようなことを言ったような気がする。

さて、このブログを読んでいるのは、プログラマー、システム屋の人が多いはずだ。対象を登山から普段の仕事に置き換えて考えてみよう。心当たりがないだろうか?最後の「海外(世界)で通用しない」という言葉の重みや如何に?