Contenu connexe
Similaire à 人は一ヶ月でエンジニアになれるのか - 詳細解説 (15)
人は一ヶ月でエンジニアになれるのか - 詳細解説
- 10. 1. 基本だけ一通りさらう
▸ 簡単なウェブアプリケーションを作成する
▸ もしくはドットインストールや書籍を自習させて終わり
2. 「実践が一番勉強になるでしょ!」という声と共に配属
▸ もちろんOJTでしか身につかないものも多い
▸ 一方単純に教育コストをケチっているだけのケースが多いのも確か
3. あとはコードレビュー中心で育成
▸ 結果として現場の負担増
▸ 大きな成長は「成長のきっかけになる仕事」次第で運否天賦
▸ コードは一通り書けるようになっても、クラス設計やデータベース設計、トラブル
シューティングなどがいつまでも弱い「頭打ちエンジニア」になりやすい
その結果ありがちな新人育成
- 11. 1. 基本だけ一通りさらう
▸ 簡単なウェブアプリケーションを作成する
▸ もしくはドットインストールや書籍を自習させて終わり
「ありがちな新人育成」の問題点
よく出来た自習教材ほど、それをなぞるのは簡単。
しかし一方で
• 学習が体系化されず、未知の課題に応用できない
• そのコードが暗黙に前提としている知識について学べない
• 異常系やパフォーマンスなどが欠落しがち
• コードリーディングの能力が鍛えられない
などの問題が残る。
他方現場の仕事はその多くが既存コードの変更であり、
配属後に学んだものとのギャップを感じることが多い。
問題点
- 12. 2. 「実践が一番勉強になるでしょ!」という声と共に配属
▸ もちろんOJTでしか身につかないものも多い
▸ 一方単純に教育コストをケチっているだけのケースが多いのも確か
得てして現場のコードは「教科書的」ではなく、様々な理由で特殊。
• 長年の拡張に伴い、肥大化したメイン処理
• 過去の言語仕様に由来する、冗長な処理
• 過去に使われた機能に由来する密結合
• 社内の他プロダクトも理解しないと触れられない社内共通ライブラリ
結果、配属後は殆ど戦力にならず、再度現場で研修的なことが行われたり、
チームによっては周囲にも聞けず一人デスマーチ状態に陥りがち。
問題点
「ありがちな新人育成」の問題点
- 13. 3. あとはコードレビュー中心で育成
▸ 結果として現場の負担増
▸ 大きな成長は「成長のきっかけになる仕事」次第で運否天賦
コードレビューは有用だが、学習という観点から見ると難点も多い。
• 成長を促すコードレビューは難しい
• 最適なコードではなく、状況に合わせたコードが求められることが多い
• 場当たり的な指摘に留まり、概論的な学びが得にくい
コードは一通り書けるようになっても、クラス設計やデータベース設計、
トラブルシューティングなどがいつまでも弱い「頭打ちエンジニア」になりやすい。
問題点
「ありがちな新人育成」の問題点
- 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
普段のやり方では中途半端にしかならない
- 25. 普段と今回の方針の違い - まとめ
普段(6ヶ月) 今回(1ヶ月)
データ構造・アルゴリズム・メモリ管理・ビット操作など。
ウェブ系の開発ではなかなか普段触れないところこそ、研
修でしっかり触れて基礎を身につける。
普段使っているハッシュテーブルなどについても、それがな
ぜ早いのか、どういうデータ構造になっているか、などを
しっかり理解。
基礎をこそ学ぶ
一気に色々なものを学ぶのではなく、まずはCLIで徹底的に
プログラミングだけを学習。その後徐々にHTTPやHTML,
CSSなどを学んでいく。データベースもまずは単体でテーブ
ル設計、インデックス、クエリを学び、プログラムから接
続するのはそれぞれ学んでから。
段階的に学習
MySQLであればB-Treeの構造をしっかり理解。クエリにイ
ンデックスがどう効いてくるかはそこから演繹的に導き出
すことを期待する。またハッシュインデックスなどについ
ては飛ばす。後で自分で調べてもらう。
デザインパターンも一つだけ。「他が未習得」であることを自
覚させておくことで「何を学んでいないか」を知る。
少し上のレベルをそれぞれ一つだけ学ぶ
段階的にやっている時間が無いので、とりあえずアプリケー
ションを作りながら、わからない所を学ぶ。いわゆる遅延
学習法※1。しかしそれだと表面的な知識になりがちなの
で、↓で補強。
すべてを同時に
※1 遅延学習法・・・遅延評価勉強法とも。教科書的に順序を追って勉強するのでなく、その知識が必要になってから勉強
する方法。
- 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面に」「こう
いうマス目を増やして」「プレイヤーに性別つけて」など。
いかに当初のコードが拡張性に乏しいかを指摘していく。
ガンガン仕様変更要求を出す
すすめ方
- 37. 3, 4週目 ‒ 本番開発
進め方
現場のPMに依頼して簡単そうなチケットをいくつか出して
もらう。その中で取り組めそうなものをトレーナーがピッ
クアップ。
フロー体験を引き起こすように「やるべきことが明確で設
計とコーディングに集中できるか」「本人にとって程よく
難易度が高くチャレンジングか」などを基準に。
適切な難易度のチケットをもらう
実際行ったもの
結果的には簡単な変更に終わるものであっても、既存の大
規模なコードベースの上での修正なので考慮すべきことも多
く、考慮漏れなどが出やすい。
既存の仕様をきちんと調べているか、影響範囲などが見え
ているか、適切にエラー対応出来ているかなどを確認。
上手く実装できてるつもりでも、例外対応できてない、例
外が考慮しきれてない、などはあるある。
簡単なバグ修正 5点
「広告掲載を社内管理画面から予約投稿できるようにする」
機能を実装。詳しくは次スライド。
新たな機能実装
開発は通常と同様に開発環境で開発、テストの流れ。プル
リクエストのレビューはまずトレーナーだけで行う。この
時は習作と同様に教育的観点を強く持ち込んで指摘。
トレーナーのレビューが通過した後に、プロダクトの正規
のレビュワーにもレビューしてもらう。プロジェクト毎に
コーディング流儀が違う場合もあるので、(出来るだけトレー
ナー側で吸収出来るのがベストではあるが)、追加の指摘は
入りやすい。
マージ・リリースはプロダクトのエンジニアに依頼。
開発とプルリクエスト