ITエンジニア指導教官の雑談
SI業界でITエンジニアの入社後教育を担当しています。要は素人ITエンジニアを少しでも使えるようにして現場に送り出す係です。今回は、そんな私が指導教官として思う所を雑多に書いてみようと思います。
SIとは何ぞや他、もう少し詳しい自己紹介は以前に書いた記事の冒頭部分に書いてありますので、もしよろしければ合わせて参照下さると幸いです。
雑記です。今回もつれづれなるままに。
素人ITエンジニアの一番の問題は専門知識ではない
教育の進捗を阻害する一番の要因は、対象者にソフトウェアエンジニアリングやプログラミングの専門知識がないこと、ではありません。
対象者が勉強の素人であることです。
あくまで弊社の場合は、です。
自分なりの勉強方法が確立していません。恐らく、勉強で成功体験もしていません。こちらから見ると、給料もらって勉強しているのに、その程度しかやらないの？と言う子が多い。勉強素人を垣間見る場面が多すぎて、ここに理路整然と書ききれるかはわかりませんが、書いてみます。妄想かも知れないし、時代錯誤かも知れないし、異論反論もあるでしょうけど。
勉強素人あるある
最初から効率を求めようとする
1つ目は、以前の記事でも紹介したこの一言。
効率の良い勉強法はありませんか？
これが、社会人経験ありのアラサー・専門学校卒・大卒、といった経歴の人たちの口から出ます。
特に昨今のタイパというふざけた言葉のせいもあると思いますが、この質問が1on1で非常に多く出ます。ドがつくほどの素人のくせに効率を求めるなんて100年早いと思いますが、良いように受け取れば早く会社の役に立ちたい、と言う気持ちの現れかも知れません。ですが、ですがです。効率の前に、そもそも定着する方法を手にしているのでしょうか？
資格試験の場合は結果が出るのでまだ良いのですが、どんな分野のエンジニアでも、獲得しなければならない知識がたくさんあります。資格で得られる知識は氷山の一角にしか過ぎない。見聞きする言葉の半分以上、何のことか分からない状態のはずです。それを逐一調べて理解し、仕事で活用できないとプロとは呼べない。それらの雑多に見える膨大な知識の山をどう崩してどう自分のものにするか、と言うのが大きな課題です。エンジニアである以上は、一生その課題と格闘しないといけません。
勉強素人はいわゆる高等教育で卒業しているはずなんです。どうやれば知識を定着させて、自分のものに出来るか、学生の間に解決しておかなければならないし、教育者はその子が卒業後も一人で学んでいけるように指導しないといけない。とは言え、勉強素人を卒業しなかったことを嘆いても何も変わらないですし、指導しなかった教育者を責めても仕方がないので、そこを卒業させて上げるのが、ITエンジニア指導教官の第一かつ最大のミッションです。と今改めて思いましたw
で、どうするか。私なりのアプローチは単純です。技術書を沢山読めです。自分が抱えている問題を解決してくれそうな本があれば、片っ端から買って読め。Amazonのレビューは気にするな、自分が気になったら買って読め。
今の自分には難しすぎて読んでも余り理解が進まないこともありますし、簡単すぎて得られるものがなかったということもあります。それでも良いから兎に角読め。難しいと思ったら、途中でやめて置いておけば良い。代わりにその難しくて分からなかった所を解説してくれて、理解が進みそうな本を探して買え。それも分からない？またそれも積読スタックに積んで、分からなかった所を理解できそうな本を探して買え。
そうしてようやく、誤差を縮めて行ける様になる。誰が書いた本がわかりやすいか、どういう風にレベルを調整すれば自分の頭に入りやすいか、段々分かってくる。演繹的な思考が得意な人は、抽象論とか論文に近いところから始める。帰納的な思考が得意な人は、例題が沢山載っている所から始める。
自分がどちらが得意なのかも最初は分からない。その感覚を、人に教えてもらうことは本質的に不可能です。貴方の脳のリバースエンジニアリングが出来れば別ですが、まだそこまで技術は追いついていない。
これを掴むのに効率的な方法はない。本質的にスクラップアンドビルドだから。
どのくらいのペースで読むか。経験ベースでは少なくとも週に一冊。短くても三年続けましょう、が今の私の推奨案です。三年続ければ、150冊ですよ。三年で150冊と格闘した人と3冊と格闘した人とでは、力の差は明らかだと思いませんか。
でもパイセン、今の給料では…。
ですね。技術書は大抵高い。一冊5000円以上することも普通にあります。毎週買えば、月2万以上掛かります。弊社の様に個人的な図書購入費も経費で落とせる場合は活用してもらえば良いですが、そうでなくても、3年後に向けた投資だと思ってどこかを削って我慢しましょう。収穫はとてつもない。
他の選択肢としては、周りに発信して譲ってもらう、古本を買う。
本を買いたいので食事を奢って下さいも結構。いくらでご馳走します。後で助かったと思えば、君の後輩に同じことをして上げてくれれば良い。
この話しをすると、大抵の人は、そうですね！やってみます！というのですが…。
モゴモゴして全然始めない
第２の問題はスピード感のなさです。どれが良いのか迷ってしまって、と言って次の1on1でもまだやってない。正解は自分で導き出すものです。一発でシックスシグマ的な解を導き出せると思うなんて、傲慢。まずその日から、遅くてもその週末には始めて下さい。話しはそれから聞きます。精度を上げるには時間が掛かるんだから、四の五の言う前に始めましょう。どうせ、自分では思いつかないんだから、言われたことを手を抜かずに暫くやってみましょう。３ヶ月続けて駄目だと思うなら、また考えましょう。
分からないと言う状態を我慢できない
始めたは良いものの、あるテーマのことが全然分からない、と言うこともあります。そんなの当たり前です。今の知識と思考力ではそうなることもあるでしょう。考えても見て下さい。初見ですんなり出来る知識に高い価値があるでしょうか。難しいから価値があるんです。その状態をお腹に抱えたまま、分からないなー、と思いながら考え続ける耐性を持ちましょう。
沢山出てきてお腹いっぱいになることもあるでしょう。そんな時はスタックに書き出しておきましょう。
我慢出来ないとどうなりますか？
諦めたらそこで試合終了です。
君たちは思っているより強い。だって、私が採用したんだから。自信を持って、分からねー、と言い続けましょう。発信しているとそのテーマに関心のある人が寄ってきます。雑談レベルで急に、分かった！となることもあります。これは本当です。キョウカンウソツカナイ。
ググり方が下手、あるいは、プロンプトり方が下手
生成AI のお陰でGoogle先生はお役御免になるかも知れないですが、本を買うほどではないけど、ちょちょっと調べて先に進みたい、と言うこともありますよね。
素人が調べる時の入力を横で見ていると、そんなんでは正解に近づけないよ、と言うものが多い。
ググり力などと言う言葉が昔流行りましたが、今だとなんですかね。良いプロンプターになれるか、でしょうか。プロプ力？
そこも沢山調べて、かつ知識がついていかないと精度が上がらない。そんな案件個別のキーワード入れて出てくるわけ無いでしょ。そこは抽象化・一般化しないと。
原典に当たらない
ググって、プロンプって、お手軽情報に出会うと、それを鵜呑みにする。一番上に出てきたものを何の疑いもなく信じて、その結果解決しない。Qiitaに載ってました、Zennに載ってました、Wikipediaに書いてありました。初動としてはそれで結構。でも、その情報は誰が保証してくれるんですか？そういうメディアに投稿する方は、善意を持って書いてるので、意図的に誤りを書いたりはしないでしょう。でも、内容を保証する責任がないので、書いたことを細部まで検証しません。親切な読者が誤りを指摘してくれることもありますが、それは運が良ければ。
最終的に必ず、その情報を誰が保証してくれるのか、情報の原典は何かを考えて、調べないといけません。そこだけが正しいと信じて良い。
論文・仕様書・技術マニュアルの類だけが唯一信じるに足る情報源です。自分のテーマに関係ある原典はどこにあるのか、必ず確認しておくべきです。
抽象化・一般化出来ない人は本質的に向いていない
抽象化・一般化と言う言葉を繰り出したので、本質的に向いていない人の話しをします。ソフトウェア開発は、現実世界（AsIs含む）をモデリングして、概念レベル・論理レベル・物理レベルのモデルに次々と変換して行く作業の連続です。モデリングは抽象化作業そのものです。パターンを見出し、些末なことを削ぎ落とし、共通することのみを抽出して本質を明らかにする。
プログラミングに一番近いところで言うと、関数・サブルーチン（古い！）・メソッドの設計です。具象レベルでは違うけれども、これとこれは同じことしてるよね、と言うものを一つの関数にして、具象部分を変数にしてしまう。
ITに関係なく、これってこないだ指摘したのと同じ話だよね？と言われて、何のことか本気でわからない人には、この仕事は出来ません。忘れてました、言われてみれば、の人は可能性があります。あれとこれは同じ、と認識できる力が本質的に必要な世界です。ITに限らず頭脳労働の全てに当てはまる話しではありますけど。
向いていない人の話しまでするつもりはありませんでした。今日はこの辺が締めどきだと思います。
では。読んで頂いてありがとうございました。