人は一ヶ月でエンジニアになれるのか - 詳細解説
•847 likes•394,806 views
Report
Share
Download to read offline
新卒2年目のウェブディレクターが1ヶ月でエンジニアに転身したプロジェクトの、教材・方針・進行内容について具体的に解説しました。またあまりの反響の大きさに、あらたな募集も開始することとなりました。本気でエンジニアを目指す方も、まずは話を聞いてみたい人も、ぜひご応募ください。 https://www.wantedly.com/projects/15926
More Related Content
What's hot
What's hot(20)
Viewers also liked
Viewers also liked(20)
Similar to 人は一ヶ月でエンジニアになれるのか - 詳細解説
![[Observability conference 2022/3/11] NewsPicks のプロダクト開発エンジニアが実践するスキルとしての SRE](https://cdn.slidesharecdn.com/ss_thumbnails/observabilityconference2022311newspickssre-220310143345-thumbnail.jpg?width=384&fit=bounds)
Similar to 人は一ヶ月でエンジニアになれるのか - 詳細解説(14)
![[Observability conference 2022/3/11] NewsPicks のプロダクト開発エンジニアが実践するスキルとしての SRE](https://cdn.slidesharecdn.com/ss_thumbnails/observabilityconference2022311newspickssre-220310143345-thumbnail.jpg?width=768&fit=bounds)
Recently uploaded
Recently uploaded(6)
人は一ヶ月でエンジニアになれるのか - 詳細解説
- 3. http://careerhack.en-japan.com/report/detail/453 http://www.slideshare.net/kiyotoyamaura/1-45361529 ｢人は一ヶ月でエンジニアになれるのか｣とは？ ▸ リブセンス新卒2年目のディレクターが ▸ 1ヶ月業務から離れてウェブエンジニアへの転身を図ったプロジェクト ▸ その後なんとか現場でウェブエンジニアとして活躍中(?) メディア掲載 スライド 本人編
- 4. http://careerhack.en-japan.com/report/detail/453 http://www.slideshare.net/kiyotoyamaura/1-45361529 ｢人は一ヶ月でエンジニアになれるのか｣とは？ ▸ リブセンス新卒2年目のディレクターが ▸ 1ヶ月業務から離れてウェブエンジニアへの転身を図ったプロジェクト ▸ その後なんとか現場でウェブエンジニアとして活躍中(?) メディア掲載 スライド 本人編 本スライドでは、その裏側について、トレーナー視点で詳細に解説します。 ウェブ系に限った話ですのでその点はご留意ください。 読み終わった後は • どういう方針で1ヶ月を進めたのか • 具体的に何をどういう順番で行ったのか • どういう教材や書籍を用いたのか • その結果何が起こったか がわかるものを目指しています。
- 6. 前置き
- 7. そもそも覚えることが多い
- 10. 1. 基本だけ一通りさらう ▸ 簡単なウェブアプリケーションを作成する ▸ もしくはドットインストールや書籍を自習させて終わり 2. ｢実践が一番勉強になるでしょ！｣という声と共に配属 ▸ もちろんOJTでしか身につかないものも多い ▸ 一方単純に教育コストをケチっているだけのケースが多いのも確か 3. あとはコードレビュー中心で育成 ▸ 結果として現場の負担増 ▸ 大きな成長は｢成長のきっかけになる仕事｣次第で運否天賦 ▸ コードは一通り書けるようになっても､クラス設計やデータベース設計､トラブル シューティングなどがいつまでも弱い｢頭打ちエンジニア｣になりやすい その結果ありがちな新人育成
- 11. 1. 基本だけ一通りさらう ▸ 簡単なウェブアプリケーションを作成する ▸ もしくはドットインストールや書籍を自習させて終わり 「ありがちな新人育成」の問題点 よく出来た自習教材ほど、それをなぞるのは簡単。 しかし一方で • 学習が体系化されず、未知の課題に応用できない • そのコードが暗黙に前提としている知識について学べない • 異常系やパフォーマンスなどが欠落しがち • コードリーディングの能力が鍛えられない などの問題が残る。 他方現場の仕事はその多くが既存コードの変更であり、 配属後に学んだものとのギャップを感じることが多い。 問題点
- 12. 2. ｢実践が一番勉強になるでしょ！｣という声と共に配属 ▸ もちろんOJTでしか身につかないものも多い ▸ 一方単純に教育コストをケチっているだけのケースが多いのも確か 得てして現場のコードは「教科書的」ではなく、様々な理由で特殊。 • 長年の拡張に伴い、肥大化したメイン処理 • 過去の言語仕様に由来する、冗長な処理 • 過去に使われた機能に由来する密結合 • 社内の他プロダクトも理解しないと触れられない社内共通ライブラリ 結果、配属後は殆ど戦力にならず、再度現場で研修的なことが行われたり、 チームによっては周囲にも聞けず一人デスマーチ状態に陥りがち。 問題点 「ありがちな新人育成」の問題点
- 13. 3. あとはコードレビュー中心で育成 ▸ 結果として現場の負担増 ▸ 大きな成長は｢成長のきっかけになる仕事｣次第で運否天賦 コードレビューは有用だが、学習という観点から見ると難点も多い。 • 成長を促すコードレビューは難しい • 最適なコードではなく、状況に合わせたコードが求められることが多い • 場当たり的な指摘に留まり、概論的な学びが得にくい コードは一通り書けるようになっても､クラス設計やデータベース設計､ トラブルシューティングなどがいつまでも弱い｢頭打ちエンジニア｣になりやすい。 問題点 「ありがちな新人育成」の問題点
- 14. 1. 基本だけ一通りさらう 2. ｢実践が一番勉強になるでしょ！｣という声と共に配属 3. あとはコードレビュー中心で育成 これだけだと、本人も現場も不幸。 とはいっても、Off-JTで深堀りし続けるのは時間がいくらあっても足りないし、 現場で覚えた方が効率が良いのも確か。 「ありがちな新人育成」の問題点
- 18. "高度な専門知識と技能を身につけるうえで 「場所」がいっそう重要になる可能性が高い。 中世の職人と同じように、私たちも学ぶべき点の ある人たちのそばに身を置く必要性が高まるだろう。 - Lynda Gratton (2012) WORK SHIFT pp. 268
- 19. 今回の方針
- 20. 研修後も自走
- 22. 普段と今回の方針の違い Level 1 Level 2 Level 3 Level 4 Level 5 普段の育成(6ヶ月) 基礎から順番に 積み上げていく ある程度学習の期間がとれる場合は、基礎から順番に積み 上げていく。一気に色んなものを学ぶ方法に比べ • 混乱が起きずにひとつひとつの概念を丁寧に学べる • その人のペースに合わせて着実に積み上がる • 基礎をしっかり理解することで応用が効きやすい といったメリットがある。弊社でも通常の新人はこういっ た育成を行う。 期間による学習法の違い 今回1ヶ月という期間を設けたのはあくまで業務内での緊急 的な転身だからであって、理想はもっと時間を掛けたしっ かりとした基礎の積み上げ。 適切な学習法は期間・人によって様々
- 23. 普段と今回の方針の違い Level 1 Level 2 Level 3 Level 4 Level 5 普段通りに進めると... Level3までしか行けず この後何をやればいいか不明瞭 Level 1 Level 3 Level 4 Level 5 今回の方針 部分的にはLevel5まで到達させることで 不足点がわかりやすくなる 今回の設定された期間は1ヶ月なので普段のやり方では途中までしかたどり着けない。 そこで、基礎部分以降は全体像(ビジョン)を示しつつ、ビジョンと自己との乖離を認識できるカリキュラム構成 とし、不足部分は研修以降の自学に期待する。書籍「学習する組織」でいう所の「創造的緊張」を利用する。 Level 2 普段のやり方では中途半端にしかならない
- 24. "ビジョンと今の現実の乖離はエネルギー源である。 乖離がなければ、ビジョンに向かって 進むための行動を起こす必要もないのだ。 乖離こそが真の創造的エネルギーの源である。 - Peter M. Senge (2011) 学習する組織 pp. 207
- 25. 普段と今回の方針の違い - まとめ 普段(6ヶ月) 今回(1ヶ月) データ構造・アルゴリズム・メモリ管理・ビット操作など。 ウェブ系の開発ではなかなか普段触れないところこそ、研 修でしっかり触れて基礎を身につける。 普段使っているハッシュテーブルなどについても、それがな ぜ早いのか、どういうデータ構造になっているか、などを しっかり理解。 基礎をこそ学ぶ 一気に色々なものを学ぶのではなく、まずはCLIで徹底的に プログラミングだけを学習。その後徐々にHTTPやHTML, CSSなどを学んでいく。データベースもまずは単体でテーブ ル設計、インデックス、クエリを学び、プログラムから接 続するのはそれぞれ学んでから。 段階的に学習 MySQLであればB-Treeの構造をしっかり理解。クエリにイ ンデックスがどう効いてくるかはそこから演繹的に導き出 すことを期待する。またハッシュインデックスなどについ ては飛ばす。後で自分で調べてもらう。 デザインパターンも一つだけ。｢他が未習得｣であることを自 覚させておくことで「何を学んでいないか」を知る。 少し上のレベルをそれぞれ一つだけ学ぶ 段階的にやっている時間が無いので、とりあえずアプリケー ションを作りながら、わからない所を学ぶ。いわゆる遅延 学習法※1。しかしそれだと表面的な知識になりがちなの で、↓で補強。 すべてを同時に ※1 遅延学習法・・・遅延評価勉強法とも。教科書的に順序を追って勉強するのでなく、その知識が必要になってから勉強 する方法。
- 27. 実際の流れ
- 28. 書きながら 学び続ける
- 29. 全体の流れ 事前準備 環境整備 & 予習 1週目 習作Ⅰ ‒ すごろく 2週目 習作Ⅱ ‒ Twitter的なもの 3週目 本番開発Ⅰ - バグ対応 4週目 本番開発Ⅱ - 機能追加
- 32. 日常の進め方 1日の基本サイクル レビュー時に • やってきたことのレビュー • 次回レビューまでのお題出し を行う。 自習 + レビュー(1時間) 読書はページをめくっていれば簡単に終わってしまうので、 出来ればまとめを作ってもらい頭にしっかり入れる。 課題図書は「まとめ」を作る レビューで何を伝えるか コードレビューから始まるが､それはあくまできっかけ。次 に学ぶべき概念をコードに絡めて話していく。 例えば継承が出てきたら • 継承はどういう関係であるべきか • 継承ではなく委譲を使うのはどんなときか • 継承のときに気をつけるべきこと など。リスコフ置換則など絡めてコードを書きながら話す。 翌日だいたい下手な継承してくるので、Template Method パターンにつないだり。nullエラーが出たらNull objectパ ターンにつないだり。 コードレビューはあくまできっかけ 次に学ぶべきものを考えて、少々無茶なお題出しを行う。 教育目的なので、突拍子もない仕様変更でもOK。 コース取りを考えたお題出しが勝負？ 今回は若手の何人かが自主的にカバーに入ってくれて、自習 中の質問相手になってくれていた様子。 自習中も簡単なミスを指摘してくれるような人が周りにい ると心強い。感謝。 自習中も出来れば質問できる環境を MVCなど取っ掛かりが厄介なものは､がっつり1時間ほど講 義して基本的な概念を学んでもらう。 とはいえ講義は全体で4回くらい。 必要であれば講義を追加
- 33. 1週目 - 習作（すごろく） <?php $game = Game::getInstance(); $game->setBoard(new Board('data/board.csv')); $game->addPlayer(new Player('Taro')); $game->addPlayer(new Player('Jiro')); $game->setDice(new Dice()); $game->start(); sugoroku.php 以下のソースコードが動作するよう、すごろくゲームを開発せよ。 問題
- 34. 1週目 - 習作（すごろく） 1. 出てきたコードに対して、レビューを入れていく 2. きちんとしたコードになるように修正を何度か繰り 返す 3. コードがまとまってきたら大幅な仕様変更を行う 4. 1に戻る ポイント だいたい色んなマス目に対応出来るように作られていない ので､その辺からインターフェース・ポリモルフィズムなど を学んでいく。 「Nマス進む」「一回休み」「スタートに戻る」など。 意地悪な所では「他ユーザーと位置を入れ替え」など、1 ユーザーで完結しない処理はだいたい対応できない。 マス目のイベントが肝 ここではOOPを中心にプログラミングだけを学ばせたいの で、データベースやウェブは一切登場させない。 全てCLIで ログをテキストで出したりHTMLで出してもらったりして、 いわゆるLoggerクラス的なものを学んでもらう。 (だいたい最初は標準出力するので..) またログを出力しないNullLoggerクラスを作ってもらって、 Null objectも体験してもらう。 ログ処理も 殺意持たれるくらいに出す。「サイコロを12面に」「こう いうマス目を増やして」「プレイヤーに性別つけて」など。 いかに当初のコードが拡張性に乏しいかを指摘していく。 ガンガン仕様変更要求を出す すすめ方
- 36. ポイントすすめ方 バリデーション、認証、データベース、リダイレクトなど、 フレームワークの基本的な流れをつかむ。高度なスケーラ ビリティは今回は扱わない。 フレームワークの基本的な流れをつかむ フレームワークは多くの機能を提供するが、CLIアプリと異 なり処理の流れを追いにくく、全容把握が困難。 学習者の理解度にあわせて、講義形式でのインプットを実 施する。今回はMVCパターンなどを2時間程度実施。 必要に応じて講義を加える 1. 出てきたコードに対して、レビューを入れていく 2. 理解度に応じて講義を実施する 3. きちんとしたコードになるように修正を何度か繰り 返す あくまでウェブやフレームワークの連携を学ぶのが目的。 プログラミング的お題をこなしてもらうなら、既に環境が 切り分けされているCLIお題の方で行う。 こっちではあまりエグい仕様変更要求は行わない 2週目 - 習作（Twitter的な何か）
- 37. 3, 4週目 ‒ 本番開発 進め方 現場のPMに依頼して簡単そうなチケットをいくつか出して もらう。その中で取り組めそうなものをトレーナーがピッ クアップ。 フロー体験を引き起こすように「やるべきことが明確で設 計とコーディングに集中できるか」「本人にとって程よく 難易度が高くチャレンジングか」などを基準に。 適切な難易度のチケットをもらう 実際行ったもの 結果的には簡単な変更に終わるものであっても、既存の大 規模なコードベースの上での修正なので考慮すべきことも多 く、考慮漏れなどが出やすい。 既存の仕様をきちんと調べているか、影響範囲などが見え ているか、適切にエラー対応出来ているかなどを確認。 上手く実装できてるつもりでも、例外対応できてない、例 外が考慮しきれてない、などはあるある。 簡単なバグ修正 5点 「広告掲載を社内管理画面から予約投稿できるようにする」 機能を実装。詳しくは次スライド。 新たな機能実装 開発は通常と同様に開発環境で開発、テストの流れ。プル リクエストのレビューはまずトレーナーだけで行う。この 時は習作と同様に教育的観点を強く持ち込んで指摘。 トレーナーのレビューが通過した後に、プロダクトの正規 のレビュワーにもレビューしてもらう。プロジェクト毎に コーディング流儀が違う場合もあるので、(出来るだけトレー ナー側で吸収出来るのがベストではあるが)、追加の指摘は 入りやすい。 マージ・リリースはプロダクトのエンジニアに依頼。 開発とプルリクエスト
- 38. " 目標が明確で、フィードバックが適切で、 チャレンジとスキルのバランスがとれている時、 注意力は統制されていて、十分に使われている。 心理的エネルギーに対する全体的な要求によって、 フローにある人は完全に集中している。 - M.Csikszentmihalyi (2010) フロー体験入門 pp. 43
- 40. 学習資料
- 41. 最低限に絞り まとめ化
- 50. まとめ実物 ‒ リーダブルコード
- 51. まとめ実物 ‒ MySQL
- 54. 終わって気づいたこと