三行
- 報告と確認は大事だから怠らないように
- 手段と目的を履き違えるな
- 勉強は大事だから習慣化する(軽くでいい)
新人教育に手を出そうかと思ったんです
おはようございます。この季節は手元が冷えまくってさむ谷園の冷え茶漬けなのでなるたけキーボードいじりたくないデブです。
私事ですが去年に転職しまして、いい感じにやれてます。フルリモート最高です。
そんなこんなでまあまあ月日も経って試用期間も終わり、前々から思ってた教育関連に手を出したいと本社で色々言ってます。
とは言え本社側としても長期で色々考えててとりあえず今々私が手を付けれそうなのが参画後研修というやつっぽい空気なのでそれ向けに一本記事を書きます。
で、その参画後研修の対象が以下の感じです。(以降新人君、とします)
- 研修終わって本格的に業務に参加しだした人
- 大体1,2年目くらい
はい。大事な時期です。
どのくらい大事かと言うとアニメの1～3話、ラノベ1巻、漫画連載1~3話くらい大事です。もう少し分かりやすく人間の年齢で言うと人格形成期、0~10歳(諸説ありますが大体この時期)くらい大事です。
一般論として、人間は年齢を重ねるにつれて人の言うことに本気で耳を傾けることが少なくなります(鎖付きブーメラン)。無論個人差は大きいですが雑に言うと「今までなんとかなったし自分はこれで大丈夫」という考えが大きくなります(飛来骨)。人格形成としてはそれで正しいことですが、あえて主観的な言葉を使うと歪な、あるいは未熟な状態で固まってしまうと矯正が難しくなります(カジュアルな自刃)。
変な言い方にはなりますが、新人の頃にどれだけいい意味で意識を高く出来るか、それを当たり前に出来るかが大事です。いやホント年取ると物覚えが悪くなるし習慣の改善とか痛い目見ない限り続かないのよ
保険として言っておくと、私自身は決して優秀なプログラマ/エンジニアではありません。物覚えは悪い方ではないとは思っていますが性格が俗っぽく、基本怠け者なので意識もそんなに高くないです。ですが、実績として現場の方、特に技術畑の方からはそれなりに評価を頂いており、ある程度信頼されているという自負はあります。
なのでこれから私が記すことを実践し、身に着ければ優秀な人材になれるという保証はありません。あくまで参考程度です。あと私怨私情も盛り沢山です。
他にも似たような記事はいっぱいあるので、沢山読んで下さい。情報を取捨選択し、自分の中でちゃんと消化してこれからに活かしてほしいと思います。
そして願わくば数年後、一人前になったときに似たような記事を書いて次の世代にも繋げてくれればと思います。なんかあとがきっぽいな
新人君に身に着けて欲しいマインド
因みにここで言うマインドというのは仕事に対する「心がけ」「基本的な考え方」「姿勢」とかそんな意味合いを指します。
横文字使っとけば色んな概念を雑にいっしょくたに出来て楽ですね。真似しちゃだめですよ。ろくろ回しとか呼ばれるようになります。
常に勉強し続けなければ生き残れない
つまるところ「常に知識を吸収し、更新し続けろ」という話。横文字使うとアップデート。
IT業界は非常に進歩の早い業界で、たった数年で大きく変わります。
具体的に言うと例えばこの5年で技術は大きく進歩しました。ぱっと思いつく限りでも
- プログラミング言語のメジャーアップデート回数
- SPAの流行
- AI技術の発展
- 量子コンピュータの商用化
- スマホがどんどん縦に伸びていく
サンダーボルトが制限解除され、一瞬とは言え無制限に
という感じで大きく変わっています。
stackoverflowの調査結果の2018年と2022年とを見比べても面白いかもしれません。例えばdevelopment environmentの項目を見るとvscodeの台頭が凄まじく、デファクトスタンダードの座をこの5年で勝ち得たことが伺えます。
また項目の違いなどから2018年と2022年ではそもそも求められている技術の質も多少なりとも変わっていることも見て取れます。(あくまで全体として、ですが)
赤の女王仮説
私この話が好きでよくするのですが、進化生物学の中で赤の女王仮説というものがあります。
この説は軍拡競争や有性生殖の利点についての仮説なのですがその辺りは一旦置いておいて、私が言いたいことは以下の引用に詰まっています。
「赤の女王」とはルイス・キャロルの小説『鏡の国のアリス』に登場する人物で、彼女が作中で発した「その場にとどまるためには、全力で走り続けなければならない（It takes all the running you can do, to keep in the same place.）」という台詞から、種・個体・遺伝子が生き残るためには進化し続けなければならないことの比喩として用いられている。
wikipedia :赤の女王仮説 より
この話の要点は「その場にとどまるためには、全力で走り続けなければならない」というところです。言い方を変えればちんたら歩いてると置いていかれるということです。
先にも述べたようにIT業界は進化が早いです。いつまでも同じ技術で同じことをしているだけでは相対的に能力は落ちていきます。
つまるところ、生き残る=お仕事を貰い続けるには日々勉強が必要だし、今以上のお仕事を貰うにはもっと勉強が必要だよということが言いたいのです。
ド直球に言うと今より高いお給金が欲しいなら勉強する必要があるということです。金のために勉強をするのだ
これは新人とかベテランとか、IT業界とか勤め人とか仕事とか関係なく、全てのことに言えると私は思っています。
研修で学んだ技術は現場レベルには到底及ばない
初っ端からやる気を削ぐようなこと言って本当に申し訳ないんですが、事実として覚えていてほしいです。
誤解しないで頂きたいのですが研修が無駄と言うつもりは毛頭ありません。
あくまで技術が現場で求められる水準に全く届いていない、ということです。
なおここで言う技術というのは例えば、
- SQLを学んだ
- javaでプログラミングを学んだ
- 簡単なwebサーバーの立て方を学んだ
とかのことです。
恐らく研修は技術だけではなくビジネスマナー等の対人スキルも教えてくれていると思います。
また、長期間に渡って社外の人と一緒に勉強するという経験は貴重なものです。ぼっちの私には苦痛でしたが
保身の言い訳はこの辺りにして本題を語りましょう。
繰り返しになりますが研修で学んだ技術というのは現場水準には到底及ばないです。基礎中の基礎というか業界内での常識程度でしかないです。
例えるなら野球で公式試合をしようというのに「ルールやバットやボールの握り方は教わった」程度でしかありません。
だからこそ現場水準の技術を早く身につけるには勉強が大事なのです。
人によっては「ならそんな研修なら受けなきゃよかった」とか思うかもしれないです。私は思ってました
ただ、仕方ないんですよ。理由はいくつかあります。
- そもそもたった1,2ヶ月という時間はあまりにも短すぎる
- 現場で使う技術の種類は現場ごとに違い、星の数ほどあるので「これさえ抑えとけば大丈夫」というものがない
- 研修作ってる側が最前線で働いてる人ではないことが多い
- 技術の進歩が早すぎて教材が時代に追いついていない
- 研修を受ける側が「何がどのように役に立つか」ということを理解出来ていない
- 「基本的なやり方」は教えてくれても「優れた/効率のいいやり方」は教えてくれない
とまあ色々な要因があります。
ただやらないよりはよっぽどいいですし、研修はあった方がいいです。
とは言え結局は研修で学んだことを活かせるかどうかは本人次第という月並みな言葉で締めるしかないわけですが。
大前提として、現場にとって新人はお荷物
まあそんなわけなので新人君がいきなり現場で大活躍！みたいなことは滅多にないわけです。十中八九お荷物です。
ですが安心して下さい。新人の面倒を見ることも上司のお給料に入っています。割には合わないが
とは言え新人を露骨にお荷物扱いする上司は十中八九ろくな人間ではないです。(唐突な自己紹介)
新人君に頼める仕事は大抵が「誰でも出来る仕事」か「上司自身がやった方が早い仕事」です。
まあ当然といえば当然です。上述の通り1,2ヶ月の研修上がりなんて素人に毛が生えた程度です。いきなり高度なスキルが求められたり、責任の大きい仕事は任せられません。
ですが仕事があるだけまだマシです。 私は研修上がって2週間くらいは「ごめん！ちょっと今手空いてないからこのソースでも見てて！」と放置されてました。まあそのソースがアレでバグだったり脆弱性があったりしたので指摘したことは期待以上の成果だったとは思っています(隙自語)
とは言え最悪放置されていようが仕事は仕事です。曲がりなりにもお金を貰っているのできちんとやりましょう。言われたことを言われた通りにやる、これが勤め人の第一歩です。(ただし、まともな職場である場合の話)
新人君に求められていることは「早く一人前になること」
ところで何故お荷物になることが分かっていて現場に放り込むかと言えば早く戦力になって会社の売上に貢献して欲しいからです。要するに新人君に対する投資です。
恩着せがましい言い方になりますが、新人君目線にするとお金を貰いながら勉強している状態です。
いやこれ本当に貴重な時期なんですよ。新人君の特権です。(厳密に言えばある程度働いたあとでも公の職業訓練校なら授業料なしで失業保険を貰いながら学べますが、出処は税金なので実質的に過去の自分のお給金から捻出しているような構図)
あとこれは単純におじさんの羨望ですが、「多くの時間を勉強に充てられる環境」って本当に貴重なんですよ。子供の頃って大人は皆口を揃えて「勉強出来るときに勉強しとけ」って言ってたじゃないですか。当時は「勉強なんてやってられるか遊びてえわ」って感じなんですけど今では学生の従兄弟に言う側です。絶対皆言うようになるから。ホントに。
この貴重な時期にちゃんと勉強して頂けたらおじさんは嬉しいです。
上司がやった方が早い仕事を任されたら大当たり
ちょっと話が脱線しましたが、新人君の仕事の話に戻します。
もし新人のあなたに「上司がやった方が早い仕事」を振られた場合、それは基本的に大当たりです。(例外あります)
何故ならその場合、「新人を育てよう」という方針がどこかにあるからです。(誰/何処のものかは置いておいて)
因みに私は基本このパターンだったのでその頃の上司には感謝ばかりです。
このパターン、本当に上司の負担が大きいんですよ。
- 上司自身の仕事
- 新人の仕事の進捗管理
- 新人の仕事の質疑応答
- 新人の仕事の出来の確認
- 新人への赤ペン先生
を並行してやることになるので。
でも結局これが一番成長に繋がります。最前線で働く人が一番の教科書です。
隙間を見つけて勉強する
ではそうではなく、誰でも出来る作業を振られたり放置された場合はどうするか。
さっさとやるべきことやって自主的に勉強して下さい。
身も蓋もないようですがこれしかないです。
ただし一つだけ注意点があります。
作業を終わらせるタイミングを図らなければならないです。
現場の空気が「空いた時間に勉強してOK」であれば問題ないのですが、基本的に勤め人というのは「労働力のサブスク」です。 作業が終わったと報告したらまた作業を積まれ、無限に終わらない現場はあります。
そういう現場の場合「人手は使うもの」です。育てようなんて気は一切ないと思ってください。あいつらは良くて「仕事やってるうちに勝手に成長するっしょw」とか思ってます。最悪「四の五の言わずにはよ手動かせ」とか思ってます。
なのでその場合、「作業中に勉強時間を挟む」必要があります。作業時間の8割は実作業、2割は勉強時間、のように。バレないようにひっそりと。
但し、どんな現場でも現場のルールは守りましょう。
勉強の仕方が分からないという場合は具体的にどう勉強するかを後述するのでそっちを読んで下さい。
因みに私はごく短い間ですが冗談抜きで10万単位ある書類の打ち込みという地獄のような作業をしていました。エンジニアとは一体……？
勉強もクソもなかったです。何なら休日にも駆り出されました。まあホントにジョブとジョブの間のスポット対応だったので「そんなこともあったなあ」という感じですが。
別に業務外で勉強しろと言っているわけではない
ここまでさんざ勉強しろと口を酸っぱくしていますが私は何も「業務終わりや休日も勉強しろ！」とは言っていないですし、一切思ってないです。というか私は業務時間外に勉強は基本していないです。趣味でツールの作成や記事の執筆なんかはやっていますが。
まあそれがやれるに越したことはないんですけどね。でもやる必要はないんですよ。仕事は仕事、プライベートはプライベートで割り切っていいです。私はそうしてます。というか20過ぎたらもう老いることしかないので遊べる体力のあるうちに遊んどけ
何が言いたいかと言うとただ言われたことをこなすだけでなく、知識を吸収しながら仕事に取り組み、隙間を作って勉強しましょうということです。
まともな現場で、つつがなく業務が進んでいれば節々で若干暇になる時期があります。スケジュールを余裕を持って組んでいるからです。そのときには業務時間内でがっつり勉強しましょう。
まあ結局一番伸びるのは趣味でパソコンいじってたら勝手に技術と知識がついていた、みたいな人なんですけど。別に上の上目指す必要はないです。中の上くらいで立派にご飯食べていけます。
責任は上司に押し付けろ
さて先程「新人の面倒を見ることも上司のお給料に入っています」と言いましたがこの面倒を見る、というのは「新人のミスの尻拭いをする」というのも入っています。
人間である以上誰にでもミスは当然あります。プロ棋士ですら二歩という初歩の初歩や、先手後手の勘違いという勝負以前のミスをして負けることもあるくらいです。
まして新人なら尚更ミスする確率は高くなります。単純な勘違い手違いすれ違い、そもそもの理解が足りていなかったりと要因は様々ですが、大なり小なり何かしらのミスは確実にやらかします。というか一回くらいやらかして痛い目見ろ！私はやばめの三回くらいやらかした！
重要なのはミスしたときの対応です。
大抵のミスは取り返しが付きます。ただどの時点で誰が責任を持っているか、というのが大事です。これが早い段階で上位役職の人にあればあるほど実際にやらかした人のダメージは少なくなりますし、往々にして実害自体も少なくなります。
ではどうやって上位役職に責任をもたせるか。上司にすぐ報告することです。
まずは報告すること
「結局『報告・連絡・相談』かよ」
と思うかもしれないですがその通りです。別に連絡や相談はしなくていいので最低限報告だけは怠らないで下さい。 報告が遅れれば遅れるだけ、自身へのダメージは大きくなると考えて下さい。というかマジで最悪は懲戒処分までありますし、不幸になる人間しかいないです。
例えばの話、会社(この場合は出向先の他社を想定)の入場証を失くしたとしましょう。
失くした時点で報告すれば最悪見つからなくても(初回であれば)「次回から失くさないための施策の提案とその徹底」とかの注意勧告で終わります。(因みに上司や本社の偉い人は始末書書いたり平謝りだったりもっと大変です)
これが報告を怠り、何やかんやでズルズル引き伸ばして何かの拍子でバレた場合大騒ぎになります。例え何事もなかったとしてもそれは結果論です。偉い人たちは「これでもしなんかあったら責任どうすんねん。何か盗られたら？機密情報が漏洩したら？内部から放火される危険性もあったんやで？」となります。大人って大変ですね。
とは言え偉い人の心配も当然です。例えばクレジットカードを落としたら本気で焦りますよね？まず探すとしてもカード止めて再発行して、などの見つからなかった場合のことを想定し、もし見つからなかった場合はそうやってミスをケアします。ですがそれが自分の与り知らぬとこで起きたのなら？実は一週間前に落としてた、となったら肝を冷やすと思います。最悪不正利用されてもカードならある程度は保険が効くでしょうが、これが会社の機密情報だった場合シャレになりませんし取り返しも付きません。(よしんば金銭的補償が出来たとしても信用は取り戻せない)
少し話を誇張した節はありますが有り得なくはない話なので、何かやらかしたときには何よりも先に上司に報告しましょう。ミスを報告しないことはいつ爆発するか分からない爆弾を抱えるのと一緒です。
それと当たり前ですがミスはミスなので反省して同じことを繰り返さぬように。
『報連相』は上司側が意識しなければならないこと
とは言え報告しづらい上司がいるのは間違いないです。
気難しい人だったり、すぐ怒る人だったり、ねちっこい人だったり、部下を見る目がアレだったり 、すぐつまらないダジャレ言ったり。
本来は上司側が「気軽に『報告・連絡・相談』出来る環境や雰囲気を作る」べきです。
包含的にはなりますがよく言われる言い方をすると「心理的安全性を高めるべき」というところですかね。
この辺りは天下のgoogle様がGoogle re:Workで書いてくれています。(厳密には効果的なチームとは、というお題目ですが)
一応心理的安全性の一次ソースも置いておきます。
正直アレな上司にあたった場合新人君に出来ることは限られていますが、新人君もいつまでも新人ではなくゆくゆくは部下を持つことになるでしょう。
そのときに「自身が、少なくとも部下がミスを報告出来るような上司」になってくれればと思います。
失敗を恐れるな
さて上記ではミスの話をしましたが、今度は失敗の話です。
「意味一緒じゃね？」と思うかもしれないですがここではこう定義しましょう。
- ミス
- 業務上の過失、ヒューマンエラー
- 失敗
- バグや不具合を出すこと
バグや不具合も過失っちゃ過失なんですが細分化ということで。
ともあれ開発にせよインフラにせよバグや不具合は付き物です。むしろバグが一切見つからないプログラムやシステムはないです。
特に新しい技術を取り込む場合は頻発します。一日二日かけて調査した結果たった一行余計な処理挟んでたとかホントによくあります。
なので「良く分からないし不具合出そうだからちょっと手間だけど既知のやり方でいいや」とかは基本的にやめて下さい。
まともな現場であればバグや不具合を本番に出さない仕組みが整っています。(レビュー、テスト、など)
バグが出ても出なくてもそれは確実に知識となり、成長に繋がります。失敗を恐れないでください。むしろバグや不具合を出してその原因を調査して修正する経験は積めば積むほど良いです。
確認を取ることで責任を共有する
よしんばバグや不具合が見つからず、そのままリリースされたとしてもそれは個人の責任ではなく会社の責任になります。何故なら「皆でちゃんと動くこと確認したから」です。
これはもっと小さい単位、新人と上司の間でも成り立ちます。(普通は)
作業内容だけでなく、業務上の書類でも仕事の上で何か不安な点があれば上司に確認しましょう。「こここんな風に作った(設計した)んですけど大丈夫ですかね？」「ここってこう書くんで大丈夫ですか？」程度の内容で大丈夫です。
何かあれば上司は(まともであれば)「この部分がこう不安だから確認しといて」とか「その方法じゃなくこっちの方法でやって」「ここの項目はアレを書けばいいよ」とかアドバイスをくれるはずです。
OKを貰った時点でその部分については上司にある程度は責任が移ります。例えあとで何かあったとしても上司が何かしらの対応はしてくれるはずです。多分。
これの何が良いかと言うと「手戻りが少なくなる」ことにあります。
例えば書類の話で「ここの項目微妙だけど適当に書くか」で間違っていた場合、提出して担当の人がチェックしてから戻されます。ですが上司に聞いてそこで修正出来た場合は同じ失敗をするにしても全体でかかる時間は少なくなります。総務の人も大助かりです。(文脈の都合上上司とは書いてますが先輩や担当部署の人でも構いません)
書類だけではなく、開発やインフラ構築にも同様のことが言えます。
バグを出すにしても一人でやってテスト段階で発見するよりも実装/構築段階で上司に見てもらってそこで見つけかれば手戻りがなくて済みます。手戻りがあったとしてもそれは「多少は上司の責任」になります。(流石に全部、とは言えませんが)
そういうわけなので上司に確認を取ることで言質を取り、失敗のリスクの一部を移すというのは保身のためにも、業務全体にとっても大事なことです。もし失敗しててもダメージの一部は上司が肩代わりしてくれます。
「イチイチ聞いてくんな！」という上司の場合は残念ながら上司ガチャハズレです。もう一度回せるようだったら回してください。無理なら諦めてください。南無。
目的意識を持て
ここまで新人時期の能力や立場にまつわる話をしてきましたが、そもそもエンジニアとしての基礎的な考え方の話をしましょう。
目的意識の話です。自分で書いた表題なのに生理的嫌悪感が湧いてくる
まあどういうことかと言うと無限に引用されまくってる「三人のレンガ職人」で説明は事足りますね。
Q. あんた何してんの？
A1.レンガ積めって言われたんでレンガ積んでるやで
A2.壁作ってる。割のいい仕事なんよ
A3.ぼおくはね！！！大聖堂を作ってるんだ！！！！すごいことだよね！！！君もそう思うだろお？
悪意を込めた要点はこんな感じ。
因みにこれ出典どこだろうと調べていたのですが、各所でイソップ寓話の～とか言われてはいますがイソップ寓話にこんな話ありません。(wikiのペリーインデックスの項目で確認)
調べてみると出典不明でそもそも古典ですらないらしく、とあるとこでは「校長先生の話説」まで出てます。真偽は不明で諸説あります、程度ですが。
つまるところこれをイソップ寓話出典、みたいに書いてあるサイトはすべからく「まともに出典も確認しない無能が書いたもの」なので一切信じないでください。
書き物では出典は重要です。まあ出典元がwikiなのも本当は微妙なんだけど
因みに私は「人とサテュロス」が好きです。人間基準で考えたらただのキチガイだけど教訓がいくらでも深読み出来るのが良い。初対面の人は大体サテュロス扱い
閑話休題。
ともあれこの三人の言を目的意識という観点で見ると、
A1. とりあえず惰性でやっている
A2. お金を稼ぐためにやっている
A3. 誇りを築くためにやっている
という風に見れます。
ここでA1の場合、自発的成長の伸びしろは皆無です。だって言われたことをただやっているだけなので。
A2の場合は早く終わらせるために効率向上の方法を考えたり、もっとお金を貰うための工夫を考えるかもしれません。
A3の場合も同様に効率を考えたり、あるいは見栄えや格式のために良い案を出してくれるかもしれません。
今回では芽が出なかったとしても次回その目標を達成するための努力をする伸びしろがA2,A3にはあります。
私が言いたいのは、少なくとも何も考えずに目の前のことだけやるだけでは効率が低く、目的を定めてそれを成し遂げるために必要なことを逆算して目標とし、その目標に取り組むと効率が良いということです。
ここで言う効率というのは状況や個人の考え方で異なります。例えば私の場合は「お金が欲しい」(目的)=>「お給金をあげるには仕事の能力が高いか、他の価値が必要」(目標)=>「能力をあげるために勉強。自分でも出せそうな付加価値を探す/身につける」(取り組み)という感じで、効率=お給金の上昇率となります。
手段と目的を入れ替えるな
どっちかって言うとこっちが言いたいこと。
別の言い方をすると手段に囚われるなということなんですが伝わりますかね。
健全な状況を想定すると、例えば今やっている手段で躓いたり問題が浮上した場合に別の手段を検討出来るかどうか、ということです。
何か問題があったとき、解決出来るのが一番ですが解決出来そうなものがない場合はそもそもの目的に立ち返って別の手段を取った方が結果的に良い場面というのは多々あります。
そこまでの過程をなかったことにするというのは非常に惜しいですがその間に調べた知識や経験は無駄になりません。勉強代だと思って割り切りましょう。
あとその過程で一度失敗したことにも取り組めるとなお良いです。失敗したことで苦手意識を持ち、遠ざかっていいことはないです。何より過去の自分が出来なかったことをなし得るというのは成長の証です。
一応言っておきますがこれは「躓いたらすぐ投げ出せ」と言っている訳では無いです。まずは問題解決に取り組んで下さい。そして万策尽きたり、時間的に厳しくなってきた場合に初心に立ち返って手段の再検討をする、ということです。
悪い状況を想定すると……ほぼ愚痴なのでやめましょう。
ともかく言いたいことは手段に囚われて目的が達成出来ないのでは本末転倒。目的を達成するための手段はいくらでもあるということです。
おまけ「文系・理系とエンジニア」
あんま関係ないので読み飛ばしてもOK。
「理系はエンジニアに向いてる」とか「私文系だから不安……」みたいなのをたまに見かけますが、結論から言いましょう。
理系とか文系とか関係ないです。そもそもそんな区切りに意味はないです。
文系だの理系だのは日本でしか言われてない(らしい)です。私から言わせればそもそもその括り方がおかしいです。
考古学と法学を同列に扱います？化学と物理学を同列に扱います？同じ化学でも有機化学と無機化学その他諸々あるんですよ？多かれ少なかれ被る部分はありますがそれは所謂理系文系学問も一緒です。考古学の年代判定に化学の知識が必要ですし、そもそも学問、科学というのはすべからく人類の歴史の積み重ねです。あらゆる学問はどこかしらで別の学問と被っています。
で、エンジニアにとって大事な能力は雑に言うと以下の通りです。
- 人の話を正しく理解出来るか
- 自分の考えを正しく伝えられるか
そうです。国語が出来るかです。
よく言うじゃないですか「数学の文章問題を解くには国語が必要」と。それと一緒です。全ての学問の基礎である国語が出来るかどうかなんです。
システム開発もインフラ構築も究極的にはある目的を達成するための手段を作ることです。
そのために
- 目的を理解すること
- 目的を達成するための手段を考えること
- 手段を関係者に伝えること
- 手段の構築手順を考えること
- 手段の構築手順を関係者に伝えること
という能力が最低限必要になります。
逆にこれさえ出来ればある程度は大丈夫です。本当はもっと工程がありますし求められる能力もありますが割愛。(というか私の知識が足りない)
因みに国語能力という面で先進国、こと日本はとても有利です。
理由は語ると長いのですが短く言うと、
- 日本語そのものの語彙力が高い(大学教育をほぼ母国語で受けられるレベル)
- 文字種が多く、特に漢字の情報解像度が高い
- 外来語が受け入れやすく、造語も作りやすいので概念化が簡単かつ浸透しやすい
京言葉の煽り性能が高い
まあ日本語が強すぎるのと英語教育のやり方がゴミすぎて英語が苦手な人が多いというのは一つの弱点ではあるのですが、最近は翻訳技術の向上で多少解消されつつはありますね。多少は。とは言え最低限高校英語は出来た方がいいです。私は出来ないのであの頃の自分をぶん殴ってでも英語を勉強させたいです。deepl翻訳が手放せない。
これ以上語るとにわかが露呈するので締めますが、日本語至上主義というわけではないです。英語は分かるほうが良いですし、勉強する価値があります。英語が読めるだけで情報収集能力は違う次元になります。
新人君に身に着けて欲しい習慣
まあ要するに勉強しろよ、ってことなんですけどね。横文字使うとインプット。
毎出勤日に午前午後で15分ずつ勉強する
兎にも角にも勉強する時間を確保します。
まずは午前午後で15分、合計30分を目安に。
これくらいなら勤務時間から捻出しても業務に支障をきたすことはないはず。タバコ休憩と大差ないです。
継続こそが力です。一朝一夕では技術も知識も身につきません。
まずは内容の程度は別に勉強する習慣そのものをつけます。
具体的にどう勉強するのか
勉強しろ勉強しろとずっと言っているので具体的な勉強方法の一例を段階ごとに紹介します。
読む/見る
まずは何かを読んだり、動画を見たり、だけでいいです。
読むのは本でもネット記事でもいいです。動画はyoutubeにも色々転がってます。ただ勤務時間中にyoutubeはリスキーなので非推奨。
それを選定するのもめんどくせえ！という場合はqiitaやzennの日時トレンドで気になった記事を読むだけでもいいです。
調べる
で、色々読んだり見たりしていると分からない言葉だったり気になる技術が出てくるかと思います。
それを調べて、出てきた記事なり動画を見ます。そこで出てきた言葉や技術を……と無限に繰り返します。
ひとまず習慣としての勉強はここまででよいです。
実績として私はこれを続けて二年半で基本情報をノー勉でワンパンしました。結構ギリギリだったけど合格は合格
まあこの程度で取れる基本情報が中堅レベルになって有り難みがあるかと言われると微妙なところではあるのですが取って損はないですし祝い金で美味しいもの食べられました。
作る/動かす
さて次の段階では上記で得た知識をもとに何かを作ります。
Q.何かってなんなの
A.『さあ？』
いや学んだ技術によって違うのでこればかっりは何も出せません。
ただ言えるのは作る過程そのものが大事なので何かのパクりでもOKということです。(商用化するとなると話は別ですがここでは勉強なので)
例えばで言えば私はマインスイーパとか作ってましたね。デバッグついでに遊べる！
書く
次の段階、とは言いますが別に何も作らずにすっ飛ばしてこっちでもいいです。
学んだことを文章にします。
これは持論ですが他人に説明出来ないものは感覚で、他人に説明出来るのが知識です。
感覚を言語化することでより理解が深まります。
あと振り返ることで「よく考えたら違う手法の方が良かったかも」となるのでそれの検討をするだけでも良いです。
とは言えこれは流石に勤務時間中はアウトかもしれないのでやるならプライベートの時間の方が無難です。
あとついでに言うと学んだ内容を記事にしてどこかで公開しておくと転職のときに有利になります。
今から始めるならqiitaじゃなくてzennの方がいいかも。
やり取りはデータで残す
人類社会には最高にホットな対人エクストリームスポーツ、「言った言わない」が存在します。
雑に説明すると言ったか言っていないかを交互に投げつけ合う責任と瑕疵のドッジボールとも呼べる競技です。
企業間個人間問わず、口頭でのやり取りの内容をどちらかが都合のいいように歴史改竄を試みるときに催される決闘なのですが、実はこれには必勝法があります。
やり取りをデータで残すことです。
これにより歴史改竄を防げます。あとは発言が何時何分何秒地球が何回回ったかを即答出来れば即勝利します
この際、チャットツールやメールなど改竄が困難かつ他人に見せられるもので残すのが重要です。
因みに企業間でこれが催された場合、どちらが勝つにせよ誰にとっても不幸な結末しか待ってません。アーメン。
またハラスメントが行われた際の証拠にもなりますので、危機を感じたらテキストだけでなくボイスレコーダーなども用意しておくと良いです。
これ本当に真面目で重要な話なんですが、特に女性の方は密室に呼び出されるようなことがある場合は必ずボイスレコーダーを持っていって下さい。
過去に担当営業に呼び出されてセクハラをされ、泣き寝入りに近い状態で退職を余儀なくされ、そのまま精神が病んで自ら命を断ってしまった方が私の身近にいます。
質問するときは
作業を進める中で誰かに何かを質問するということがよくあると思います。
というかお願いだからほどよく人を頼って下さい。世の中自力で解決出来る問題とそうでない問題、そもそも悩んだって仕方のない問題があります。考える時間、悩む時間も大切ですが実際に手を動かす時間も重要です。
とは言えならほいほい質問していいのかと言うとそうではないです。
「分からない！とりあえず聞こ！」でやっていると知識はついてもエンジニアとしての能力は殆どつきません。
ここで言うエンジニアとしての能力というのは「問題解決能力」です。
最初のうちはそれでも仕事が進みますが、いつまでも先生がいるのは学校だけです。一人で動けないエンジニアは戦力ではなく手数でしかないです。
全て独力で解決出来るのが理想ですが、新人君にそれは厳しいです。なのである程度キリがいいというかやれることはやってから質問しましょう。やっている間にそのやれることの内容は進歩していきます。
加えて言うと「質問の質」も高めないと答える側、上司はどんどんぶっきらぼうになります。
ここで言う「質」というのは「問題が高度なものか」ということではなく、「問題にどの程度向き合ったか」ということを指します。「よく分からんけどとりあえず聞くか」ではなく「調べたけどどうにも分からないんです」というスタンスで質問する、ということです。
極端な話、「なんかえらー？っぽいのがでたんすけど」と謎のポップアップ画面だけ見せた場合、無言で顔面をディスプレイにぶち込まれても文句は言えません。因みに「急にブラウザのトップページにhao123とか出てきたんすけど」とかの場合は明日から君の机はありません
つまるところ質問するのは大事ですが、質問する側もタイミングや内容が適切でないといけないよという話です。
とは言えそれにビクビクして質問出来ない、という状態も好ましくありません。
「空気読んで柔軟に対応しろ」と言うのは簡単ですが、エンジニア職を選ぶような人間は陰キャだけ(断定的ド偏見)なので難しいです。
まあ上司側も結構それに悩んでいて、「質問のルール策定してみた」系の記事はあちこちにあります。
というわけで私の方でもルール及びテンプレートを作成してみました。
- まずは自分で調べる
- 制限時間は5~10分
- 制限時間内に解決の目処が立たない場合は質問をする
- 質問内容をテキストにまとめる
- 内容は以下の通り
- やりたかったこと
- 躓いたところ(エラー内容,設定項目が分からないetc)
- どのように調べたか
- 検索ワードやどのようなページを読んだか
- 調べているときに分からなかったとしてもタブは開きっぱなしにした方がよい
侍エンジニアとTechAcademyは閉じて良い
- 内容は以下の通り
- 上記をメールかチャットで上司に送信する
- この際に「分からないことがあったんで質問送ったのであとで確認してください」的なことを口頭で言うと良い
- 調べ物を再開する
- 手元のテキストの「どのように調べたか」を追記しておくこと
策定理由を書いておきます。
自力の制限時間
当たり前ですがまずは自分で調べて下さい。
調べ方は……いえそれも自分で身に着けて下さい。場数踏めばなんとかなります。頑張れ。
それで制限時間を設けます。
理由はシンプルで「大概の問題は既に誰かが先にぶつかって、既に解決されてネットの海に漂っている」からです。
ついでに言うと検索ワードが適切であればgoole検索1ページ目に答えがある場合がほとんどです。
逆に言えば5分10分で答えにたどり着けないということは調べ方が悪いか本当に困難な問題の可能性があるので、この辺りを区切りとしてます。
テキストにまとめる
いきなり口頭で質問するのではなく、まずは「何がしたかったのか」「何故実現出来ていないのか」を書き出します。
人間不思議なもので書き出して整理するとふと「あれそういえば」となることがあります。あと何度も推敲したはずなのに投稿した瞬間文章のミスが見つかり始めます
そこで何か引っかかてもとりあえずテキストを書き続けて下さい。
「どのように調べたか」も書き出せるとグッドです。思考プロセスが読み取れるので上司としてもアドバイスしやすくなります。
メールかチャットで送ってもう一度調べる
まとめたテキストを上司にデータで送ります。
理由は大きく2つ。
1つは上司は基本忙しいです。質問してすぐに答えられる状態でないことの方が多いのであとでも回答出来るような形式にします。スケジュールにすれ違いがあってもこれなら大丈夫。
このとき口頭でも伝えておくと忘れられる確率が減ります。エンジニアは役職が上がるほどメールやチャットが多くなるのでそもそも気づかない、後回しにしてたら忘れたということも普通にあるからです。もしすぐ上司が答えられるような余裕があればそのまま回答してくれますし。
そして上司の回答を待っている間にも調べ物は継続しましょう。最初の自力の制限時間を短くした理由がここにもあります。
もう1つは往々にして同じ問題にまたぶつかるからです。
一度やっただけで覚えられるほど人間は賢くありません。(たまにいるけどそういう天才)もう一度同じ問題に当たった場合は過去のテキストが参考になります。
同じ質問をしても構いません。繰り返さないことに越したことはないですし、メモっとけよというのも正論ですしそうすべきですが忘れることだってあります。「あのお何度も申し訳ないですけどお……」としおらしい態度でやってれば多分大丈夫です。多分。
無論、回答を貰ったらちゃんと解決方法やアドバイスをメモすることは忘れないようにしましょう。どうせ忘れるんだから
あとがき
ところどころ私情や私怨が垣間見えてますがそれが私の芸風ということで一つ。
それで言うとちょくちょく(まとも/普通であれば)とか付けてますがまあ酷い現場は一定数確実に存在するので……としか。
つらつらと書いてきましたが私部下どころか後輩の面倒すら受け持ったことないんですけどね。
基本一人でどうにかする(あるいはどうにかなる)現場だったのでしゃーなしなんですが。
そうそう、私の新人時代の面倒を主に見てくれた上司は御二方います。
御二方とも優秀なエンジニアで大変お世話になりましたし、ご迷惑もおかけしました。
私の考え方の一部はこの御二方、特に最初の二年くらいを見てくれた前半上司のご指導がベースになってます。
それのおかげもあって現場ではそれなりに評価、信頼を頂くことが多いです。一度信頼されすぎて大変なことになりましたが。
逆に、正直言葉選びに迷うような人にも出会ってきました。
そのような人を可能な限り減らしたいと思ってこの記事を書きました。
あとzennで投稿しようかなと思いましたがアカウント作るの面倒なんでこっちにしました
ところで新人"君"、と言ってますがこれポリコレ棒で叩かれないですかね……？