文系プログラマによるTIPSブログ

文系プログラマ脳の私が開発現場で学んだ事やプログラミングのTIPSをまとめています。

新卒をググってコピペするだけのマシーンにさせないために

自然とググってコピペするだけになってしまうのです〜
f:id:treeapps:20170817135400p:plain

ここ数ヶ月ほどずっと新人教育をしていて気づいた事がありました。

  1. 課題が出される。
  2. googleで検索する。
  3. コピペしてちょっと直す。
  4. 提出する。

私と私以外の第三者から新卒に課題を出していたのですが、どうも新卒(仮にA君とします)はどんな課題が出されても上記行動パターンを取っていた事が解ったのです。ググってコピペして完了〜、という具合です。

A君に一体何が起きていたのでしょうか?

A君に起きた事

ググってコピペして終了

フレームワークの使い方を調べ、ライブラリの使い方を調べ、それを繋ぎ合わせただけで、それらが何を行っているのかを全く説明できない状態に陥っていました。最近のフレームワーク・ライブラリが便利過ぎてそうなりがちなのですよね。

課題の出し方も悪く、ググってコピペだけでクリアできてしまうものもチラホラあったようです。

ググり方を訓練するきっかけにはなったと思いますが、課題の意図・目的はそうではありませんでした。

自分でビジネスロジックを書く事ができない

A君は絶望的にビジネスロジックを書く事ができませんでした。

ここで言うビジネスロジックとは、forでループしてifで特定データをフィルタリングして残ったデータをListに詰めて・・・と言った言語の基本機能のみを使ってデータを作り出すような、所謂ゴリゴリする処理のことです。

A君はフレームワークの使い方とライブラリについてはほんの少しだけ理解しており、そこは(ググって)繋ぎ合わせる事ができます。しかしフレームワーク・ライブラリ以外のコードを書く事ができるようにはなっていませんでした。

課題を自分の都合のいいように解釈する事があった

A君は課題の文章を正しく解釈していたが、何故か課題の文章を自分の都合のいいように書き換えて結論を出してしてしまう事がありました。

理由を聞いてみると、「どう書いたらいいのかよく解らなかったのですが、この書き方なら動いたのでそうしました。」と返ってきました。言い方は悪くなりますが、要は「想定とは違う結果だけど動いたんだからそれでいいだろ」という事です。

これは間違っているでしょうか?

ある面では「答えが1通りとは限らないし、別の面からの解があっても構わない。むしろそういう視点こそが重要だ。」という考え方もあります。

また別の面では「課題は◯◯を使って◯◯を行う事、という成果物を求めており、明確にそれが書かれている。しかしその要件を満たさない成果物が提出された。それでは要件を満たせない。」という考え方もありますね。

他人の言葉に強いバイアスがかかってしまう

これは前述の解釈の件と関連がありますが、A君は上司から「そのフレームワークの事よく知らないけど、一般的に◯◯は◯◯っていうやり方したりするよね」といった事を言われると「ああ、自分のやり方は間違ってて、そうやるのが正解なんだ。そうしよう。」という行動をとりがちでした。勿論それは課題が求める成果物ではありません。

後で「◯◯は◯◯っていうやり方をする」の詳細を私が調べてみると、確かにそのやり方でも動くことは動きますが、バージョンが古い時のやり方で、今はdeprecatedな非推奨な書き方でした。公式ドキュメントにもそう書かれています。

A君は最初は正しいやり方の書き方で悩んでいたのですが、他人から別の事を言われた結果、自分のやり方を捨て他人に言われた事を回答としてしまいました。

A君の行動は正しかったのでしょうか?

上司からそう言われたのだから、(他人との意見の衝突を避けるという意味でも)言う事を聞いておくのが正解」とも言えるし、「正しいやり方ではないのだから駄目」とも言えます。

スケジュールに間に合わない

誰しも経験がある事だと思いますが、A君は課題の全てをクリアできずに提出日を迎えてしまう事がありました。

何故間に合わなかったのかを聞いてみると、「この部分を調べるのに時間がかかってしまったので終わりませんでした」と答えました。A君は課題に夢中になり過ぎて「他人に頼る」という事を忘れていたようです。

間に合わなかったのはA君が悪いのでしょうか?課題を出す側が悪いのでしょうか?


A君の行動には全てA君なりの考えがあり、そういう行動をしています。

では何故微妙な行動をしてしまったのかというと、「その課題が目的としていることを明示していなかった」事に原因があると私は気づきました。

課題の内容と共に課題の目的も明示する

例えばスケジュール遅延してしまった課題が、もし「この課題の目的は、どんな手を使ってでもスケジュールに間に合わせる事です。そのためなら誰の力に頼っても構いません。」と明示されていたら結果はどうだったでしょうか?恐らく「うーん、ここが解らん。期日に間に合わせたいから聞いちゃえ!」と行動を起こし、無事スケジュールに間に合ったでしょう。

自分の都合のいいように解釈してしまった課題、またはバイアスがかかってしまう件が、もし「この課題の目的は、文章の意図を正しく読み取り、求められる成果物を正確に把握する事が目的です。」と明示されていたら、「◯◯なら解るんだけど、それは求められてないから再度調査して駄目そうなら聞いちゃえ!」という行動になったかもしれません。

しかし、1種類の課題で色々な目的を詰め込む事は難しいですね。

課題は目的ごとに出題する

合っているとは思いませんが、ざっくり以下のような課題に分けたらいいかな?と思っています。

  • スケジュールに間に合わせる事を主題とし、何が何でも期限に間に合わせる課題。
  • 自分で考える事を主題とし、スケジュールよりも自分の頭で考えて答えを出す事に重きを置いた課題。
  • 文章を正しく解釈する事を主題とし、認識の齟齬が起きないようにする課題。
  • 自分が他人にAPIを提供する事を主題とし、他人が求めるものを知り、自分のコードが他人に使われるとどうなるかを知る課題。

それぞれ考えてみます。

スケジュールに間に合わせる課題

仕事にはスケジュールがあるので、間に合わせる必要があります。

しかし、自分が知らない部分が現れたり、今の自分の知識では難しい部分は必ず出てきます。

その時にどうするか。

チームメンバーを全力で頼るのです。場合によってはチーム外、更に言うと社外(StackOverFlow等)に頼っても構わないのです。自分の知っている人・知らない人の力を借り、期限に間に合わせます。

自分がチームメンバーを頼るように、チームメンバーも自分を頼ってきます。頼り頼られ、協力しあってクリアします。

頼り頼られる事で、相手に自分の要望を伝える訓練、相手の要望を正しく解釈する訓練が行えます。

自分の言葉が如何に相手に伝わらないかを知り、自分の言葉を相手に伝える事が如何に難しいかを知る、という事を知るきっかけにもなりますね。

そういえば以前以下の記事を書きましたが、これを身をもって知るきっかけになると思います。

www.bunkei-programmer.net

自分で考える事

フレームワーク・ライブラリに無い処理が必要になった時、ググりきれずに答えが見つけられなかった時、そんな時は自力で泥臭いコードをガリガリ書いて乗り切らないといけない事があります。

この時「フレームワーク・ライブラリでそれができないので無理です」は通じません。仕事の発注側にはそんな事は関係無いので「フレームワーク・ライブラリ使わなきゃいいじゃん?」と言われて終わりです。

自分で考える事は非常に重要で、日頃から自分で考える訓練をしておくと、自分で考える事は論理的思考を鍛える事に繋がるので、トラブル時に非常に強くなれます。

障害が発生した際に「手順・マニュアルが無いので私には何もできません。」と口を開けて待っているだけの状況から、「◯◯が動かないから、まずはログを見よう。ログにこう出ているのだから、あれが原因か。あれを正常に戻すにはこれを再起動すべし。再起動でダウンタイムを発生させたくないから、1台づつ切り離して作業すれば大丈夫だ」という行動が取れるようになるかもしれません。

論理的思考を鍛えると、会議での無茶振りにも対応できるようになったり、手順を読む側から手順を作る側に回れたり、いい事は多いと思っています。

文章を正しく解釈する事

新卒の間はプログラムの事ばかりに目が行きがちで、相手が言っている事を正しく理解する事が上手く出来ない場合が多いです。「あれ?これってこういう意味じゃなかったんですか!?作り直しだ・・・・あ!マズイ!今日が期限日でもう修正が間に合わない・・・」なんて経験もあると思います。

文章を正しく読み、意図、要件を正しく把握していないと、そういった事を簡単に起こしてしまいます。基本は「書いてある事を書いてある通りに解釈する」事が重要ですね。

しかし、そうではない場合もあります。自分の認識齟齬ではなく、相手が間違って伝えてしまう場合もあるのです。

例えば相手は「◯◯をしたい。こんなやり方どうよ?」と言ってくる場合がありますが、相手はプログラマでは無いので、正しい事を言っているとは限りません。場合によっては非合理・非効率な事を言っている事だってあります。勿論相手には善意で提案してみただけで悪意はありません。

この時正しく文章読んで相手の意図を読み取り、「相手の言っている事はちょっとおかしくないか?」と気づき、本当に正しいやり方を考える事ができると最高ですね。

相手からの言葉を自分の脳内で変換する際に、今までの経験則から自分の都合のいいように曲解したり、バイアスがかかって相手の言う事を鵜呑みにして思考停止したりしがちなので、惑わされずに正しく文章を読み取り、意図を汲み取る事が今後A君には必要になっていきます。

自分が他人にAPIを提供する事

これは、提供される側ではなく、提供する側に回った時に何が起きるのかを知る事に繋がります。

新卒は学校の先生から一方的に情報を提供される事には慣れていますが、自分が他人に何かを提供する事に不慣れです。(院生の論文等は除く)

これを訓練するのにAPIの実装はとても都合がいいと思っています。APIを提供する側になると、如何を気にする必要があります。

  • APIの利用者が増えた際に負荷に耐えられるのかを検討しないといけない。
  • APIマニュアルを作り、APIの使い方を伝えないといけない。
  • 想定外のデータが渡される事を考慮し、バリデーション処理を実装しないといけない。
  • エラーが発生した時、エラーが起きた旨を伝える実装をしないといけない。
  • APIを特定の人だけに公開するため、認証処理(IP制限など)を実装しないといけない。
  • 将来APIが拡張される事を想定して、可能な限り疎結合で汎用的な実装にしておきたい。

ざっと考えただけでこれくらいありました。

今まで自分のためのコードしか書いた事が無い場合、自分のコードが他人に使われる時に上記の問題にぶち当たります。今まで「え〜、そんな事するの面倒だからやらないよ」と逃げていた部分に向き合わないといけません。

相手からすると以下のような事があると思います。

  • このAPI、仕様書が無いからどんな項目があって、どんな型・バリデーションがあるのか解らないよ。
  • このAPI、ここが配列になってないせいで、実装する側がクッソ面倒なんだけど。
  • このAPI、コードという項目名がcdだったりcodeだったり、全然統一されてないんだけど。
  • このAPI、エラーがあった時にエラーメッセージも無いし、何がエラーなのか解らないよ。
  • このAPI、たまにnginxのhtmlが返ってくるんだけど・・・
  • このAPI、なんかgoogleにインデックスされてるんだけど・・・・

使う側の視点を知る事で、どんなものを提供したらよいのかを知り、それを設計し実装する訓練になります。

雑感

何も考えずに課題を出しても、「ググってコピペして終わり」で済むものができる事があります。新卒は焦っている事が多く、「とにかく課題を終わらせなきゃ!」という気持ちが全面に出てしまい、内容の理解よりも「終わらせる事」を重視してしまいます。課題の目的を明示しないと大体このパターンになってしまうので、課題を出す側は慎重に内容を検討すべきです。

新卒の場合はまだ「学校の先生と生徒」という構図が生きていて、口を開けて待つだけになり、どうしても自分で考える事が苦手になりがちです。経験年数が浅いうちは先生と生徒の構図でも問題ありませんが、年をとり自分が指示をする側に回らなくてはならなくなった時、今までの経験が問われます。その時に指示をする側に回れないと、将来自分のできる事や可能性が大幅に少なくなる事もあると思います。

コンテナ・サーバーレス・マネージドサービス等が増えてきた昨今、自分一人でかなりの部分を作る事ができてしまいます。以前まではここまではできず、ハードウェアの呪縛に囚われて苦しんでいました。そんな時代も過ぎ、本当はいつかあんな事やこんな事がしたいと思ってIT業界に来たのに、ググってコピペしかしてこなかったから結局何もできませんでした、なんて事になったら嫌ですよね。

そうならない、そうさせないために、教育をする側が上手く導いていかないといけないのですが、IT業界は歴史が浅く歴史に学びにくいので、中々難しいのですよね。