Twitter で「コピペで済ますプログラマ」という話題を見かけました。
プログラムが書けないプログラマ、でもあります。
冗談みたいだけど、本当にそういう人はいます。
本とかネットとか、いろんな場所で「例示」されたプログラムを持ってきて、組み合わせて目的のものを作り上げてしまうのね。
昔から「読み書き算盤」と言われます。まず読めないとどうしようもないけど、「書く」というのは読むことの延長ではなく、違うレベル。
プログラムも同じで、「読める」…意味が分かることと自分で書けることは違います。
コピペプログラマは、読めるから組み合わせることもできるけど、書けないのです。
とはいえ、それがダメだというのではない。
最初は意味も分からず写経するのが大切だし、意味が分かってきたら真似して作ることが大切。
でも、その段階でプロになってしまうと、ちょっと問題が出てきます。
「業界記」として書いている一連のシリーズでは、あまりネガティブなことは書かないようにしています。
でも、今回はこうした話を書いてみます。
プログラム課としてはかなり年長の「ベテラン社員」がいました。
一度一緒に仕事をしたこともあります。年長なので、その時のメインプログラマでした。…肩書上は。
でも、実際にはコピペプログラマ。自分では書けず、過去のプログラムの切り張りでプログラムを作ります。
ゲーム作成って「そのゲーム独特の」処理も多いのね。コピペでは済まない。
そうした部分は、部下のプログラマに任せます。
メインプログラマは全体を統括するのが仕事で、実際のプログラムは他の人に任せてもいい。
ここでは、実際にほとんどを組んだ人を「事実上のメインプログラマ」と呼びましょう。
この、事実上のメインプログラマが作っていて、どう処理してよいかわからない部分がありました。
ハードウェアに密接に関係するパラメーターを決定しないといけない部分で、仕様書を繰り返し読んでもどのようなパラメーターが求められているかわからないのね。
ある程度の試行錯誤が必要でした。
しかし、事実上のメインが試行錯誤を始めてしまうと、進捗が止まってしまいます。
そこで、「肩書上のメインプログラマ」がその部分を担当しました。
ベテラン社員で顔が利きますから、他の部署に行って必要な処理をしている他のプログラムを見つけ出し、該当部分をもらってきます。
あとは、プログラムの流れを見て該当処理をしていると思われる部分を、丸ごとコピペ。
そのままでは動かなかったので、変数の形式などを試行錯誤しながら「それらしく」合わせます。
これで完成。
プログラムの内容は理解していないので、本当に正しいのかわかりません。
でも、必要としている変数の値の範囲では「それらしく」動いているのだからいいんじゃないかな。
「事実上のメインプログラマ」が、後学のために処理の内容など尋ねたのですが、「切り張りしただけだからわかんねぇ」とのこと。
何やってるのかわからないで、よくちゃんと動くプログラム作れますね…と、変な感心をしていました。
この人と同期の、また別の人の話。
同期なので当然ベテラン社員なのだけど、一応自分でプログラムはできました。
でも、ちょっと論理性が怪しい。
「読み書き算盤」でいえば、算盤の部分ができていない感じ。
その人が、ST-V の導入初期に「３Ｄプログラムの勉強会をしよう」と提案しました。
ST-V は３Ｄを扱えるハードだったけど、３Ｄ経験者はまだあまりいませんでした。
そこで、３Ｄの基礎概念くらいは全員が知っている必要がある、と考えたようです。
ここら辺は、ベテランらしい面倒見のよい部分です。
特に反対など出るわけもなく、会議室で第1回の勉強会が行われました。
ここでは「ゲームを作る上での」概念が大切。
だから、回転行列とかを教えるのではない。そんなものはライブラリを使えば済む話。
２Ｄなら表示したい座標を指定すればよかったけど、３Ｄだとカメラ座標とキャラクタ座標があって～ とかそういう話。
話がキャラクターの動きになった時、「回転はＸ、Ｙ、Ｚの軸を中心に行われるけど、どの順番で回しても一緒」と先輩社員。
え、それ違いますよ。回転順序は重要、と僕が指摘したのですが、「お前、３Ｄわかってないなぁ。あとで説明してやるから席に来い」と言われます。
で、一通りの説明終了後に、先輩が実際の動きを実演してみせるというので、興味のある人は先輩の席の周りに集まります。
まず、「回転順序は関係ない」ことが実演されます。
３Ｄのモデリングソフトを起動し、回転を実演します。
Ｘ軸を回してからＹ軸を回せばこういう形で、Ｙ軸を回してからＸ軸を回しても同じ形に…なりません。
焦って何度か同じ操作を繰り返す先輩社員。でも、同じになるわけないです。３Ｄでは回転順序は重要ですから。
本当は他にもいろいろ実演しながら説明する予定だったのだけど、なんとなくここで会がお開きになってしまいました。
勉強会も、続けてやる予定だった２回目は行われませんでした。
だって、みんなの前で「教える」と息巻いていた人が、基本部分すら理解していないとわかってしまったのだから。
みんなの前で誤りを指摘して恥をかかせた形になってしまったので、この先輩社員には後まで恨まれていたような気がします。
セガは大手会社だったから、プログラマーの技術力も高かったんでしょう？
と人に言われることがあります。
でも、ここに例を挙げたように、そんなことはありません。
初歩的なことでもできない人は結構多かった。
「技術力」は個人のものなので、大手だからと言って高いことはない。
でも、大手だと「層」の厚さはありました。多くの個性が集まっているのね。
コピペしかできなくても、顔が広くて必要なプログラムを確実に見つけてくる、というのも大切な個性。
３Ｄ勉強会を開いた人だって、３Ｄは理解していなかったけど、２Ｄゲームでは有名なものを何本も手掛けた方です。
もっと大切だったのは、プログラマー以外の「テストプレイ要員」が豊富にいたことのように思います。
中小企業だと、余計な人員を雇う余裕はないので、全員がゲームの作成にかかわっていて「デバッグプレイ」まで手が回らないことも多いのです。
でも、人員に余裕があれば、ひたすら遊んでバグを出すこともできる。
バグっていうのは見つからないと除去できないもので、見つけ出すことが何よりも大切です。
結局、個人の技術力は高くなくても、大手の総合力で「製品につぎ込まれた技術力」は高く見えるのね。
まぁ、人数が多いと平均値から離れている人も出てくるわけで、とてつもなく高い技術力の人もいましたけどね。
そちらの話は、またそのうち書く機会もあると思います。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |