「若手エンジニアに送る"心構え"と"キャリア観"」を聞いてきた
サポーターズColab主催の「若手エンジニアに送る"心構え"と"キャリア観"」を聞いてきました。
内容のまとめ記事はすでに何人かの方が書いてくださっています。
ですので、自分的なハイライトを中心に書いてみたいと思います。
どんな内容だったか
実際にまとめきるのは不可能な内容でしたが、強引に3行でまとめると、
- 技術の学び方を学べ
- アウトプットを続けろ
- 経験から技術の流れを俯瞰しろ
こんな内容でした。
これらに付随して、技術書の読み方、学びのペース、機会の得方などを話されていました。
印象に残った話
80分間の講演の中で、印象に残ったのは以下の2つです。
- デールの円錐
- ロードマップ指向とエコシステム指向
デールの円錐
エドガー・デールという教育学者が1969年に発表したコンセプト図で、「学習後2週間でどれくらい覚えているか」を表したものです。これははじめて知りました。
英語ではLearning Pyramidというらしく、こんな画像がひっかかりました。
学習の方法ごとに、2週間後に覚えている割合を列挙すると
- 読む - 10%
- 聞く - 20%
- 見る - 30%
- 見ると聞く - 50%
- 学んだことを話す - 70%
- 話した上でやってみる - 90%
こんな感じだそうです。
つまり、技術を自分に身につけるには人に話した上で実際にやってみろ というわけですね。
ITエンジニア的にこれが一番良くできるのはライブコーディングですので、@t_wada さんが学習効果のある方法として推すのも頷けます。
ぐだぐだ言ってないでコードを書けよ、ハゲ。 なんて名言もありますが、ぐだぐだ言った上でコードを書くのが一番良い ってことでしょうか。違うか。
学生のときに塾講師を5年ほどやってたんですが、一番下ってまさに塾講師の仕事 で、受験生のときより高校数学がよほど身についているのはこういうわけなんですね。
ITエンジニア的には一番下の「話す」のを「書く」のに置き換えれば結構効果が高いんじゃないですかね。
ロードマップ指向とエコシステム指向
「人のつくる渦を見る」というキーワードで話されていました。
具体的にはこのブログ記事が元とのこと。
ロードマップは、スキル開発のガイドラインになっていて、これを頼りに、誰が何をいつどれくらい勉強すべきかを考えるのだ。
（中略）
しかし、今の業界は、「エコシステム」の時代だ。熱帯雨林のように、食いあいつつ共生しあうさまざなタイプのプレイヤーが、自分の為だけの個別の意思決定をして、その相互作用で技術が発展していく。
モヤモヤしていたものがストンと落ちたような気がしました。
「何かを勉強する」ということに関しては無意識に学校の勉強をモデルにする部分があり、それってつまりはロードマップ型なんですよね。国の学習指導要領とか大学のシラバスに基づいて勉強を進めていけばテストの点が取れたり単位が取れたりする。
けど今の業界は「エコシステム型」で、手前勝手にいろんな方向に発展していく。ので、統一的なガイドラインがなく、自分がどの方向に進むべきかは情報を十分集めた上で自分で決めないといけない。
で、情報を集めるのにはキリがないから、自分の進む道に確信が持てない。それでモヤモヤしている。
だから、自分の身につける技術は好みと勘でえいやっと決めるしかなくって、それを一つに絞るとそれがオワコン化したときに危ないから複数身に付けろと。
ここらを踏まえて自分はどうなのか、と省みると、深めようとしているのは
なので、バランス的にはそこそこなんじゃないかなと思いますね。
わかりやすいアウトプットが出にくいので、そこは工夫次第ってとこかな。
質問に答えてもらいました
今回のイベントでの質疑応答はTwitterでつぶやいて、スタッフさんがピックアップする 形で行われました。
アカウント名をあまりスタッフさんが見ていなかったのか、2つした質問が両方採用されまして、直接回答をいただきました。
「技術が身についた」って何？
まずはこちらのツイートでした質問。
うーん、新しい言語は何をもって「学んだ」とするのか #spzcolab
— expa (@expajp) 2017年9月23日
この質問には、
自分で作ったサービスを公開するところまで。エンジニアにはライブラリ型とアプリケーション型がいるので、成果物は異なる。
また、何も見ずにスラスラ書けるようになる、というのが一つの到達点。
との回答をいただきました。
本とかのレールから外れて成果物の方針を決めるのってそれなりにまとまった時間が必要で、連休とかで意識的に作っていかないといけないのかなと思いますね。
Write Code Everydayのネタ決めをどうするか
先日こんな記事を書きましたが、
こういう状況なので、こんな質問をしました。
WriteCodeEveryDayをやってみてはいるものの、毎日コミットできるネタしか選べない縛りが苦しい #spzcolab
— expa (@expajp) 2017年9月23日
こちら、どのように解決されているのでしょうか #spzcolab https://t.co/e1VTmbne3N
— expa (@expajp) 2017年9月23日
この質問には、
手段が目的化しないように。大事なのはプログラミングを習慣化することで、John Resig氏のルールはちと厳しすぎるところがある。適度に緩めよう。
実は、サービスを公開していればユーザからバグ報告や要望として降ってくる。
Rails Tutorialでも良い。
と回答をいただきました。
「ユーザから降ってくる」ってのは目からウロコでした。いままでサービス公開したことないですもんね。。。
実はRails Tutorial始めようと思ってるんですけどProject Eular一区切りのProblem 50に苦戦中なんですよね。。。
とりあえず、50を倒したらそちらにシフトします。
まとめ
普段からモヤモヤしてることに一つの「回答」を与えてくださったような講演 でした。
勉強会聞きに行って「参加するだけで満足」のパターンに陥りつつあるので参加は迷ったんですが、行って本当に良かったです。
アウトプットちゃんとしないとですね。サービスの形で。
