社会人でやり続けるとマズいエンジニアの勉強方法5選
僕は専攻が情報系ということもあり、周りにはIT業界でシステムエンジニア(SE)やプログラマを志望する学生さんがたくさんいて、プログラミングなどでの相談を受けたりすることがよくあります。 するとその中で「この勉強の仕方を社会人で続けたらまずいな」と思う人がそこそこいます。
僕が見た範囲だと、多くの学生さんは普段授業で習った範囲でプログラミングをしていて、卒研や修論をしていても新しい言語やライブラリの使い方などの勉強は正直そこまで力を入れているという印象がありません。 僕はこういう『今の自分にできる範囲』で課題を片付けようとしてしまう姿勢に、いつも疑問を感じてしまいます。
課題提出期限までの時間がないとか、(モダンな)プログラミングに詳しい人がいないとか、社会人経験がいないというような事情があるのもわかりますし、そういうことは社会人になってから身につければ良いという考え方もあるかもしれません。
しかしSEにとって、勉強とは習慣であり、習慣は身につけるのにも直すのには時間や労力がかかるものです。時間のある入社前に「SEとしての正しい勉強方法」を知っておくと、入社後の成長の下地になると思います。
そこで今回は僕が感じた、社会人でやり続けるとマズいエンジニアの勉強方法を5つ紹介します。
1. プログラムやエラー文をしっかり読まない
まずはしっかり自分が書いたプログラムやエラー文を読む習慣を付けましょう。
経験ある人も多いかと思いますが、自分も研究室で「○○っていうエラーが出てるんですけどどうしたらよいですか???」みたいな質問を受けます。 そこでたいてい言うことは次の通り。
- まずエラー文はちゃんと読んだ?
- エラーの発生前はどんな処理をしている?
- エラーの位置は何行目の何文字目?
- その関数は何を入力に何を返却するもの?
- 公式のリファレンスにはなんと書いてあった?
すると「よくわかっていないけど、とりあえずコピペで動かしてみた」というケースがやたら多いのですが、これは絶対に直した方がいいです。 今自分が書いたコードは何をしているのか、どんなエラーがどうして発生したのかをよく読む癖をつけないと、いつまでもパターンを覚えられず、関連するプログラムへの知識が一向に深まりません。
関連する話としてデバッグの方法を知らないという人も多いですね。 例えばステップイン実行をするだけで、変数の値がどこで予期せぬ値に変わるのかが分かりますが、見ているとそもそもやり方を知らないという人が多いので覚えておきましょう。
2. 知らない言葉を調べない
Unixには「知らないコマンドは絶対叩かない」という格言(?)があります。 これは、逆に言えば意味を知らなければ何もできないということです。
プログラミングをしていると、知らない言葉に頻繁に出会いますが、そういう時に放置してしまう姿勢は考え物です。 単に自分が困るだけではなく、クライアントやチームメンバーと話をするときもわかったフリして話を進めた結果、タスクの実行が困難になったり期待はずれのことをしてしまい全体に迷惑がかかるからです。
ここで注意してほしいのは、必ずしも100%の理解をする必要はないということ。
例えば「HTMLとは何か」の認識が完璧にできていなくても
- HTMLというよくわらないもの
- HTMLというホームページを作るための書き方でカッコで何かわからない文字を尖りカッコで囲った難解な文章
では、その後にできることがだいぶ違いますよね。 「よくわからない」では相手もどこから話を始めていいか分からないでしょう。 でも、ある程度わかっていれば、ホームページの話をしていることは共通認識として持てますし、次はHTMLタグの種類を説明すれば良いというように、理解が足りない部分が具体的になります。
言葉の意味を多少でも知っておくだけで、再び勉強するときもとっつきやすくなるし、「ある程度知っているなら」という条件付きでプロジェクトに参加できる可能性も増えます。
3. 言われたことを言われた範囲でしかやらない
仕事でもそうですが、言われたことだけをやり続けるのもご法度。
例えばぼくの大学では1年生の授業でプログラミングを教える際、先生がエディタとしてTerapadというエディタを紹介します。 Terapadは汎用性があり軽量なのですが、補完やオートインデントなどの機能がないためある程度プログラミングをしていると不便に感じてきます。
しかし、卒研の段階でも複雑なプログラムやLaTeXで書く論文をTerapadで書き続けている人が大勢いるのを見てとてもびっくりしています。 「不便じゃないの?? もっと便利なエディタがいっぱいあるよ」と教えると「え、そんなものあったの??」というような顔をされます。 こうなってしまうのは「Terapadしかない」「教えられたものだけしか使ってはいけない」という頭、言い換えれば「他にどんなエディタがあるのだろう」と発想できない頭になってしまっているからにほかなりません。
そうなってしまっては、学習の幅も機会も相当狭まってしまいます。 ぜひ言われたことの『上下左右』を考えましょう。
例えば最初にHTMLの勉強をしたら
- なぜHTMLは表示されるのだろう
- 同じことをまとめておけないだろうか
- クリックしたら動くようにするにはどうするのだろう
- サーバーってなんだろう
- もっと楽にHTMLを書けないだろうか
などの思考を持つと学習することの幅がグッと広がります。
4. 英語を避ける
これもあまりに多すぎます、英語しかないから諦めるという人。 海外の公式ドキュメントやStackOverFlowに当たっただけで、ブラウザのバツボタンを押しちゃう人がかなりいます。
これはとってももったいないこと! ほとんどの記事は高校レベルの英語力で充分に読めるので、少し時間をかけて読めば日本語のソースを探し続けるよりもよっぽど効率が上がります。 簡単な内容でも、なぜか日本語には答えがなく、逆に英語だとすぐに答えが見つかることも多いです。
かく言う自分も、実は以前インターンしていた時にあるフレームワークの使い方を日本語で調べていました。 その時は日本語の方が早く見つかるし理解も正確にできると思ってたのですが、先輩から「英語じゃないと一次情報(=誰かの伝聞や翻訳されていない公式の情報)に当たれないから、日本語はやめたほうがいいよ」とアドバイスされました。 それまでも特に英語には苦手意識はありませんでしたが、なんとなく日本語の方が読みやすいと思っていたのでついついそっちを見てしまっていたのでした。
それから英語のドキュメントを読む習慣をつけたところ、まるで道が開けたように使えるライブラリが増えたり知らない情報を自分のものにできるようになりました。 決して英語を勉強しなおす必要はなく、知らない単語だけ辞書で調べる程度で充分なのです。 大事なのは「英語だから見ない」という意識をなくすことです。
5. 勉強したこと自体に満足する
勉強は何のためにするのでしょうか? それがわからないで盲目的に勉強することは、貴重な時間を無駄にするだけです。
会社の目的はお金を稼ぐこと。 あなたの興味と会社の必要性は、一致する場合もありますがそうでないこともあります。 (なので僕は可能な限りそこが一致する会社に行くことを選んだのですが)
なので「とても有意義に勉強できた!!」で終われば、それは会社的には何もやらなかったことと同義です。 趣味としてやる勉強自体はよいですが、しっかり普段の仕事のスキルを上げるための自分磨きをする習慣を付けたいところ。
そのためには「この勉強をすることで仕事にどう役立つのだろう?」という疑問を考える習慣をつけるべきです。 普段の勉強でも、目的を考えてやるだけでその後のアウトプットが大きく改善されると思います。
チャットで絶対に返答してもらえるちょっと面倒だけどシンプルな方法
全体に投げたけど返事来ない問題
LINEやSlackの「全体にメッセージ投げたけど誰からも返事が返ってこない」問題。
このとき、メッセージを投げた人は「大事なことだからお前ら全員回答しろーーー!!!」って思っているし、投げられた方は「ああ、全体になんかメッセージ来てるな...(からの既読にして画面を無言で閉じる)」みたいなことをしていると想定します。
そしてメッセージの内容は(投げる側にとっては)どうでも良くない問題であることが多く...
- みんなこのアンケート回答して!
- 誰かこの仕事代わりにやって!!
- 週末の飲み会の出欠の返事くれ!!!
そしてことごとくメンバーからシカトされ、後々メッセ投げた人間の負担が増え、それによりチーム内の空気が険悪になるという負のサイクルに....
「全体」ではなく「個人」宛にDMを送る
ではどうやったら確実に全員から返事をもらえるか。
答えはとってもカンタンで「全体ではなく個人ごとにメッセージを送る」ことです。
LINEであれば全体ではなく個人LINEへ、Slackであれば@channelや@everyoneをつけるのではなくDM(ダイレクトメッセージ)で送るなどするわけです。
実はたったこれだけで本当に回答率が上がります!!!
試しに想像してみてください、誰かから冒頭に例示したようなメッセージが、全体LINEで来た時と自分宛てに直接来た時を。
「やべっ、回答しなきゃ!!」と思ってしまうのはどちらでしょうか
「あぁはいはい...」とスルーしたくなるかのはどちらでしょうか。
人間は都合よく「全員」に「自分」を含めるという心理を持つ
なんでこういうことが起きるかというと、人間は「全員」に自分が含まれるかどうかを勝手に都合よく解釈してしまう心理を持っているからです。
都合よくというのは、ポジティブなことについては「全員に自分も含まれている」と解釈するのに対して、ネガティブなことについては「全員の中に自分は入っていない(=他人事)」と解釈してしまうということです。
例えば「全員におみやげのお菓子あります」と聞くと、人間誰しもこの「全員」に「自分も含まれてほしい」と思うわけで、実際頭はそう解釈します。
よって普段活動をサボっているようなメンバーでさえも「自分はおみやげをもらう権利がある!!」と考えるわけですね。
一方「誰かこのタスクをやってください」と聞くと「オレには関係ない、他の人がやってくれる」と勝手に期待してしまうというのは、皆さん誰でも経験のあることではないでしょうか。
これはネガティブなことについては「自分を対象から除外したい」という心理が働くため、結果として他人事として解釈しスルーしてのです!!
よって「全員」や「誰か」ではなく、名指しで「あなたがやらなければいけない!!」とメッセージすることで、受けた側は「自分がやらなければいけない」という気になり、結果として回答率が上がるのです!!
それでも無視したら、その後確実にお互いの会話で触れることになりますから、逃れられないですしね（笑）
僕もこの方法によって、本当に全員からの回答が必要なものはほぼ回答を得ることができています。
とは言え対象の人数が数十人いたり、頻繁にメッセージを送ることがあったりすると、労力は馬鹿になりません。
なので、本当に全員に言わなければいけないことを吟味したり、そもそもチームの命令系統がトップダウンになってしまってはいないかなどを確認することも必要ですね。
「@channel厨」問題も解消する
あとこれはSlackなどのメンション機能があるチャットに限った話ですが、よく全員に通知したいがために頻繁に@channelや@everyoneを付けて頻繁に発言する人=@channel厨がいて、問題になったりします。
その意味でも、@channelや@everyoneの使用頻度を減らすことで全体へのチャンネルに書かれた内容が見やすくなるという効果もある思います。
まぁそこら辺については、みんなでもう一度@naoya氏の有名な情報共有のまとめスライドを見て勉強しましょう（笑）
エンジニアが勉強するモチベーションを例に、ルールと制度と文化の違いを理解する
ふと最近「なんでエンジニアはそんなに勉強するんだろう?」という疑問について考えたことがありました。
というのも、ぼくは諸事情からSEやWeb エンジニア志望の大学生にプログラミングを教えることがあるのですが「エンジニアはプログラミングを勉強し続けるものだ!!」という(エンジニアの間では当たり前な)理論が社会人には通じても学生にはいまいちピンと来ないものだと気づいたからです。
これについては人によって答えがバラバラだと思いますが、だいたい3つに分かれるのではないでしょうか。
例えば「なぜプログラミングを勉強するのか」を学生にとっての例とともに示すと
- 義務やルールとして (例: 単位取得のため、入社までに必要)
- メリットがあるから (例: エンジニアになれば給与が良い、インターンや就活で有利)
- 興味や趣味で (例: アルゴリズムが好き、アプリを作りたい)
みたいな分け方が出来ると思います。
「すべき」「できる」「したい」の3軸フレームワーク
実はこれは、就活や研修でよく教えられる有名な思考フレームワークで、あることをする時のモチベーションを「すべき」「できる」「したい」の軸で考えるというものです。
この「すべき」「できる」「したい」こと3つが全て重なることを仕事にするのが最も良いと一般には言われていて、自分も改めてそうだなと感じたことがありました。
例えば
- 研究としてのプログラミングは別にそこまでやりたいわけではないけれど卒業するために必要だからやるのでなかなか進まない
- 趣味でやるプログラミングはやりたいからやっているけれど特に期限や質のボーダーはないので中途半端になってしまう
みたな感じで、どれかが欠けているとモチベーションは持続しないのかなと思いました。
前述の「エンジニアが勉強する理由」なら
- そもそも「勉強したい」という気持ちがないと、いくら義務であってサポート制度があっても利用するモチベーションすら起きない
- 「勉強できる」環境になければ(残業毎日終電まである等)、やはり物理的・金銭的に勉強することは難しい
- 「勉強しなくてもしてもどっちでも良い」のではよほど自分に厳しくない限りいつまでも完了しないし、いわばただの趣味になってしまう
というように、3つの要素ともマッチしていないと集中的かつ継続的な勉強というのは難しいと思うのです。
ルール・制度・文化は3つの軸のモチベーションを広げる要因
そこで外部要因として、この3つのモチベーションを広げるのが「ルール」「制度」「文化」だと思います。
ルールは「すべきこと」を規定するもので、普通自分ではなかなか決められません。
しかし外部で「朝礼で報告しなければいけない」「勉強しなければエンジニアとしての市場価値が下がる」というルールが設定されていれば、嫌でも勉強をやるモチベーションになります。
そこに「できること」を支援する制度が必要になります。
例えば新しい技術書を買うことを支援したり、勉強会やカンファレンスへの参加費を負担してくれるといったような制度は、勉強できるという行動の幅を広げることにつながります。またリモートワークを許可するというのも時間の使い方の自由度を上げ、結果的に勉強できる可能性を上げることになりますよね。
でも最後に「したいこと」として勉強を捉えなければ行動につながりません。
そこには文化というものが絡むと思っていて、例えば周囲が積極的に勉強していて自分もそれに釣られるとか、LT会やQiitaで成果を報告することでドヤ顔できたり笑い合えるという文化が「したい」のモチベーションを広げていくことになります。
そしてここで最初の疑問である「なぜエンジニアは勉強するのか?」の答えに戻ると、この3つのうちどれかを理由にしている人もいれば、全てを理由に勉強する人もいるというのが答えになるわけです。
ただ一つ言えるのは成長の早い人は3つ全てのモチベーションを持ち、さらにそれを広げられる環境にいるということでしょう。
途中の例にも出したように、全てが上手く揃っていないと、結局やらされ仕事になったり単なる趣味に終始したりという結果になるので好ましくありません。
はじめのうちはこの考え方がよくわからないと思いますが、自分は幸いな事にインターンや趣味のプロジェクトなど様々なきっかけでプログラミングをすることで、上記のことを理解できました。
3つ軸で考えれば誰かが何かをやらない本当の原因が分かる
ちなみにこの考え方は他のことでも同じだと思います。
特に個人的な経験では「制度」について誇張されがちな傾向があると感じています。
つまり「そもそもそうすべき/したいと思う人が本当にいるのか」という点が見落とされているということです。
「うちの大学に来ればこんなことが学べます」「我が社に入ればこんな事業ができます」
確かに「できる」は大事だが、本人にもそれだけの「やりたい」モチベーションは本当にあるの?
少子化を止めるには産休・育休や保育制度の拡充が必要
子供を儲けなければいけない・儲けたいと本当に思っている人達って多いの?? 自分のことの方が大事だったり結婚するの面倒と思っているだけなんじゃないの??
起業家を増やすには資金や施設などの補助が必要だ
そもそも起業をミッションとして生きている人や会社を興したいという意欲のある人自体が少ないのでは???
議論はあるとおもいますが 、産休育休制度を義務化したりベンチャー支援を充実させるのは、実は「できる」ようにしているだけで、当事者自身が「しなければいけない」「そうしたい」と思わなければ意味は無いでしょうね。
以上、モチベーションの源泉について思考を整理しました。
