Diary?

(23:48)

相変わらず某新人のコードとか発想には悪い意味で驚かされる。というわけで本日のアレなやり取りをどうぞ。

public class Foo {
    private Map<String, Hoge> map;
    （略）
    /**
     * 引数 x と y から map のキーが構成されると思って。
     * 引数に対応したキーの有無で処理を分岐させる。
     */
    public void bar(String x, String y) {
        map.get(x+y); //ツッコミどころ A
        if (map.isEmpty()) {//ツッコミどころ B
            （略）
        }
    }
}

えーと、詳しいコードを載せる気力がないのでエッセンスだけ抜粋。要するにメソッド内の分岐にメンバである map がキーを持っているかどうかを使いたいのだけど、どこから電波を受け取ったのか上記のようなコードになってしまった。たった数行でこんだけデカいツッコミどころを書かれると、俺はとても困る。ゲンナリしつつも頑張って対話を試みてみた（そろそろ限界なので明日もっぺん説教だな。説教なんざしたくもねえってのが本音だが）。

---

俺

「まずはこのコードの頭の方、ここで何をやるつもりだったのか説明して」

新人

「map に値がなかったら分岐して処理をしようと」

俺

「ということは、 isEmpty で思ったとおりの処理になると思ったわけか」

新人

「そうです」

俺

「じゃあ、 x + y をキーとして持ってないときに isEmpty の結果が false になると?」

新人

「はい」

俺

「じゃ、どうやって map は x + y がキーにあるかないかわかるんだ?」

新人

「?」

俺

「isEmpty って引数ないでしょ。それでどうやってキーの有無がわかるんだ?」

新人

「その、上の行で get してるところで」

俺

「get した結果はどこにあるの?」

新人

「?」

俺

「get には戻り値があるでしょ、それはどこ?」

新人

「……」

俺

「ないでしょ、どこにも。もしかして、 get しただけで isEmpty とかの挙動に影響があると思ったとか?」

新人

「はい」

俺

「そもそもの isEmpty の Javadoc には何て書いてある?」

新人

「『マップがキーと値のマッピングを保持しない場合に true を返します』」

俺

「……あのさ、 "Empty" って単語の意味はわかってる?」

新人

「いえ、わかんないです」

---

ここで俺の心が折れた。ちなみに上のやり取りは毎回毎回数十秒から数分のフリーズを挟んでおり、その上これはかなり端折ったやり取りなので実際にはどうなのかは推して知るべし。

結局その後もいろいろと指導はしたけど、何かもう根本的なところから勘違いをしているというか、思考の順序が無茶苦茶というか、シナプスの繋がりに難があるというか。俺は今までプログラマになれるかなれないかの差というのは抽象化能力で決定されると思っていて、いわゆる「再帰とポインタ」の話もそこに行き着くんじゃないかと思っていたんだけど、どうにも実はさらにその前の段階で差が出ているようだ。

じゃあその前の部分の「差」って何だろうって話なんだけど、これはもう単純に言語能力なんじゃないかな。いや、これも結局は抽象化能力に還元されちゃうのかもしれないけど、とにかく文章を読み解いたり他人に説明したりする能力の欠如ってのが最大の障壁になってる気がする。でもそれだったら他の知的労働とか全部できないってことになるか?　よくわからん

しかしまったく意味不明な単語があって、しかもそれがメソッド名に使われているという状況で辞書を引かないのは致命的にマズい。別に単語の意味を知らなくてもドキュメントから類推できればそれでもいいという事もあるんだけど（いや本当は全然良くねえけど）、まったくその辺が理解できずにいて平気というのはどういうことだろう。

そういえば前に採用拒否にした奴に対して「自分が理解できない事を認められないので勉強しない」という印象を持ったというかそう分析したんだけど（これは上司もそう分析した）、よくよく思い出してみれば「ゆとりの法則」に似たようなことが書いてあったな。ちとそこら辺に関する事を抜粋してみる。

私たちには、あまり重要でないことを学習するときはスポンジのように新しい知識を吸収するが、本当に重要な事は学習しようとしない傾向がある。これは組織にも、個人にもいえることだ。

教育者は、学習プロセスは4つの要素で構成されると教えている。学習者、指導者、教材、共同学習者である。

開発手法を教えはじめた頃の経験から、人びとは自分にとって本当に重要な事を学習するときには、一時的にパニックになることがわかっている。（中略）そんなときは、あたりを見回して、ほかの人も青ざめていること、ほかの人も冷や汗をかいていることがわかると、学習者はほっとする。

チームは理想的な学習環境であり、コーチとして指導したり、されたりすることが日常の中で欠かせない場所である。

「ゆとりの法則」で組織における学習に割かれているページはそれほど多くないが、それでも充分過ぎる程に重要な示唆を含んでいる。俺は改めて共同学習者の重要性という奴に気付かされたので、どうにかして新人連中を団結させようと試みているけど、なかなか上手くいかないものだ。

中途採用の場合等は入社時期の関係上、研修生の習熟度が凄まじくバラバラなので、むしろ研修生同士で教え合うには好都合だとも思っているけど、なかなかそういう風にはならないのがもどかしい。ちなみに研修生同士でアドバイスし合うような状態になった連中は、サンプルが少ないのがちとあれだけど、そうでない連中よりもずっと良く伸びた。特に講師に対してアドバイスをもらうときに、他の研修生が質問者の発言をフォローするという形になると、教える方も教わる方も非常に楽になる。

こういうのはあんまり押し付けがましくやるわけにも行かないので、一体どうすりゃいいのか途方に暮れている部分もある。先に出した「言語能力」というのは「コミュニケーション能力」に割とダイレクトに繋がっていて、それが欠如してる奴をどうやって周囲に溶け込ませるか、そして俺がどこまで忍耐強く付き合えるかというのがおそらく最終的な問題で、ぶっちゃけ俺は聖人君子じゃねえから我慢の限界ってのがあるわけだ。

さて、明日からマジでどうしようか。