…を書こうと思っていた矢先に↓が投稿された。
しかもぼくが書こうとした内容よりも理論付けられていたり、充実した内容だったり、深掘りされてたりして非常に良いのでこれ読めばだいたい終わるし書かなくていいじゃんね！ってなった。
完。
employment.en-japan.com
これを読んだあとで「あーこんな良いエントリあるならぼく書かなくてもいんじゃね？っていうかぼくも知らない内容書かれてて充実度で完敗だし書く必要性無くね？？」とか思って書かないでおこうかと思っていたのだけども
別にぼくが似たようなことを書いてもPV数やまとまっている内容の充実差で件のエントリに微々たる影響を及ぼすこともなかろう、あと単純に書いて頭の中を整理しておこうと思い直したので今書いてる。
タイトルは元々の主旨なのだけどそれは↑を読めば満足できると思うのでこのエントリはそこからちょっと外れているものを書いておこうと思う。
ぼくの「これがあかんのやぞ！」とかを列挙して自戒を見える化のログとするのが目的に急遽変更する。
なので多分考えをまとめるとかすっ飛ばしていきなり書いてるので支離滅裂なことになっている点に注意してもらいたい。
パラシュート勉強法
ぼくは恥ずかしい人なのでこのパラシュート勉強法なる呼称を知らなかったのだけど最近自分のできる技術的な範囲を広げたい、広げよう！と思ってパーフェクトRuby on Railsの初版本を片手に写経していたのだけどこれがかなり難航していた。
理由としては単純でこの書籍が刊行された当初のバージョンがRails4.xを基準にしており、最新の5.xでは動かない…みたいなことが多発したというだけだ。
とはいえコードの部分ではなくgemのインストールやライブラリの依存関係など解決したい問題の本質以外の部分で大いに煩わされていてストレスフルなので↑の書籍を買おうか悩んでいるかたには現時点ではおすすめできない。
第2版が出て最新のRailsやRuby、gemなどに対応してくれたら検討する候補にあげてもいいかもレベルだと思う。
不満な点でいえばGithubなどに書籍のサンプルコードをおいてくれていないのでRailsの変更があったのでここを直さないと動かない！みたいな部分のサポートがないのが非常に不満だった。
蛇足だが、この手のサポートはGo言語によるWebアプリケーション開発が非常に良かった印象がある。
Githubに掲載されているコードがあって書籍との差異を検知できる仕組みがあったので非常に良かった。
今後買う「書いて覚える」系の技術書はこの手のサポートがあるかないかを購入基準にするのがベターかもしれないなあと思ったりなんかした。
PHPはこの辺後方互換がかなり考慮されているので、技術書に書かれているレベルのものであまり困ることがなかったのだけどRailsはJavaScriptほどでないにせよ変化の激しいものがあって初学者には書籍で学ぶのが難しいと感じることとなった。
「公式チュートリアルを写経」にしておけばよかったといまは後悔している。
railstutorial.jp
そんなわけなので「まず自分が作りたいアプリケーションを実装していってわからないところがあればそこだけググったほうが早いし理解度あがるんじゃね？」的なことを考えていた。
先のエントリ紹介されているがそれをパラシュート勉強法というらしい。
何故最初からそうしなかったか？
この手法では単純に体系的に学ぶことが出来ないからだ。
ぼくもエントリを書かれた方と同じく大学でコンピューターサイエンスを専攻していたわけではないので非常にわかるのだが、体系的に学ぶ強みというものがある。
これがあるため「最初は遠回りに見えても最終的に体系的に学ぶことが最短なのではないか？」と考えるに至ったので今回は書籍を一からなぞるという行為を選択した経緯となる。
そして「学問に王道なし」という言葉があるように恐らくは体系的に学ぶことが出来る以上の効率の良い学習方法はないとぼくは考えている。
ところが結果だけみるとこのパーフェクトRuby on Railsにおいてはそれはあまり正解ではなかった。
基本的にはこのアプローチで間違いない。
ではなぜぼくが失敗したのか？というと一次ソースを当たらなかったことが原因だろうと思う。
これは件のエントリでも書かれていて非常に耳が痛い内容だった。
重要なのは「実際にLinuxを触る前からコマンド一覧をひたすら眺める」とか、「単純なルーティングも設定したことがないのに『マスタリングTCP/IP』を読みはじめる」 というようなことを一切しないことです。
必要なピースを拾い集めながら、知識のマスを少しずつ埋めていきます。上記でカッコ書きしたようなことは、勉強の初期段階よりも、学習が進んでから全体の横串を通すときに行ったほうが効果的です。
この一言でほぼ言いたいことがまとまってたので引用させてもらったが改めて端的にまとまっていて良さを感じる。
他にも遅延評価的学習方法は個人的には若干疑問視する部分があって完全には同意していないけど「必要になってからやる」「やったら徹底的にやる」は真理だと思ってる。
ところでこのパラシュート勉強法という命名がぼくには非常にユニークで面白く感じたので一応補足的に書いておこうと思う。
これは件のエントリには書かれていなかったのだ！(ﾄﾞﾔｧ
以前バズってくれたエントリリーダー(管理者)ではなくエンジニア(実務者)でありたいと願う人々へで紹介したElastic Leadershipに書かれていたことなのだが「学習フェイズにおいて挑戦的課題が重要だ」と述べられている。
挑戦的課題とはなにか？
- 不安を感じる
- 挑戦するのに勇気がいる
- リスクがある
- 類似点はあるがその時とは違うと感じている(悪い意味で)
乱暴にまとめてしまうならば、これらの要素を兼ね備えたものが挑戦的課題だ。
これらは全て「信頼を損なう」「力量を低く見積もられる」「自分の底が露呈してしまう」などの心理的安全性の外側に踏み出していることで初めて実感するものであり
これこそが成長には絶対的に必要なものだと書かれている。
逆にこれらの不安要素が含まれない学習は学習したつもりになっているという旨が記載されている、課題ではあっても挑戦ではないという意味だと認識している。
著者はこの状態を「安全領域から一歩踏み出す」というような表現をしているのが面白い、体感的にも成長が飛躍的に向上したときはこれらの挑戦部分を克服したときであることが多かったなあと思う。
この件がどうパラシュート勉強法の命名がユニークであることと繋がるのか？だがパラシュートというと一般的には遙か上空の彼方から身一つでアイキャンフライしちゃう頭のおかしいスポーツだと思う。
そのときに感じることはなにか？
↑の不安要素を内包しているんじゃあないかとぼくは考え、このパラシュート勉強法という命名が非常に端的に成長するために必要な学習要素を含んでいるように感じたというだけの話しなんだけどね。
実際にそれらを意図しているかどうかは不明なので勝手に妄想して「おおこれは言い得て妙だぞ！」と感心したよと。
恥ずかしいことを隠さない
ぼくの知人に id:otiai10氏という方がいる。
このひとをぼくは非常にすごいなと思っていてその理由が「恥ずかしい勉強会」というものを開催しているのだ。
hazukac.connpass.com
これってすごいことだと思っていて「今更聞けないけど知っておきたい〜」みたいなエントリが定期的にはてブには流れてくる。
これらを読んで満足しているひとはぼくも含めて多いだろうと思う。
そこから更に一歩踏み込んで「ぼくはこれを知らない恥ずかしい人なのだけど恥ずかしいからこそ学ぶぞ！」みたいな精神は見習うべきものがあるし、なによりそれを実行できる勇気がすごいなと感じている。
なので最近ぼくも真似をしてQiitaに恥ずかしい話しを投稿したら速攻でアドバイスやフィードバックが返ってきて自習ではなかなかこういったフィードバックは得にくいし恥ずかしい話しはもっと公開すべきなのではないか？と思った次第。
恥ずかしいことを隠しても問題が秘匿されるだけで技術力の向上には1mmも貢献しないが恥ずかしい話だぞ！って予防線貼れば対象読者も「ああこれは恥ずかしいやつの書いたことか」と思ってくれるかもしれない。
心理的安全性を確保しつつフィードバックによって技術的な知識や知見を得られるのでもっと早くに恥を晒してればなーって思った。
技術力以外の恥なら晒し放題なくせにチキンなので日和って損してたなーと改めて思いましたまる
本を買って満足しない、本を読み切って満足しない
はてな社員の誰かがいってたけど「手を動かしたやつが一番エラい」は真理。
本を買っても、ただ本を読みきっただけでも技術力の向上には1mmも貢献しないのだ。
手を動かして真に頭で理解することが重要、書籍はそのための案内板のようなものだと思おう。
勉強会に参加も然り。
本業以外でスキルセットを磨く場を作る
これは万人向けってわけではないのだけど本業以外にスキルセットを磨く場を設けておくとパラダイムシフトが起こって点と点、線と線が繋がりだして学習速度が飛躍的に上がるように感じたぞ！って話し。
僕の場合は副業がきっかけだった。
副業をはじめてどういう点で変わったのか？
まず時間に対する概念というか考え方が大きく変わったように思う。
時間のやりくりやスイッチングコストが大きいことがどれだけ問題か？がようやく理解できた。
平日の夜に自宅に帰ってから副業にジョインするのでどうしても残業が出来ない(しない)、少ない時間で成果を出せる実装をしないといけないなどの自己制約を課すようになった。
それまでは本業で「このタスク定時までに終わらんかったけどあと1時間残業すれば終わりそうだなー」とか軽く考えてた。
「残業は悪だ」みたいな基本思想は元々あったんだけど悪とか正義じゃなくて終わらないと副業先に迷惑をかけることになるのでなんとしても終わらせる！！！みたいな方向に考え方がシフトした。
あと「本業+副業」を行っているためどうしても自分の学習にかける時間が激減する。
本業にせよ、副業にせよお金をもらっている以上そちらを優先するのは当たり前なのだけど、エンジニアとしては日々技術力を磨かないとぼくみたいなへっぽこ園児ニャアはおまんまの食い上げになってしまうと思うし、事実そうなるだろうなと日々感じている。
なので土日をかなり意識的に時間をとって自習にあてたり技術書を読む時間に宛ててるようにしている…んだけどこれがなかなか大変。
これは本業だけだと実感しなかった点で自分の時間の大切さを噛み締めてる、アニメみる時間とかゲームする時間が激減した。
「短い時間で如何に効率よく学習できるか？あるいは如何にシャローワークを殺していくか」みたいなことを考えるようになった。
その結果として「Elastic Leadership」「イシューからはじめよ」「DeepWork」「GRIT」みたいな今まで読まなかった自己啓発系？なのかわからないけど書籍を読むようになった。
ある意味ではこれはいい転機だったのかなと思う、それによって今まで得られなかった、あるいは意図的に避けていた事柄に触れたり知ることが出来て少しだけ考えの幅が広がったように思う。
過去エントリでも紹介しているが一応列挙したものを再度あげておく、興味があれば読んでみるといいのではないかなとぼくは思ってる。
おすすめはElastic Leadershipとイシューからはじめよの2つ。
DeepWorkとGRITは興味があれば…って感じかな。
これらのことから離れる時間を意識的にとる
人にもよると思うが技術だけではなくて観光したり温泉入ったり娯楽小説読んだりゲームしたりすることも時には必要。
ぼくは元々このあたりのスイッチングコストが大きくて下手だったので最近は意識的に土日のどちらかは必ずジムにいったり気になってた小説を読んだり買ったままになっていた技術書を読むようにしている。
あとたまにブログ書いたりブログネタを考えたりとか。
意識の切り替えが重要で本当に必要なときだけ集中するモードを養うことが肝要。
集中できる場を作る
人によるが自分がここなら誰にも邪魔されない！という場所を持っておくのが重要。
読書なら鴨川デルタ(近くにベンチが沢山ある、デルタから少し離れただけでほぼ確実に座れる)、コードを書くときは会社近くのスタバか烏丸御池近辺のスタバを愛用してる。
↑のスタバ休日はほどよく人来ないし京阪三条にあるスタバと違ってほどよく長い出来るので大変助かる。
テラス席だと広々と使えるしだいたいヘッドフォンしてコード書いたりしているので騒音とかもほぼ気にならなくて捗る。
唯一のネックは電源だけど店内なら電源あるので最悪一定時間だけそこから拝借する。
継続性を持つ
自分でこれくらい出来るだろ！と思うのからちょっと少なめに見積もるようにしている。
例えば英語の学習をしようとして1日2時間！とかいきなりぶっ込むとだいたいどこかで詰む。
なので寝る前の30分だけ！とかかなり緩めの条件に設定する、人間は怠け者なので恐らくはコレですらサボる。
…サボるがたった30分だし！と思えるかどうかが個人的に重要かなと思ってて2時間だとその分を取り戻すべく翌日分に追加するとその分の時間を確保できなくて心折れてやらなくなる。
出来ると思ってやったことが出来ないと心が折れてやらなくなるのは万国共通なので条件は緩めにする。
物足りないと感じたら増やす方向で今のところちょうどいい塩梅。
あと重要なのが出来ない場合のリカバリー方法。
必ず翌日にもっていくと溜まったときに心折れるので週の最低ラインを設定して最悪それを超えていればOKという風にぼくは調整した。
このあたりは属人性が高いので話半分くらいで聞いておいて欲しい。
まとめ
もっと早い段階でこれらの学習方法に気づいていればもう少しマシなエンジニア人生を送れたのかなーと思うけども現状よりも悪化させないためにも今後も継続してやっていこうと思ってる。
