はじめに
この記事は、「モチベーションクラウド Advent Calendar 2018」25日目の記事となります。
モチベーションクラウド開発に新卒2年目からジョインすることになった@shioura_yuuyaです。
モチベーションクラウドアドベントカレンダーの最終日を担当させて頂きます。
モチベーションクラウドの開発現場はハイレベルなベテランエンジニアの方々ばかりなので、配属に先立ち私はまず七ヶ月に渡るプログラミング研修を受けました。
基礎から実践で使える技術までじっくりと学んだ上で、現在は現場でエンジニアとして働いています。
この記事では、私がプログラミングを習得するためにどのような学習をしたのか、細かい内容より学習姿勢的な部分にスポットをあてて、効果的に感じたものを3つご紹介したいと思います。
- ドリルをやらなきゃ九九は覚えない
- それ本当?の精神
- ドキュメント化は未来への投資
プログラミング学習を始めたばかりの新人の方、あるいはそんな新人をレクチャーする立場の方に参考になるものとなれば幸いです。
ドリルをやらなきゃ九九は覚えない
研修では一部分に絞った技術要素を重点的に学ぶことで、継続的・自主的に学習して成長していける状態になることがGOALでした。
とはいえ、学ぶべき技術要素は鬼たくさんありました。
(Ruby、Rails、コマンド操作、Git、SQLなどなど)
最初はとにかく参考書を読みました。が、読むだけでは問題がありました。
読んだだけでは実践できない
具体的には、、、
- プログラミング言語の参考書は読んだが、いざプログラミング問題を解こうとすると書けない
- 参考書のどこに何が書いてあるかも思い出せず索引できない
- コマンド操作の本は読んだがどんな時に使うものなのか分からない
といった事態が発生しました。私は、実は何も習得できていないのに、本を読むことで「勉強したつもり」の状態になっていたのです。
その状況を打破するために行ったことが、手を動かすことでした。
手を動かしながら参考書を読む
参考書を黙読するだけではダメで、とにかく手を動かしました。
- irbを使って参考書に出てくるRubyのプログラムを実際に動かしてみる
- Gitは実際にGitHubのリポジトリとか作ってpushしてみる
- SQLもターミナル上で全て実行する
上記のようなことをめんどくさがらず徹底的に実践していくことで、学習内容の習得度合いは格段に上昇しました。
たとえば小学生の頃に九九を覚えるためにガリガリとドリルを解いたことと同じで、プログラミングにおいて「手を動かす」ことは非常に重要なファクターであると感じました。
それ本当?の精神
詰まったことや分からないことがあった時、ちょっとGoogleで検索すれば公式サイトやQiitaや個人のブログやらさまざまな情報を手に入れることができます。
情報収集をするときには、必ずその情報が「本当に正しいか」の検証を行いました。
これには二つの理由があります。
- 間違った知識を習得してしまう可能性がある
- 情報が正しいか検証する力はエンジニアにとって必須の能力となる
間違った知識を習得してしまう
これは、そのままの意味です。
ネット上で得ることができる情報は有象無象。個人サイトはもちろん、企業のブログであってもちょっと間違ったことが書いてあることは十分ありえます。
当然ですが、一次情報をたどることを大切にしました。
上記のようなことを行うことで「本当に正しいか」確認していました。
逆に、個人のブログなどでも公式の参照が記載されているものは、信用ができそうだな、という指標にもしていました。
情報が正しいか検証する力
最初は正しい情報を収集するために始めたことですが、正しいか検証するという作業はそれ自体エンジニアとしての資質になりうることを感じます。
(例)git reset
のオプションによる挙動の違い
研修の中でgit reset
の各オプション(--hard HEAD~
や--mixied HEAD~
、--soft HEAD~
)の違いを説明し、それを証明することを求められた時がありました。
この時私は次の3つのことを行いました。
- Pro Gitを読んで、大枠の挙動を理解する
-
git help reset
でマニュアルを開きPro Gitの説明が正しいか確認する - 意図した通り動いているか手を動かして(実際に
git reset
を行って)確認する
このような「仮説」と「検証」は、現場に出た今でも日常的に行う仕事であり、プログラミング学習初期段階で癖をつけておくことは非常に有意義なものであると感じています。
少なくともテキストを丸暗記するより、ずっと実効性があると思います。
ドキュメント化は未来への投資
研修中に学んだことは、なるべくドキュメント化してGitHubのWikiに溜めるようにしていました。
正直最初はいちいちドキュメントを書くことにめんどくささを覚えていました。まとめている時間はインプットも止まるので、効率悪い気もして。
しかし結論、このドキュメント化する作業が知識の定着という意味で非常に効果的であると感じました。
知識の体系化
学んだことをドキュメント化することは、知識を体系化する作業です。学んだことを関連付けたり、構造的に整理したりしながら、まとめていくことが求められるからです(特にGitHubのWikiはMarkdownで書くため、普通の文書よりドキュメントの構造を意識できる気がする)。
体系化することで、知識の習熟度が上がる実感があります。
記憶には「エピソード記憶」と「意味記憶」がありますが、テキストなどで学ぶような意味記憶は体系化して関連づけることによって思い出しやすくなるという研究もあるそうです。
(http://www.ipc.hokusei.ac.jp/~z00105/_kamoku/kiso/2002/itou.htm)
知識の定着が進むことで、結果的に学習効率も向上したように感じます。
ナレッジの蓄積
また、Wikiに溜めていったことはやがてナレッジとして未来の自分や、所属する組織全体にとっても貴重な資産となります。
まとめ
私が初学者として実際にやってみて効果的に感じた学習手法を3つ紹介しました。
- ドリルをやらなきゃ九九は覚えない
- それ本当?の精神
- ドキュメント化は未来への投資
いずれも現場で活躍するエンジニアであれば空気を吸うようにやっていることかもしれません。
しかし、プログラミング初学者にとっては必ずしもそうではありません。
- 「技術書読んだだけで勉強した気になってしまう」という気のせい
- 「ブログに書いてあったら検討せず信じちゃう」という思考の甘さ
- 「ドキュメント書くより勉強進めたい」という短期視点
などなど課題も多く、相応の「訓練」を経て習得できた(今もしている)ものであったと思います。
プログラミング初学の時点で習慣化するくらい体に染み込ませたことで、スムーズに現場の業務に入ることができたと感じています!
おわりに
モチベーションクラウド Advent Calendar 2018は本記事を持ってゴールとなります。
モチベーションクラウドは「One for all, All for one」を実現する企業(組織)を増やしていくという思いが込められたプロダクトです。そのようなプロダクトを作っている開発チームの一員としては、自分たち自身が世界中でもっとも「One for all, All for one」な開発組織でありたいと思っています。
だからこそ、開発メンバーで一丸となって取り組み、無事最後まで走りきれた今回の企画は(私がゴールテープを切るのは恐縮ですが)、「One for all, All for one」の1つの形のように思えて、とても嬉しい気持ちです!