Upcoming SlideShare
人は一ヶ月でエンジニアになれるのか - 詳細解説
- 1. 本スライドでは 新卒2年目のウェブ ディレクターが 1ヶ月でエンジニア に転身したときの 教材・方針・進行に ついて解説します。
- 2. http://careerhack.en-japan.com/report/detail/453 http://www.slideshare.net/kiyotoyamaura/1-45361529 ｢人は一ヶ月でエンジニアになれるのか｣とは？ ▸ リブセンス新卒2年目のディレクターが ▸ 1ヶ月業務から離れてウェブエンジニアへの転身を図ったプロジェクト ▸ その後なんとか現場でウェブエンジニアとして活躍中(?) メディア掲載 スライド 本人編
- 3. http://careerhack.en-japan.com/report/detail/453 http://www.slideshare.net/kiyotoyamaura/1-45361529 ｢人は一ヶ月でエンジニアになれるのか｣とは？ ▸ リブセンス新卒2年目のディレクターが ▸ 1ヶ月業務から離れてウェブエンジニアへの転身を図ったプロジェクト ▸ その後なんとか現場でウェブエンジニアとして活躍中(?) メディア掲載 スライド 本人編 本スライドでは、その裏側について、トレーナー視点で詳細に解説します。 ウェブ系に限った話ですのでその点はご留意ください。 読み終わった後は • どういう方針で1ヶ月を進めたのか • 具体的に何をどういう順番で行ったのか • どういう教材や書籍を用いたのか • その結果何が起こったか がわかるものを目指しています。
- 4. 自己紹介 桂 大介 エンジニア兼取締役。 最近社内ではスパルタ教育で名が売れてせつない。 トレーナー 山浦 清透 2013年に新卒としてリブセンスに入社。 Webマーケティングを担当していたが、 今回たっての希望によりウェブエンジニアへ転身。 座右の銘は「一寸先は光」。 トレーニー
- 5. 前置き
- 6. そもそも覚えることが多い
- 7. ウェブエンジニアつらい 覚えるべき領域が多すぎるし､それぞれが深くてゴールがない。 ウェブの代表的な技術だけでも.. などなど。 他にもデータ構造・アルゴリズム・OOAD・セキュリティ・正規表現・・・ 覚えるべきことが無数にある。
- 8. 竹内先生に同情されるくらい大変 http://careerhack.en-japan.com/report/detail/346
- 9. 1. 基本だけ一通りさらう ▸ 簡単なウェブアプリケーションを作成する ▸ もしくはドットインストールや書籍を自習させて終わり 2. ｢実践が一番勉強になるでしょ！｣という声と共に配属 ▸ もちろんOJTでしか身につかないものも多い ▸ 一方単純に教育コストをケチっているだけのケースが多いのも確か 3. あとはコードレビュー中心で育成 ▸ 結果として現場の負担増 ▸ 大きな成長は｢成長のきっかけになる仕事｣次第で運否天賦 ▸ コードは一通り書けるようになっても､クラス設計やデータベース設計､トラブル シューティングなどがいつまでも弱い｢頭打ちエンジニア｣になりやすい その結果ありがちな新人育成
- 10. 1. 基本だけ一通りさらう ▸ 簡単なウェブアプリケーションを作成する ▸ もしくはドットインストールや書籍を自習させて終わり 「ありがちな新人育成」の問題点 よく出来た自習教材ほど、それをなぞるのは簡単。 しかし一方で • 学習が体系化されず、未知の課題に応用できない • そのコードが暗黙に前提としている知識について学べない • 異常系やパフォーマンスなどが欠落しがち • コードリーディングの能力が鍛えられない などの問題が残る。 他方現場の仕事はその多くが既存コードの変更であり、 配属後に学んだものとのギャップを感じることが多い。 問題点
- 11. 2. ｢実践が一番勉強になるでしょ！｣という声と共に配属 ▸ もちろんOJTでしか身につかないものも多い ▸ 一方単純に教育コストをケチっているだけのケースが多いのも確か 得てして現場のコードは「教科書的」ではなく、様々な理由で特殊。 • 長年の拡張に伴い、肥大化したメイン処理 • 過去の言語仕様に由来する、冗長な処理 • 過去に使われた機能に由来する密結合 • 社内の他プロダクトも理解しないと触れられない社内共通ライブラリ 結果、配属後は殆ど戦力にならず、再度現場で研修的なことが行われたり、 チームによっては周囲にも聞けず一人デスマーチ状態に陥りがち。 問題点 「ありがちな新人育成」の問題点
- 12. 3. あとはコードレビュー中心で育成 ▸ 結果として現場の負担増 ▸ 大きな成長は｢成長のきっかけになる仕事｣次第で運否天賦 コードレビューは有用だが、学習という観点から見ると難点も多い。 • 成長を促すコードレビューは難しい • 最適なコードではなく、状況に合わせたコードが求められることが多い • 場当たり的な指摘に留まり、概論的な学びが得にくい コードは一通り書けるようになっても､クラス設計やデータベース設計､ トラブルシューティングなどがいつまでも弱い｢頭打ちエンジニア｣になりやすい。 問題点 「ありがちな新人育成」の問題点
- 13. 1. 基本だけ一通りさらう 2. ｢実践が一番勉強になるでしょ！｣という声と共に配属 3. あとはコードレビュー中心で育成 これだけだと、本人も現場も不幸。 とはいっても、Off-JTで深堀りし続けるのは時間がいくらあっても足りないし、 現場で覚えた方が効率が良いのも確か。 「ありがちな新人育成」の問題点
- 14. どこで道を間違えたのか 現場配属がゴールになっているため、最低限の技能を付けさせるための、広く浅い 詰め込み型・完結型の研修になってしまっている。結果、出来るだけ早い段階での 現場配属が目指され、ますます研修の意味希薄化＆現場の負担増へと傾いていく。 研修 現場 研修 現場 研修と現場が分断されるのではなく、 現場の仕事を下支えし続けるような研修。 目指すべきは
- 15. 独学でも学べるのか 独学のデメリット 教材自体はたくさん出ているが玉石混交。Amazonレビューなどによりある程度の選定は出来るものの、 どれが今の自分に最適かまではわからない。また万が一書籍選びに失敗したときも「書籍代がもったい ない」とサンクコストに囚われて効率悪く続けてしまいがち。 良い教材を見つけるのは大変 プログラミングは「環境構築で1ヶ月詰まった」「スペルミスで30分悩んだ」「コードが動かなくなっ てどう直せばいいかわからない」など、躓いて前に進まない状況が発生しやすい。 一定レベルまで達成できれば後は自習で伸ばしていけるものの、プログラミングを諦めて戦線離脱しま うのはだいたい躓いた時。 躓いている間の学習効率が低い 独学で学んだ人は多いし、当然「学べる」。 しかし、効率を比較すれば、早期にメンターを見つけたい。 メンターがいれば、こうした「もったいない」停滞や離脱を抑制することができる。
- 16. 周囲にエンジニアがいれば手助けを請うのもひとつ。ただし無償でお願いし続けるのが心苦しいとき や、周囲にそういったエンジニアがいない場合は有料サービスの検討も。コースで完結するものでな く、アドバイザー・メンターがいるのがベター。 TECH::CAMP https://tech-camp.in/ TechAcademy https://techacademy.jp/ 例えば環境構築で詰まってアドバイスを受けたいとき、その原因が設定の問題なのか、バージョンの問 題なのか、タイプミスの問題なのかを、具体的な実物を共有せず説明することは困難。タイプミスがな くとも、スペースを誤ると異なる振る舞いをする言語もあるので「タイプミスがない」と言われてもメ ンターは鵜呑みにできない。 よってリアルな「場所」を共有できるメンターが見つけられればベター。書籍「ワークシフト」でも 「高度な専門知識と技能を身につけるうえで場所がいっそう重要になる可能性が高い」と言われてい る。 有料サービスも視野に 出来ればオフラインで会えるものを メンター探しのポイント 周囲に適当なエンジニアがいない場合は、有料サービスも含めた検討を。 独学でも学べるのか - メンター探し
- 17. "高度な専門知識と技能を身につけるうえで 「場所」がいっそう重要になる可能性が高い。 中世の職人と同じように、私たちも学ぶべき点の ある人たちのそばに身を置く必要性が高まるだろう。 - Lynda Gratton (2012) WORK SHIFT pp. 268
- 18. 今回の方針
- 19. 研修後も自走
- 20. そもそも今回のケースでは 研修の役割 本人の希望による転向・学習なので、学ぶ意義の説明や、 モチベーション管理などは基本的に不要。 研修は本人が全速力で走り続けるために何ができるかのみ を考える。 学ぶ気概は十分にある 研修後の自走も狙う 1ヶ月なのでそもそも研修中にすべてを教えるのは不可能。 「何を学んだのか」と同じくらい「何を学んでいないか」 を知ることが大切。その「不足感」「欠如感」が次の学び につながる。 研修が終わったときに「次何を学べばいいかわからない」 ではなく「次はこれとこれを埋めていこう」という状態に なると良い。 現場の仕事を下支えし続ける研修 (無作為的にせよ)目線を下げてしまったり、「次何やったら いいですか？」に代表されるような指示待ち(トレーナーボ トルネック)状態を起こしてしまわないように、常に走り続 けるためのレールを整備する。 二歩先、三歩先で高速道路を引き続けて、本人がアクセル をべた踏み出来るような状態を作り続けるのが理想。 トレーナーは、本人が研修についていけない事よりも、研 修が本人についていけない事を恐れるべき。 研修はキャップにもカタパルトにもなり得る
- 21. 普段と今回の方針の違い Level 1 Level 2 Level 3 Level 4 Level 5 普段の育成(6ヶ月) 基礎から順番に 積み上げていく ある程度学習の期間がとれる場合は、基礎から順番に積み 上げていく。一気に色んなものを学ぶ方法に比べ • 混乱が起きずにひとつひとつの概念を丁寧に学べる • その人のペースに合わせて着実に積み上がる • 基礎をしっかり理解することで応用が効きやすい といったメリットがある。弊社でも通常の新人はこういっ た育成を行う。 期間による学習法の違い 今回1ヶ月という期間を設けたのはあくまで業務内での緊急 的な転身だからであって、理想はもっと時間を掛けたしっ かりとした基礎の積み上げ。 適切な学習法は期間・人によって様々
- 22. 普段と今回の方針の違い Level 1 Level 2 Level 3 Level 4 Level 5 普段通りに進めると... Level3までしか行けず この後何をやればいいか不明瞭 Level 1 Level 3 Level 4 Level 5 今回の方針 部分的にはLevel5まで到達させることで 不足点がわかりやすくなる 今回の設定された期間は1ヶ月なので普段のやり方では途中までしかたどり着けない。 そこで、基礎部分以降は全体像(ビジョン)を示しつつ、ビジョンと自己との乖離を認識できるカリキュラム構成 とし、不足部分は研修以降の自学に期待する。書籍「学習する組織」でいう所の「創造的緊張」を利用する。 Level 2 普段のやり方では中途半端にしかならない
- 23. "ビジョンと今の現実の乖離はエネルギー源である。 乖離がなければ、ビジョンに向かって 進むための行動を起こす必要もないのだ。 乖離こそが真の創造的エネルギーの源である。 - Peter M. Senge (2011) 学習する組織 pp. 207
- 24. 普段と今回の方針の違い - まとめ 普段(6ヶ月) 今回(1ヶ月) データ構造・アルゴリズム・メモリ管理・ビット操作など。 ウェブ系の開発ではなかなか普段触れないところこそ、研 修でしっかり触れて基礎を身につける。 普段使っているハッシュテーブルなどについても、それがな ぜ早いのか、どういうデータ構造になっているか、などを しっかり理解。 基礎をこそ学ぶ 一気に色々なものを学ぶのではなく、まずはCLIで徹底的に プログラミングだけを学習。その後徐々にHTTPやHTML, CSSなどを学んでいく。データベースもまずは単体でテーブ ル設計、インデックス、クエリを学び、プログラムから接 続するのはそれぞれ学んでから。 段階的に学習 MySQLであればB-Treeの構造をしっかり理解。クエリにイ ンデックスがどう効いてくるかはそこから演繹的に導き出 すことを期待する。またハッシュインデックスなどについ ては飛ばす。後で自分で調べてもらう。 デザインパターンも一つだけ。｢他が未習得｣であることを自 覚させておくことで「何を学んでいないか」を知る。 少し上のレベルをそれぞれ一つだけ学ぶ 段階的にやっている時間が無いので、とりあえずアプリケー ションを作りながら、わからない所を学ぶ。いわゆる遅延 学習法※1。しかしそれだと表面的な知識になりがちなの で、↓で補強。 すべてを同時に ※1 遅延学習法・・・遅延評価勉強法とも。教科書的に順序を追って勉強するのでなく、その知識が必要になってから勉強 する方法。
- 25. 「何を学んでいないか」を知る とは デザインパターン と呼ばれている何か デザインパターンというものを知らない(もしくは概念は知っていて も具体例を一つも知らない)状態で、デザインパターンについて学ぶの は難しい。 1つでも知っていれば、そこから他のパターンは学びやすくなる。 何より「まだ学んでいないこと」として強く認識されることで、 次の学習につながりやすい。 まだ学んでいない 他のパターン Singlet on
- 26. 実際の流れ
- 27. 書きながら 学び続ける
- 28. 全体の流れ 事前準備 環境整備 & 予習 1週目 習作Ⅰ ‒ すごろく 2週目 習作Ⅱ ‒ Twitter的なもの 3週目 本番開発Ⅰ - バグ対応 4週目 本番開発Ⅱ - 機能追加
- 29. 事前準備 環境構築 Macを手配。基本的なアプリケーションのインストールや､ いわゆる環境設定は全てこちらで代行。エディタはPhpStorm を利用しようと思ったが､本人の強い希望によりvimにて。 環境設定はもちろん出来るに越したことはないが、プログ ラミングを学んでからの方が学習が楽。 全てこちらで行う 入り口(文法など) ドットインストールを何周かしてもらって､簡単な文法や関 数についてはカバーしてもらう。一周して終わりではなく、 きちんと手に馴染むまでやってもらう。 「わかる」と「書ける」は別。 ※会社で使う場合は法人契約が必要です(それでも安い!!) ドットインストールを活用 自習できるものは自習 基本的に自習の方が早いし、本人のスピードで進められる ので良い。不明点はメモっておいて、後から質問してもらう。 良い教材が増えればこれでどんどん進められるんですが...今 回はドットインストールとGitくらいでした。 AtlassianのGitチュートリアル https://www.atlassian.com/ja/git/tutorial Gitはチュートリアルで ※ちなみに山浦さんは(一応)リブセンスで1年半くらいWebマーケティングを担当していたので､ 基本的なWebリテラシーは既に付いています。
- 30. Gitを先に学ぶメリット Gitはソースコードのバージョンを管理し「壊す前に戻れ る」「いくらでも壊せる」機能を提供する。 開発現場でも必須のツールだが、躓きがちな初学者にこ そ必須のツールと言える。 いくらでも壊せる環境を、最初から 抽象的な概念・操作に慣れる Gitはソースコードのバージョンをノードのように管理し ている。こうした抽象的な操作もその後の学習の下地の 一つとなる。 https://www.atlassian.com/ja/git/tutorial
- 31. 日常の進め方 1日の基本サイクル レビュー時に • やってきたことのレビュー • 次回レビューまでのお題出し を行う。 自習 + レビュー(1時間) 読書はページをめくっていれば簡単に終わってしまうので、 出来ればまとめを作ってもらい頭にしっかり入れる。 課題図書は「まとめ」を作る レビューで何を伝えるか コードレビューから始まるが､それはあくまできっかけ。次 に学ぶべき概念をコードに絡めて話していく。 例えば継承が出てきたら • 継承はどういう関係であるべきか • 継承ではなく委譲を使うのはどんなときか • 継承のときに気をつけるべきこと など。リスコフ置換則など絡めてコードを書きながら話す。 翌日だいたい下手な継承してくるので、Template Method パターンにつないだり。nullエラーが出たらNull objectパ ターンにつないだり。 コードレビューはあくまできっかけ 次に学ぶべきものを考えて、少々無茶なお題出しを行う。 教育目的なので、突拍子もない仕様変更でもOK。 コース取りを考えたお題出しが勝負？ 今回は若手の何人かが自主的にカバーに入ってくれて、自習 中の質問相手になってくれていた様子。 自習中も簡単なミスを指摘してくれるような人が周りにい ると心強い。感謝。 自習中も出来れば質問できる環境を MVCなど取っ掛かりが厄介なものは､がっつり1時間ほど講 義して基本的な概念を学んでもらう。 とはいえ講義は全体で4回くらい。 必要であれば講義を追加
- 32. 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 以下のソースコードが動作するよう、すごろくゲームを開発せよ。 問題
- 33. 1週目 - 習作（すごろく） 1. 出てきたコードに対して、レビューを入れていく 2. きちんとしたコードになるように修正を何度か繰り 返す 3. コードがまとまってきたら大幅な仕様変更を行う 4. 1に戻る ポイント だいたい色んなマス目に対応出来るように作られていない ので､その辺からインターフェース・ポリモルフィズムなど を学んでいく。 「Nマス進む」「一回休み」「スタートに戻る」など。 意地悪な所では「他ユーザーと位置を入れ替え」など、1 ユーザーで完結しない処理はだいたい対応できない。 マス目のイベントが肝 ここではOOPを中心にプログラミングだけを学ばせたいの で、データベースやウェブは一切登場させない。 全てCLIで ログをテキストで出したりHTMLで出してもらったりして、 いわゆるLoggerクラス的なものを学んでもらう。 (だいたい最初は標準出力するので..) またログを出力しないNullLoggerクラスを作ってもらって、 Null objectも体験してもらう。 ログ処理も 殺意持たれるくらいに出す。「サイコロを12面に」「こう いうマス目を増やして」「プレイヤーに性別つけて」など。 いかに当初のコードが拡張性に乏しいかを指摘していく。 ガンガン仕様変更要求を出す すすめ方
- 34. 2週目 - 習作（Twitter的な何か） 問題 以下の機能を実装し、Twitterクローンを実装せよ。 ・会員登録 ・ツイート ・フォロー/アンフォロー ・タイムライン
- 35. ポイントすすめ方 バリデーション、認証、データベース、リダイレクトなど、 フレームワークの基本的な流れをつかむ。高度なスケーラ ビリティは今回は扱わない。 フレームワークの基本的な流れをつかむ フレームワークは多くの機能を提供するが、CLIアプリと異 なり処理の流れを追いにくく、全容把握が困難。 学習者の理解度にあわせて、講義形式でのインプットを実 施する。今回はMVCパターンなどを2時間程度実施。 必要に応じて講義を加える 1. 出てきたコードに対して、レビューを入れていく 2. 理解度に応じて講義を実施する 3. きちんとしたコードになるように修正を何度か繰り 返す あくまでウェブやフレームワークの連携を学ぶのが目的。 プログラミング的お題をこなしてもらうなら、既に環境が 切り分けされているCLIお題の方で行う。 こっちではあまりエグい仕様変更要求は行わない 2週目 - 習作（Twitter的な何か）
- 36. 3, 4週目 ‒ 本番開発 進め方 現場のPMに依頼して簡単そうなチケットをいくつか出して もらう。その中で取り組めそうなものをトレーナーがピッ クアップ。 フロー体験を引き起こすように「やるべきことが明確で設 計とコーディングに集中できるか」「本人にとって程よく 難易度が高くチャレンジングか」などを基準に。 適切な難易度のチケットをもらう 実際行ったもの 結果的には簡単な変更に終わるものであっても、既存の大 規模なコードベースの上での修正なので考慮すべきことも多 く、考慮漏れなどが出やすい。 既存の仕様をきちんと調べているか、影響範囲などが見え ているか、適切にエラー対応出来ているかなどを確認。 上手く実装できてるつもりでも、例外対応できてない、例 外が考慮しきれてない、などはあるある。 簡単なバグ修正 5点 「広告掲載を社内管理画面から予約投稿できるようにする」 機能を実装。詳しくは次スライド。 新たな機能実装 開発は通常と同様に開発環境で開発、テストの流れ。プル リクエストのレビューはまずトレーナーだけで行う。この 時は習作と同様に教育的観点を強く持ち込んで指摘。 トレーナーのレビューが通過した後に、プロダクトの正規 のレビュワーにもレビューしてもらう。プロジェクト毎に コーディング流儀が違う場合もあるので、(出来るだけトレー ナー側で吸収出来るのがベストではあるが)、追加の指摘は 入りやすい。 マージ・リリースはプロダクトのエンジニアに依頼。 開発とプルリクエスト
- 37. " 目標が明確で、フィードバックが適切で、 チャレンジとスキルのバランスがとれている時、 注意力は統制されていて、十分に使われている。 心理的エネルギーに対する全体的な要求によって、 フローにある人は完全に集中している。 - M.Csikszentmihalyi (2010) フロー体験入門 pp. 43
- 38. 結果 本番メディアで新機能を開発 スキーマ変更まで出来れば良いかなと思っていたが、結果 的にはテーブル設計まで到達。 テーブル設計 バリデーション・データベース接続・編集・削除など一通り のCRUDを実装 CRUD スマートフォン版ジョブセンスのトップページにも(簡単なが ら)実際に手を入れてコミット フロントエンド変更 某社のバナー広告
- 39. 学習資料
- 40. 最低限に絞り まとめ化
- 41. ウェブ教材 ‒ ドットインストール 言わずと知れた初学者向けプログラミング学習動画サイト。 今回はPHPの文法や関数に慣れ親しんでもらうために最初に利用。 開発環境やエディタ、gitなどの講座もあり、最初の一段目として 使いやすい。今回は事前学習で利用。 http://dotinstall.com/
- 42. 今回の教科書3冊 かなり絞ってこの3冊。この中でも読んでもらうのは一部の章に絞って指定。 だらだらいつまでも読めてしまうので、しっかり読むために指定部分の「まとめ」を作ってもらう。
- 43. 今回の教科書3冊 - 他の情報との立ち位置比較 特定の技術要素ジェネラルなプログラミング 実践・ベストプラクティス 理論・設計・原則 ネットの情報 コードレビュー ネットのみでは体系的知識を得にくいため、それを補完するために書籍を利用する。 知識偏重/実践偏重にならないようバランスを取って活用。
- 44. 書籍 ‒ 「アジャイルソフトウェア開発の奥義」 タイトルにはアジャイルとあるが､どちらかというとオブジェク ト指向分析・設計に強い本。初学者向けの本とは言い難いが､こ れ一冊マスターすれば､基礎的なOOPの考え方は抑えておけるの で今回の教科書に。パターン周りの細かい所は飛ばす。主に2週 目で利用。 ちなみになぜか絶版中・・・ 「アジャイルソフトウェア開発の奥義」 http://www.amazon.co.jp/dp/4797347783
- 45. 書籍 ‒ 「リーダブルコード」 最近大人気のコーディングテクニック本。｢コードコンプリート｣ ｢クリーンコード｣に比べコンパクトにまとまっているため、初学 者には渡しやすかった。 読んで終わりではなく、繰り返し読んでコードを見返してもらう ため、全期間に渡って利用。 「リーダブルコード」 http://www.amazon.co.jp/dp/4873115655/
- 46. 書籍 ‒ 「実践ハイパフォーマンスMySQL」 MySQLの鉄板。これも初学者向けとは言い難いが基礎が確実に 詰まっているので､これを教科書として進めていった。 ボリュームはかなり多いので､今回は｢データ型｣と｢B-Treeインデッ クス｣に絞って熟読。主に3週目で利用。 「実践ハイパフォーマンスMySQL」 http://www.amazon.co.jp/dp/4873116384/
- 47. ちなみにこの本、日本の第三版はなぜかAmazonレビュー低いですが、米国では高評価。 技術書はレビューも参考にならないことが多いので、あまりアテにせずに、 出来ればまわりの信頼できるエンジニアの判断を仰ぎましょう。 (版を重ねた本はレビュー劣化しやすいので、前の版のレビューを確認するという手もアリ) 書籍 ‒ 「実践ハイパフォーマンスMySQL」 日本版 米国版
- 48. 書籍は必ず「まとめ」を書いてもらう 本人の記憶定着 ただ課題図書をこなすだけだとページをめくるだけで終わっ てしまうので、要約して残すことで読書をより濃密な体験 にする。 また文章にするときに理解していないことに気づくことも 多い。 読書の濃密化 レビュワーのチェック 本を読んでもらってもそれが正しく理解できてるかはわか らない。まとめ化してもらうことで、本人の理解に誤りが ないかを第三者からチェックできる。 正しく理解出来てるかを確認 社内Wikiにあげておくと、レビュワーだけでなく多くの人 の目に触れるので、本人の学習モチベーションアップや、他 の人の刺激になることも。 社内の刺激に 頭の中に入っているけどその場その場で忘れてしまうこと を、一瞬で思い出せるように。特にリーダブルコードなど、 繰り返し読み返すものは、自分なりのまとめを作っておく ことで、その後の見返し効率がぐっとあがる。 後から見返せるように
- 49. まとめ実物 ‒ リーダブルコード
- 50. まとめ実物 ‒ MySQL
- 51. まとめ実物 - 講義内容や、わかりづらい所も
- 52. 社内のエンジニアの目に止まって激励をもらうことも
- 53. 終わって気づいたこと
- 54. トレーナーの学び Off-JTでしか出来ないこともある なぜかベンチャーはOJT至上主義みたいな所がある。 確かにOff-JTは外した時の目も当てられない感がヤバい。 その点OJTは結局業務に即しているから、何かとてつもな く外すとか、目も当てられない状態は基本やってこない。 しかし、一方で今回みたく直角の曲がり角を作るとか、急 激なカタパルトを拵えるとかには、あんまり向いていない んじゃないかと思う。 やってみて気づいたのは、(今更と言われるかもしれない が)Off-JTにあるものすごく大きな可能性だった。理屈では わかっていても、これを実感出来たのは大きな収穫だった。 20代で学んだことを30代40代と繰り返していけば済むよう な時代は終わっていて、ずっとずっと学び続けていかなけれ ばいけない現代で、Off-JTは今こそもっと見直されても良 いと思うし、それが企業の強さを支えるひとつの仕掛けに なることも十分にあり得ると思う。 教育と学習 今回いわゆる教育は殆ど行っていない。強いて言えば数回 の講義はそれに値するものだったと思うが、基本的には本 人の学習に拠る所が大きい。この1ヶ月プロジェクトを成功 たらしめたものが何かあるとすれば、それは絶対に本人の 熱意から来る勤勉さや行動力だろう。 人は本人の学びたくないことを学ばせることは出来ない。 もしトレーナーに何か出来ることがあるとすれば、学びた いものの具象物をいかに提示するか、その走り続けるレー ルを途絶させることなく、何歩先も敷いておけるか、に尽 きる。 だから先述した「本人が研修についていけない事よりも、 研修が本人についていけない事を恐れるべき」というのは、 この期間中僕がずっと思っていたことでもある。 トレーナーはキャップにもカタパルトにもなり得る。 カタパルトになるのは恐らくそんな難しいことではない。 むしろ必要以上の手助けや、気負いや、親切心が、キャップ へ近づく手立てになってしまうのだろう。
- 55. リブセンスとしての学び 挑戦が次の挑戦を呼ぶ 挑戦的で居続けるというのは結構たいへんで、誰しも口先 では挑戦が大事と言いつつ、目の前の大切なものをいつま でも捨てられないでいる。何かを守りながら果敢な挑戦を するというのは殆どの場合難しい。そして僕も割りとそう いう人間のひとりだと思う。 しかし、たまに大胆に挑戦しようと思えるときがあって、 それはたいてい他の挑戦を(たとえその結果が失敗だったに せよ)耳にしたときなのだ。本プロジェクトは当然社内でも 話題になり、様々な刺激を生み出した。 誰しもがそれを少しずつ自分のカタチに直して受け入れる。 1ヶ月でもエンジニアでもないにせよ、今躊躇している何か への後押しとして。 もともと本プロジェクトはただの社内のイチトレーニング だ。メディアに載ったりするようなものではないし、こう やってスライド作って外部にまで出していくのは気恥ずかし い部分もある。けれど、それによって刺激を受ける人がい れば、それもうちの会社のビジョン実現に至る一つの過程 だと思う。 エンジニアへの転身志望者の多さ 実は一度社会に出てからのエンジニアへの転身事例はそん なに多くないし、転職を介さずに社内で転身する事例はさ らに少ない。なんとなく予想していた事実だったが、今回 メディアに取り上げて頂いたり、その反響を見る中で改め て気づいたことでもあった。 実社会とソフトウェアの交差点で戦うリブセンスでは、技 術一辺倒のエンジニアのみでなく、多種多様なバックグラ ウンドを持った多様性のあるチームを組成したいと思って おり、この転身をさらに増やしていきたいと考えている。 そこで今回新たにWantedlyで「未経験からエンジニアへの 転身志望者」を募集することにした。 https://www.wantedly.com/projects/15926 まだそこまで拡散していないにも関わらず、既に多くの「話 を聞きたい」という申し込みを頂いて、反響の大きさを感 じている。 単純に転身したい人だけでなく、社内でそういう事例を作 りたい人も含め、ぜひ話を聞きに来て頂ければと思う。
- 56. トレーニーの学びも聞いてみました 改善可能な状態にすることの大変さ この１ヶ月、学ぶことだらけでしたが、一番の学びは、 「サービスを継続的に改善できるようにしていくことは、 動くものを作ることとは全く別物」だということです。 あまりうまく説明できないのですけど、車の製造に例える と、一度完成した普通車に対して、オープンカーに仕様を変 更して！って言っても、簡単には変更できないじゃないで すか。場合によっては新しく一から作り直すしかない。変 更できるようにするためには、初めからオープンカーにも 対応できるような仕様じゃないといけない。 Webサービスのコードもそれに近くて、何も考えずにただ 動くものを作ると、その後変更に耐えられないんですよ。 新しい機能を付けたり、既存機能を変更できるようにする ためには、ちゃんと変更可能なようにコードを作っていか ないといけない。 しかも困ったことに、同じ人がずっと作っているならコー ドの仕様が分かっているため変更しやすいものの、作り手 は定期的に変わっていきます。 新しく入ってきた人でもコードの変更ができるようでなけ れば、サービスとしては持続していかないのです。 なのでエンジニアさんは、ただ動くものを作るだけでなく、 長期にわたって改善可能なものにしていくということに対 して、多大な労力をはらっていました。 ディレクターをしていた時は、サービスを改善可能な状態 にすることの大変さ、重要さについてそれ程深く考えたこ とがなかったです。そういうことにも注力しながら施策を 実現していたんだなと、エンジニアさんに対する敬意の念 がより一層深くなりました。
- 57. 最後に、プログラミングをこれから学ぶみなさんへ。 このスライドから掴み取って欲しいこと このスライドには欲していたものがあったでしょうか。恐 らく多くの人は期待していたものを手に出来なかったので はないかと思います。なぜならこのスライドはあくまで一 企業の中のひとつの研修の記録でしか無いから。 トレーナーが居ない人は。聞ける相手が居ない人は。レ ビューしてくれる人が居ない場合はどうしたら良いでしょう。 その答えはここにはありません。 しかし、山浦がエンジニアになるにあたり一番重要だった ことはトレーナーでもレビュー体制でも書籍情報でもあり ません。 一番重要だったのは、彼の熱意です。 リブセンスではこれまでこんな事例は一つもありませんで した。職種の転向・1ヶ月の業務離脱・取締役のトレーニン グ。全てが初めてのことでした。 それを可能にしたのは、一点、彼の熱意だけなのです。 人は誰しもが熱意で何かを動かすことが出来るのでしょう。 実際今回、関係者以外でも多くの人が自発的に彼の学習を 手助けしました。 だから、まずは声をあげましょう。荒らげましょう。 そして、熱意が伝わるだけの行動を起こしましょう。 プログラミングは独学で学ぶのが難しい分野のひとつだと 思います。最初はピントが外れた行動になってしまうかも しれません。効率の悪い学習の仕方になってしまうかもし れません。初めからメンターが見つかればそれに越したこ とはありません。 しかし、その状況にないならば、それを呼び起こすだけの 行動を続けてみましょう。それを続けることで周囲の誰か を動かすことはできるかもしれません。 事実彼はそれを成しました。 その一つの事実こそが、このスライドが誰しもに示す、ゆい いつの価値かもしれません。 本スライドがこれを読んだ方の現実を何か一つでも変革す る手助けになればさいわいです。
Login to see the comments