|
ゆとり教育が提唱されてはや○年。当初は詰め込み教育の弊害だなどとの意見があり，効果が疑問視されながらも導入が強行された。ところが，円周率が「およそ3」になったことが示すように，ゆとり制度は基礎知識をないがしろにした教育体系である。
彼らの底なしの使えなさは，近所で塾経営をしている方から，「毛沢東」を真顔で「けざわひがし」と読む大学生が講師をしていると聞いたときから恐怖とともに実感している。その結果，この世代は人材不足になるため同業者間で壮絶な学生の取り合いが起こるだろう。起こらなければ，人事部の世の中を見る目がないということで，それはそれで困るのだが。
この教育環境で育った新人（ここではユトリストと呼ぶ）が社会人デビューするまで，あと1年。その破壊力は想像もつかないが，近年の新人をみるとその傾向がいくらかは見えてきた。いくつか事例を紹介するので，来年以降の新人対策として教訓にしてもらいたい。
最高の指導教官
最近，大手ベンダーでは新人教育が見直されたようで，研修が手厚く行われるようになってきた。いろいろと議論はあるだろうが，私自身はこの流れは非常に良いと思っている。GEだろうがどこだろうが，外資で「ここの社員は頭がよい」と好印象をもたれているような会社では，それこそ信じられないペースで研修が行われているからだ。
ただ，問題は受け手のレベルである。研修内容がすばらしくても受け手に響かなければ無意味だ。この事実を教えてくれるのが最近の新人である。紹介するのは，弊社と取引のあるベンダーでかなり前から研修を指導してきた講師の方のお話し。
そのベンダーでは，新人がシステム開発をロール・プレイング形式で学べるように，きちんと定義された仕様に沿ってシステムを開発する。もちろん仕様には穴も用意されている。各クラスの教官がお客様の役割も兼ねているので，仕様について確認しながら開発を進めるようにもなっていた。
彼の話では，ここ数年，この形式についてこれない新人が増えてきたそうだ。なぜか？ それは，仕様を読んでいてわからないことがあると，教官に確認せずに，まずGoogleで検索するからだ。
どうも最近の学生は，わからないことがあるとすぐに検索する行動パターンを取るようだ。もちろんそれ自体は悪いことではない。私もAPIの仕様などは，すぐにGoogleで調べるようにしている。問題なのは「Google＝正しい」と短絡的に判断する理解力のなさだ。Googleで紹介された説明をそのまま受け入れ，特に理解を深めることなくそのまま引用する。これではその情報が本当に正しいのか，絶対にわからないだろう。
ところが細かい仕様にかかわる説明など，当然ネットには存在していない。そのときは「ここの仕様についてですが…」などと言って教官に確認すればよいものを，それをせずに「ここには皆が正しいと思える正解が無いから，適当に決めておこう」となる。そして仕様とは似て非なるものができあがる。
このベンダーのカリキュラムでは，教官が定期的にアウトプットを確認するフェーズがあるのだが，ユトリストの成果物と仕様との乖離があまりにも大かったので，既存スケジュールでの修正は無理と考え，大幅にレビュー時間を割くように調整したそうだ。このように，ネットによるコミュニケーション・スキル不足と検索偏重が相乗効果を発揮し，他者の介入を許さないある意味「俺様最高」な勘違いアプローチが最近のユトリストには蔓延しているようだ。
検索アプローチには二つの壁がある。一番目の壁は，まずGoogleに情報があるかどうかだ。最近の新人は，ネットにある情報と無い情報の区別もついていないことがある。そのためGoogleに情報が無いと，今度は何も調べずに有識者に聞きにくる。先輩はGoogle代わり，と言うわけだ。これではスキルが身に付かないことは容易にわかってもらえるだろう。
二番目の壁は，上位に出てきた情報を正しいと信じてしまう短絡さ。Googleで上位に紹介されているからといって，正しい情報という保証は無い。しかし，ユトリストにとっては「上位にある＝正しい」なのだ。
学校で英語を教えている知人によると，このあたりの思考パターンは英作文に似ていると言う。英作文では，まず和英辞典で単語を調べる。単語の英語表記にはいろいろとニュアンスがある。場合によっては不適切な表現であるにもかかわらず，一番最初に紹介されている単語を利用して英作文を作る。そのままの意味が和英辞典に無い場合は，すぐあきらめる。おどろくほど思考パターンが似ている。
両者に共通するもの。それは「理解の停止」だ。“調べる→無いならあきらめ，あれば一番最初のを利用”となる。そこには理解を深めようという意思は微塵も無い。その結果，日本人の英語レベルは低くなっており，この面での競争力の無さは皆さんもご存じだろう。技術スキルが国際競争力での英語レベル並に低いユトリストが，戦力として御社に採用される日が近づいてきている。
ユトリスト版「クローンの逆襲」
さて，仕様を何とか定義できたとして，次はコーディング。コーディングでも検索が威力を発揮するのは変わらない。ネットにあるコードを何の疑いも無くコピーし，とりあえず正常系なら動くものができあがる。
あえて「正常系」と書いたのには意味がある。もうピン！ときた方も多いと思うが，新人のコードにはエラー処理が無いのだ。その原因はネット上のサンプル・コード。通常，サンプル・コードではエラー処理を省略することが多いので，それをそのままコピーすれば当然ひどいコードができあがる。最近はネットのコードでもエラー処理が充実しているのもあるが，やはりそれは例外。
とりあえず動くコードを，ネット上のコードのつぎはぎで作り，動かして修正するのがユトリスト開発の王道。ところが，ユトリストは動作原理を理解していないので，デバッグに多くの時間がかかる。
さらに追い討ちをかけるのがコードの長さ。コピペで簡単に作れる手軽さから，たとえ共通化できるところがあっても，別コードとして書いて（コピーして）しまう。
こうしてエラー処理の無い低品質なコードが大量生産され，保守どころかデバッグもままならない状態。以前の連載で，このようなコピペ・コードによる被害を「クローンの逆襲」と書いた。ここで終われば，前のネタのパクリになるので書かなかったが，ユトリストはさらなるネタを用意してくれていた。
実装部分がコピペなのはわかる。そしてその元ネタがネット上にあることもわかっていた。ユトリストが恐ろしいのは，テスト・コードですらコピペすることだ。これが似ているテスト・ケース間でのコード・コピーなら，手順の省力化と納得する。しかし，ユトリストは違う。
ネットで同じようなシナリオのコードを探し始めるのがユトリストだ。当然そんなものは存在しないので，彼らは行き詰まる。行き詰まるとコードを自作するが，そこには深い理解が伴っていないので，見るもおぞましいテスト・コードができあがる。かくして，ユトリストは動かないコードと保守できないコードを生産し続けるのだ。
ユトリストとのつきあい方
ユトリストの恐ろしさがわかってもらえたと思うが，それではどう対処すればよいのだろうか？ もちろん，銀の弾丸は存在しない。個人的には，じっくりと時間をかけて考えさせる機会を持たせるのが一番ではないかと思う。最近は何かと即戦力を望む傾向があり，研修も数は増えても短期間で終わっているケースが多いのではないだろうか？
私自身もコンピュータに全く触ることなくこの業界に入った。スキルアップに一番効果があったのは，コーディングに集中できた環境だった。そのとき開発していたのがドライバだったので，資料が少ない中で試行錯誤を繰り返してなんとか開発した。その間，ドライバを提供するOSを開発したベンダー開発者と直接やり取りできる機会もあった。
これだけの期間と環境があったからこそ，OSやCPUの動作原理などを理解できたのだと思う。要は，ラッキーだったのだ。この機会が無ければ，いまだにこのようなコラムで「書かれる側」の人間だっただろう。
“考える時間と環境を与えよ”などと書くと，特に年配の方には「俺達は働きながらスキルを身に付けてきたんだ。甘ったれるな！」と言う人がきっといると思うが，それは間違いだとはっきり言っておく。年配の方は，仕事をしていればどのようにコンピュータが動くのかを理解できる環境にいたのだ。
昔は今のようにOSやライブラリ，ミドルウエアが無かったので，開発作業自体がコンピュータの動作原理などを理解する時間になっていた。社内の既存の環境についてわからないことを質問すれば，それを開発した人から直接回答を得られただろう。今で言えば，OSの開発者からドライバの書き方を教えてもらえるようなものだ（もちろん普通の開発現場では，そんなすばらしい環境は提供されていない）。
それに対して最近は，OSや高級言語ライブラリがプリミティブな仕組みを隠ぺいしている。社会人になるまでに，その中身をじっくり理解する環境は無いし，機会も無い。そのため，まずは隠ぺいしているものの動作原理の理解から入る必要がある。当然だが，OSやライブラリを開発した人と直接やり取りできるパスも無い。これがどのくらい大きなハンデになるかは，ある程度の技術力と常識がある人なら理解してもらえると思う。
このような現状を踏まえ，忙しいのはわかるが，新人に徹底的に考えさせる環境を提供すること。そうして，検索以外の方法で物事を理解するための，本人なりのスキームを作る手助けをすること。これが，一番のユトリスト対策になるだろう。
これを実現できる研修をぜひとも用意してもらいたい。
