こんばんは。組長です。

ひでみさんの例え、すごく分かります。IT業界だけでなく、他業種の友達からも似たような趣旨の愚痴を聞くことがありますし、逆に自分も後輩について頭を抱えたくなることもあります。

>「自分が西に向かってることにも気づいてないんじゃないかな」
残念ながら状況はもっとひどく、「気づいてない」というよりも、「考えてない」と言いたくなるような感じがします。まぁ、個人差はありますが。

何て言うか・・・、とにかく受け身なんですね。新人さんご自身も、指導される先輩方もどちらも大変だなぁ・・・と思います。

ひでみさん、こんばんは。

新人さんとのやりとりが実にリアルで、読んでいてニヤリとしてしまいました。私も全く同じ会話がありました（笑）

自分が社会人４～５年目だった頃は、色々なことが解らなかった自分をベースにして教育ができたんですよね。解らなさ加減と申しますか、その時期の悩みを共有しつつイイ感じで指導ができていました。

ところがある時期を境にして『もう、自分の時と比べてはいけないんだな・・・』と考えるようになっていました。なんと申しますが、未知の生物に思えてくる瞬間があります（笑）

できれば自社の中間層に間に入ってもらい、年代の差を埋めるべく教育を任せたいのですけどね。その教育担当が迷った際は私を頼ってくれるような組織が理想なんですけど、漏れなく弊社も中間層が不足しています。

新人教育は大変ですよね。しかも私の場合、経験の浅い人と私がセットで派遣されることが多いため、常駐先で教育を行う事もあります。説教は影でコッソリしつつ、誉める時は皆の前で。モチベーションを失わせないよう気も遣います。

年代の近い後輩だとヒントを与えるだけでモリモリやってくれるのですが、今はなかなか難しいですね（人によりますが）。ヒントをヒントとして受け取ってもらえないことも多いです（笑）それでも仕事は進めなければならないので、自分がやってしまうこともしばしばです。

仕事の厳しさを教えようとするとヘコんでしまう人もいますし、解らないなら訊いてくれと言うと、余り調べないで訊いてくる。教えすぎると甘えてくるし、誉めると調子に乗っちゃうし（笑）

人間相手のことなので、本当に難しいですね・・・

結局は一日の中で何段階かマイルストーンを設定して進捗を確認するしかないんですよね。こちらは出来ると思って作業を振ってるので、出来なかった時の理由を本人の口から言わせることが大切でしょうか。

近道はないですよねぇ。まぁ弊社の採用率が限りなく１００％近いことにも問題がありそうですけど（笑）

ちなみに私の殺し文句は
『今は頭の中に”点”が散在しているかもしれない、でも点と点が線で繋がる時が必ず来る』
でした。

・・・もっと具体的な指導をしたかったと反省しています（笑）

ひでみさん、初めましてこんばんは。

仕事の合間で休憩がてら、
RSSリーダーで何かおもしろい記事ないかな～？ と眺めていたら、
タイトルを見て
　「え？ どういうこと!?」
と興味を引かれ、内容にとてもインパクトがあったのでレスさせて頂きました。
（実は投稿すること自体、これが初めてでドキドキ...）

自分にはちょりぽんさんがおっしゃっているような、

>解らないなら訊いてくれと言うと、余り調べないで訊いてくる。
>教えすぎると甘えてくるし、誉めると調子に乗っちゃうし（笑）

というドンピシャな後輩が何人かいるんです(笑)
年齢はみんな１つ下でほとんど変わらないのに、
「どうして自分で何も調べもしないですぐ聞いてくるんだろう？」
とイライラしてしまうときも少なくないです。

なので、少し前から
「まず自分でネットとか資料で調べてみた？ 調べて何か分かった？
　それでも解決できなさそうなら質問しに来てね」
と（自分の中では）ちょっと厳しめに接するようにして、
自分でググる癖をつけてもらおうと試みているところです。

そういった折りにひでみさんの投稿を拝見して、
逆に何も聞いてこないほど自分で調べすぎるようなこういう人も
いるんだ!? とビックリしました。

自分の周囲の後輩環境からはまったく想像できませんが(笑)

それでも後輩に質問されると、「頼られてる感」があって
ほっとけなくてヒントを教えたり
一緒に解決してあげたりしちゃうんです...

「人を教えて育てる」ということはすごく難しいですね。
アメとムチというのか、つかず離れずというのか、
この加減具合がなかなかつかめないです...

はじめまして。いつも拝見しています。
私自身もそうなんですけど、新人は大きく2回成長すると思っています。大失敗をしたときと、後輩がついたとき。
我々は後輩に指導しているんじゃなくて、そのまた後輩への指導の仕方を教えているんだろうなと思ったりします。誰かの受け売りのような気もしますけど。。。

こんにちは。

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

やはりこの部分に危険を感じてます。
動いてるけど、なぜ動いているかは判らない。
こんな新人さんが増えてますね。

はじまして。

基本を身につける前の新人の教育は難しいですね。
技術的なスキルが低くても、コミュニケーションスキルがあれば成長できるのですけど。人と話すのが苦手な方っていますよね。

自己流コーディングの中堅も困ったもんですけど...

電気設計や機械設計なら、設計が悪ければ動作しないんですけど、プログラムって、どんなコードでも「動いてしまう」ので、たちが悪いと思います。

はじめまして、いつも見てます！

フレームワークとか使うとなかなか理解できずにやらなければならない時もありますが、自分のかくソースを理解しないで使っちゃうってのはよくないですねｗ

でも僕は新人に、解らなければまずググれと教えてたりします。

「教えてもらってないからできない」
という考えをもった新人が多いような気がするからです。。

目的をしっかり見つめさせて、３０分悩んだら必ず相談にくること
ということを守らせて必ず半日に一回中間地点で報告させる。
という方法とれば結果的に＋だと思いますよ。

ググるのも一つのスキルですよ！
ほんと情報収集できない人もいますから・・

ベテランの人でもやったことないこと（フレームワーク等）については、
情報収集（ぐぐり）もしないで文句いってる人間も多いですからね・・

広い意味での開発環境が整ってきた事に関する弊害だと感じました。
私の時はすでにVB6時代でしたので、そういった得体のしれない仕組みに振り回されることに危機感を感じ、アセンブリ世代に敬意を持ちつつ、OSの実装までどんどん低レイヤを学習したものですが、ひでみさんの記事を拝見するに今時の新人は「未知なるコード」という事自体を意識していないようですね・・・
こういった事がこれ以上進むと、技術が分からない技術者が大量発生し、IT業界に対する不信につながるでしょう。
なんとも恐ろしい事です。
それにしても、学校はソフトウェア工学などの基礎知識も教えていないのかな？
そういえば、まつもとゆきひろ氏が「ソフトウェア工学を嘗めるな」と言っていた気がします。

途中まで読みましたが、なんだか・・・
「レジストリ」の件を読んで、気持ちが悪くなりました。

あなたは自分が豊富な知識を持っていることを自慢したいだけなんですね。
後輩の方もそのあたりはすでに理解しているようで、貴方に聞かないんでしょう。

あなたの文章は、自分の知識の豊富さを誇示することと、
経験の少ない、知識の無い者を愚弄しているだけの
自己満足作文です。

まぁプログラミングに限らず、生活や仕事や勉学において、ありとあらゆる情報が簡単に手に入り、あらゆる「正解」に（あたかも）ダイレクトに簡単に即座に、たどり着けるようになりましたね。
Google、Wikipedia、などなど、いやあ便利になったもんです。
目的地を入力するだけで、あとはナビにおまかせで、遠回りすることなくゴールできますね。
1本むこうの道に美味しいラーメン屋があることにも、どの町を通過したのかも、海が近いことにも気づくことなく、新しい発見も苦労もしない。
まさしく「西に向かっている」ことを意識するのではなくナビが教えてくれる「手順」である新幹線のほうが重要で、方角や位置関係や新幹線に乗る理由はどうだっていい。

なのでその分、最初の入力を間違えたり適切なレスでなかったり理解が不十分だと、もう止めどなくメチャクチャに、そして対応もできず最終的にお手上げになってしまうのかも。

ベタな言い方ですが、やはりプロセスは大事なんでしょうね。
「自分で調べようとする気持ちは大事にするべき」と書かれていますが、ただ、もし「ググって楽をしようとしてる」のなら、つまり正解だけ手っ取り早く得ようとすればググるのが楽ですが、プロセスや理解の部分がそっくり抜けているので、本当は正解じゃなくても判断できないのではないでしょうか。
犬小屋を作ろうとして、「かなづちの持ち方」をマスターする前に「五重塔の作り方」を見つけたのでコピペして作業開始するような。どうしてこんな巨大な柱が必要なのか考える前に、「杉木材の販売店」をググって…

初めまして。こちらiGoogleに登録しているので、いつもタイトルチェックをして興味があると読ませて頂いております。今回もタイトルで「え、グーグル先生が駄目なのか！？」と結構グーグル先生にお世話になっているので気になって読ませて頂きました。こういう話は結構昔からありますが、原点はグーグル先生ではなく「自分で説明できないコードを書いている」事が問題なのだと思います。調べ方があざといというか、ずるいのかなと。自ら調査する姿勢は評価するべきとありますが、これは調査しているのではなく、カンニングしているに近い気がしました（しかも問題文が違うテストを気づかずに覗いているような中途半端さ）。途中経過の式が無くて答えだけ書けば良いという安直な考えが見えるような気がします。調査するというのは、それが何であるかを理解する迄が肝心だと思うのですが、こちらのケースでは知ろうとする意思も見えませんし、結果として知識にもなりはしないので全くの時間の無駄だと思います。
グーグル先生ではなく本を使っても、これでは変わらないのでは？
要は自分の為にも知識を身につけようという姿勢があれば、グーグルでも本でも正しい方向で使えるのではないかと思います。
ただ、どうやってこうした姿勢を身につけさせれば良いのかが悩ましい所です。
仕事の知識を吸収する事へのモチベーションを与えられれば良いのですが、果たしてこうして安直に仕事をしている人が仕事に夢を持っているかどうか…。

初めまして
学生時代はポケコンのBASIC、現在はExcelのVBAでしかプログラムに携わってない私です。

プログラムとはジャンルの違う職についてますけど、後輩との問答で
「あの人がこう言ってたからそうした」といった回答をされると正直腹が立つ。
「文句があるならあの人に言えば？」みたいな言動。
理解してるのかもしれないけど、何も分かってないようにも取れる。
どちらにせよ、その状態で仕事をされてもなぁ････････と愚痴ってみたり（笑）
でも記事を読ませていただいた時、真っ先に思い浮かびました。

でも「教わる誰か」にしても「ググる」にしても、その情報を元に本人の力で
「根拠」や「知恵」といったものに辿りついて欲しいとは思いますね。

こんばんわです。ひでみです。
なんかにぎやかなことになってます（苦笑）。
いつものことながらコメント返しが簡単ですみません。

組長さん。

> 何て言うか・・・、とにかく受け身なんですね。新人さんご自身も、指導される先輩方も
> どちらも大変だなぁ・・・と思います。

そうですね、一言で言うと「受け身」なんですね、多分。
「聞きたいことがある」という空気を発して「質問はある？」と聞きにきてくれるのをじ～っと待っているんですよ
きっと空気読まない女だと思われてただろうなあ。
質問できない人はたいてい何か問題があっても報告ができない人なんで、自分から話しかけることに慣れさせたかったんですけど。

ちょりぽんさん。

> 仕事の厳しさを教えようとするとヘコんでしまう人もいますし、解らないなら訊いてくれと言うと、
> 余り調べないで訊いてくる。教えすぎると甘えてくるし、誉めると調子に乗っちゃうし（笑）
> 人間相手のことなので、本当に難しいですね・・・

どこまで教えたらいいものか、どこまで厳しくしたらいいものか、本当にいつも悩みます。
みんな別々の人間ですからどこにも正解がないし、場合によっては取り返しのつかないことになります。
他の人ならもっと気軽に話しかけたりするんだろうか、私って近寄りがたいんだろうか、とか考え出すときりがなくなるし。

TOM1935さん。はじめまして。

> ちょっと厳しめに接するようにして、自分でググる癖をつけてもらおうと試みているところです。
> 逆に何も聞いてこないほど自分で調べすぎるようなこういう人もいるんだ!? とビックリしました。

それはうらやましいようなうらやましくないような（苦笑）。
教える方も教えられる方も適切な距離感をつかむのは大変なんですね。
でも「適切」自体がまたあいまいな言葉で、誰がそれを判定してくれるんだ、ってことになっちゃいます。
そして、加減がわからないといっている間に、どんどん世代が離れていって、さらにわからなくなっていくという……。

NG0さん。はじめまして。

> 我々は後輩に指導しているんじゃなくて、そのまた後輩への指導の仕方を教えているん
> だろうなと思ったりします。誰かの受け売りのような気もしますけど。。。

そうかもしれません。私が20年を経ても覚えている言葉を言ってくれた先輩は偉大でした。
私はそれを後輩に伝えられるんだろうか、と思うと不安になります。

ヴァンさん。

> 動いてるけど、なぜ動いているかは判らない。
> こんな新人さんが増えてますね。

なぜ動いてるかわからないけど動いているから、それ以上のことを考えようとしない。
それでどうやってプログラマの仕事をおもしろいと思えるようになるのか、と思います。

はぎさん。はじめまして。

> 電気設計や機械設計なら、設計が悪ければ動作しないんですけど、プログラムって、
> どんなコードでも「動いてしまう」ので、たちが悪いと思います。

プログラムは動かすのが簡単ですし、失敗しても金銭的損失がないから痛くないんですよね（機械とかだと材料費がかかる）。
その手軽さは利点だと思うんですけど、プログラミングで金を稼ごうという人が、お手軽な段階で留まるわけにはいきません。

麻さん。

> ググるのも一つのスキルですよ！

確かにググるというのは、いまやエンジニアにとっての必須スキルです。
できないのかとあきらめかけていたことができるとわかった時なんて「Google先生、ありがとう！」とか言っちゃいます（心の中で言ってるつもりでたまに声に出してるらしい）。
けれど、ひらがながうまく書けないのにやたらむずかしい漢字が書けちゃう、という状況はバランスが悪すぎるかと思います。

インドリさん。

> こういった事がこれ以上進むと、技術が分からない技術者が大量発生し、
> IT業界に対する不信につながるでしょう。なんとも恐ろしい事です。

私が恐ろしいと思うのは、誰かに与えてもらえるのをじっと待つ、という姿勢です。
「つくる」仕事を選んだ人がただのコピペで仕事を間に合わせようとするな、と思うんですが。

mmmさん。

レジストリを知っていることが、そんなに自慢できるものとは知りませんでした。

uchiさん。

> 「自分で調べようとする気持ちは大事にするべき」と書かれていますが、ただ、
> もし「ググって楽をしようとしてる」のなら、つまり正解だけ手っ取り早く得ようとすれば
> ググるのが楽ですが、プロセスや理解の部分がそっくり抜けているので、
> 本当は正解じゃなくても判断できないのではないでしょうか。

自力で正解を導き出そうとがんばっている、のではなく、ググる方が楽だと考えている、ということですか。
人に聞く方が楽だと私は思うんですが、聞くことの方が手間だと考えていた、という可能性はありますね、確かに。
そうなると、なんで聞くのは手間なのか、ということを追求すべきだったのかもしれません。

Kudohさん。

> グーグル先生ではなく本を使っても、これでは変わらないのでは？
> 要は自分の為にも知識を身につけようという姿勢があれば、グーグルでも
> 本でも正しい方向で使えるのではないかと思います。

Googleはあまりにも情報が多すぎるので、本だったらそんなに迷う余地がないと思いました。
検索していると一瞥しただけで「これは使えないから次」って調子でページが読み捨てられちゃうんですけど、本が1冊しかなければそれをじっくり読むしかなくなりますから。
それに、検索していると意外とあっという間に時間が過ぎちゃうんですけど、本だとそのようなことがないので、30分経ったらすぐにあきらめて質問をしに来てくれるんじゃないかと考えたんですね。
とにかくGoogleから一度ひきはがして、それ以外のやり方を経験させよう、としたわけで、本人にもそれを説明したんですけど、ただのいやがらせと受け取られたのかもしれません。

まさやさん。

> 「あの人がこう言ってたからそうした」といった回答をされると正直腹が立つ。
> 「文句があるならあの人に言えば？」みたいな言動。
> 理解してるのかもしれないけど、何も分かってないようにも取れる。

そういう会話ってありますね。「みんなそう言ってるから」とか。
それが「信頼」なのか「責任転嫁」なのかで、だいぶ事情が違ってくると思うんですけど、本人は無自覚でそういうことを言ってたりするのでたちが悪いです。

こんばんは。Masaです。

今回の記事を読んでて気になることがありました。

文面から判断する限り、その新人は何も考えていなかったり、答えのまる写しをしているのとは違うのではないのかなと感じました。

不器用でやや頭が切れる傾向があり、それでいて人付き合いが苦手な人の場合、関連する知識すべて理解できないとまっとうな仕事ができない人である場合があります。たとえば、鋳物を作る時に砂鉄や粘土を集めることから始め、木材5mの長さを測るのに5m以上の物差しを作るところから始めるようなタイプです。

その新人ってそのようなタイプではないですか？そのような人の場合、案件内で入手しないといけない知識とその関連知識を自分で全部調べつくそうとするし、仮にあきらめて質問したとしても質問の答えから新たに疑問持ってしまってそこを調査し、と延々続けて時間をなくし、あわてて物を作ってずれた結果を出す、ということを繰り返すことになります。

今回の内容を読むと「コンフィグファイル」と聞いてソフトウェアの設定格納方法すべてを調べ(ファイルだけではなくレジストリ・起動オプション・ソフト内の定数など)、その中で(実現可能性はまったくわからず)レジストリがいいと思って調査していたと想像できます(レジストリに設定を格納するという考えは実現が難しいけれどアイデアとしてはありだと私は思います)。

もし、その新人が私の言ったようなタイプだった場合は冗談抜きでかなり伸びる可能性があります。何しろ、案件起きるたびに関連技術すべてを自分で調べようとするのですから、調査が追いつかないで失敗繰り返す代わりに相当な知識と思考力を養うことになり、(何年もたつ場合もありますが)成果が出てくれば実装・設計等何でも人以上にこなせるいわゆるスーパーSEになる可能性すらあります。

もちろん、そこに至るまでは現実から考えると突拍子もない行動を連発し、全然関係ない方向に物事を動かして最悪デスマーチを引き起こす場合もあるので監視していないと危なくてしょうがない厄介者だと思います。ただ、大器晩成型の有望な人材である可能性がありますので、気長に育ててみてはいかがでしょう？

文章を読んだだけで想像で書きましたので間違っていたらごめんなさい。ただ、私自身の経験ではそういう人は最終的にかなり伸びている傾向がありましたので記載いたしました。よろしかったら参考にしてください。

転職して運用中心の仕事からプログラム中心の仕事になりました。
件の新人君よろしく、判らないところはすぐにググってとにかく動くコードを書くようにしていますが、一点だけ、とにかく内容を理解してコピる、もしくは動かして内容を理解できないようならさらに調べるようにしています。
最終的に（実施の有無はともかく）コードレビューで説明できるように気をつけていますが、たまにこのような記事を見ると自分の作業を見直す良い機会になります。

連続投稿になってすいません。

私のいったタイプは本文の仙台に行く話で例えれば、西に行っているのに気付かないのではなく、チケットの買い方、すべてのホームに止まる電車の行き先、仙台に行く電車の型などをいちいち全部確認したり、飛行機などのほかの交通手段とどっちがいいかと延々比較したりして全部わかるまで電車に乗らないタイプということです。

そういうタイプでもぎりぎりになれば電車に乗らざるをえませんが、あわてて乗るのでチケット買い間違えたり電車に乗り間違えたりと、普通やらないような信じられない行動を起こすことになります。

入社二年目のメーカー機械設計者です。
「自分で説明できないコードを1行たりとも書くな！」は、
プログラマだけに限らないですね、、参考になります。

こんばんは!!

ひでみさん、こんばんは。

>「適切」自体がまたあいまいな言葉で、誰がそれを判定してくれるんだ、ってことにな
>っちゃいます。

そう、ホントにそうなんですよね!!
質問された内容のレベル（？）とか、納期までの残時間とか、
そのときそのときの状態でどの程度フォローした方がいいのか？
というのはやはり変わってきちゃうものなので
自分でそのとき「適切」と思った対応でいいのかな、と感じてきています。

Masaさん、こんばんは。

>案件内で入手しないといけない知識とその関連知識を自分で全部調べつくそうとするし
>、仮にあきらめて質問したとしても質問の答えから新たに疑問持ってしまってそこを調
>査し、と延々続けて時間をなくし

自分も似たようなところがあるので、何となくわかる気がします。
「頭が切れる」というところが、自分の場合該当していないのがすごく残念ですが(笑)
自分の場合だと、
「修正箇所以外の他の部分へ影響が出ないか？」
「より効率の良い方法や、今の修正箇所に応用できることが他のどこかにないか？」
「今の作業には直接関係ないが、あれはどういった仕組みだろう？」
といったような、不安や興味が引き金となって
「全体的に色々と把握できることは把握してからベストな方法で作業を進めたい」
という気持ちが新人時代にありました。

けいさん、こんばんは。

>とにかく内容を理解してコピる、もしくは動かして内容を理解できないようならさらに
>調べるようにしています。

すごく後輩として欲しいタイプです(笑)
自分でコーディングする以上、理解できないのにコピペして動作させるのは
何だかモヤモヤしますよね～。
「仕事」である以上、納期も考えて作業を進めなければいけないので、
「作業完了」を最優先として理解を伴っていないコピペで作業を進められるようなら
それもアリだと思うよ、と自分は新人の後輩には言っています。
（まぁどっちみち必ず後で自分がチェックするので・・・）
ただ作業完了後にでもいいから、自分で書いたコードはちゃんと理解してね、という
前提でですが。

全体的にとても納得できる文章ですが、最後の
「自分で説明できないコードを1行たりとも書くな！」
は、さすがにちょっと言い過ぎではないかと思いました。

私もプロとして食べている以上、いまでこそ自分はある程度、そのコードが
何をするためのものか理解できるようにはなりましたが、未だに人様の作った
言語やライブラリを使う以上、「おまじない」を書くことは常です。(※)

逆に、プログラミングは手で動かしているうちにわかるという側面もあると
思うので、「一行たりとも書くな」と言われると逆に学習効率が落ちます。
いや、勉強の過程じゃなくて「成果物」の話をしてるんだよ、と言われそう
ですが、期日までに仕上げないといけない成果物の場合こそ、「おまじない」
としてやりすごす技術もある程度のバランス感覚をもった上で、必要だと
思うんですよね。

おそらく、この新人はそのバランス感覚がないんでしょう。
また、「人に聞く」ことの意味がわかってないんでしょう。

「自分で説明できないコードを1行たりとも書くな！」の背後には、
「わからないことは俺に聞け」というひでみさんの親心が透けて見えますが、
この言い方でこの手の新人にその意図が伝わるかは疑問です。

(※) 例えば、Java でよくある public static void main(String[] args) で、
なぜこの関数名が一意に main である必要があるのか、きちんと「説明」
できる上で書いているプログラマって何割くらいいるでしょうか？
まぁ、どの程度までの深さと正確さの説明を要求するかにもよりますが。

私の前の職場にも、理解してないコードを平気で書く後輩がいました。
なまじ仕事ができるので、注意しても反省するどころか、
先輩の私の考え方を逆に注意するありさまでした。

「自分で説明できないコードを1行たりとも書くな！」
には賛成です。
実装してしまって、ある条件下では意図しない動きされては困りますから。

「コンフィグ実装するならレジストリを使え。」は、ＭＳのスタンダードだったと思います。MS系の教本とかにも出てると思います。その意味では新人さんは正統派です。仕組みも十分用意されているはずなので、レジストリを使って「全て説明できるコード」を書く事は容易と思います。

逆にレジストリがなぜいけないかを説明できるでしょうか？実は、私もレジストリが大嫌いです。Windowsのダメさの源とも思っています。一歩踏み込んで、なぜダメなのかを教えてあげたほうが諦めがつくと思います。

大学の教官です。
自分で考えない学生が増えており、おっしゃるとおりの傾向があるように思います。とてもいい話だと思ったので、私の反省も込めてコメントを。

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

この上司だったら答えを知っていて、自分にアドバイスをくれるんじゃないかと期待していたのだと思いますよ。

＞「もっと早くに聞きにこようよ」というと、「仕事をしてたんでジャマしちゃ悪いかと思って」といわれました。

尊敬されている証拠だと思いますよ。尊敬している人に自分の実力のなさはみせたくないじゃないですか～。

で、こういった場合どうするかですが

■解決策を指示しない
この場合は、ググるな、本を読めということですね。解決策は人によりけりで、同じ方法が全員に当てはまらないということもあります。また、この方にはよい方法かもしれませんが、それを指示すれば次に困ったときも指示しないといけなくなるような気がします。

■なぜ解決できないかを自分で考えさせる習慣をつける
時間がかかりすぎたときは、誰かに相談した方がよいのではないかということを自分で気づいてもらうように、「なんでそこでつまづいたんだろうね」「どうすればよかったんだろうね」という質問を投げかけるようにしています。そして出てきた答えは何であろうとほめ「今度からはそうやってみよう」というと納得します。変な答えであればどうせうまくいかないので、また相談にきますが、同じことを繰り返し、自分で答えをみつけさせるようにしています。時間かかるように思えますが、そのうち自分でこのプロセスを回せるようになるので、加速度的に手がかからなくなります（その人の能力にもよりますけど、この新人は大丈夫だと思いますよ）

こんにちは。ひでみです。めずらしくお昼に書いてたりします。
「こんばんわです」に対抗させるのなら「こにゃにゃちわ」とか書くべきでしょうか（←古すぎるからっ）。

Masaさん。

何かを間違えて理解しちゃったりしているのなら、間違い方に一貫性がでてきます。ですので、ここがこう違う、と説明して納得してもらえれば、一気に理解がすすみます。
けれど、その場その場で出会った情報をその時その時でなんとなく納得しちゃって、それをそのままコードに書くので、間違え方につじつまがあわなくなるわけです。
多分、局所的には考えているけれど、その情報を組み合わせて考えるところまで頭がまわらなくて、結局、情報量の多さにパニクってしまうんだろうな、と私は理解していました。
ですので、入ってくる情報量を減らしてパニックをおさえようと思ったわけですが、情報量の多さに慣れきっているので情報を絞られると逆に不安になるのか、単純にGoogleを使わないという発想自体がありえないと思われたのか……。

> 関連する知識すべて理解できないとまっとうな仕事ができない人である場合があります。

私も以前リーダーに「1を聞いて10を知る、って言葉があるけど、おまえは10まで知らないと1から動きださないなあ」と言われたことがありました。未だにそういったところは残っていますが。

> ただ、大器晩成型の有望な人材である可能性がありますので、気長に育ててみてはいかがでしょう？

残念ながら、現在、同じ職場にはいないもので……。

けいさん。

> 件の新人君よろしく、判らないところはすぐにググってとにかく動くコードを書くようにしていますが、
> 一点だけ、とにかく内容を理解してコピる、もしくは動かして内容を理解できないようならさらに調べるようにしています。

Googleに散らばっている知識は多くの場合、コピペするための「素材」として書かれたのではなく、誰かの助けになればいい、という気持ちで書かれているんだと思います。
けいさんのようなやり方で利用されているのなら、その記事を書かれた方も本望かと思います。

chunさん。

> 「自分で説明できないコードを1行たりとも書くな！」は、
> プログラマだけに限らないですね、、参考になります。

疲れたりしててうっかり手を抜きそうになってしまった時、振り返ってみればあれはもっとつっこめた、と反省した時に、自戒の言葉として20年間、唱え続けてきた言葉です。
私をプログラマとして生き延びさせてくれた言葉だと思っています。

けんけんさん。

> 「自分で説明できないコードを1行たりとも書くな！」の背後には、
> 「わからないことは俺に聞け」というひでみさんの親心が透けて見えますが、
> この言い方でこの手の新人にその意図が伝わるかは疑問です。

この言葉を言われたのは私で、この件の新人にはこれは言ってないです。

「これはおまじないです」と説明できるのなら、それはOKだと思います。言語仕様としてそういうことになっている、という理解がちゃんとありますから。
試行錯誤の過程で書いたコードでも「こう書いたらどう動くのかを確認してみたかった」という説明をすることができます。
言語やOSのすべてを説明しろ、なんておそろしいこと言われたら、私だって逃げますよ。
先輩が「理解できてないコード」ではなく「説明できないコード」と言ったのは、「なんとなくで書いて、思考のプロセスがないから説明できないんだ。そんないいかげんなことをするんじゃない！」という意味だったんだと、私は理解しています。
まあ、それを言った当人の真の意図は、今となっては知りようもないですが。

Ｃａｒさん。

> 私の前の職場にも、理解してないコードを平気で書く後輩がいました。
> なまじ仕事ができるので、注意しても反省するどころか、
> 先輩の私の考え方を逆に注意するありさまでした。

理解してないコードを書く人が仕事ができる、というのがちょっと想像つかないんですが。
検索能力と情報をうまい感じにコピペする作業に長けている、ということでしょうか。

新人さん。

> 「コンフィグ実装するならレジストリを使え。」は、ＭＳのスタンダードだったと思います。

えっ、そうなんですか？
データ移行ツールなどという一時的にしか使わないアプリケーションのために、レジストリを持ち出してくるなんて話、きいたことがありません。

> 逆にレジストリがなぜいけないかを説明できるでしょうか？
> 実は、私もレジストリが大嫌いです。Windowsのダメさの源とも思っています。
> 一歩踏み込んで、なぜダメなのかを教えてあげたほうが諦めがつくと思います。

一応、それは説明したんですが、本人はレジストリを使うことに固執していたわけではなく、レジストリを使わないといけない、と思い込んでいた状態でしたので、仕様書に書かれているコンフィグファイルとは何か、を説明したらあっさりひきさがりました。

hika_twitさん。

> 尊敬している人に自分の実力のなさはみせたくないじゃないですか～。

新人なんだからわからなくて当然だと思うので、わからないということ自体を知られたくない、というのは正直わからないです。
私は「自分で盗め」的な環境で育てられ、「わかってない」ということをアピールしなければ教えてもらえない、わからないままだと先輩に放置されっぱなしで仕事を任せてもらえなくなる、と思っていたもので、隙を狙っては質問におしかけてました。
ああ、そういう根本的なところが行き違っちゃってるんですね。

ご丁寧なアドバイスをありがとうございます。
教えていただいたことを意識して、新人に接していきたいと思います。
これから先、機会があるのなら……。

ご苦労様です。

教わりに行く度にキツめのお叱りを交えつつ学習する
技術を習得は早いんだけど結構聞きに行くのが億劫になったりする

その位自分で調べろ→分からないで悩む→早く聞きに来いよ→どうしたらいいんだ…
こんな感じで辞めていった同僚もいるから案外笑えはしないけど、数年前の自分を見てる様な気がした

というか、ちゃんと教えるメソッドを模索しましょうよ。
その新人がかわいそうです。
かなり前の話だそうですが、その新人は無事育ったのでしょうか。それだけが心配です。

こんばんは。自分もまだまだ新人なので、なかなか耳が痛いです。

でも、ひでみさんのいうのはもっともで、考える時間分の給料が発生しているわけです（新人研修のときに叩き込まれました）。

おそらくその新人さんのいいところは、きちんと自分で考えようとするところで、悪いところはコスト意識ゼロのところなのだと思います。
私はまず自分で考えてみて、試行錯誤してダメなら一回休みます。それで再チャレンジしてダメだったら先輩に聞くようにしています。

あと、これは人事に聞いたことなのですが、「最近の子はかまってちゃんが多いのは、都市伝説ではなく割と本当のこと（何百人も面接した経験則）」なようで。
私は放っておかれる方がいいタイプなので「ちょっと今時ではないよね」と言われました。

なんだかはてブで文句いっている人もいますが、新人の私が納得できることなのに、先輩方が文句言っているのがよく分かりません。
あまり気にせずに、これからも面白いコラムを書いてください。
いつもとても参考にしているので。よろしくお願いします。

こんばんわです。ひでみです。

鞍馬さん。

> ご苦労様です。

お気遣いありがとうございます。

ｓｓｓさん。

> 教わりに行く度にキツめのお叱りを交えつつ学習する
> 技術を習得は早いんだけど結構聞きに行くのが億劫になったりする

私は叱られるのは全然、平気ですねえ。叱るのにはエネルギーがいるから、どちらかというとありがたいと思います。めんどくさいからまあいいやと言って自分で片づけちゃう人もいるのに、労力と時間をかけて私に教えようとしてくれている、と思うとなおさらありがたいです。
まあ、言ってることがちゃんと筋が通ってるのが前提ですが。

> その位自分で調べろ→分からないで悩む→早く聞きに来いよ→どうしたらいいんだ…

こういう話はよく聞きますね。
そういうタイミングがはかれないでいるのかと思って30分ルールを設定してみたんですが……。
少なくとも私は「その位自分で調べろ」と言ったとこはないです。
本を渡して「このページに書いてあることを読んでもわからなかったらまた来るように」くらいは言いますけど。
でも、先輩も突き放した方がいいのか、手助けしてやった方がいいのかで、悩んでいたりするんですよ、多分。
どちらが本人のためになるのかを先輩も模索しているのだと、頭の片隅にでも置いてあげてください。

Error401さん。

> というか、ちゃんと教えるメソッドを模索しましょうよ。

参考までに、ちゃんと教えるメソッドを模索していないと、どの点から判断されたのかをお教えいただきたいんですが。

mojinaさん。

> なんだかはてブで文句いっている人もいますが、新人の私が納得できることなのに、
> 先輩方が文句言っているのがよく分かりません。

文章のどこをすくいあげるのかでだいぶ印象が違ってくるのだと思います。
あと、文章に書いていない部分をどう想像するかでも、かなり違ってくると思います。
それに確かに私はダメダメな先輩です。結局、新人の意識を変えることに失敗していますから。

他の誰かがやっていれば、もしかしたら成功していたのかもしれない、という気持ちはいまだに私の中に残っています。
人に教えるのはいつだってこわいです。何かを間違って伝えちゃったらどうしよう、プログラミングはこんなにおもしろいのに私がつまらなく感じさせちゃったらどうしよう、といつも不安に思っています。
でも、こわいからとしり込みして、私が先輩からもらったものを後の人に渡さない、というのもダメだと思っています。
ほんとにいろいろとむずかしくって……って、新人に愚痴ってどうする、自分（すみません）。

とまあ、いろいろと葛藤はあるわけなんですが、それでもやっぱり検索に頼りすぎるのは危ないと思うので、この記事を書きました。
まあ、「おまえが頼りないからだろ」と言われたら反論のしようもありませんが。

> あまり気にせずに、これからも面白いコラムを書いてください。
> いつもとても参考にしているので。よろしくお願いします。

ありがとうございます！
おもしろいのとか、参考にしてもらえるのとかを書けるかどうかはわかりませんが、できるだけ正直な文章を書いていきたいと思っています。
これからもおつきあいいただければ幸いです。

新人とか関係なく、その方は10年後も20年後もズレたこと言って、ズレたことしていると思います。
そのズレかたは、ちょっとアスペ入っている感じもします。

こんばんは。
お返事ありがとうございました。

> けれど、その場その場で出会った情報をその時その時でなんとなく納得
> しちゃって、それをそのままコードに書くので、間違え方につじつまが
> あわなくなるわけです。
> 多分、局所的には考えているけれど、その情報を組み合わせて考えるところ
> まで頭がまわらなくて、結局、情報量の多さにパニクってしまうんだろうな、
> と私は理解していました。

となるとやっぱり私の想像していた人だったかも…。
関連すること全部知らないと不安で色々調べようとするけど、ふつうはそれだけの知識を一気に整理できないからパニクるんです。時間がたって整理できてくればかなりの戦力ですが。

私の知ってる限りこういう人は職人肌・学者肌といわれる人に多いですね。

> 入ってくる情報量を減らしてパニックをおさえようと思ったわけですが、
> 情報量の多さに慣れきっているので情報を絞られると逆に不安になるのか、
> 単純にGoogleを使わないという発想自体がありえないと思われたのか……。

それは無理だと思います。全部知ろうとすることを抑えて自分が必要なことだけ手っ取り早く調べることができるような器用な人ならそもそもそんな問題起こしません。また、不器用ゆえに行動制限したってその通りにはなかなか行動できないと思います。私が「不器用」といったのはそのためです。

あと、「人付き合いのうまい人」にはまずこういう人はいませんね。基本的に「空気を読んで行動できる人」ですから、周りの空気読んで自分の好奇心抑えるでしょう。

また、「やや頭が切れる」というのは「ちょっとしたことでもすぐ疑問点が浮かぶ」ということです。これが全然理解できていない時期だと逆に問題になるんですよね。

効率主義的な考えだとこういう人は切り捨てられるんでしょうか。大成する可能性が高いだけにすごくもったいない気がします。

> 私も以前リーダーに「1を聞いて10を知る、って言葉があるけど、おまえは10
> まで知らないと1から動きださないなあ」と言われたことがありました。
> 未だにそういったところは残っていますが。

私もそういうところがありますし、あまりに理解が遅いのでトラブルを起こしたこともあります。ただ、最近ではそういう人のほうが結局技術者には向いているんじゃないかと思うようになりました。

1を聞いて10を知るということは残りの9を理解していなくても結果が出せるということです。これは一見ものすごくいいことのように見えますが、仕事に厳密さを要求される技術者が9を理解しないで結果を出して果たしていいのかと。トラブル起きたときにこの差は大きいと思います。10を知ってようやく1が出せる人の方が技術者として信頼に足ると思います。

もちろん、技術をそこそこ習得して人を使いリーダー・マネージャーと出世しようと考えている人や、効率重視の人にはこの考えは通じないかもしれないとは思いますが…。

新人クンが「自分で説明できないコードを1行たりとも書くな！」を心から実感して、
日々の雑用程度の業務に対してもこの姿勢で取り組みだすまでは
苦難の日々だと思いますね～。
私もこの新人クン（内気な性格でどちらかといえば、非社交的なら）とほぼ同じ思考でした。

全体が見えず局所的な部分しか見えないからツギハギで提出してしまうし理解も部分的なんですよね。
それが新人時代に経験する苦しいところであり成長するための大事なステップなんですよ。今の時代の若者は。

「自分で説明できないコードを1行たりとも書くな！」
これを実践できない人は数年で会社辞めると思います。
新人クンに対して言うべきか言わざるべきか思案のしどｋろですね

おそらくあなたは非常に仕事ができる人だと思いますので、ご不満に思う気持ちはわかります。ですがその新人が聞きに来ないのは、おそらくあなたに聞きにくい雰囲気があるからではないでしょうか？気軽に質問しやすい雰囲気を本当に作れていますか？

> 「困ってます～」的なジェスチャーは見せるんですが、聞きにこないんですよ。
> 最初のうちこそ、「どんな感じ？」と聞きにいってたんですが、なんでわたしが御用伺いをしなくちゃいけないんだろ

新人が質問しに来るのと同じく、上司の側から助け船を出すのも仕事のうちでは？

あとGoogleの正しい使い方をあなたが知っているなら、そのコツを新人に教えてあげたらいいんじゃないでしょうか。

ひでみさん、こんばんは。

ひでみさんにも予想外の盛り上がだとお察しします（はてなブックマークが凄いことに）。これですと、月刊エンジニアライフの３か月連続採用も間違いなさそうですね（笑）

冗談はさておき、ここをご覧の方々は皆、ひでみさんが勤務する会社が零細企業だという前提がスッポリ抜け落ちている印象を受けました。批判派は大企業の新人、賛成派は零細で成長してきた人だと推察します。

ひでみさんが訴えたい事の主旨は『理解していないことを”できました”と挙げてくるな』という一点に尽きます（と読み取りました）。なのにタイトルだけに過剰反応する人や、ひでみさんの指導能力にまで批判する人がいることに事態の深刻さを痛感しました。

会社を学校と同じように解釈している人が多いです。要するに『自分がどうなんだ』という視点があれば、教育担当に批判が及ぶことはありません。根底に「甘え」が蔓延しているように思いました。

また、効率を無視するということは、時間の概念がぶっ飛んでいることと同義です。時間の概念がない仕事などありえませんし、零細ではなおさら顕著です。与えられるのを待ってダラダラ学びたいのであれば、それこそ趣味でやってくださいと言いたい。技術は先輩が教えてくれると考えている人の多さに驚きを禁じ得ません。

そもそもGoogleを駆使したとしても成果物が妥当であれば、この記事は生まれなかったわけですよね。この記事は、理解していないことを”できました”として挙げてくる責任感の無さに突っ込んだ、非常に有意義な内容であると思います。

「新人だから、経験浅いから」。これを免罪符にして甘えて欲しくない。例えば『質問し難いから訊かない』という発想は甘えの極みです。

と、ここまで書いてみてコメント欄には書ききれないと気付きました。すみませんが、便乗で記事を書くことにします。

はてブから来た機械技術者なのら。
教えたことの効果というのは、すぐに現れるものばかりではないにょろ。
新人さんも何年か経ってから「ひでみさんの教えたこと（教えたかったこと）の意味」が分かるよ、きっと！
分かってもらえなかったら、それは教わった側の力不足さ。
それを怖がったりためらったりしていては、モノを教えることができなくなるにょろ。
初めは痛いけど、だんだん良くなってくるさ！

自分は何が分かってないのかも分からない状況では、
上司に質問する事も憚られるのではないでしょうか？
「何が聞きたいの？」と聞き返されるのは目に見えてます。

本の索引を見ても、どれが解決方法に繋がっているのか検討もつかなければ、
無闇にWebで検索してでもヒントが欲しくなるはずです。

あなたがその新人に与えたのは、ただの足枷です。
成長を促すなら、段階を踏んで当人のスキルで解けなくもない
難題を繰り返し与える事です。

新人が上手くコントロールできないので、足枷をつけてみたけど、
結果は良くありません、って話をコラムにして晒してる訳ですよね。
僕がその新人ならあなたの事は絶対に信用しないでしょう。

>独学で勉強をしているのなら、どれだけ大回りしてもいつかたどりつければいい、寄り道もムダにはならない、といってあげられますが、仕事でやっているかぎりは、少しでも効率的に覚える義務が発生します。

もし社長がそういってるのなら仕方ないですね。

私も社長やってるけど、私なら「好きなように覚えさせろ」って言うかな。

大回りの人件費を払っても、コードがつぎはぎでも、「自力解決」は本人の血となり肉となると思ってるからです。

これは誰にも相談する人がいない社長業を経験しないと分からないかもしれません。

ちなみに私もコードを書きます。
つぎはぎのww

まさにそんな新人だった私ですが、
私がググってた理由==先輩、上司に質問しない理由は、
向こうが忙しそうだったからです。
質問しても、面倒くさそうに答えられるのが精神的に申し訳なかったです。
(もっと単純に人と話すのが無理って理由もありますが)

先輩や上司に質問しやすいかどうかはー環境依存でしょうねぇ。
聞かれることを嫌う人も居ますし、どんどん聞いて欲しい人も居ますから(^^;
前者は、時間効率は悪いですが、調べるという力は徐々に上がっていきますね。
後者は、時間効率は良いけど、調べるという意欲は減っていくかもしれません。
中間が一番良いのはわかるけど、なかなかできませんね。

聞く側も同じように性格の違いがでるとこなんですよねぇ。
何も考えずに聞く人もあれば、聞くことが恥ずかしいと思う人も居る。
まぁ、小さなプライドを維持するために大きな信頼を失う場合もあるわけで(^^;

今は、まったく別の視点で、ググると危ない場合もありますね。
Webにあるサンプルコードや解説が間違っている場合です。
サンプルコードは、一応動作する形になっているものは性質が悪いｗ
検索で始めに見つかるものが間違ってると、間違いの伝染率は高くなりますよねぇ。
まぁ、悪意をもって間違えることは少ないんですが・・・
多くの場合、第三者が間違いを指摘して修正されます。
しかし、間違いを書いたことを認めるのが嫌だったり、間違いを指摘されて恥を書かされたと思われるような人もい居ます。
こういう人が初心者用の解説を書いてると、性質が悪いｗ

間違っているかどうかを判断するのは簡単じゃないんですよねぇ。
この辺は経験とかセンスですかね、自分もしくはサンプルが間違っていれば違和感を感じるんですよね。
その違和感を追いかけるかどうかでも変わりそう。

検索する時は、検索したものが正しいものかどうか、疑うことだけはしてほしいなぁ。
動作原理は詳しく知らなくてもいい、動作仕様（使い方）だけは理解して欲しい。
コードを自分なりの解釈でもいいから、筋が通る解釈ができるようになって欲しい。
コピペで成長したと思っている人ほど、コードの書き方に一貫性がない。
そんなのを見ちゃうと、理解度（技術力）を疑うことになるんだよなぁ。

ひでみさん、おはようございます。

大盛況ですね。
ちょっと怖いけど、ほとぼりが冷めた頃に書かせていただくかも……。

ひでみさん、はじめまして。
新人はそんなものではないでしょうか？
今新人の子も何年もすれば、今のひでみさんの気持がわかるようになるんじゃないでしょうか？

おはようございます。ひでみです。めずらしく朝に書いています。
「こんばんわです」に対抗して「おっは」とか言うべきでしょうか？（←山ちゃんファンとしてはまったく古くならない言葉）

macさん。

> 全体が見えず局所的な部分しか見えないからツギハギで提出してしまうし理解も部分的なんですよね。
> それが新人時代に経験する苦しいところであり成長するための大事なステップなんですよ。

最初の頃は何がどうつながるのかがさっぱりわからなくて、本当に苦しかったですね、私も。
これを乗り切れなくて辞めていった仲間もたくさんいました。

飯塚さん。

> その新人が聞きに来ないのは、おそらくあなたに聞きにくい雰囲気があるからでは
> ないでしょうか？気軽に質問しやすい雰囲気を本当に作れていますか？

それを言われると自信がないですね。
気をつけていたつもりですが、私が質問しやすい人なのかは、私にはわかりません。

> 新人が質問しに来るのと同じく、上司の側から助け船を出すのも仕事のうちでは？

助け舟をだすのはむずかしいことではありませんが、助け舟を出しすぎてしまうと、相手がききにくるまで自分は黙っていればいい、という間違った解釈を与えてしまうことになりませんか？
自分の要求を相手に伝える、というのも大事な仕事です。というか、社会人として必須スキルです。
「それができない人もいるんだからわかってやれよ」という言い分もわからないではないですが、そのままでは将来的に大問題です。
すくなくとも私は「30分悩んだら」という条件をつけて、相手は「わかりました」と答えました。それなのに、30分悩んでもききにこない、というのは私の指示を無視しているということになります。それは問題ではありませんか？
指示に従うことよりも、質問しにくい、という気持ちの方が勝つことを、「そんなに質問しにくい人なんだ」と解釈されても、反論しようはないですが。

ちょりぽんさん。

> ひでみさんにも予想外の盛り上がだとお察しします（はてなブックマークが凄いことに）。
> これですと、月刊エンジニアライフの３か月連続採用も間違いなさそうですね（笑）

はてなブックマークもご感想のうちなのでひととおり読んではいるんですけど、予想外というか、想像したこともなかったというか。
こういうのも「炎上」というんですかね（苦笑）。
私は意外と大丈夫ですけど、うちの社長とか社員のみんなとか友達がとても心配してくれてるんじゃないかと思って、そっちが心配になってきました。

> ひでみさんが訴えたい事の主旨は『理解していないことを”できました”と挙げてくるな』
> という一点に尽きます（と読み取りました）。

それもありますし、「理解できてないことを理解できてると錯覚することは危険だぞ」というのもあります。
理解のたりなさを情報の多さでフォローするするのもひとつの手ではあるけれど、情報が少ないから理解できない、というのはちょっと違うだろう、と。

> そもそもGoogleを駆使したとしても成果物が妥当であれば、この記事は生まれなかったわけですよね。

そのとおりですね。実際、私も「駆使」とまでは言わなくても多用していますし、使うこと自体は否定しません。

> と、ここまで書いてみてコメント欄には書ききれないと気付きました。
> すみませんが、便乗で記事を書くことにします。

私のコメント数を超えていただければ、影が薄くなって助かります（笑）。

真っ赤なレモンさん。

> 教えたことの効果というのは、すぐに現れるものばかりではないにょろ。
> 新人さんも何年か経ってから「ひでみさんの教えたこと（教えたかったこと）の意味」が分かるよ、きっと！

そうだといいんですけど。本当に。

kさん。

> 自分は何が分かってないのかも分からない状況では、
> 上司に質問する事も憚られるのではないでしょうか？
> 「何が聞きたいの？」と聞き返されるのは目に見えてます。

でもこの場合、「コンフィグファイルって何ですか？」と訊けばいいだけですよね。
それはそんなにむずかしいことですか？

> あなたがその新人に与えたのは、ただの足枷です。
> 成長を促すなら、段階を踏んで当人のスキルで解けなくもない難題を繰り返し与える事です。

元々「データ移行ツールをつくりあげる」という仕事があって始まった問題です。
それは、当人のスキルで解けなくもない難題、だったと思います。

IT社長さん。

> 私も社長やってるけど、私なら「好きなように覚えさせろ」って言うかな。
> 大回りの人件費を払っても、コードがつぎはぎでも、「自力解決」は
> 本人の血となり肉となると思ってるからです。

それは立派なお考えだと思います。
自力解決は確かに本人の血と肉になります。

pさん。

> まさにそんな新人だった私ですが、
> 私がググってた理由==先輩、上司に質問しない理由は、向こうが忙しそうだったからです。

新人の頃は、先輩や上司はものすごく忙しそうにみえました。実際、忙しかったんだと思いますが。
そこに割り込むのは申し訳ないと思うのは、ものすごくまっとうな方だとおもいます。
けれど、自分がわからないままでいるのは、結果的に相手の負担を増やすことになる、ということも考えて欲しいんですよね。

Ｓｏｄａさん。

> 検索する時は、検索したものが正しいものかどうか、疑うことだけはしてほしいなぁ。
> 動作原理は詳しく知らなくてもいい、動作仕様（使い方）だけは理解して欲しい。
> コードを自分なりの解釈でもいいから、筋が通る解釈ができるようになって欲しい。

まったくそのとおりです！
それができているのなら、コピペだろうがパクりだろうが……。

生島勘富さん。

> 大盛況ですね。
> ちょっと怖いけど、ほとぼりが冷めた頃に書かせていただくかも……。

なんかうっかりエンジニアライフに金字塔うちたてちゃったかもしれません（爆）。
おっかしいなあ、生島さんと違って（笑）炎上させる気はさっぱりないんですけどねえ。

ごめんなさいさん。はじめまして。

> 新人はそんなものではないでしょうか？
> 今新人の子も何年もすれば、今のひでみさんの気持がわかるようになるんじゃないでしょうか？

どうなんでしょうねえ。そうだといいですねえ（嘆息）。

がると申します。
本文とコメントを拝見して…しみじみと「学び方/問い方/教わり方とその礼儀」について、改めて考えるよいきっかけとなりました。
私は基本的に、教えは「乞うもの」だと思ってますし。学ぶというのは、教わる相手が支払った相応のコスト(時間だったり書籍だったり経験だったり)を頂戴する事だと思っているので。
いわゆる「教えてくれて当然」「指導できないほうがわるい」「聞きにくい教わりにくい雰囲気を放っているあなたがだめなんだ」という論調は、根本的に理解できないので(苦笑

ただ。
増長慢な後輩はともかくとして、「右往左往と萎縮している」子をフォローするのは、これはまぁ上司の役割だと思いますので。
まずは「大丈夫だ世質問しても怖くないよ」と諭すところから、大抵は始めます。あんまり冗談事でもなく「質問したら怒られる」と思っている人(…で、実際に質問すると怒られる現場)は、案外にあちこちで散見されるもの、なので。

ソフトウェア職人気質、という書籍にわりあいこってりと書かれているのですが。
この業界(に限らないのですが)、お仕事は「完璧に出来るようになってからやる」ものではなくて「お仕事の中で日々修練していくもの」だと思うので(これもまた、これを否定する御仁と現場は多々あります)。
「意欲がある子を」如何に育てるか、は、とても大切な事だと思います。
後は「育て方/教え方を教えて」自分が少し楽になり。
「“育て方/教え方”の教え方」を教えると、後はねずみ算になっていきます(笑

書籍で独習するほうがよい部分もあり。人から口伝でOJTでなければ伝わらない部分もあり。
そういう部分を綺麗に織り交ぜて「啐啄之機」のごとく、絶好の機会をうかがえるように切磋琢磨していきたいと思います。…いやこれが非常に難しいのですが(苦笑

こんばんは

お話を拝見した感じだと「作る」ということの最終地点が違っているように思います。
で、その最終地点をつなげるために不足していたものは「テスト」だったんじゃないでしょうか？

テストの仕方/計画の立て方

これって非常に大事ですが、教えるのも難しい部分ですよね？

で、私が育った環境（COBOLの汎用機）でのお話ですが、バッチPGにて1円のずれが数億の違いになってしまう業種でしたのでテストの際に必ず提出しなければならなかったものが

・テストケース・・・修正でも新規の際のテスト＋改修部分が必須
・走行記録・・・これはあまり一般的ではないかもしれませんが、提示したテストケースでテストを実施した際にすべてのコードが少なくとも1回実行されていることが記録されたもの

この2点が必須でした。
テストケースより何より全走行テストはやっていて非常にバグ減少に効果があったように記憶しています。

物を作ることは「動けばいい」ではなく、「完璧に動く」ことだということを教えていくことがよろしいのではないでしょうか？
もっというとプログラムの作り方＋「確認の仕方」が「ものづくり」なんではないかと思います。

あと、非常に個人的な感情ですが、他人に多くを求めるとストレスの素になるのでどこで躓いているのか見つけることにしています。

・・・・なんか取り止めなくなってしまいましたね。。。。。

初めまして、こんばんは。
いつも楽しく拝読しています。

私も同様の経験があります、ひでみさんが見た新人と・・・。
どうソースを書いていいかわからず、時間もなく、
罪悪感に苛まれながら、先輩のソースをコピペして
しまいました。

でも、バグを発見した時に自分で書いたソースなのに
何をやっているのか分からず、どう修正していいのかも分からず、
途方にくれました。

その経験を活かし（？）、今の新人には先輩がソースチェックを
するのではなく、ソースレビューをして自分のコードを説明して
貰うようにしています。
時間に余裕があるときにしか出来ませんが、かなり有効ですよ。

ひでみさん、こんばんは。

弊社は教育できる人が居ないので、情報収集の貴重な機会となりました。ありがとうございます。（個人的に、はてなブックマークのコメントは大変参考になりました）

＞私のコメント数を超えていただければ、影が薄くなって助かります（笑）。

すみません、現時点で何も書いてません・・・

ただ、この金字塔（笑）に対するコメントが賛否別れるところは大変興味深いので、何日後になるか不明ですが、次は予定を変更して教育に関する記事を書こうと思います。

『要するに明日から何すればいいの』という切り口で考え方を発信してみますね。
いつもながら全て体験ベースなので、大したことは書けません。あまり期待しないでください（笑）

こんばんわです。ひでみです。
今日、うちの社長に「みんな心配してるけど、心配してないから」と言われました。日本語は深イイです。

それと、同じ職場にいたこともある友人から「仕事中は近寄り難い雰囲気がある、というのはよくわかる」というメールがきました。
そうか……そうだったのか……。
気をつけたいんですけど、無意識にやっていることだけに、どうすればいいのかがわかりません。

がるさん。

> 「意欲がある子を」如何に育てるか、は、とても大切な事だと思います。
> 後は「育て方/教え方を教えて」自分が少し楽になり。
> 「“育て方/教え方”の教え方」を教えると、後はねずみ算になっていきます(笑

すてきな考え方ですね。
こっちが悩みすぎてしまうと、相手にもそれが伝わってしまうんでしょうし、教えることをもっと気楽に考えた方がいいのかもしれません。
お言葉ありがとうございました。

しっぱさん。

> 物を作ることは「動けばいい」ではなく、「完璧に動く」ことだということを
> 教えていくことがよろしいのではないでしょうか？
> もっというとプログラムの作り方＋「確認の仕方」が「ものづくり」なんではないかと思います。

最初からがっちりとテストケースをくみ上げて、これをすべてクリアするものをつくれ、というのは確かに最終地点としてわかりやすいですね。
趣味でプログラムを書いているのなら「楽しかった」で終わらせてあとは放り投げてもいいんですけど、仕事ではそれを使い続けるお客様がいらっしゃるということを、最初っからきちんと教え込まなければならないという意識は、正直、抜け落ちていたと思います。コーディングばかりにこだわりすぎていたのかもしれません。
プログラマとして、「ユーザーさんがどんな操作をやってもボロは出さない！」という心意気は忘れたくないものです（実際にはでるんですけど（泣））。

ダレゴリラさん。はじめまして。
いつも読んでくださってるそうで、ありがとうございます。

> どうソースを書いていいかわからず、時間もなく、罪悪感に苛まれながら、
> 先輩のソースをコピペしてしまいました。

あっ、よかった。罪悪感があったんですか（あれ？　よくないのか？）。
私がみてきた新人のリアクションを見ていると、「これくらいいいじゃん」と思ってやっているような印象があって、それがどうしてもひっかかっていたんですが、悪いことだと思ってやっているのなら、なんかちょっと安心します。

> 今の新人には先輩がソースチェックをするのではなく、
> ソースレビューをして自分のコードを説明して貰うようにしています。

まさしく「自分で説明できないコードは書くな！」ですね。
先輩がレビューするよりも時間はかかりそうですけど、効果はありそうです。パクらせていただきます！（笑）

ちょりぽんさん。

> 弊社は教育できる人が居ないので、情報収集の貴重な機会となりました。
> ありがとうございます。（個人的に、はてなブックマークのコメントは大変参考になりました）

私もいろいろなことを考え直すよい機会になりました。ところどころでダメージをくらうのが難ですが（苦笑）。

> この金字塔（笑）に対するコメントが賛否別れるところは大変興味深いので、
> 何日後になるか不明ですが、次は予定を変更して教育に関する記事を書こうと思います。

金字塔……自分で言っておきながら今になってみるとはずかしい……。
ちょりぽんさんがあのコメントの中から何をすくいあげるのか、とても興味があります。
急かすつもりはまったくないんですが。

生島さんへのレスで「金字塔」という単語をチョイスしていたのが、笑いの琴線に触れたんですよね。

ひでみさんには大丈夫だと思うんですが、一応６００人超が観てるので決して馬鹿にしてるわけじゃないということを明言しておかないと、なんだか怖い（笑）

次のテーマですが、私の場合は後輩との距離感を可能な限り縮めようとするので、一線を越えて甘えてくる行為を如何に線引きするかの戦いになりますね。

記事もそこらへんが肝になってきます。

ちなみに今日は（も）酔っぱらっているので未だ着手せずです（笑）

ではでは。
（実は今までの全てのコラムは酔っぱらって書いています・・・）

ひでみさん、こんばんは。
saki1208です。

私は去年のちょうど今ごろ、同じような体験をしました。
作業内容までほぼ同じですw

こちらの説明が不足している部分もあったようですが、15年以上の経験差があり、
どこまで説明するものかこちらとしても相当悩みました。
# エンドユーザ相手に説明する方が相手が全くの素人であることや専門的な知識を身
# に付ける必要がなく、すべてを説明しないといけないと思っている分楽ですね。

こちらはヒントを与えているつもりでもヒントの内容そのものが理解できていないケ
ースも多く、わからなければ聞けと言っても声を掛けづらいなどの場合もあり、なか
なかうまくいきませんでしたねぇ。
ペアプロっぽく一緒に考えながらコーディングすることもあったのですが、頷いてい
るばかり。後で聞いても何も理解できていない。似たような課題にぶち当たっても自
分で考えようとしない。多分、公式は覚えられても自分ではそれを導くことができな
いんですね。
# 学歴は彼らの方が上ですけどねw
# 学校の勉強では間違いなく勝てないでしょうorz
メモは一生懸命取っているのですがそれで精いっぱいみたいで書いた内容しかわから
ない...
# 1年生や2年生にそれを求めるのも酷な気はしますがw

最近よく考えるのは、今の若い子は少し可愛そうかなぁと...
昔はもっと時間を掛けて新人の教育をやっていましたし、各プロジェクトでは必ずそ
のプロジェクトのための技術的な基盤を調査したり作ったりする時間が与えられてい
ました。大抵は新人と4〜5年生のペアにもう少し経験のある技術者をオブザーバーと
して付けたりしてやってた気がします。
今は低価格化?や短納期化が常に行われており、新人であっても戦力としてカウント
され、本来時間を掛けて学ぶべきこともやらないもしくはやっても相当速いペースで
やらされてるんじゃないかと思います。
# 本当は本人のやる気次第なんですけどね...

ただ、最初の時点で要領の良い子と要領の悪い子では相当に差が出てしまいますので
もう少し何とかならんかなぁといつも考えています。

こんばんは。Masaです
先日の書き込みはちょっと言葉が足りなかったかもしれません。

最初に打ち明ければよかったのかもしれませんが、実を言うとその新人は新人時代の私に非常によく似てるんですよ。ですのでどうしてもコメントしたくて…。
伸びる可能性があるとかやや切れる傾向があるとか言った後にこういうのを打ち明けるのも気が引けるのですが、最初の書き込み時にとても打ち明ける勇気が出なかったもので申し訳ない。(とはいっても今までいった意見に偽りはありません。打ち明けられなかったからどこか回りくどい言い方になっただけです。)

あの頃の私の経験からいって、その新人に関していえばコスト意識が低いとか自分が分かっていない答えを平気で書いているとかそういうのではないと思うんですよ。

だいたい、こんな感じじゃないかと。
1.与えられた仕事はすべて理解しないといけないと思って関連知識を徹底的に調べる
2.調査項目が多すぎて時間をなくす
3.時間がなくなったので(不本意ではあるが)締め切りに間に合わすために提出物を出す
4.期限ぎりぎりかちょっと遅れるくらいに提出し、半端な調査で作っているのでつぎはぎになる

つまり、「締め切りに間に合わせないといけない」と「提出物の内容はすべて理解しないといけない」が両立できないときに折り合いをつけられず、結局両方とも満たせない結果になっていると。想像するにそれで新人本人も相当に悩んでいるんじゃないかなと思います。

また、この新人は別にひでみさんが苦手だというのではなく、誰に対してもその態度だと思います。
その新人は「コンフィグファイル」と聞いて「レジストリ」なんてアイデア出せるほどですから(良くも悪くも)ユニークな発想の持ち主だといえます。そういう人は通常変わり者扱いされますので自分の発言がもとでいじめられた経験があると思います。そうすると、そのトラウマで人に声を掛けられなくなっている場合があります(声をかけると相手が敵になると思いこんでると…。一種の対人恐怖症です。)。

その状態では無能者通り越してかなりの厄介者だし、ひでみさんの印象に残るのも当然かと思います。(私を指導した先輩はその後どんなひどい新人を見ても有能に見えると言っています)

もちろん、そういう問題は新人が自分で乗り越えなければならない問題です。ただ、乗り越えるために悩んだことは絶対にキャリアにいきます。また、「締め切りに間に合わせないといけない」と「提出物の内容はすべて理解しないといけない」の両立も真剣に悩み続けていれば、そのうち二つの折り合いをつけなくても両立させる方法を見つけられると思います。

それまでの間は非常に面倒でしょうが、特別扱いしたり見捨てたりしないで見守ってほしいなと思った次第です。(今は配下にいないということですのでこの一言はあまり意味をもちませんが)

もし今まで言葉足らずで不愉快な思いをさせてしまっていたならその点はお詫びいたします。

「新人とは、わからないということはわかっているが、何がわからないのかはわからない」

「若手は、最適化と手抜きの違いがわからない。そして、確実に手抜きだけを真似る」

「ベテランは、昔話は好きだが、最新の開発手法は嫌いだ」

私は、「この関数の意味は？」と後輩に問いかけたら「自分でググれ」と返された・・・。
君、コードレビューの意味って知ってる？

皆さん、こんにちは。

コラム＆コメント、今回も興味深く拝見しました。

今回のコラムですが、
新人君の"その場しのぎ"的なプログラムの書き方に、
「これってどうなの？」と危機感を覚えた。
(言い方は悪いかもしれませんが…＾＾；)
と私は解釈しました。
(間違っていたらすみません。)

それを踏まえてですが、
google先生も何でも、使い方次第なんじゃないかと思います。
例えば、包丁は料理するのに便利な道具ですが、
使い方によっては人を殺すことも可能ですよね。

google先生も使い方次第では"先生"にもなるし、
"カンニングペーパー"にもなるってことなんじゃないかと。
(コメントでgoogle使ってるって方々は"先生"として使ってるのだと思います。)

結局は、本人の心がけ次第ってことなんでしょうか…。

顧客にバイナリを納めたとき、顧客の中に一人や二人、
こそっとバイナリが読める人間がいると思ったほうがいいですよ。

VB6のやつとかてきめん。
猫も杓子もIDispatch*ですね、はいはい。

こんばんわです。ひでみです。
はてなブックマークが落ち着いてきたようです。正直、ホッとしました（言っちゃっていいのか？）。

ちょりぽんさん。

> 生島さんへのレスで「金字塔」という単語をチョイスしていたのが、笑いの琴線に触れたんですよね。

言葉の選び方が変わってる、とよく言われます。
『ググるな危険』というタイトルもなんとなく思いついたからつけたんですけど、なんか刺激的だったらしいです（私の感覚はどこかズレているんだろうか）。

saki1208さん。

> ペアプロっぽく一緒に考えながらコーディングすることもあったのですが、
> 頷いているばかり。後で聞いても何も理解できていない。

なんだか同一人物かと疑いたくなるような……（苦笑）。
問題なのは、わかってないのに「わかりました」と答えることなんですよ。
これが、わかってないのにわかってるつもりで言っちゃってるのか、わからないと言えなくてつい言っちゃってるのかが、さっぱりわからないんです。

> 今は低価格化?や短納期化が常に行われており、新人であっても戦力としてカウントされ、
> 本来時間を掛けて学ぶべきこともやらないもしくはやっても相当速いペースで
> やらされてるんじゃないかと思います。
> ただ、最初の時点で要領の良い子と要領の悪い子では相当に差が出てしまいますので
> もう少し何とかならんかなぁといつも考えています。

これはなんだか身につまされる話です。私もどちらかというと要領の悪い子だったので。
私の場合は「わかりません」を連呼してもっと説明プリーズ！　な子でした。今だったら「先にググれ！」と言われてたかもしれません。
そんな手間のかかる新人につきあってくれた先輩に感謝感謝です。
その感謝感謝を、後輩に引き渡したいとは思うんですけど、「わかりません」と言ってくれませんでした（泣）。

要領の悪い子は、自分が要領が悪いことを自覚していて、それをなんとか隠そうとして逆に失敗する、というパターンが多いような気がしています。
どうにかフォローしてあげたいんですけど、要領が悪い子だと思われている、迷惑をかけてる、というのがまずストレスになってるっぽいので、かまいすぎると逆にプレッシャーなのかなあ、とか思っちゃって、互いにすくみあう感じになっちゃったりします。
本当に、もう少しなんとかならないもんですかねえ（嘆息）。

Masaさん。

> つまり、「締め切りに間に合わせないといけない」と「提出物の内容はすべて理解しないと
> いけない」が両立できないときに折り合いをつけられず、結局両方とも満たせない結果に
> なっていると。想像するにそれで新人本人も相当に悩んでいるんじゃないかなと思います。

この推測は意外とありえそうな気がします。
だとしても、それを伝えて欲しいんですよ。「わかりません」でも「できません」でもいいから。

> もし今まで言葉足らずで不愉快な思いをさせてしまっていたならその点はお詫びいたします。

そのようなことはまったくありませんので、ご心配なさらないでください。
いろいろと興味深いお話をきかせてくださってありがとうございました。

迷言さん。

> 私は、「この関数の意味は？」と後輩に問いかけたら「自分でググれ」と返された・・・。

「なんでこんな関数も知らないんだ、この先輩」と思って言ってるんならスゴイ……。

福田(仮)さん。

> 新人君の"その場しのぎ"的なプログラムの書き方に、「これってどうなの？」と危機感を覚えた。

厳密に言えば「苦しまぎれ」に「その場しのぎ」をやっちゃってる印象がありました。
はやいうちにやめさせないと、その場しのぎでもなんとかなるって思い込んじゃうぞ、そのままじゃ苦しいばっかだぞ、という危機感を覚えました。

> google先生も使い方次第では"先生"にもなるし、"カンニングペーパー"にもなるってことなんじゃないかと。

ほとんどのエンジニアは“先生”として使っていると思います。
でも、“カンニングペーパー”として使っちゃって成功してしまうと、依存するくせがついちゃうんじゃないんですかね。
“カンニング”は発覚してるぞ、と教えればやめるかと思ったんですが、本人には“カンニング”という意識はなかったのかもしれません。

こんにちは
　酒屋の息子と申します。

私もよくgoogle先生にお世話になってます。
ただ、必ず裏は取りますし
完全には理解できなくともある程度納得した上で
流用させてもらっています。
（１００％流用はまずないですが）

これはgoogleに限らず本に記述している事も含めてです。
自分で納得できない事を信じきれない天邪鬼ですから。

仕様で「コンフィグファイル」を使うとされているのだから、仕様に従うのが当然なのでしょうが、

たとえば、
http://msdn.microsoft.com/ja-jp/library/cc429779.aspx には、
「注意 この関数は、16 ビット Windows ベースのアプリケーションとの
互換性を保つ目的でのみ提供されています。
Win32 ベースのアプリケーションでは、初期化情報をレジストリに格納してください。」
とされています。

> データ移行ツールなどという一時的にしか使わないアプリケーションのために、
> レジストリを持ち出してくるなんて話、きいたことがありません。

聞いたことがないとすればそれは勉強不足でしょう。

そもそもなぜ、「コンフィグファイル」をつくるのはよくて、
レジストリに書き込むのはだめなのか、私にはよくわかりません。
# 「コンフィグファイル」というのは、.iniファイルのことだと思って書いています。

> Atsushi777さん

あなたのおっしゃっていることはすべて理解したうえで答えます。(そう言わないと私がかみつかれそうですので)

原則はどうあれ「データ移行ツール」のようなものの設定は、OSの標準設定格納場所に保存はしてはいけません。Microsoft純正の設定移行ツール等でもそのような設計になっていたと記憶しています。

理由はものすごく簡単なことです。もう少し考えてください。

こんばんわです。ひでみです。

酒屋の息子さん。

> 私もよくgoogle先生にお世話になってます。ただ、必ず裏は取りますし
> 完全には理解できなくともある程度納得した上で流用させてもらっています。

検索エンジンの使い方はかくあるべし、だと思います。
本でもサイトでも、あるいはテレビや新聞のニュースでも、鵜呑みにすることは危険だと思っています。たいがいのことは裏をとるのが困難なのであきらめますが、とりあえず疑う気持ちだけは持っておきたいと思っています。
そして、せめて自分の仕事のことくらいは、可能なかぎり自分で確認をとるように心がけています。とは言っても、なかなか徹底できないんですよねえ、これが（時間が足りなかったり、根性が足りなかったり）。

Masaさん。

フォローありがとうございました。

それと、昨日のコメント返しが舌足らずで申し訳ありませんでした。
いろいろと考えてみたんですが、いまだにうまくまとまりません。私なりに納得のいく答えがみつかったら、いつかお返事を書かせていただくかもしれません。

> 勉強不足でしょう。

プログラマって、サラリーマンだと思うのですけど。。

おっとっと、釣られるわ、他社を利するわ(ry

// ぜろさむ・げぇむ。

> (そう言わないと私がかみつかれそうですので)
別にかみついているつもりはないのですが…。

> 理由はものすごく簡単なことです。もう少し考えてください。
すみません。
「ものすごく簡単なこと」を前提に考えてみたのですが、わかりませんでした。
もしよろしければ教えていただけないでしょうか?

－作業済んだけどデータ移行プログラムを入れたフォルダ消せば何もかも全部消えるよね？
「レジストリに設定が残っていますが」
－え？それはどうすれば良いの？
「気になるならレジストリ・エディタで消してください」
－レジストリ・エディタ？なにそれ？一時的なプログラムなのに…
「それは勉強不足でしょう」
－申し訳ありません…orz

そうか。アンインストーラがないんですね。

常に楽する方法を考えている人なら、複数台の古いＰＣから複数台の新しいＰＣへの移行を行う（１：ｎ、ｎ：ｎ）とき、設定は１回で済ます方法を真っ先に考えると思うのだが。
まあ、仕様書の書き方に問題もある（※１）のだけれども、「ものすごく簡単なこと」を前提に考えてもわからないって・・・現役の自称プログラマとか自称ＳＥだったら一緒に仕事したくねえなあ。

※１・・・通常は設定ファイルもしくはシステムファイルなど、そのシステムでしか使用しないテキストファイルですよと明言する。コンフィグファイルは、ＯＳの設定ファイルと混同するため使用しない。（ドライバの場合は実際にコンフィグファイルに書き込むこともあるので。）
↑全てオープン系の話ね

> 常に楽する方法を考えている人なら、複数台の古いＰＣから複数台の新しいＰＣへの移行を行う（１：ｎ、ｎ：ｎ）とき、設定は１回で済ます方法を真っ先に考えると思うのだが。
なるほど。同じ設定を使いまわせると。
こういう環境では確かにおっしゃるとおりですね。

> 現役の自称プログラマとか自称ＳＥだったら一緒に仕事したくねえなあ。
まあ、私とは仕事することないから大丈夫ですよ。

どういう動作をおこなうプログラムかにもよりますし、
どういうユーザーを想定するかにもよりますし、
使い方をどうユーザーに理解してもらうのかによりますけど、

「普通は」書き込みアクセス権があるかどうかわからない実行ファイルのあるフォルダに
書き込みする必要のある設定ファイルを作らせるようなことをしないとは思いますよ。

しかし、よく考えれば用途が限定されているのであれば、むしろ当然ですね。
> データ移行ツールなどという一時的にしか使わないアプリケーションのために、
> レジストリを持ち出してくるなんて話、きいたことがありません。
この部分への突っ込みは撤回して謝罪します。_o_

ひでみさんこんにちは。

盛況なようで(笑)
本編と関わり無いコメントで恐縮です。

> Atsushi777 さん

> 「ものすごく簡単なこと」を前提に考えてみたのですが、わかりませんでした。

それって本気で言ってます？
「売り言葉に買い言葉」なのなら、やめておいた方が良いです。
少なくとも、パワーユーザーレベルの知識があれば十分わかる事だと私はおもいます。

反論するのであれば、「反論する理由」及び「双方のメリット・デメリット」を「反論する者」(この場合、Atsushi777 さん)が示すべきです。
リファレンス引っ張ってきて「こう書いてあるのだから、そんなのはおかしい。」みたいに言ってしまうのは、愚の骨頂ですよ。ただ「噛み付いている」と思われてもおかしくないです。

物事の本質を踏まえて柔軟に考えてはいかがでしょうか？

Algolさん。

.iniファイルを使うか、レジストリを使うかは、
まさにそのメリット・デメリットに応じて決められるべきものだと思います。

その仕様書を読めば自明なのかもしれませんが、
『「データ移行ツール」のようなもの』がどちらを使うべきかが、
それほど自明なこととは思えなかったので。

迷言さんがかかれているような話であれば、
.iniファイルを実行ファイルと同じフォルダにおいた方が
メリットがあるというケースが多いことでしょう。

リファレンスを示したのは、「聞いたことがない」というので、
.iniファイルを扱うAPIがそもそも、deprecatedだということを示したにすぎません。
どちらでもいいケースなら、わざわざdeprecatedなAPIをつかうことはないですよね?

売り言葉に買い言葉というつもりはまったくありません。

なつかしいですね。「新人教育」。自分もやりました。ひでみさんも既に
理解していることと思いますが、新人教育には新人を教育するという目的
の他に隠された青写真があります。つまり、管理者と教育者の育成ですね。
色々な新人がいるので一括りには言えませんが、どんな事にも「すなお」
に接した人の成長が早かったように思います。教える側も例外ではありま
せんでした。普通の社会人や、せいぜい優秀なプログラマにするにはこれ
で十分でした。後に経験したことですが、極めて困難な課題を解決できる
才能は、天性のものだと感じました。これらの人々は誰にも頼らずに粘り
強く課題に取り組む集中力が抜群です。例の新人君もその才能があるかも
知れません。暖かく見守りましょう。自分も
　　「自分で説明できないコードを1行たりとも書くな！」
と言っていましたが、それもふまえ、後にこう考えるようにもなりました。
　　「人が解決済みの問題をもう一度解決したりするな」
とは言うものの、自分で解決しないと納得できなかったりもしますが
自分は(笑)。

saki1208です。

横槍すみません。

ひでみさんの発言にある「データ移行ツール」がどのようなデータの移行を
目的としたツールかは文面だけではわかりませんし、使用方法も想定できま
せん。
例えば市販のOS引っ越しツールみたいな個人使用を想定した移行ツールなら
レジストリに設定を保存するのもありでしょうね。
でも会社の日常業務で使用するようなシステムのデータ移行ツールならエン
ドユーザが設定を変更することは想定していないかもしれません。

「コンフィグファイル」と書かれているところを「レジストリ」に読み替え
る必要はないですよね。
# 相手が新人であるということを考慮するならば、コンフィグファイルにつ
# いての説明が仕様書に必要だったということでしょう。
# コンフィグファイルの書式等の標準仕様が社内で統一されていて通常は特
# に記述していないなんてことも考えられますから...

新人でないなら...
「コンフィグファイル」を「レジストリ」に脳内変換するような人と仕事す
ると大火事になりますよね。それこそ進捗管理だけじゃなく、コードレビュ
ーしないと...
# 企業ごとの文化が絡みますから一概には言えませんが、レジストリに保存
# するなら「レジストリ」と書くんではないですかね?

連投すみません。

なんか中途半端でした。

前半の移行ツールについての件は、使用目的の違いで設定をどこに保存する
のがよいのかなどの前提が異なりますのでもう少し詳細が提示されている状
態でなければ議論しても意味がないという思いがあり書きました。

こんばんは。Masaです。
本筋から離れた話題を延々続けて申し訳ありません。

> Atsushi777さん

なんでそんなに居丈高なのでしょうか？人に教えを請うているのに。

それはともかく、「メリットがある」というレベルではすまない問題がありますのでその点を記載します。(私は「OSの標準設定格納場所に保存はしてはいけません」と書きましたよね？)

1.「データ移行ツール」のようなものはリムーバブルデバイスに保存して使いまわすことが多いです。リムーバブルデバイス上で使うソフトウェアの設定をレジストリに保存してはいけないのは当然ですよね。

2.移行ツールの情報を移行元システムに書きこんでしまうと誤って自分の設定を移行してしまう危険が生じます(移行したその設定が次回移行時にどのようなトラブルを引き起こすかを想像してください)。そんな事故を起こさないために移行ツールの設定はプログラム自身と同じ場所に保存するか本体を自動解凍書庫にしてプログラム内部に格納すべきです。

以上が答えですが、フィールドを知っていればこの程度は感覚的にわかりそうなものです。もしサポートデスク等フィールドを知らない現場で仕事をなされているのであればフィールドの状況を少しは理解できるよう努力されることをお勧めします。

> saki1208さん

プログラマが特定企業向けにカスタムメイドで作る必要のある移行ツールといえば、大量のPCデータ移行をする際にCEがリムーバブルメディアに格納して使いまわす、移行自動化ツールくらいしか私は思い浮かばないです。

もし他のプログラムを作ることがあるなら、それは後学のために知りたいです。

saki1208です。

>Masaさん
MasaさんのおっしゃっているのはOS間のアカウント移行やユーザドキュメントの
移行を行うツールですよね?
それをカスタムメイドする前提の移行ツールではないですか?

私が言っているのはそういったPC間の移行やOS間の移行を行う類いの移行ツール
ではなく、システム間のデータ移行などを行うツールです。
例えば、システムリプレースなどで旧システムから新システムへデータベースの移
行を行うなどとした場合にDBのバージョンが変わるとかRDBMSが変わるとかでは
それぞれのマイグレーションツールを使うことが多いと思いますが、テーブル/項
目の増減やそれをある程度汎用的に処理できるようなデータ変換ツールとして作る
とした場合の話ですね。

データ移行といっても「いろいろなデータ」があり、移行する内容も違えば方式も
違って当たり前だと思います。
一般論としての解はあっても正解は一つではありませんし、お客様、使用状況に
よっても変化します。
# たとえお客様からの依頼でレジストリを使用するような指示を受けても私はレジ
# ストリは使いませんけどねw
# 最近は見ませんが、よく壊れるし...
# ちなみに最近のMSはレジストリを推奨していないと思います。

>1.「データ移行ツール」のようなものはリムーバブルデバイスに保存して使いまわすことが多いです。リムーバブルデバイス上で使うソフトウェアの設定をレジストリに保存してはいけないのは当然ですよね。
>2.移行ツールの情報を移行元システムに書きこんでしまうと誤って自分の設定を移行してしまう危険が生じます(移行したその設定が次回移行時にどのようなトラブルを引き起こすかを想像してください)。そんな事故を起こさないために移行ツールの設定はプログラム自身と同じ場所に保存するか本体を自動解凍書庫にしてプログラム内部に格納すべきです。

引用部分の1、2ともにあなたのおっしゃっている内容は至ってまともな内容だと
思いますよ。
# 1は情報漏えいなどの観点も含め移行先にゴミ、余計なものを残さないこと
# 2は障害時の切分け等も含め元データは元のままの状態で残すことが望ましいこ
# となどを考慮した上での発言であると認識しています。

また書き忘れorz

もちろんレジストリを使用しないのは使用しない理由、代替案等を説明し了承を
得た上での話ですよ。

こんばんわです。ひでみです。

Atsushi777さん。Dannaさん。迷言さん。Algolさん。saki1208さん。Masaさん。
ひとまとめにしちゃってすみませんです。

このコラムの本筋からはずれてしまうので、あえて具体的なことを書かなかったんですが（仕事内容を外でしゃべるな、という教育が浸透しすぎていて、問題がないだろう場合でも避けてしまうという習性もあったりして）、どうも混乱の元になっているようなので説明させていただきます。

「データ移行」というのはデータベース内のデータの差し替えでした。
使用していた言語は Visual Basic 2005 で、仕様に書かれていた「コンフィグファイル」は app.config をさしていました。
Visual Basic 2005 において app.config は扱いがとても簡単で、新人に使わせてもまず失敗の余地がなく安心ですし、環境変数は app.config に記述する、というのはVBではデフォルト的な仕様になっていると思います。
「コンフィグファイル」ではなく「app.config」と記述していれば行き違いがなかったのは確かです。この点に関しては配慮に欠けていました。app.config は言語固有のものなので、仕様書には汎用的な表現として「コンフィグファイル」と書いてあったんだと思います（経緯を覚えていないので推測ですけど）。

けれど、きっかけがたまたま「コンフィグファイル」→「レジストリ」だっただけで、仕様に誤解の余地がない書き方がされていたとしても、別件でなんらかの行き違いが発生していた可能性はかなり高かったと思います。
誤解の余地のない文章を書き続けるって、ものすごく難しいですから。

仲澤＠失業者さん。

> 自分も
> 　　「自分で説明できないコードを1行たりとも書くな！」
> と言っていましたが、それもふまえ、後にこう考えるようにもなりました。
> 　　「人が解決済みの問題をもう一度解決したりするな」
> とは言うものの、自分で解決しないと納得できなかったりもしますが
> 自分は(笑)。

「人が解決済みの問題をもう一度解決したりするな」というのは、せっかく先人が苦労して解いてくれたんだから、ありがたくその成果をいただいちゃおうよ、といったところでしょうか。
それはごもっともですね。
この解決方法を思いついた人はえらいなあ、と思うことはよくあります。
以前は、そういうものは雑誌とかで紹介されない限りは、ほぼクチコミで伝わっていたと思うんですが、今ではネットであっという間に広まります。
そういう点では、ネットは本当にありがたいものだと思います。

ひでみさん、こんばんは。
saki1208です。

なんか同じ作業だと言われてもあまり違和感が無いような...

それは置いといて、「車輪の再発明」と言うヤツですねw
ただ、フルスクラッチでシステムを作っている方は多少理解していただけると
思いますが、どんなに優れた発明(この場合責任の所在がはっきりしない無償の
ソース/ソフトウェア/ハードウェアと言うことになるでしょうか?)であっても
費用をいただいて構築するシステムに利用するというのはあまりよいものでは
ないですから再発明もしょうがないのかなと...
今は昔と状況が違うのでお客様からの指定ではなっから使用している場合もあ
りますけどね。

# まぁ、自分がこだわったところで世界的にメジャーなソフトウェアベンダー
# であっても利用している場合もあるわけですから意味がないかもしれません
# が...
# ただし、そういったベンダーでは自社でサポートを行っているでしょうけど。
# あんまり厳密に言い出すと使えないものがたくさん出てきますし...

> 「データ移行」というのはデータベース内のデータの差し替えでした。
> 使用していた言語は Visual Basic 2005 で、仕様に書かれていた「コンフィグファイル」は app.config をさしていました。
なるほど。勝手に勘違いして申し訳ないです。

なんだか私の表現が居丈高に感じられるようで、
不快に思われた方々申し訳ありませんでした。

＞Masaさん
Atsushi777さんのどのへんの発言を居丈高ととらたのですか？
何度読み返しても分からないので。。

どちらかというとあなたのほうがよっぽど居丈高では？

同じ教えを請うにしても
かたや「もしよろしければ教えていただけないでしょうか?」
かたや「もし他のプログラムを作ることがあるなら、それは後学のために知りたいです。」

>フィールドを知っていればこの程度は感覚的にわかりそうなものです。
>もしサポートデスク等フィールドを知らない現場で仕事をなされている
>のであればフィールドの状況を少しは理解できるよう努力されることを
>お勧めします。
あとこれがどうにも分からない。自分の常識はみんな知っていて当然で知らないなら勉強しろと？なんて居丈高な。

>Atsushi777
すみません。勝手にお名前使ってしまいました。
どうしても理解不能だったので。

でもレジストリには書かないです。

こんばんわです。ひでみです。

ushi3さん。

話に割り込んで申し訳ありませんが、正直なとこを言っちゃえば私もAtsushi777さんのコメントを威圧的だと感じていました。
ご本人にそのつもりはまったくないのかもしれませんが、「間違いを認めろ」と迫られているような感があると言うか……。
問いかけられている本人と、傍から見ている人で、受ける印象が違うのかもしれませんね。
とにかく、私はそう感じていたので、Atsushi777さんへの直接的なコメント返しは避けていた次第です。

コンフィグファイルとレジストリに関する話はとても有意義だったと思いますが、どのような言葉がどのような印象を与えるか、という話題が、この記事のコメントとして適切とは思えませんし、感情的な方向に話が進むおそれが多分にあります。
Masaさんが反論なさりたいというのなら話は別ですが、できればこの話題はこれ以上、広げないでいただきたいんですが……。

>ひでみさん
コラム主のひでみさんがそうおっしゃるならそれで構いませんが。。
だったら最初にMasaさんがAtsushi777さんに居丈高だと発言したときに同じようにそうゆうのなしっておっしゃればいいのに。
なんだかずいぶん都合いいですね。

>Masaさん、Atsushi777さん
ということなので、失礼いたしました。
返信不要です。
もうしわけございませんでした。

そういえば私が新人だったころ。
厳しい先輩に
「不精するな（手を抜くな）」とよく言われました。
しかし、
「もたもたせずに要領よくやれ」ともよく言われていたのです。

当時、この２つが矛盾しているとしか思えず、無理難題を言われているように感じていましたが、今ではよく分かっています。

・アウトプットの品質は絶対に落とすな。
・同じ品質を出せるならば、できるだけ速くやれ。
・”不確実だが速くできる”方法と”確実だが時間はかかる”方法が考えられる場合は、”確実だが時間はかかる”方法でやれ。
・”確実だが時間はかかる”方法でやる場合は、それをやる時間をきちんと確保せよ。
こういう考え方の帰結が「不精するな」「要領よくやれ」という言葉であった、と。

・・・新人には分からないっす（笑）
でも今では「不精するな」を肝に銘じ、折に触れて唱えています。
「私はいま、面倒な仕事で不精しようとしてたよな（苦笑）危ない、危ない」と自分を戒める。

「悩むな」とも言われてました。これは・・・悩んでも確かに無駄です（笑）
大抵は、悩んでいる時は迷っているだけ。判断ができないでいる。
判断方法が無いなら、とにかくやってみる。やってみてダメだったら、そのときは別の方法を試す。

先人の言葉は、分かる人にはいつか分かる。
分からない人には、いくら説明してもいつまでたっても分からない。

結局のところ、SE・プログラマなんてもんは「出来る人の理論」でしか説明できないということでしょうね。
皆、分からない人のポジションにまで降りて説明なんてしないので、教えられた方もその説明自体が今ひとつ分からないのに、すぐ「なんで分からないの」「ちょっとは調べてよ」とぽろっと言う。
同じ調子でwebに書いたりするから、その記事は圧倒的な説明不足で欠陥だらけ。

結論には100%同意できますが、姿勢には全く。
教育にアクティビティ振りましょう。片手間でなんとかなるって考えが既に迷惑なんですよ。

saki1208です。

手は抜いてもいいと思いますよ。
同一の結果が残せるのならば...
# 抜きどころを間違えるとひどいことになりますけどね。

こんばんわです。ひでみです。

ushi3さん。

すみません、説明がちょっと足りなかったようなので、補足させていただきます。

表現が不愉快もしくは不適切だ、という旨を指摘すること自体は、まったく問題ないと思っています（ただの攻撃になっては困りますが）。
なので、Masaさんが「居丈高だ」と指摘されたことと、ushi3さんが「どこが居丈高かわからない」と指摘されたことは、私の中では同レベルな扱いでセーフになっていました。
ushi3さんも同じようなものだと判断されたので、Masaさんを止めずにushi3さんを止めたのは不公平だとお感じになったのかと思います。
今回、話をさえぎったのは、そこから派生した話題がアウトな領域まで飛んでいってしまいそうな気がしたので予防措置をとらせていただいた、ということです。
気配なんていうあやふやなもので対応を変えたのか、と言われると、反論のしようがないんですが……。
念のため断っておきますが、MasaさんやAtsushi777さんが信用ならない、ということではありません。それを火種にしてムダに話を燃え上がらせる人が入ってくることを警戒した、ということです。

そんなあやふやな理由では納得できないということでしたら、話を振り出しに戻すことは止めません。
ushi3さんの次のコメントを私が削除・編集しないことをお約束いたします（ただの攻撃と判断した場合は別ですけど）。

真っ赤なレモンさん。

> ・アウトプットの品質は絶対に落とすな。
> ・同じ品質を出せるならば、できるだけ速くやれ。
> ・”不確実だが速くできる”方法と”確実だが時間はかかる”方法が考えられる場合は、
> 　”確実だが時間はかかる”方法でやれ。
> ・”確実だが時間はかかる”方法でやる場合は、それをやる時間をきちんと確保せよ。
> こういう考え方の帰結が「不精するな」「要領よくやれ」という言葉であった、と。

わっ、わかりやすい……。
新人の頃はどれが確実な方法なのかも、自分がやろうとしている方法にどれだけ時間がかかるのかもよくわからないんですよね、実際のところ。
新人の頃はわからないし、できない。
それでも、こういうことはきちんと伝えておくべきだと私は思うんですが、新人を混乱させるだけだからやめとけ、という意見もあったりして……難しいです。

今では教える立場さん。

> 結局のところ、SE・プログラマなんてもんは「出来る人の理論」でしか説明できないということでしょうね。

私が私の理論でしかものを語れない、というのは事実だと思います。
なぜ、システムエンジニアやプログラマに限定されているのかがよくわかりませんが……。

saki1208さん。

> 手は抜いてもいいと思いますよ。
> 同一の結果が残せるのならば...

本人は同一の結果が残せると信じてたけど、実際は違ってた、というパターンが、一番めんどくさいことになりそうな気がします。

自分は新人に毛の生えた程度ですが、
　入社1～2年の間は「ググれ」のみが先輩の助言でした。
　特に1年次はＳＥとして入ったのに、「ＳＥはプログラムをしてはならん」という部長命令で(実装に偏った設計思想が身についてしまうためだとか)なぜか同期の中で私だけプログラムでなく雑用ばかりやってました。
　そのまま2年目でプログラムのイロハも分からないまま、「ググれ」と「なんとなく分かるよ」という助言だけでやってきたので大変苦労しました。推薦図書も聞いたんですが、「ググッた方が早いよ」で一蹴されましたしね。
　そして、いざ実装をしてみれば、ひでみさんの記事の通りの新人です。
　
　結局確実なことは「ググる」というツールはその人の経緯と個人の力量そして会社の教育スタンスによっていか様にも左右されるんだということですよね。ただこのツールの特徴は振れ幅が大きい分、「新人」が多用すべきものでないことは確かです。会社のスタンスならば完全に社員教育の丸投げです。
　私は少なくとも、「ググる」を推奨していないＳＥや会社を信用しますね。推奨している人は確実に「動けばいい」としか考えてないと思います(実際弊社のソースは汚いソースとバグの宝庫ですww)

こんばんわです。ひでみです。

ひいさん。

「ググれ」だけでプログラマを育てようって、どんだけチャレンジャーな会社なのかと思うんですが……。
「動けばいい」と本気で信じているコピペプログラマは、自分でコードが説明できないので、教える際には「ググれ」としか言いようがないのかもしれません。

こんにちは。しっぱです。
レス頂きましてありがとうございます。

>けど、仕事ではそれを使い続けるお客様がいらっしゃるということを、最初っからきちんと教え込まなければならないという意識は、正直、抜け落ちていたと思います。コーディングばかりにこだわりすぎていたのかもしれません。

そうなんですよね・・・・
私もSIer時代は実際のユーザーさんの顔があまり見えず、ここが抜けていた時代がありました。
ですが、良い経験をさせていただいたことがありまして、それ以来下記の2点は絶対に守るよう心がけています。

・オペレーションに対する理解をしてから開発
・他人に渡しても読みやすいコーディング
　⇒性能部分と相対する部分が出てきたりして結構悩みますが・・・・
　　開発のみで保守は別会社ってこともありますしね！

今考えると、以前いた会社で耳にタコができるくらい聞いた言葉「手離れの良いプログラム」というものに包含されていたんだなとしみじみ感じます。

私の場合、そこまでひどくはないですが、同じような状況はありました。
そこで、３つのことを心がけ、それなりに効果があったと思いますので、のせておきます。

１）自分の記述したソースには責任を持たせる。
具体的には、ソースに自分の署名させることや、バージョン管理などで、誰が直したのか、もしくは作ったのか明確にすることです。
やはり、間違ったものや、とんちんかんなものが自分の名前をつけて、ずーと、残ってしまうことはいやだと思うので、それはいやだなーという感情を常に持たせてあげる。

２）みんな、理解するために苦しんでいるんだという事実と、勉強して到達できないレベルでもないということを理解させる。
できる人をみて、センスが違うからとか思ってしまうものだが、わかる人もセンスなどではなく努力した結果であって、努力さえすれば到達できるレベルのことである。という事実を教えてあげる。
私は、自分の机に読んでほしい本を置き、それを見ながら解決するという姿を見せることで、質問に来なくても、その本を見せてくださいというお願いが来るようにはなりました。

３）会社内部からではなく、外部のメディアを使ってその人に訴える。
ちょっとこれは大変ですが、たとえば、ググった結果が自分のサイトだったりしたらどうでしょうか？
そしてある時、そのサイトは自分のサイトだよ。って教えてあげる等。
会社内部から先輩としての意見よりかなり効果があると思います。
もしかしたら、「あー、そりゃググるは信じられないな。」思ったとしてもそれはそれで、効果があることでしょう。

はじめまして、某所でここへリンクを見つけまして
内容を読ませていただきました。

題名の「ググるな危険」よりも
「自分で説明できないコードを1行たりとも書くな！」が
本命なんだと思います。
ググる事自体が問題ではなくて理解できないままコピペしている事が問題なんですよね。
私も一緒に仕事をしている後輩達に言葉は違いますが、
全く同じような事を言います。
何をやっているのか、どうしてそれをやるのかがわからずに
コードを書いてはいけないと言う話です。

内容を理解しないでコードを流用しても全く応用が利かず、
改修もままならない状況になるだけです。
この辺の所は結局時間を掛けて実感してもらうしかないよなぁ
と言うのがもっぱらの実感です。

話が少し変わりますが、
一足飛びにアプリを作ろうとしてわかりませんを連発するケースを
時々見ますけれど、こう言った技術は一朝一夕で身につくものでは無いので
ステップバイステップと言う考え方の必要なのではと思います。
会社だとなかなか時間を掛けて教えてあげられないのも事実ですけれど。

こんばんわです。ひでみです。

まさぼうさん。

> みんな、理解するために苦しんでいるんだという事実と、
> 勉強して到達できないレベルでもないということを理解させる。
> できる人をみて、センスが違うからとか思ってしまうものだが、わかる人もセンスなどではなく
> 努力した結果であって、努力さえすれば到達できるレベルのことである。
> という事実を教えてあげる。

これを教えるのはなかなかむずかしいです。
ネガティブな性格の子はそういう話も自慢話ととらえるようで、「できる人はみんなそう言うんです」で話が終わってしまい、どういう言い方をすれば受け入れてもらえるのかがわかりません。
これはもう、繰り返し言い続けるしかないんでしょうかねえ。
だいたいの子は「まだ始めたばっかりですから、これからがんばればいいんですよね！」という感じになるんですけど。

ＰＡＴＩＯさん。

> 内容を理解しないでコードを流用しても全く応用が利かず、
> 改修もままならない状況になるだけです。
> この辺の所は結局時間を掛けて実感してもらうしかないよなぁ
> と言うのがもっぱらの実感です。

やはり、このやり方は最終的に損だ、ということを実感しないことにはどうにもならないんですかねえ。
こういうコードで成功体験を与えたらマズい、と思っていたんですが、あえて失敗体験を与えろ、というのもひとつの考え方かもしれません。なんかちょっと目からウロコです。

ちょっと視点を変えて・・・
新人さんが「ググる」と危ないのはもう一つIPの問題もありますよね。
気軽にコピーしてきたコードの断片(もしくは全部)のIPをちゃんと確認しているのか？

ネットに転がっているコードの断片についてライセンスが明示的に示されていることなんてあまりありませんし、ましてやGNUライセンスのコードをカジュアルに「パクッて」きた時は、商用のアプリケーションであれば目も当てられないことになります。

新人さん(ベテランさんもそうですが)が、ちゃんとIPを確認しているのか、ということについては怪しいことも多いんじゃないかと思います。

そういう意味では「自分で説明できないコードは・・・」の下りはこの問題でも有効なのかな？

さらに視点を変えて・・・

そもそも、「インターネットの使用が許可されている環境」で仕事がするのが当たり前なんだろうか？
ググりたくてもググれないとき、どうするつもりなんだろう？

私の業務経験の半分は、「そもそもインターネットがなかった」と「セキュリティの関係で使用禁止」だったので。

こんばんわです。ひでみです。

えのさん。

> ネットに転がっているコードの断片についてライセンスが明示的に示されている
> ことなんてあまりありませんし、ましてやGNUライセンスのコードをカジュアルに
> 「パクッて」きた時は、商用のアプリケーションであれば目も当てられないことになります。

一応、本文中にも著作権を侵害しない限りという注意書きを入れていたんですが、考えてみれば、著作権を侵害しているのかどうかを判断するだけの知識がない、という可能性もあるんですね。
そこまでは思い至りませんでした。想像するとめちゃくちゃこわいです。

CMPさん。

> 私の業務経験の半分は、「そもそもインターネットがなかった」と
> 「セキュリティの関係で使用禁止」だったので。

私も同じようなものです。正社員はインターネットが使用できるけど、派遣社員はイントラネットにしかアクセスできないなんていう会社もあったりしました。
そういう環境に陥った時、検索エンジンに頼っている人はどうするんですかね？
ネット環境が整っているのがあたりまえで、そうでない環境で働くことを想像することもないのかしら？

「プログラマで生きている」から一気に読ませていただきました。
おもしろい。非常に共感します。私も自分が作りたいモノは特にない。
データ（多量なほど「良し」とします）を最速で右から左に受け流す作業が好き。
シンプルで美しいロジックなら結果「最速」になるハズですもんね。
私も20年超のプログラマ歴を持つ１児と３匹（猫）の母です。児とか言っても私よりはるかにデカいけど。70になっても80になっても、流行の言語でソフト作っちゃうサイバーばーちゃん目指して修行中です。私は全くの未経験から学歴なし、資格なし、特技なしでこの業界に入ったので、Ｃ○ＫとかＣ○Ｃの新人様たちからは人間だとか思われてないんだろうな。外注をおだてていつまでもこき使う方が経営的にお得だと思うんだけど、そんな思考回路だから、私はいつまでたっても小市民なのかな。
大体、設計が良ければプログラムなんてそんなに多くのパターンないんだから、彼らの評価による「最低」のプログラマだってうまく使うのが腕の見せ所だろうに。強将の下に弱卒なし、だと思うんだけど。
ひでみさんが「いろいろ」遭遇したような状況に陥ると、私は記録モードにシフトします。で、忘れないように相手の名前をメモっておく。その後、趣味の小説に悲惨な役で登場してもらう。ちょびちょび版デスノート。いや、バーチャルな世界での仕返しが主目的ではありませんよ。最後には幸せになる主人公の名前は同名の人に読まれても問題ないけど、悲惨な最期を遂げる人の命名って心理的に厳しいじゃないですか。そこをちょこっとご協力頂く。しかし、このような図々しい発想が出来るようになってからは理想的な協力者が少なくなってきたような……。
さあ、ひでみさんのコラム読んで元気回復したので、春になったらまた協力者探しの旅に出ようかな。

こんばんわです。ひでみです。

ちょびちょびさん。
私の文章を読んでちょっとでも元気になっていただけたなら幸いです。
なんか私も元気をいただきました（手厳しいコメントに地味～にヘコんでたりしたんですのよ、正直なところ）。

> ひでみさんが「いろいろ」遭遇したような状況に陥ると、私は記録モードにシフトします。
> で、忘れないように相手の名前をメモっておく。
> その後、趣味の小説に悲惨な役で登場してもらう。

これは名案ですね！（笑）
小説じゃなかったらどんな手があるかな……。前向きに検討してみます（爆）。

大変面白く読ませて頂きました｡
自分を振り返り反省したり､そういえばあんな後輩がいたよなと思い出しました｡
以前あった事を思い出しました。
「ちょっと教えていただきたいんですが」という後輩に考え方のヒントを伝えると
「ヒントじゃなくて答えを教えてください」私という後輩がいました
「なんで答えを教えなくてはいけないの？答えは自分で見つけないと」と言ったら「じゃあ、いいです。もう二度と聞きません」と言われました。
随分なめられたもんですが､その後輩よりいくらかマシなのかもしれません。
当時はネットなんて便利なものはなかったから､人に聞くしかなかったけど､姿勢というか態度というか､そういったものはこの後輩と同じような気がします

私は全くダメダメな頭だから人のソース見て判らないで使って動かしてみてやっと理解するを繰り返してやっとこ自分で考えられるようになりましたが、当初､わからない所を聞く時はちんぷんかんぷんな質問してた様で「何を言ってるのか判らない」としょっちゅう言われてたので質問するのが辛かったですね
私は凄く遠回りする、たまらない後輩です
ひでみさんの後輩が”私の後輩”タイプでなく”私”タイプならその後輩も今後、この世界では苦労するだろうなあと思っています
（隋分前なので苦労してるだろうな、かな？）

何タイプとかいろいろ書きましたが､実際の所､私はその後輩は､全部知らないと始められない人ではなく､楽して結果を出したい人だったと思います
聞かない理由は案外「女の人に聞くのが嫌」だったかもしれません
この仕事って案外「女かよ」と思っている人もいます。
以前後輩が付いた時これをダイレクトに言った奴がいました｡
こういう人に限って何か言われた時の言い訳は怠らないです

「きちんとしたコードを書ける人になってくれること」
うんうん、よくわかります
昔でも今でも、この気持ちに変わりないのだと思います
私もそう言ってくれた人の言葉は忘れていませんし､今でもそうあろうと思っています
ひでみさんのコラム面白いので今後も楽しみにさせてください

こんばんわです。ひでみです。

よみこさん。

> 「ヒントじゃなくて答えを教えてください」私という後輩がいました
> 「なんで答えを教えなくてはいけないの？答えは自分で見つけないと」と言ったら
> 「じゃあ、いいです。もう二度と聞きません」と言われました。

これはすごすぎますね。私だったら、本当に二度と何も教えないと思います。

> 聞かない理由は案外「女の人に聞くのが嫌」だったかもしれません
> この仕事って案外「女かよ」と思っている人もいます。
> 以前後輩が付いた時これをダイレクトに言った奴がいました。

以前「女は仕事ができないからチームにいれたくない」と言った人がいました。
そう思っていること自体バカですが、それを口にしちゃうなんて救いようのないバカだなあ、と思いました。
口にしなくても、「なんで女？」と思われてるなあ、と感じることはたまにあります。どうしてだかそういう気配は察知できるものなんですよねえ。

はじめまして。
私は社会人2年目のペーペーですが、
なんとまさにこの新人のようではないか！とひどく痛感致しました･･･。
先輩への質問の仕方を考えるうち、自分で調べた方が早いのではないかと誤った方向に突き進み、気付いたら無駄に時間が過ぎている･･･。

この記事を読んで、入社した頃にお世話になった先輩から「30分悩んだら訊きに来い」と言われていたことを思い出しました。
（そう言われた理由もよくわかりました･･･。）
異動後の現在の先輩が「まずはググって調べて」と言う方に代わったためか、最近はそのことをすっかり忘れておりました。

給料泥棒だった自分を反省するきっかけとなりました･･･ありがとうございます。

こんばんわです。ひでみです。

エリさん。はじめまして。

なんかちゃんと通じてるみたいで、うれしいです。とてもうれしいです。ありがとうございます。めっちゃ報われた気持ちになりました。
そうなんです。「迷子になったらいつでも助けてやるよ～。でも、SOSは自分で出さないとダメだよ～」ってだけのことなんです。
自分で調べることは大事です。でも、最初のうちは調べてもわからないことがたくさんあって当然ですから、どうぞ先輩を頼ってください。
って、エリさんの先輩さんじゃない私が言うのはどうなんだろう……（苦笑）。

Ｓｏｄａ さん。

> 今は、まったく別の視点で、ググると危ない場合もありますね。
> Webにあるサンプルコードや解説が間違っている場合です。
> サンプルコードは、一応動作する形になっているものは性質が悪いｗ
> 検索で始めに見つかるものが間違ってると、間違いの伝染率は高くなりますよねぇ。
> まぁ、悪意をもって間違えることは少ないんですが・・・
> 多くの場合、第三者が間違いを指摘して修正されます。
> しかし、間違いを書いたことを認めるのが嫌だったり、間違いを指摘されて恥を書かされたと思われるような人もい居ます。
> こういう人が初心者用の解説を書いてると、性質が悪いｗ

dankogaiがPHPerをdisる大きな理由の一つがこれですね。
メールアドレスをvalidateする誤った正規表現が蔓延してると。
記憶によれば、メールアドレスのvalidateを正規表現で行うのは
不可能で、外部のメンテナンスされているライブラリ
(CPAN, Ruby gemsなど)を使うのが正しいとdankogaiは言ってた気がします。

＃dankogaiマンセーではなく、非常に参考になる考察を含むネタとして
＃受け止めるのが良いとは思いますが。
＃ちなみにPHPは読み書きしますが、私はPHPerではありません。

PageRankのアルゴリズムでは、こうなっちゃうのは仕方がないのですが。
Googleの検索結果のS/N比はそれなりに高いと思いますが、
データ量が世界最大なので当然ノイズも膨大な量になる。
ですので、紙媒体(WEB+DB PRESSなど)で自分の中にフィルタを作らなければなりません。
検索結果を脳内のGeekフィルタに通すよりも、ブログやTwitterで
Geekを追いかける方が効率的なのは自明です。

「自分で説明できないコードを1行たりとも書くな！」って
大手ではコードレビューやるし比較的当たり前ですが、
書かれたコードの1行が担う価値的に中小ではダメダメみたいです。

＃前者の障害は新聞沙汰になるけど、
＃後者のユーザはそれこそググッても出てこなかったりする。

「おまじない」も可能な場合(自社サーバの設定ファイルとか)は
リファレンスなど出典のURIをコメントに書くようにしています。
最近は長いURIでもbit.lyで短縮できるから助かります。

個人的には、日本語サイトでググると自分のエントリがトップに表示され、
英語サイトの検索結果の30件程度の中からピックアップして読めるように
なるのが、Googleユーザとしての1つのマイルストーンかと思ってます。

＃但し、このマイルストーンの基準で言うと、後半部分はインド・中国の
＃コピペプログラマは無条件にクリアしてしまいますがｗ

P.S. ちなみに、私も性格的にはこの新人君タイプで、
　 　30分ルールを遵守すべき人間です。orz
　 　ですので、スキルの高いGoogleユーザ == 仕事の出来る人
　 　とは限らない。orz

はてなブックマークも含めて、「質問しにくい雰囲気を作る方が悪い」という意見が、わからない。
本文には、「質問しにくい雰囲気を作っていました」とは、書いていない。
むしろ、この新人は、最初から質問しようとしない人だったように思われる。

　とてもいいエントリーなのに、理解できる人より、理解できないor理解したくない人の方が多いとは、残念だ。

　しかし。。。検索結果を無批判に信じる人が多いのか。困ったもんだ。

流石にくぐるの禁止はダメ上司

こいつはくそ上司だ

この人には聞きたくないのはなんとなく分かる。

ライブラリが豊富になった今となっては新人くんの方が正しかったのだな。少なくともコーディングのレベルでは新人くんの方が新しい技術にはキャッチアップしやすいのではなかろうか

中身を全く分かっていないソースをコピペはどの現場でもNGだろう。
ググるにしても他に良い方法はないだろうか？といった考えを常に持たないと駄目だ。
基本的にプログラマーは興味と探求心がないとやっていけない。自ら考え、勉強して設計や実装の選択肢を増やそうとする気がない人はプログラマーには向いていない。

あと、執筆者が上司としてどうかという問題にすり替えるのはナンセンスだ。
この記事に対して時代の経過とともにそういう意見が増える傾向にあるなら、ITの未来はかなり暗いと思う。

あまりに美しい文に感動すら覚えました。
自分はプログラマーですらなく、コードの内容やプログラマーとしての正しさなどは分かりません。
しかしシチュエーションにおいて大変共感できることが多く、ただこんな上司が、または恩師でもよく、あるいは友人としてでもいい、人としてこのような人物に巡り会いたかった人生だった