プログラマで、生きている

　わたしがまだ新人プログラマだった頃、キックオフミーティングで渡された仕事の割り振り表のメンバーの欄に「X」と書かれていたことがありました。

　「Xって誰ですか？」と尋ねると「そのうち現れるであろう誰か」という答えが返ってきました。要するにエンジニアを確保するつもりはあるんだけど見つかっていないということです。「ホントに現れるのか？」とわたしは疑っていましたが「X」は現れました。

　ていうか、わたしでした。

　リーダーから「X」と命名（？）された先輩とわたしは2人でその担当分を片づけることに（もちろん本来の担当分も片づけた）。

　「結局見つからないんだったら、最初っからXなんて書かなければいいのに」とグチったら、一緒に担当分を増やされた先輩に「上の人間もぎりぎりまでがんばって探してたんだよ。いないものはいないんだから仕方ない。いる人間でがんばって片づけよう」と諭されました。

　その後、さまざまなプロジェクトを経て、いない人を「X」と書いたあのリーダーは正直者だったんだなあ、と思うようになりました（苦笑）。

　なんとかして頭数があっているようにみせかけますもんねえ、普通（←簡単にバレるけど）。

　それからさらに数年経って、その時点でのリーダーに「X」の話をしたところ、「そうやって頭数を合わせるのも大変だけど、結局のところ重要なのは仕事量を合わせることなんだよ」という話をしてくれました。

リーダー「開発能力は足し算じゃなく掛け算だ。1の仕事ができる人と0.5しか仕事ができない人を組ませると、普通に考えれば1＋0.5で1.5だけど、実際には1×0.5で0.5になるんだよ。それなら1の人が1人で仕事をした方がマシ。もしくは0.8が2人で0.64の方がまだ数字がいい」

わたし「でもそれだと、1未満の人は数字を減らすだけだから、いない方がいいってことになりませんか？」

リーダー「うん、そうなる。だから労力と金をかけて人を足すより、できないヤツを引く方がいいってこともある。でも、今は1未満でも育てて1以上にしとかないと将来的に苦しくなるから我慢して使うという判断もある。それでも苦しい時は仕事の割り振りを変えて、掛け算の枠からはずれるように仕向ける。1未満でも足し算にすれば数字はあがる」

わたし「それと、その計算だと1の人はどれだけ集めても1にしかなりませんけど」

リーダー「いわゆる力仕事的なプログラムは話が別だけど、そうじゃないものは1の人間がどれだけ集まっても1の仕事しかできない。おかしいと思うかもしれないけど、そういうもんだ」

わたし「じゃあ、1ってのは一人前って意味じゃないんですね。人の足をひっぱらないレベルということですか？」

リーダー「まあ、そんな感じ」

わたし「これまで、そういうことまったく考えたことなかったです」

リーダー「君はそんなことまったく考えなくていいから、もっと自分の数字をあげておれを楽にしてくれ！」

　要するに頭数「X」よりも、その人が持っている能力値の変数「x」の方が、リーダーとしては問題だということらしいです。

　仕事量を現す「人月」（＝頭数×月数）という言葉がありますが、そのリーダーの計算方法は「人人月」（＝能力値×能力値×月数）ということになりましょうか（←「能能月」という言い方もできるけどなんか音の響きがイマイチ）。

　人月計算は「頭数×能力の平均値×月数」な考え方なので、1の人が10人いて1カ月だと10になりますが、人人月計算方式でいくと1にしかなりません。これはものすごい差ですね。10の人が1人と1の人が9人で1カ月なら10になりますけど。

　チームでシステムを作っている限り、人と人の係わり合いが作業量に影響するというのは自然なことで、この「人人月」理論の方がなじみやすいというか、納得しやすいというか。

　評価する人間の考え方や、与えられる仕事内容で、数字はずいぶんと違ってくるでしょうし、そのリーダーだって厳密に部下を数値化しているわけじゃなくって、目安としてそういうとらえかたをしているだけだと思いますけど。

　そんなリーダーの話をきいてから、わたしは折に触れ、そのことについて考えるようになりました。

　わたしの「x」は今どれくらいなんだろうか。誰の「x」に助けてもらってるんだろうか。誰かの「x」を支えてあげられているんだろか。わたしはわたしの「x」をまだ上げることができるんだろうか。

　それを考えたからって何がどうなるものでもないと思いますが、なんだかちょっと気持ちが落ち着くというか客観的になれます。

　それに、誰かに「x」を補ってもらいながら、誰かを補う「x」を獲得していく。そうやってエンジニアたちの係わり合いはリレーされていくのだなあ、とか想像すると、なんか楽しい気分になったりしません？（←わたしだけかも）

　ところで、そんな話を聞かせてもらった当時は、「1の人間はどれだけ集まっても1」の理由がさっぱりわからなかったんですけど、仕事を続けているうちに、それっぽい現象に何度か遭遇しました。

　わたしが観察した印象では、推進力がないんですね。誰かが指示を出してあげればそこそこ仕事はできるんですけど、指示なしではどこに向かっていけばいいのかわからなくて、その場に立ち尽くしてしまう感じです。なるほど、その場に立ち尽くしてしまう人間が何人いても、やっぱりその場から動けないんだなあ、と納得してしまいました。

　でも、こういう場合はここに向かえばいい、というパターンをある程度、覚えれば、そういう子たちもいつかは自分から動きだすようになります。それがレベル1からの脱却ということなのかもしれません。

　エンジニアの頭数は有限、時間も有限（ていうか常にタイト）です。

　けれどプログラマとしての「x」は自力で増やせるのだから、青天井を目指してしまおう！　とか元気な時には思ったりします（苦笑）。そして、年で「x」が減った、と定年までは言いたくないなあ、と常に思っているのです。

　わたしは専門学校で FORTRAN を習って、就職してからも2年間くらいはずっと FORTRAN をやってました（たまに BASIC もやってましたけど）。

　で、FORTRAN の仕事がなくなってきたから、という理由で C 言語を勉強するように言われたんですが、これがかなり苦労しました。カチカチした FORTRAN になじんでいたわたしには、C がとてもアバウトというかフリーダムすぎる言語に思えたんです。

　なぜ = と == で意味が違う！ とか、なぜ *（アスタリスク）をこんなに使いまわしてる！ とか、なんかもう腹が立ってしかたありませんでした（苦笑）。なによりも頭を悩ませたのは、御多分に漏れずポインタでしたが。

　当時はパソコン1台を複数人数で使うのが普通でしたので、お金を稼げないわたしはほとんどマシンに触らせてもらえず、本を片手に、先輩から出されたお題に頭を悩ませ、「これでどーだっ！」と手書きのコードを見せては、「まだわかってない」と先輩に一蹴されて放置、という方式でC言語を勉強しました。

　間違っているコードでも、実際に動かしてみて、どういうふうに動いているかを確認できるのなら、どう間違っているのかもわかりやすいんですが、そんな要求は叶えられず、「あのパターンはダメだった。このパターンもダメだった。だとするとこうかっ？」という、トライ＆エラーというよりは当たって砕けろ的な教育でしたね。

　そんな状態の中、意地になってコードを書き続けていたら、ある日、1つの問題が解けた時に、「あれ？」と思いました。

　それまでまったくかみあわなかったたくさんの知識が、突然、1つにまとまって、どうしようもなく分からなかったことがするっと理解できるようになったということを、はっきりと自覚できたんですよ。

　なんだか、1つのピースが正しい場所にはめこまれた瞬間に、他のピースまできれいにならんじゃった感じでした。

　「そうか、そういうことだったのか」と思って、思わず「うわっ」って声に出しちゃいましたよ。

　「うわっ、うわっ、うわっ。今、何があったの？ 何したの？ 自分」みたいな。

　そしたら今度は、そんな単純なことを理解できなかった自分が、理解できなくなっちゃったりして（苦笑）。

　FORTRAN を覚えた時は、学んだところが学校だったこともあって、実にのんびりと習っていて、そんな電撃的なことなんてなにもなく、英語の授業のように単語と文法を黙々と覚えて、なんとなくコードが書けるようになりました。

　いちいち頭の中で、これはこういうことだからこう書くんだ、とそれこそ英語の試験の答案を書くような感じでいつもプログラムを考えていたんですね。　

　でも、C言語が「わかる」状態になってからは、ほとんど考えなくてもコードが書けるようになりました。日本語からC言語に翻訳していたものが、ダイレクトにC言語で考られるようになったイメージです。それ以降は、ロジックを考えることに集中できるようになったので、ものすごく楽になりました。

　ちなみに、C/C++やVisual Basicに関してはダイレクトですけど、JavaはC++をJavaに翻訳しているイメージだったりします。だから、いまだにJavaがへたです。

　といった話をIT業界とは無関係な友人にしたところ「言語爆発みたいなことかな？」と言われました。

　「えっ？ そんな言葉があるの？」

　「ネイティブでない言語を習得する時にそんな現象が発生するって、どっかできいたことがあるような……。あやふやだけど」

　「ああ、プログラミング言語も、一応は言語だもんね。同じような現象が発生しても不思議じゃないよね。それにしても爆発って表現がおもしろいなあ」

　「頭の中でビッグバンが発生する感じ？」

　「ああ、なにかがものすごい勢いで広がっていく感じはあった。うん」

とかいった会話で盛り上がりまして、ためしに「言語爆発」という言葉を調べてみたところ、断片的に単語を口にすることしかできなかった子供が、突然、猛烈な勢いで言葉をしゃべり始める時期が「言語爆発期」と呼ばれていることが分かりました。

　うまくしゃべれない子供でも、周囲の言葉はきちんとインプットされていて、それがある日、突然、アウトプットを始めるらしいんです。

　それを自分の経験に当てはめてみると、ものすごく似た現象であるように思えます。

　日本語を理解した時の自分なんて覚えていないけれど、もしかしたら、同じ経験をしていたのかもしれないなあ、と思うとニマニマしてしまいます。

　いろんな情報をひたすら詰め込んで、でもそれがうまくつながらなくって、一歩も進んでないように思えても、実は脳内では「言語爆発」の準備が着々とすすんでいたりするんですよ、きっと。

　そんなことを知って以来、わたしは「分からなくても分からなくても詰め込み続けろ！ そして考え続けろ！ いつか脳内で爆発が起きるから！」と自分に言い聞かせるようになりました。

　まあ、詰め込むものの選び方とか詰め込み方にはいろいろと工夫が必要だと思いますが。

　たまに周囲のプログラマにそういう体験があるか訊いてみたりするんですけど、「あるある！」って言ってくれる人は結構いますね。

　やっぱり普通に発生する現象なんだと思って安心する気持ちもありますし、そんな特別なことじゃないんだとがっかりする気持ちもあって、いろいろ微妙です（苦笑）。

　最初ほどのインパクトはないものの、その後も小規模な「爆発」を繰り返し、今の自分があります。ずっとずっとプログラミングを続けていったら、いつかとんでもない「爆発」が起きないかなあ、と思います。

　楽しみにしてるんですけどねえ。まだまだ詰め込みが足りないんですね。きっと。

　ところで、「言語爆発」という言葉の正確なところは、わたしはきちんと調べていません。わたしの解釈が正しいのかどうかもわからないので、ご興味のある方は独自に調べてみてください。ググって危険があるかどうかはわかりません（笑）。

　あけましておめでとうございます。

　旧年中は思いがけずたくさんの方にコラムを読んでいただき、とてもうれしく思っております。まことにありがとうございました。

　コメントもたくさんいただきまして、本当にありがとうございました。ことに年末にコラムニストの逆転仕事術さん（『エンジニアライフたまに見るならこんなコラム（女性エンジニア編』）と編集の金武さん（『座談会：「エンジニアライフ」をめぐるごきげんな日々』 ）がそろって、わたしのコラムの中で『プログラマなんかで終わりたい』が一番好き、とおっしゃってくださったことは、本当にうれしかったです。

　実を言いますと、当初わたしが書きたかったのは『プログラマなんかで終わりたい』だけでした。

　わたしが仕事関係でつきあってきた人たちの中に、プログラマに留まろうとしていた人なんて1人もいなくて、皆あたりまえのようにシステムエンジニアもしくはプロジェクトマネージャを目指すか、この業界を辞めていくかでした。プログラマからシステムエンジニアに「出世」するルートに乗れる機会が何度かあったにもかわらず、それを回避してきた自分はかなりのマイノリティであることは、重々承知しています。

　けれど、「ずっとプログラマなんてありえない」という扱いをされるのはどうしても納得がいきませんでした。
さまざまな状況や希望をもとに考えた結果、選択肢からはずされるのならともかく、そんな選択肢は存在しない、と思われるのはイヤだったんです。

　そんなわけで、主流からはずれてるけどとりあえず安定した生活はできてるよ、ということをどうしても書きたくなったのでした。

　「プログラマで、生きている」なんて大仰なコラム名をつけたのも、ちょっとでもプログラマの方々の関心を惹こうと考えた結果でした。今になってみるとなんか恥ずかしいんですけど、この看板（苦笑）。

　この年までプログラマをやってきて、今のIT業界の中でプログラマを続けるのは大変だということは、身にしみて分かっているつもりです。

　この業界で生き延びたいだけなら、お勧めできないルートであることは、まず間違いありません。

　流れに逆らってその場から動かないというのは難儀なことですよ、ホントに。

　ですから、「みんな！ ずっとプログラマでいる方が楽しいよ！」などと言う気はまったくなくって、後輩が「ずっとプログラマでいようと思うんです」とか言い出したら「よく考えてみた方がいい」と引きとめるようなことを、一度くらいは言ってあげないといけないと思っています（←でもそんなこと言い出した後輩は1人もいない）。

　それでも、「プログラマ止まりのルートはある！」と、わたしはどうしても言いたかったんです。

　当該コラムなどにさまざまなコメントをいただきまして、いろいろと考えることはあったんですが、今のところ「プログラマなんかで終わりたい」という気持ちに変わりはありません。

　プログラマとシステムエンジニアの仕事をわけること自体がおかしい、というご意見もありますが、それをできる能力がある人ならそれでもいいと思うんですけど、両立はかなり困難な気がします。

　プログラマがフォローすべき知識は年々増えていきます。言語や開発ツールの類も新しいものがどんどん出てきます。

　既存システムもそう簡単には捨てられないので、増えていく知識ばかりを追いかけていくわけにもいきません。

　システムエンジニア的な仕事（マネージメント、コンサルティング、システム設計etc.）とプログラマ的な仕事（プログラム設計、コーディングetc.）を高水準で両立させることができるのは、かなり優秀な方に限られるんじゃないんでしょうか。

　定年までプログラマとして置いてくれることを約束してくれる職場なんてめったにない。生活もかかってるんだし、そんなリスキーなルートをわざわざ選ぶなんてできない、というご意見もあるようです。

　これに関しては反論できないですね（苦笑）。わたしだって、今の会社がつぶれたら次に拾ってくれるとこあるのかなあ、と不安になることもあります。それでも「あの時、素直にシステムエンジニアになってればよかったのかなあ」と思ったことは一度もありません。なんでだか、「それでもなんとかなる。プログラマのままで食べていける」という根拠のない自信がいつも湧いてでてくるんですよ。なんなんでしょうね、この人（笑）。

　とりあえず、うちの会社をつぶさないことが今のところ最も確実なリスクヘッジだと思うので、全力を挙げてうちの会社を守っていきたいと思います（新年早々、不吉なことばっかり言ってすみません、社長）。

　繰り返し言いますけど、今のIT業界ではプログラマからシステムエンジニアになることが主流です。けれど、今、「プログラマ止まり」が流れに逆らう存在であっても、これから業界構造が変わって主流のひとつになる可能性だってあるとは思いませんか？

　流れは変わるものです。

　ていうか、変えるための1滴になりたくて、このコラムを書いているような気がしてきました。

　ところで、『プログラマなんかで終わりたい』だけが書きたかった、と言ったんですが、もうちょっと書きたいことがあるんで、しばらくはこちらに居座らせてもらうつもりです。よろしければこれからもおつきあいください。

　わたしはプログラマ歴は長いんですけど、SQL歴は短いです。

　別に避けていたわけではなく、データベース（以降DBと略）を扱うプロジェクトに放り込まれたことがほとんどありませんでした。DBを扱うシステムに関わった時も、そこにはDBのマイスターと呼ばれる方々がいらっしゃって、全部をお膳立てしてくださっていたので、本を読んで文法を覚えただけの状態でもなんとかなっちゃったものだから、それ以上のことを追求する気がおきなかったんですね。

　一度、SQL Server 2000のインストール、テーブル設計、SQLおよびJavaのコーディングをすべて1人きりでやる機会があったんですが、その時は速度性能をまったく要求されなかったので（←動く様子がわかる程度のものを短期間で作ってくれ、というオーダーだった）、これまた本を読んだだけの知識でなんとか乗り切れてしまいました。

　とにかくわたしはSQLにまったく興味がありませんでした。好き嫌いの問題ではなく、関心がゼロ、という状態です。

　SQLはDBの専門家が扱うもの、というイメージがあったので、そこは管轄外という思い込みもありました。わたしがDBが関係するシステムに携わるときにはいつもチームに専門家がいたので、そういう方々がいなくてC++やJavaを書いてるプログラマがDBの面倒までみるという状況はめったにないものだと思っていたんですよ。

　本当に「常識」ってコワい……。

　そんな状態でIT業界を渡ってきちゃったわたしなんですが、今の会社に入った途端にSQLが必要な仕事を任せられてしまいました。

　しかも、そういったものが業務の中心になっているらしい。

　これは今のSQLのスキルレベルでは乗り切れないような気がする、と思ってとりあえずどんな感じのものが動いているのかを確認するために、わたしの権限で見られる範囲のDBに入っていたストアドプロシージャとビューをすべて読みました。多分100本以上ありました。

　実をいうと、実際に運用されているSQLを読んだのは初めての経験でした（本当に縁が薄かったんだなあ）。

　大量のSQLを読んだ後の率直な感想は、「SQLってこんなに自由な言語だったのか！」でした。

　なぜだかSQLをずいぶんと窮屈な言語だと思っていたんですが、それはわたしの認識不足でした。SQLは創意工夫をいくらでも詰め込めむことができる言語だったんですよ。「そうか、SQLもプログラミング言語だったんだ」とか大ボケなことを思ったりして（苦笑）。

　で、最初は流し読みだったんですけど、この人はプログラマとしてちゃんとしている、と思った人の署名が入ったストアドプロシージャをじっくり読み直してみることにしました。すると、たまに不自然に遠回りしている感じがするコードに出合うんです。

　試しに、同じ結果を出すんならわたしはこう書く、というサンプルを書いてみて、速度を計ってみると、元のコードの方が全然はやかったりするわけです。へたすると10倍くらい差がでます。愕然です。

　じゃあこう組んだらどうなるの？ といろいろといじくりまわして、元のコードよりも早いタイムをたたき出した時は感動でした。「エウレカ～！」と叫びたかったくらいです（さすがにやりませんよ！）。

　そんなタイムトライアルを繰り返している時に、このSQLをC++にコンバートするとしたらどう書くだろう、と思いついてちょっと頭の中で書いてみたんですけど、これがものすごく長くなっちゃったわけです。

　こんなに長い処理がこんなにすっきりしたコードで表現されてるのかっ！ おもしろいっ！ めっちゃおもしろいじゃないか、SQL！！

　そんなわけで40にしてSQLのおもしろさに目覚めました（←いろいろと遅すぎるからっ）。

　おもわず「SQLさん、ごめんなさい」（←なぜかさん付け）と思いましたね。

　「きみがこんなにステキに楽しい言語だなんて気づきもせずに、遠くから眺めてただけだったなんて、本当に悪かったよ～」（←だいぶイタイ人だと思われそうだ）。

　ちなみに、その後、ネットで調べてみたらチューンナップの情報があちこちに大量に転がっていて、むきになってトライアルを繰り返す必要はなかったことが判明しました（←先にググろうよ、自分）。まあ、楽しかったからいいんですけどね。

　以前のわたしのように、SQLが縁遠くって遠巻きにながめている方には、SQLで遊ぶことをおすすめしたいです。

　いい思考トレーニングになると思いますよ。SQLはデータとデータをつなげるという情報処理の基本機能を、ダイレクトにみせてくれる言語ですから。

　で、何が言いたかったのかというと、生島さんとこの記事とコメント欄のO/Rマッパーを積極利用すべきか否かというおはなしを読ませていただいて、「SQLを書くのはめっちゃ楽しいから、O/Rマッパーには譲りたくないなあ」と思った、ということなんでした（いろいろとためになることがたくさん書いてあったはずなのに、こんなしょぼい感想しか出てこなかった）。

　だいぶ前の話になりますけど、「新人にデータ移行ツールのコーディングを任せるので、面倒をみてやってくれ」と頼まれたことがありました。

　その新人はやたらとGoogle検索に頼る人で、とにかくわからないことがあると、わたしに聞かずにGoogle先生に尋ねるんですね。

　検索サイトにはわたしもかなりお世話になっていますし、昔に比べるととても使い勝手がよくなっていますけれど、その人の技術レベルに対応して検索結果を出してくれるほど高機能なわけではありません。

　そのため新人の書いてくるコードは、つぎはぎというかちぐはぐというか、身についてない知識に振り回されてる感が満載でした。

　そういう弊害を気にしつつも、自分で調べようとする気持ちは尊重するべきなのかなあ、と思ってとりあえず黙認していたんですが、あるとき「ちょっと考えが甘かった」と思い知らされるトラブルが発生しました。

　その新人が「Windowsのレジストリがよく分からない」といってきたのです。

　作製中のプログラムにレジストリ操作なんてまったく必要ありません。というか、ヘタにレジストリをいじられたら困ります。

わたし：「なんでそれを聞くの？」

新人：「必要だからです」

わたし：「なんで必要なの？」

新人：「パラメータはコンフィグファイルに記述って仕様に書いてありました」

わたし：「それがどうしてレジストリにつながるの？」

新人：「コンフィグファイルを検索してたらレジストリというのが出てきて、それを理解できないとコンフィグファイルの操作方法が分からないのかと思って……」

　普通、「パラメータはコンフィグファイルに記述」という仕様を「パラメータをWindowsのレジストリに書き込む」とは解釈しません。

　けれど、Google検索はそれを結びつけてしまいました。Googleはちっとも悪くないんですが……。

　聞いてみたところ、新人はレジストリについて、半日悩んでいたそうです。

　「もっと早くに聞きにこようよ」というと、「仕事をしてたんでジャマしちゃ悪いかと思って」といわれました。勤務時間内だから仕事してるのがあたりまえだと思うんだが……。プログラミングを教えるのもわたしの仕事のうちなんだが……。

　とりあえず、コンフィグファイルについて説明した後で、「今度からもっとはやめに聞きにくるように。それと、調べものはできるだけ本でやるように」と指示を出したわけなんですが、その新人のやってることがどうにも納得いきません。

　そこで、「新幹線で仙台まで行け、と東京駅から送り出したら、先に東海道新幹線が来た、というだけの理由で大阪に向かっちゃってる感じなんですよ。この場合、普通の電車に乗って仙台に向かう方がまだ正解ですよね。なんで大阪に行っちゃうんだと思います？」

と同僚に聞いたところ、「そのたとえはどうなんだろ」と前置きしつつも、

　「自分が西に向かってることにも気づいてないんじゃないかな」という答えが返ってきました。

　自分が北に向かっているのか西に向かっているのかも分かっていない。なるほど、そんな簡単なことに気づきませんでした。我ながらにぶいです。

　自分で調べようとする気持ちは大事にするべきだと思いますけど、こんなに遠回りばかりされていてはしゃれになりません。

　独学で勉強をしているのなら、どれだけ大回りしてもいつかたどりつければいい、寄り道もムダにはならない、といってあげられますが、仕事でやっているかぎりは、少しでも効率的に覚える義務が発生します。遠回りをしている時間分、ちゃんと給料をもらっているんだということを自覚してもらわなければ困ります。そうやって1人で悩んでいる時間分だけ納期が遠ざかってくれるわけでもありませんし。

　というわけで新人に「ググるの禁止！」令を出しました。

　参考にしていいのは渡した本だけ。本の記述だけでは不足な場合は、わたしが検索して適切と判断したページのURLを教えることにしました。そして、「30分悩んでもわからなかった場合はわたしに聞きにくること！」といい渡しました。

　と、そこまで分かりやすくルールを示せば、聞きにきてくれるようになるんじゃないかと思ってたんですが、その人はやっぱりググることも、長時間1人で悩むこともやめませんでした。

　「困ってます～」的なジェスチャーは見せるんですが、聞きにこないんですよ。

　最初のうちこそ、「どんな感じ？」と聞きにいってたんですが、なんでわたしが御用伺いをしなくちゃいけないんだろ、と思いなおして、自発的に聞きにくるまで待ってたら、やっぱり半日くらい悩まないと質問にきてくれません。

　そんなにわたしに聞くのがイヤか～！

　検索はわたしの見てないところでやるようにしてたみたいですけど、上がってくるコードをみればあからさまに分かっちゃうのでだいなしでした（苦笑）。

　他人のコードのコピーで急場をしのごうとする新人は、以前にもいました。

　「どうしてもバグがとれないので見ていただけませんか」といわれてコードを読んだら、標準ライブラリ関数がありえない使い方をされていたので、「この関数がどういうことをやるかわかってる？」と聞いたら「わかりません」とものすごく正直に答えてくれました。

　頭を抱えつつ「どうして何をするのかも分からない関数が湧いて出てきたのよ」といったら、「先輩のコードを見てたらこれを使ってて、なんか使えそうな気がしたから」という摩訶不思議な答えが返ってきたので、おもわず「情報処理技術者の情報を処理するっていうのは、テキストをコピペすることじゃなーい！」と怒鳴って、新人をビビらせたなんてこともありました（苦笑）。

　とまあ、理解できてないコードを拝借しちゃう新人は以前からいたんですけど、検索サイトのおかげでそれが増殖したというか、当たり前になったというか。

　検索サイトで調べ物をするのは悪いことではありませんし、他人のコードをコピーすることを問題視しているわけではありません（著作権を侵害しない場合に限りますが）。皆、最初は模倣から始まります。

　検索したサイトで手に入れた情報を、自分の中で適切に消化して糧にできるのなら、それはとても良いことです。

　けれど、ネットの海を漂流してそこにプカプカ浮かんでいるものをすくっているだけなら、それはただのネットサーフィンです。そんなことは勤務時間外に好きなだけやりましょうよ（寝不足にならない程度に）。

　わたしが新人が検索に頼ってしまうことを危険視するのは、コピペの寄せ集めでもなんとなく動くコードが書けちゃって、それで自分は仕事を達成したという錯覚に陥ってしまうからです。

　たいていの場合、新人プログラマには「きちんとしたコードを書くこと」は期待していません。先輩たちが期待しているのは「きちんとしたコードを書ける人になってくれること」です。

　そこらへんの意識が行き違っちゃってるから、仙台に行くことよりも、新幹線に乗ることの方が重要事項になっちゃうんですかねえ。

　最後に、わたしが新人の時に先輩から言われた言葉をご紹介させていただきます。

　「自分で説明できないコードを1行たりとも書くな！」

　間違うのはしかたありません。けれども、「自分はこう考えたからこう書いた」と説明できないコードを書いてはいけません。

　1行たりとも！