目次
02-08 ゲーム会社の仕事
02-08 ボブ・バーマー 誕生日(1920)
長男が、学校の課題で「自分の人生をまとめる」ということをやっている。
もちろん小学６年生の過ごした「人生」なんて短いのだけど、今後のことは想像してある程度大人になるまで作るらしい。
つまりは、もうすぐ中学生になる子供に対して、将来について考えるきっかけを与えるのが狙いなんだな。
で、長男から「インタビュー」された。
今、長男が興味を持っているのは、テレビゲームで遊ぶことと、Scratch でゲームを作ること。
将来の職業を「ゲームプログラマー」にしたいのだけど、どんな仕事か実感がわかないらしい。
僕は実際にゲームプログラマーだったので、仕事がどういうものか教えてほしい、とのことだった。
ある程度は教えたのだけど、雰囲気とかは簡単に伝えられるものではない。
そこで、アニメ「NEW GAME!」を見せてみることにした。
放映されたのは半年ほど前だね。原作は読んだことないから知らない。
僕自身は、Amazon Prime Video で無料で見れたので、3か月くらい前に見た。
大人向けの深夜アニメなので、子供向けでない表現もある。
と言っても、女性のパンツ姿が出てきたり、その程度。まぁ、見せてもいいだろう。
流行したアニメだからこそ、いろいろと批判している人もいる。
でも、「基本的に男性がいない世界」であることを除けば、ゲーム会社のお仕事としては大体あってる、という認識。
（多少時間の流れに疑問はあるけれど、些細なこと）
人物描写とか、極端な人物が多いのだけど、いちいち会社に実際にいた人の名前が思い浮かぶ感じ。
だからこれも「ゲーム会社にいる人としては、大体あっている」という認識。
机の下で寝袋で寝てる人はいたし、机がおもちゃだらけの人もいた。
天才肌で、自分と同じようにできない人を見下す態度の人もいた。
僕が知っているのは全部プログラマーだけども。
長男の宿題の都合もあって、12話を1週間で見なくてはならなかった。
で、わからないと質問された部分とか、ここはゲーム関連の仕事として掘り下げて説明したほうがいいな、と思った部分とか、1話見終わるごとに説明を加えた。
長男の課題では、将来の職業を漠然と書くのではなく、それがどういった仕事なのかも細かく掘り下げないといけないらしい。
ゲーム会社の仕事の内容を大体理解した長男は、そうしたことを説明したうえで、自分はプログラマーになりたいと作文した。
そしたら、先生から「プログラマーの仕事」についてもう少し掘り下げるように、という指摘が入った。
それで、長男にまたインタビューされる。プログラマーの仕事を一言で表すと、どういうこと？
「コンピューターに作業の手順を教える仕事、かな」
…と答えたのだけど、しばらく後に、この答えは間違えていると思ったので、訂正した。
コンピューターに作業の手順を教えるのは、プログラマーではなく、コーダーの仕事だ。
「コンピューターの作業手順を考える仕事」
これがプログラマーの仕事。「教える」のではなく「考える」ことが大切。
そして、プログラマーが考えた作業手順を、コンピューターに教えるのがコーダーの仕事。
だけど、これは非常に古い仕事の区分で、現在ではコーダーの仕事もプログラマーの仕事の一部になっている。
「教える」のか「考える」のか。この違いは、プログラマーとして非常に大切だ。
そして、この違いを理解できないといろいろな勘違いが起きる。
数年後、日本ではプログラム教育が必修化される。
ここでの目的は、子供たちに「考える」力を養わさせることだ。
しかし、プログラムを「教える」ことだと思っている人たちが、勘違いしている発言を度々見かける。
Ｃか Python か Scratch か、なんてどうでもいい。それはコーダーの技術だ。
学校で教えたいのは、処理手順を「考える」ことで、それこそがプログラムの本質だ。
先日「コピペプログラマー」の話を書いた。
こちらは、プログラマーだと呼ばれてしまうから違和感があるだけで、コーダーだと思えば何の問題もない。
処理を考えることはできないけど、教える技術はちゃんと持っている。
だから、どこかにあるコード断片を拾ってきて、正しく改造して、目的通りのものを作り上げられる。
「考える」ことは出来なくても「教える」ことができるのだから、コーダーと考えればしっくりくる。
長男からは、ゲームプログラマーをしていて、何が一番うれしかったか、という質問ももらった。
「笑顔が見たい」からゲームを作っていた、と答えた。
どんな仕事でも、最終的にはお客さんの笑顔を見たくてやっているのではないかな。
でも、これ実は微妙な話だ。
大学の頃は、大学祭にゲームを出品して、お客さんの反応を見ることができた。
それがうれしくて仕事にしたのだけど、仕事だとお客さんから直接の反応をもらうことは難しくなった。
それでも、ゲームセンターで自分が作ったゲームを遠巻きに観察していたり、ゲーム雑誌の読者投稿で自分の作ったゲームのことを触れてくれる人がいたりすると嬉しかった。
今だって、ネットで昔作ったゲームのことが書かれているのを見つけると、嬉しくなる。
それがたとえ悪口でも構わない。本当に嫌いなら、わざわざ労力を割いて話題にしないだろうから。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はロバート・ウィリアム・バーマーの誕生日(1920)
愛称は「ボブ」。Robert は一般に Bob になります。
＃Rob なのだけど、R の音は発音しにくいので、変化させて B になる。
さて、ボブは ASCII の父として知られています。
以前、世界で最初に { } （弓括弧）を使えたマシンは何だろう、という疑問を調べたことがありあす。
今は、非常に多くのコンピューター言語が、{ } を使います。
これらの最初は BCPL という言語だ、ということになっています。
だけど、昔のマシンでは { } は使えませんでした。
BCPL は { } を使ったというけど、その時代のマシンでなぜ { } が使えたのか？ という謎を追ったのでした。
実は、この過程で昔のコンピューターで使える文字セットに興味を持ち、言語との関係や変遷をまとめたのだけど、まだ記事にしていません。
いつか記事にしたいのだけど、タイプライターと文字セットと言語と…と、密接な話題が入り組んで整理しにくいの。
それはさておき、昔のコンピューターにはタイプライターが接続されていました。
そして、タイプライターは活字を持たなくてはならない都合上、それほど多くの文字を扱えませんでした。
これらのタイプライターは「テレタイプ」と言って、操作を紙テープに残せました。
このため、「文字コード」も持っているのですが、各社でバラバラ…いや、場合によっては同じ会社でも互換性がありません。
そこで、統一コードが作られます。これが ASCII です。
当時のタイプライターの紙テープは、5～6bit 記録でした。
しかし ASCII は 7bit として制定され、今までよりも多くの文字を使えるようになったのです。
そして、ボブ・バーマーは ASCII の定義委員の一人でした。
彼は { } や ＼ （バックスラッシュ）、制御コードとしての「ESC」など、多数の文字を入れるよう提案を行っています。
これらの文字は、単に「入れたいから入れよう」というような話ではなく、よく考えて決められています。
当時は、ALGOL が「最良の言語」でした。そして、 ALGOL では、論理演算に ∧ ∨ という数学記号を使います。
だから「それらの文字を入れるべきだ」という意見も出ていました。
しかし、ボブは、すでに入っている / （スラッシュ）に ＼ を組み合わせれば、論理演算記号を表現できる、と提案したのです。
一部の言語しか使わない文字ではなく、より普遍的に使える文字を入れる。
長く使われる「標準セット」には大切な考え方でした。
そして、ESC は特に重要な提案でした。
ASCII では、「文字コード」を定めようとしていましたが、それは各社のタイプライターの差がなくなってしまうことでもありました。
タイプライターメーカーとしては、新機能を搭載しづらい…業界の進歩が止まってしまうことになります。
ASCII を決定したとしても、いつか新機能を搭載したがったメーカーが「新しい文字コード」を使い始めるかもしれません。
それでは標準コードの役に立たないのです。
ESC は、この問題を解決する素晴らしいアイディアでした。
ESC 文字コードが送られてくると、タイプライタは、ASCII 文字コードから「ESCAPE」…脱出できます。
ESC に続いて送られてきたデータを自由に解釈し、タイプライターメーカー独自の機能を追加できるのです。
ビデオ端末が登場すると、この機能により自由な位置に「カーソル」を動かしたり、文字に色を付けたりできるようになりました。
これによって、初期のテレビゲームや、ワープロなど…「グラフィカルな」ソフトウェアが作られ始めます。
もし ESC が無かったら、端末は文字しか出せないままで、コンピューターの利用用途はずっと限られていたでしょう。
このことから、ボブは「ASCII の父」と呼ばれるのです。
彼は 2004年に亡くなっていますが、彼の作っていた WEB ページはそのまま保持されています。
そのページから、写真を引用させてもらいます。
彼の乗っていた車のナンバーは「ASCII」でした。
＃2018.10.15 追記
さすがにページが消えたようです。
webarchive に、2018.5.11 時点のアーカイブが残っていましたので、リンク先を変えました。
ナンバープレートも同様です。
ボブは、IBM 、ハネウェル、UNIVAC など、コンピューター黎明期の大メーカーを転々としながら働いています。
ASCII コードの定義委員をやっていたのも、IBM の代表の一人として。
IBM が FORTRAN (1956) を発表した後、ボブは彼自身のプログラム言語を考案しています。
FORTRAN は科学者向けの「数式 ( FORmula) を変換する (TRANslate) 」言語でした。
これに対し、仕事 (COMmercial) でつかえる言語、COMTRAN (1957) を作ったのです。
COMTRAN は普及しませんでしたが、これをベースとして COBOL (1959) が作成され、広く使われるようになりました。
この当時、メモリは貴重でした。
そのため、日付などを入れる際に、1957 年を 57 というように表記するのも当たり前でした。
しかし、これは良いやり方ではない、とボブは気づきました。
このままでは、上の桁が変化する 2000 年には、多くのソフトが誤動作するに違いない。
この指摘を行ったのは、1971 年でした。
2000年問題の危険性の指摘でしたが、当時としては「30年も先に、今作っているプログラムが使われているわけがない」と誰も相手にしなかったようです。
実際には、古いシステムは「誰も完全な動作を把握できていない」ために更新されることなく、使われ続けました。
そして、彼の指摘通り、1990年代後半に社会的な問題となるのです。
彼はこのときにも、2000年問題の対処を再び考えています。
すでにソースコードが失われ、実行バイナリしかないソフトに対してパッチを当て、「50以下は +100 してから比較することで、年の順序を間違えないようにする」というような解決方法でした。
…実際に、これで延命された古いシステムが多数あります。
2050 年に問題が起きるかもしれません。
＃さすがにそれまでにはシステムが更新されている…と思いたいが、彼が指摘した 30年後に、実際に 2000年問題は起きたのだ。
2050年も、あと 33年しかない。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |