大学在学中の3年半インターンとして働いて学んだこと

情報工学科に所属して基礎的なコンピューターサイエンスを学ぶ傍ら、実際にビジネスの現場での開発を学ぶためにインターンをした。時間がない中で少しでも自分のできることを増やしていくために試行錯誤した内容を振り返ってまとめてみる。

免責

こちらは私が学生時代にアルバイトとして時給で働いていた頃の考えをまとめたものです。雇用者側としてこれらの項目を押し付けることは様々な問題に繋がる可能性もあります。あくまで新米エンジニアが成長しようともがいた過程の一例として、どなたかの参考になることがあれば嬉しいです。

優秀なエンジニアになるための考え方（マインド）

まずは自分の存在価値を作ることに全力を注ぐ

他の現場や、趣味・独学で多少知識や技能を高めていても、実際の現場に合わせた作業や知識を求められる機会は多々ある。技術的にも全てを網羅して最新情報までキャッチアップすることは不可能に近いので、現場には何かしら自分の知らないことがあると考える。前職での成果や自信で周りが見えなくなることがないように、まずは現場で自分に何が求められているのかを見極めて、それを満たせるようになることに全力を注ぐ。

興味深い技術の話を上司に持ちかけるのは、最低限自分の居場所を作ってからでよし。

いかに自分が成長できるかを追求する

週に10時間前後、月で50時間程度働いていたので、その時間をどう過ごすかで自分の能力は大きく変わってくる。自分が理想とする像をしっかり描いた上で、どうしたらその理想像に近づけるかを日々考えて仕事に取り組むことで有意義な学びを得ることができる。

熟達者のそばにいられることはありがたいことだと認識する

現場の最前線に立っているエンジニアのすぐ近くで、声をかけようと思えばかけられる状況で過ごせることは滅多にない。単に仕事の内容から学ぶだけではなく、プロフェッショナルの仕事へ向き合う姿勢、休憩の取り方、コミュニケーションの仕方を間近で見ることができる。

そのような環境に自分がいられることに感謝して、誠心誠意応える。（もし、そう思えないのであればもしかしたら職場を変えたほうがいいのかもしれない）

優秀なエンジニアになるための学び方 〜基本編〜

PC・携帯電話はマナーモードにする

給料をもらって働いている以上、仕事以外のことに時間を使うのは良くない。もちろんちょっとした休憩の合間や、緊急事態は別だが、基本的にはプライベートな作業は行わないようにする。

携帯電話はマナーモードにしてカバンかポケットにしまう。パソコンに通知をオフにするモードがあればそれもオンにしておく。

意図的に「目の前の仕事に集中して、なんとか価値を提供しようとしていますよ！」という姿勢を作っていくことで、より多くのアドバイスをもらうことができたり、後で紹介する「質の高い雑談」につなげたりすることができる。

PCの音量は最小にして、携帯のバイブレーションもオフにする

PCの通知音や携帯のバイブレーションは、自分の端末と同じ音が設定されている場合、聞こえると非常に集中力を削がれる。「何か重要な連絡が入ったかな？」と考える一瞬の時間を熟達者から奪ってはいけない。

他の人の集中力を削いでまで急ぎの連絡を受ける必要性がない立場ならそれ相応の態度で臨む必要がある。油断して携帯やパソコンが音を出してしまったら、一言「すみません」と謝って音量を下げ、次から同じことを繰り返さないようにするだけでいい。

イヤホンで音楽を聞かない

プロフェッショナルのそばで学ばせてもらっている、未熟な自分に対して信頼して仕事を任せてくれている、そんな状況でイヤホンで音楽を聞くのは失礼だと考えた。たとえ会議の声が気になったり、集中したいときは音楽を聞くと良いと自分なりに考えていたとしても我慢する。せっかく熟達者が近くにいて、声をかけてもらえる可能性があるのにその機会を自分から奪うようなことはしない。

特に、「若い世代は気に入らないことがあるとすぐ会社をやめる」といった情報が流れている今、「イヤホンをして作業することは効率的かどうか」という議論は不毛になるので会社側としては避けたいだろうし、業務命令として禁止するにしても出来るだけ波風立たないようにしたいのが人の性。そういった不必要なストレスを無意識に与えてしまわないように配慮したい。

メモをしっかりと取り、同じ指示や指摘を2度と受けないようにする

業務の指示を受けたり、なんらかの指摘を受けるときはメモをしっかりと取るようにする。

「覚えていられるから大丈夫」と自分の能力を過信することは良くない。複雑な指示・指摘の内容を本当に覚えていられたとしても、指導担当者からすれば「メモも取らずに聞くなんて、理解しようという姿勢がないのではないか？」と感じられるかもしれない。

自分の能力（どの程度のメモが必要なのか）が指導担当者に肌感覚として伝わるまでは特に、気持ち多めでメモを取っていくことが大切。

業務の指示や指摘に対してすぐに従うことができないと、自分の時間が無駄になってしまうことはもちろん、明確に仕事を止めていることになるので処分対象にもなり得る。当たり前にできていると自分で思っていることでも、できていないと判断されてしまったらそれまで。自責で考えてどうしたら指示・指摘を守れるかを考えてすぐに正すようにする。

メモをしっかりと取り、同じアドバイスを2度と受けないようにする

指示・指摘よりもっと気軽な「アドバイス」程度の意見をもらうことも多々ある。「Ctrl + aで一気に選択できて便利だよ！」というのは指示・指摘というよりアドバイスに近い。

アドバイスは人によっては聞き入れる必要がないと判断してしまうこともある。しかし伝える側としては、「本当はそれをやってくれた方が絶対速く、ミスなくできるからやってほしいんだけどな」と思っている可能性もある。

指示・指摘として言うのは憚られるけど、ぜひ伝えてあげたいと思える知識の獲得機会を逃さないためにも、ちょっとしたアドバイスは即受け入れて自分のものにしていく。

もし、アドバイス以上に良い方法があるならそれを適切なタイミングでアピールするだけで良い。

使う道具・ツール等は出来るだけ合わせる

パソコンに入っているアプリケーションまで含めて考えると、ITエンジニアほど道具に多様性がある職業は珍しい気がする。OSならWindowsかmacOSか、エディタならどれを使うか、などなど無限の可能性がある。自分が一番慣れ親しんで使いやすいものを使おうという改善意識は素晴らしいが、誰かに教えを請う立場では足かせになってしまう可能性がある。

なんらかの不具合や困りごとが発生したときに熟達者に質問しても、「そのエディタよく知らないからわからないんだよね。エディタの仕様のせいだったりしない？」と返されてしまったり、操作手順書を作って欲しいと依頼されたときにどの環境向けに作るかといった不必要な混乱を招いてしまったりする。

思い切って熟達者を信じて、一通りの道具を合わせてしまってもいいかもしれない。エンジニアは自分の道具に自信を持っていることが多いので、それらを丸ごと真似すれば「素直で向上心があるやつだ」と評価してもらえて、よりアドバイスをもらえる機会が増えるかもしれない。

優秀なエンジニアになるための学び方 〜質問の仕方編〜

質問をするときは事前に状況をしっかりと整理する

わからないことが出てきたタイミングですぐに熟達者に声をかけることはしないようにする。しっかりと状況を整理せずに質問しようとすると、以下のような状況が発生してしまうことがある。

• 不具合が起きたと思って再現しようとしたら、再現できない
• 不具合を説明している最中で超イージーミスに気づかれてしまう、または自分で気づいてしまう
• 以前教えてもらった調べ方をし忘れていて、「前伝えたことがなぜできないの？」と学び方の姿勢の指導にレベルが落ちてしまう
• 質問内容が言語化できていなくて、熟達者に正確に伝わらずに時間を取らせてしまう

結局、質問しようとしたことが浅すぎて即対処方法を示されてしまったり、質問の仕方が下手すぎて逆にヒアリングされる形になってしまったりする。

いずれにしても、熟達者と自分の両方の時間を無駄にしてしまう。

質問する際は、以下の点をしっかり押さえるようにする。

• 状況を一言で伝えられるようにしておく

  • 不具合が起きていて先に進めないのか？
  • 可能性がありそうな複数の設計で迷っているのか？

• 熟達者に何を求めているのかを明確にする

  • 自分がとっているデバッグ方法が最短かを確認したい
  • 情報がなく先へ進めそうにないが、このまま模索を続けるべきか経験をもとに判断を仰ぎたい

• どんな状況なのか詳細に伝えられるようにする

  • どんなエラーが出ているのか
  • フレームワーク等のバージョンはどうなっているのか
  • 再起動等の基本的な方法は試してみたのか
  • どれくらいの時間試行錯誤をしてみたのか
  • 解決できそうな自信はどれくらいあるのか

• どんな挑戦をしてみたのかを明確にする

  • どんな検索キーワードで調べたのか？
  • どんな条件で試してみたのか？
  • どのようにデバッグを試みたのか？

わからないことはわからないと言う

熟達者から初学者に対して「〜って知ってる？」と聞くのは、もちろんマウントを取るためではない。教育で言うところの診断的評価であり、どこまで知っていてどこから知らないのかを明らかにしていくための質問である。その質問に対して見栄を張って知ったかぶりをしたり曖昧な返事をすると、その後の指示・指摘・アドバイスが的を射なくなってしまう。

「〜って知ってる？」と聞かれたときはバカにされたなんて考える必要は全くなく、知らなければ素直に「初めて聞きました」や「名前だけは目にしたことがあります」と答えれば良い。

素直に指摘を受け入れる

エンジニアリングは情報工学として理論的に研究されている面もあるが、どうしても職人的・経験的な判断が有効なことがある。初学者からすると一見理解できないような指摘が、実は様々な経験の上に組み立てられたいわゆる「ベストプラクティス」だったりもする。

熟達者がそれを初学者に諭すとき、場合によっては「経験上こうだから」のような論理的でない表現を使うかもしれない。しかしそれは、論理的にそれを証明するのが極めて困難でありつつ、極めて困難であることを伝えることもまた困難だと思われているからかもしれない。

自分なりの考えを伝えた結果どうするかは熟達者の判断に委ねる。

パソコンの操作に精通する

質問をする際、自分のパソコンの画面を見てもらいながら説明することがある。その際に、ウィンドウがたくさん開かれていて移動に手間取ったり、ウィンドウが小さいままで見づらかったりしないように注意する。

ちょっとしたショートカットやコマンドはフルに使う。アドバイスとして習ったものは全部取り入れて当たり前で、熟達者に「なにその技！？」と言わせたら勝ちくらいの気持ちで操作を行う。

操作に手間取ると熟達者は無意識にイラつく可能性もあるし、その操作が以前熟達者から与えられた指示・指摘・アドバイスに則っていなければ問題がある。

誰よりもスムーズに操作して、一番話したい内容に参加者が集中できるように最大限配慮する。

言葉を正確に使い、正しい文章で会話する

初学者で技術の概念的な理解が浅い状態だと、語句を正確に使えないことが多々あります。語句を正確に使えていない表現とそれを正確な表現に書き換えた例としては以下のようなものが挙げられます。

正確でない表現	正確な表現
「gitで切り替えて作業しました」	「gitでブランチをmasterからmybranchにチェックアウトして作業しました」
「開発環境でいつもログインを求められるやつが〜〜〜」	「開発環境のBasic認証が」

初学者の段階でも、正確に理解できていない感覚はあるのでつい怪しいところは口に出すのが億劫になるが、自信を持って言い切るようにする。言い切ることで、そこに誤りがあればすぐに熟達者が指摘しやすくなる。

質問も尻すぼみになって「ビルドしようとしたらなんかエラーが出ていて....」となってしまいがちだが、強気でしっかりと文章になった質問をするようにする。

「ビルドしようと〜〜〜とコマンドを実行したら、〜〜〜というエラーが出ました。エラーの出力を検索して解決策を探っていこうと思いますが、この方法で問題ないでしょうか？」と聞く。

熟達者であれば初学者の悩みを軽く聞いた段階で解決策がわかってしまい、尻すぼみな質問でも正確な回答を得ることができるかもしれないが、それでは自身の成長スピードが最大にはならない。

質問の仕方すら質問する

質問する相手も熟達者とはいえ一人の人間なので、絶対的にこの質問の仕方が正しい、というものはない。ある人に聞いたら「もっと早く聞きに来なさい」と言われたのに、他の人に聞いたら「もっと考えてから来なさい」と言われる。そんなことは日常茶飯事です。いちいちそれに対して「あの人はああ言っていましたが」みたいな突っかかりをするのは学校までにする。

質問した後などに、どんな質問の仕方が良いのかを直接相手に聞いてしまう。

• 「このような質問の仕方で問題ないでしょうか？」
• 「質問のタイミングは遅いでしょうか？早いでしょうか？」

多くの相手に共通する理想の質問の仕方を磨きつつ、人と人とのコミュニケーションを大切にして質問していくことが大切。