本スライドでは

新卒2年目のウェブディレクターが 1ヶ月でエンジニアに転身したときの 教材・方針・進行について解説します。

http://careerhack.en-japan.com/report/detail/453 http://www.slideshare.net/kiyotoyamaura/1-45361529

｢人は一ヶ月でエンジニアになれるのか｣とは？

▸ リブセンス新卒2年目のディレクターが

▸ 1ヶ月業務から離れてウェブエンジニアへの転身を図ったプロジェクト

▸ その後なんとか現場でウェブエンジニアとして活躍中(?)

メディア掲載 スライド 本人編

http://careerhack.en-japan.com/report/detail/453 http://www.slideshare.net/kiyotoyamaura/1-45361529

｢人は一ヶ月でエンジニアになれるのか｣とは？

▸ リブセンス新卒2年目のディレクターが

▸ 1ヶ月業務から離れてウェブエンジニアへの転身を図ったプロジェクト

▸ その後なんとか現場でウェブエンジニアとして活躍中(?)

メディア掲載 スライド 本人編本スライドでは、その裏側について、トレーナー視点で詳細に解説します。 ウェブ系に限った話ですのでその点はご留意ください。

読み終わった後は

• どういう方針で1ヶ月を進めたのか

• 具体的に何をどういう順番で行ったのか

• どういう教材や書籍を用いたのか

• その結果何が起こったか

がわかるものを目指しています。

自己紹介

桂 大介エンジニア兼取締役。 最近社内ではスパルタ教育で名が売れてせつない。

トレーナー

山浦 清透2013年に新卒としてリブセンスに入社。 Webマーケティングを担当していたが、 今回たっての希望によりウェブエンジニアへ転身。 座右の銘は「一寸先は光」。

トレーニー

前置き

そもそも覚えることが多い

ウェブエンジニアつらい

覚えるべき領域が多すぎるし､それぞれが深くてゴールがない。

ウェブの代表的な技術だけでも..

などなど。

他にもデータ構造・アルゴリズム・OOAD・セキュリティ・正規表現・・・ 覚えるべきことが無数にある。

竹内先生に同情されるくらい大変

http://careerhack.en-japan.com/report/detail/346

1. 基本だけ一通りさらう ▸ 簡単なウェブアプリケーションを作成する

▸ もしくはドットインストールや書籍を自習させて終わり

2. ｢実践が一番勉強になるでしょ！｣という声と共に配属 ▸ もちろんOJTでしか身につかないものも多い

▸ 一方単純に教育コストをケチっているだけのケースが多いのも確か

3. あとはコードレビュー中心で育成 ▸ 結果として現場の負担増

▸ 大きな成長は｢成長のきっかけになる仕事｣次第で運否天賦

▸ コードは一通り書けるようになっても､クラス設計やデータベース設計､トラブル

シューティングなどがいつまでも弱い｢頭打ちエンジニア｣になりやすい

その結果ありがちな新人育成

1. 基本だけ一通りさらう ▸ 簡単なウェブアプリケーションを作成する

▸ もしくはドットインストールや書籍を自習させて終わり

「ありがちな新人育成」の問題点

よく出来た自習教材ほど、それをなぞるのは簡単。 しかし一方で • 学習が体系化されず、未知の課題に応用できない • そのコードが暗黙に前提としている知識について学べない • 異常系やパフォーマンスなどが欠落しがち • コードリーディングの能力が鍛えられない などの問題が残る。

他方現場の仕事はその多くが既存コードの変更であり、 配属後に学んだものとのギャップを感じることが多い。

問題点

2. ｢実践が一番勉強になるでしょ！｣という声と共に配属 ▸ もちろんOJTでしか身につかないものも多い

▸ 一方単純に教育コストをケチっているだけのケースが多いのも確か

得てして現場のコードは「教科書的」ではなく、様々な理由で特殊。 • 長年の拡張に伴い、肥大化したメイン処理 • 過去の言語仕様に由来する、冗長な処理 • 過去に使われた機能に由来する密結合 • 社内の他プロダクトも理解しないと触れられない社内共通ライブラリ

結果、配属後は殆ど戦力にならず、再度現場で研修的なことが行われたり、 チームによっては周囲にも聞けず一人デスマーチ状態に陥りがち。

問題点

「ありがちな新人育成」の問題点

3. あとはコードレビュー中心で育成 ▸ 結果として現場の負担増

▸ 大きな成長は｢成長のきっかけになる仕事｣次第で運否天賦

コードレビューは有用だが、学習という観点から見ると難点も多い。 • 成長を促すコードレビューは難しい • 最適なコードではなく、状況に合わせたコードが求められることが多い • 場当たり的な指摘に留まり、概論的な学びが得にくい

コードは一通り書けるようになっても､クラス設計やデータベース設計､ トラブルシューティングなどがいつまでも弱い｢頭打ちエンジニア｣になりやすい。

問題点

「ありがちな新人育成」の問題点

1. 基本だけ一通りさらう

2. ｢実践が一番勉強になるでしょ！｣という声と共に配属

3. あとはコードレビュー中心で育成

これだけだと、本人も現場も不幸。 とはいっても、Off-JTで深堀りし続けるのは時間がいくらあっても足りないし、 現場で覚えた方が効率が良いのも確か。

「ありがちな新人育成」の問題点

どこで道を間違えたのか

現場配属がゴールになっているため、最低限の技能を付けさせるための、広く浅い詰め込み型・完結型の研修になってしまっている。結果、出来るだけ早い段階での現場配属が目指され、ますます研修の意味希薄化＆現場の負担増へと傾いていく。

研修 現場

研修 現場

研修と現場が分断されるのではなく、

現場の仕事を下支えし続けるような研修。

目指すべきは

独学でも学べるのか

独学のデメリット

教材自体はたくさん出ているが玉石混交。Amazonレビューなどによりある程度の選定は出来るものの、どれが今の自分に最適かまではわからない。また万が一書籍選びに失敗したときも「書籍代がもったいない」とサンクコストに囚われて効率悪く続けてしまいがち。

良い教材を見つけるのは大変

プログラミングは「環境構築で1ヶ月詰まった」「スペルミスで30分悩んだ」「コードが動かなくなってどう直せばいいかわからない」など、躓いて前に進まない状況が発生しやすい。 一定レベルまで達成できれば後は自習で伸ばしていけるものの、プログラミングを諦めて戦線離脱しまうのはだいたい躓いた時。

躓いている間の学習効率が低い

独学で学んだ人は多いし、当然「学べる」。 しかし、効率を比較すれば、早期にメンターを見つけたい。

メンターがいれば、こうした「もったいない」停滞や離脱を抑制することができる。

周囲にエンジニアがいれば手助けを請うのもひとつ。ただし無償でお願いし続けるのが心苦しいときや、周囲にそういったエンジニアがいない場合は有料サービスの検討も。コースで完結するものでなく、アドバイザー・メンターがいるのがベター。 TECH::CAMP https://tech-camp.in/ TechAcademy https://techacademy.jp/

例えば環境構築で詰まってアドバイスを受けたいとき、その原因が設定の問題なのか、バージョンの問題なのか、タイプミスの問題なのかを、具体的な実物を共有せず説明することは困難。タイプミスがなくとも、スペースを誤ると異なる振る舞いをする言語もあるので「タイプミスがない」と言われてもメンターは鵜呑みにできない。 よってリアルな「場所」を共有できるメンターが見つけられればベター。書籍「ワークシフト」でも「高度な専門知識と技能を身につけるうえで場所がいっそう重要になる可能性が高い」と言われている。

有料サービスも視野に

出来ればオフラインで会えるものを

メンター探しのポイント

周囲に適当なエンジニアがいない場合は、有料サービスも含めた検討を。

独学でも学べるのか - メンター探し

"高度な専門知識と技能を身につけるうえで 「場所」がいっそう重要になる可能性が高い。 中世の職人と同じように、私たちも学ぶべき点の ある人たちのそばに身を置く必要性が高まるだろう。

- Lynda Gratton (2012) WORK SHIFT pp. 268

今回の方針

研修後も自走

そもそも今回のケースでは

研修の役割

本人の希望による転向・学習なので、学ぶ意義の説明や、モチベーション管理などは基本的に不要。 研修は本人が全速力で走り続けるために何ができるかのみを考える。

学ぶ気概は十分にある

研修後の自走も狙う

1ヶ月なのでそもそも研修中にすべてを教えるのは不可能。 「何を学んだのか」と同じくらい「何を学んでいないか」を知ることが大切。その「不足感」「欠如感」が次の学びにつながる。 研修が終わったときに「次何を学べばいいかわからない」ではなく「次はこれとこれを埋めていこう」という状態になると良い。

現場の仕事を下支えし続ける研修

(無作為的にせよ)目線を下げてしまったり、「次何やったらいいですか？」に代表されるような指示待ち(トレーナーボトルネック)状態を起こしてしまわないように、常に走り続けるためのレールを整備する。 二歩先、三歩先で高速道路を引き続けて、本人がアクセルをべた踏み出来るような状態を作り続けるのが理想。 トレーナーは、本人が研修についていけない事よりも、研修が本人についていけない事を恐れるべき。

研修はキャップにもカタパルトにもなり得る

普段と今回の方針の違い

Level 1

Level 2

Level 3

Level 4

Level 5

普段の育成(6ヶ月)

基礎から順番に 積み上げていく

ある程度学習の期間がとれる場合は、基礎から順番に積み上げていく。一気に色んなものを学ぶ方法に比べ • 混乱が起きずにひとつひとつの概念を丁寧に学べる • その人のペースに合わせて着実に積み上がる • 基礎をしっかり理解することで応用が効きやすい といったメリットがある。弊社でも通常の新人はこういった育成を行う。

期間による学習法の違い

今回1ヶ月という期間を設けたのはあくまで業務内での緊急的な転身だからであって、理想はもっと時間を掛けたしっかりとした基礎の積み上げ。

適切な学習法は期間・人によって様々

普段と今回の方針の違い

Level 1

Level 2

Level 3

Level 4

Level 5

普段通りに進めると...

Level3までしか行けず この後何をやればいいか不明瞭

Level 1

Level 3

Level 4

Level 5

今回の方針

部分的にはLevel5まで到達させることで 不足点がわかりやすくなる

今回の設定された期間は1ヶ月なので普段のやり方では途中までしかたどり着けない。 そこで、基礎部分以降は全体像(ビジョン)を示しつつ、ビジョンと自己との乖離を認識できるカリキュラム構成とし、不足部分は研修以降の自学に期待する。書籍「学習する組織」でいう所の「創造的緊張」を利用する。

Level 2

普段のやり方では中途半端にしかならない

"ビジョンと今の現実の乖離はエネルギー源である。 乖離がなければ、ビジョンに向かって 進むための行動を起こす必要もないのだ。 乖離こそが真の創造的エネルギーの源である。

- Peter M. Senge (2011) 学習する組織 pp. 207

普段と今回の方針の違い - まとめ

普段(6ヶ月) 今回(1ヶ月)

データ構造・アルゴリズム・メモリ管理・ビット操作など。ウェブ系の開発ではなかなか普段触れないところこそ、研修でしっかり触れて基礎を身につける。 普段使っているハッシュテーブルなどについても、それがなぜ早いのか、どういうデータ構造になっているか、などをしっかり理解。

基礎をこそ学ぶ

一気に色々なものを学ぶのではなく、まずはCLIで徹底的にプログラミングだけを学習。その後徐々にHTTPやHTML, CSSなどを学んでいく。データベースもまずは単体でテーブル設計、インデックス、クエリを学び、プログラムから接続するのはそれぞれ学んでから。

段階的に学習MySQLであればB-Treeの構造をしっかり理解。クエリにインデックスがどう効いてくるかはそこから演繹的に導き出すことを期待する。またハッシュインデックスなどについては飛ばす。後で自分で調べてもらう。 デザインパターンも一つだけ。｢他が未習得｣であることを自覚させておくことで「何を学んでいないか」を知る。

少し上のレベルをそれぞれ一つだけ学ぶ

段階的にやっている時間が無いので、とりあえずアプリケーションを作りながら、わからない所を学ぶ。いわゆる遅延学習法※1。しかしそれだと表面的な知識になりがちなので、↓で補強。

すべてを同時に

※1 遅延学習法・・・遅延評価勉強法とも。教科書的に順序を追って勉強するのでなく、その知識が必要になってから勉強する方法。

「何を学んでいないか」を知る　とは

デザインパターン と呼ばれている何か

デザインパターンというものを知らない(もしくは概念は知っていても具体例を一つも知らない)状態で、デザインパターンについて学ぶのは難しい。

1つでも知っていれば、そこから他のパターンは学びやすくなる。 何より「まだ学んでいないこと」として強く認識されることで、 次の学習につながりやすい。

まだ学んでいない 他のパターン

Singleton

実際の流れ

書きながら 学び続ける

全体の流れ

事前準備 環境整備 & 予習

1週目 習作Ⅰ ‒ すごろく

2週目 習作Ⅱ ‒ Twitter的なもの

3週目 本番開発Ⅰ - バグ対応

4週目 本番開発Ⅱ - 機能追加

事前準備

環境構築

Macを手配。基本的なアプリケーションのインストールや､いわゆる環境設定は全てこちらで代行。エディタはPhpStormを利用しようと思ったが､本人の強い希望によりvimにて。 環境設定はもちろん出来るに越したことはないが、プログラミングを学んでからの方が学習が楽。

全てこちらで行う

入り口(文法など)

ドットインストールを何周かしてもらって､簡単な文法や関数についてはカバーしてもらう。一周して終わりではなく、きちんと手に馴染むまでやってもらう。 「わかる」と「書ける」は別。 ※会社で使う場合は法人契約が必要です(それでも安い!!)

ドットインストールを活用

自習できるものは自習

基本的に自習の方が早いし、本人のスピードで進められるので良い。不明点はメモっておいて、後から質問してもらう。

良い教材が増えればこれでどんどん進められるんですが...今回はドットインストールとGitくらいでした。

AtlassianのGitチュートリアル https://www.atlassian.com/ja/git/tutorial

Gitはチュートリアルで

※ちなみに山浦さんは(一応)リブセンスで1年半くらいWebマーケティングを担当していたので､ 　基本的なWebリテラシーは既に付いています。

Gitを先に学ぶメリット

Gitはソースコードのバージョンを管理し「壊す前に戻れる」「いくらでも壊せる」機能を提供する。 開発現場でも必須のツールだが、躓きがちな初学者にこそ必須のツールと言える。

いくらでも壊せる環境を、最初から

抽象的な概念・操作に慣れるGitはソースコードのバージョンをノードのように管理している。こうした抽象的な操作もその後の学習の下地の一つとなる。

https://www.atlassian.com/ja/git/tutorial

日常の進め方

1日の基本サイクル

レビュー時に • やってきたことのレビュー • 次回レビューまでのお題出し を行う。

自習 + レビュー(1時間)

読書はページをめくっていれば簡単に終わってしまうので、出来ればまとめを作ってもらい頭にしっかり入れる。

課題図書は「まとめ」を作る

レビューで何を伝えるか

コードレビューから始まるが､それはあくまできっかけ。次に学ぶべき概念をコードに絡めて話していく。 例えば継承が出てきたら • 継承はどういう関係であるべきか • 継承ではなく委譲を使うのはどんなときか • 継承のときに気をつけるべきこと など。リスコフ置換則など絡めてコードを書きながら話す。

翌日だいたい下手な継承してくるので、Template Methodパターンにつないだり。nullエラーが出たらNull objectパターンにつないだり。

コードレビューはあくまできっかけ

次に学ぶべきものを考えて、少々無茶なお題出しを行う。 教育目的なので、突拍子もない仕様変更でもOK。

コース取りを考えたお題出しが勝負？

今回は若手の何人かが自主的にカバーに入ってくれて、自習中の質問相手になってくれていた様子。 自習中も簡単なミスを指摘してくれるような人が周りにいると心強い。感謝。

自習中も出来れば質問できる環境を

MVCなど取っ掛かりが厄介なものは､がっつり1時間ほど講義して基本的な概念を学んでもらう。 とはいえ講義は全体で4回くらい。

必要であれば講義を追加

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

以下のソースコードが動作するよう、すごろくゲームを開発せよ。

問題

1週目 - 習作（すごろく）

1. 出てきたコードに対して、レビューを入れていく 2. きちんとしたコードになるように修正を何度か繰り

返す 3. コードがまとまってきたら大幅な仕様変更を行う 4. 1に戻る

ポイント

だいたい色んなマス目に対応出来るように作られていないので､その辺からインターフェース・ポリモルフィズムなどを学んでいく。 「Nマス進む」「一回休み」「スタートに戻る」など。 意地悪な所では「他ユーザーと位置を入れ替え」など、1ユーザーで完結しない処理はだいたい対応できない。

マス目のイベントが肝

ここではOOPを中心にプログラミングだけを学ばせたいので、データベースやウェブは一切登場させない。

全てCLIで

ログをテキストで出したりHTMLで出してもらったりして、いわゆるLoggerクラス的なものを学んでもらう。 (だいたい最初は標準出力するので..) またログを出力しないNullLoggerクラスを作ってもらって、Null objectも体験してもらう。

ログ処理も

殺意持たれるくらいに出す。「サイコロを12面に」「こういうマス目を増やして」「プレイヤーに性別つけて」など。いかに当初のコードが拡張性に乏しいかを指摘していく。

ガンガン仕様変更要求を出す

すすめ方

2週目 - 習作（Twitter的な何か）

問題

以下の機能を実装し、Twitterクローンを実装せよ。 ・会員登録 ・ツイート ・フォロー/アンフォロー ・タイムライン

ポイントすすめ方

バリデーション、認証、データベース、リダイレクトなど、フレームワークの基本的な流れをつかむ。高度なスケーラビリティは今回は扱わない。

フレームワークの基本的な流れをつかむ

フレームワークは多くの機能を提供するが、CLIアプリと異なり処理の流れを追いにくく、全容把握が困難。 学習者の理解度にあわせて、講義形式でのインプットを実施する。今回はMVCパターンなどを2時間程度実施。

必要に応じて講義を加える

1. 出てきたコードに対して、レビューを入れていく 2. 理解度に応じて講義を実施する 3. きちんとしたコードになるように修正を何度か繰り

返す

あくまでウェブやフレームワークの連携を学ぶのが目的。プログラミング的お題をこなしてもらうなら、既に環境が切り分けされているCLIお題の方で行う。

こっちではあまりエグい仕様変更要求は行わない

2週目 - 習作（Twitter的な何か）

3, 4週目 ‒ 本番開発

進め方

現場のPMに依頼して簡単そうなチケットをいくつか出してもらう。その中で取り組めそうなものをトレーナーがピックアップ。 フロー体験を引き起こすように「やるべきことが明確で設計とコーディングに集中できるか」「本人にとって程よく難易度が高くチャレンジングか」などを基準に。

適切な難易度のチケットをもらう

実際行ったもの

結果的には簡単な変更に終わるものであっても、既存の大規模なコードベースの上での修正なので考慮すべきことも多く、考慮漏れなどが出やすい。 既存の仕様をきちんと調べているか、影響範囲などが見えているか、適切にエラー対応出来ているかなどを確認。 上手く実装できてるつもりでも、例外対応できてない、例外が考慮しきれてない、などはあるある。

簡単なバグ修正 5点

「広告掲載を社内管理画面から予約投稿できるようにする」機能を実装。詳しくは次スライド。

新たな機能実装開発は通常と同様に開発環境で開発、テストの流れ。プルリクエストのレビューはまずトレーナーだけで行う。この時は習作と同様に教育的観点を強く持ち込んで指摘。 トレーナーのレビューが通過した後に、プロダクトの正規のレビュワーにもレビューしてもらう。プロジェクト毎にコーディング流儀が違う場合もあるので、(出来るだけトレーナー側で吸収出来るのがベストではあるが)、追加の指摘は入りやすい。 マージ・リリースはプロダクトのエンジニアに依頼。

開発とプルリクエスト

"目標が明確で、フィードバックが適切で、 チャレンジとスキルのバランスがとれている時、 注意力は統制されていて、十分に使われている。 心理的エネルギーに対する全体的な要求によって、 フローにある人は完全に集中している。

- M.Csikszentmihalyi (2010) フロー体験入門 pp. 43

結果

本番メディアで新機能を開発

スキーマ変更まで出来れば良いかなと思っていたが、結果的にはテーブル設計まで到達。

テーブル設計

バリデーション・データベース接続・編集・削除など一通りのCRUDを実装

CRUD

スマートフォン版ジョブセンスのトップページにも(簡単ながら)実際に手を入れてコミット

フロントエンド変更

某社のバナー広告

学習資料

最低限に絞り まとめ化

ウェブ教材 ‒ ドットインストール

言わずと知れた初学者向けプログラミング学習動画サイト。 今回はPHPの文法や関数に慣れ親しんでもらうために最初に利用。

開発環境やエディタ、gitなどの講座もあり、最初の一段目として使いやすい。今回は事前学習で利用。

http://dotinstall.com/

今回の教科書3冊

かなり絞ってこの3冊。この中でも読んでもらうのは一部の章に絞って指定。 だらだらいつまでも読めてしまうので、しっかり読むために指定部分の「まとめ」を作ってもらう。

今回の教科書3冊 - 他の情報との立ち位置比較

特定の技術要素ジェネラルなプログラミング

実践・ベストプラクティス

理論・設計・原則

ネットの情報

コードレビュー

ネットのみでは体系的知識を得にくいため、それを補完するために書籍を利用する。 知識偏重/実践偏重にならないようバランスを取って活用。

書籍 ‒ 「アジャイルソフトウェア開発の奥義」

タイトルにはアジャイルとあるが､どちらかというとオブジェクト指向分析・設計に強い本。初学者向けの本とは言い難いが､これ一冊マスターすれば､基礎的なOOPの考え方は抑えておけるので今回の教科書に。パターン周りの細かい所は飛ばす。主に2週目で利用。

ちなみになぜか絶版中・・・

「アジャイルソフトウェア開発の奥義」

http://www.amazon.co.jp/dp/4797347783

書籍 ‒ 「リーダブルコード」

最近大人気のコーディングテクニック本。｢コードコンプリート｣｢クリーンコード｣に比べコンパクトにまとまっているため、初学者には渡しやすかった。 読んで終わりではなく、繰り返し読んでコードを見返してもらうため、全期間に渡って利用。

「リーダブルコード」

http://www.amazon.co.jp/dp/4873115655/

書籍 ‒ 「実践ハイパフォーマンスMySQL」

MySQLの鉄板。これも初学者向けとは言い難いが基礎が確実に詰まっているので､これを教科書として進めていった。 ボリュームはかなり多いので､今回は｢データ型｣と｢B-Treeインデックス｣に絞って熟読。主に3週目で利用。

「実践ハイパフォーマンスMySQL」

http://www.amazon.co.jp/dp/4873116384/

ちなみにこの本、日本の第三版はなぜかAmazonレビュー低いですが、米国では高評価。 技術書はレビューも参考にならないことが多いので、あまりアテにせずに、 出来ればまわりの信頼できるエンジニアの判断を仰ぎましょう。 (版を重ねた本はレビュー劣化しやすいので、前の版のレビューを確認するという手もアリ)

書籍 ‒ 「実践ハイパフォーマンスMySQL」

日本版 米国版

書籍は必ず「まとめ」を書いてもらう

本人の記憶定着

ただ課題図書をこなすだけだとページをめくるだけで終わってしまうので、要約して残すことで読書をより濃密な体験にする。 また文章にするときに理解していないことに気づくことも多い。

読書の濃密化

レビュワーのチェック

本を読んでもらってもそれが正しく理解できてるかはわからない。まとめ化してもらうことで、本人の理解に誤りがないかを第三者からチェックできる。

正しく理解出来てるかを確認

社内Wikiにあげておくと、レビュワーだけでなく多くの人の目に触れるので、本人の学習モチベーションアップや、他の人の刺激になることも。

社内の刺激に頭の中に入っているけどその場その場で忘れてしまうことを、一瞬で思い出せるように。特にリーダブルコードなど、繰り返し読み返すものは、自分なりのまとめを作っておくことで、その後の見返し効率がぐっとあがる。

後から見返せるように

まとめ実物 ‒ リーダブルコード

まとめ実物 ‒ MySQL

まとめ実物 - 講義内容や、わかりづらい所も

社内のエンジニアの目に止まって激励をもらうことも

終わって気づいたこと

トレーナーの学び

Off-JTでしか出来ないこともある

なぜかベンチャーはOJT至上主義みたいな所がある。 確かにOff-JTは外した時の目も当てられない感がヤバい。その点OJTは結局業務に即しているから、何かとてつもなく外すとか、目も当てられない状態は基本やってこない。

しかし、一方で今回みたく直角の曲がり角を作るとか、急激なカタパルトを拵えるとかには、あんまり向いていないんじゃないかと思う。

やってみて気づいたのは、(今更と言われるかもしれないが)Off-JTにあるものすごく大きな可能性だった。理屈ではわかっていても、これを実感出来たのは大きな収穫だった。

20代で学んだことを30代40代と繰り返していけば済むような時代は終わっていて、ずっとずっと学び続けていかなければいけない現代で、Off-JTは今こそもっと見直されても良いと思うし、それが企業の強さを支えるひとつの仕掛けになることも十分にあり得ると思う。

教育と学習

今回いわゆる教育は殆ど行っていない。強いて言えば数回の講義はそれに値するものだったと思うが、基本的には本人の学習に拠る所が大きい。この1ヶ月プロジェクトを成功たらしめたものが何かあるとすれば、それは絶対に本人の熱意から来る勤勉さや行動力だろう。

人は本人の学びたくないことを学ばせることは出来ない。 もしトレーナーに何か出来ることがあるとすれば、学びたいものの具象物をいかに提示するか、その走り続けるレールを途絶させることなく、何歩先も敷いておけるか、に尽きる。

だから先述した「本人が研修についていけない事よりも、研修が本人についていけない事を恐れるべき」というのは、この期間中僕がずっと思っていたことでもある。

トレーナーはキャップにもカタパルトにもなり得る。 カタパルトになるのは恐らくそんな難しいことではない。むしろ必要以上の手助けや、気負いや、親切心が、キャップへ近づく手立てになってしまうのだろう。

リブセンスとしての学び

挑戦が次の挑戦を呼ぶ

挑戦的で居続けるというのは結構たいへんで、誰しも口先では挑戦が大事と言いつつ、目の前の大切なものをいつまでも捨てられないでいる。何かを守りながら果敢な挑戦をするというのは殆どの場合難しい。そして僕も割りとそういう人間のひとりだと思う。

しかし、たまに大胆に挑戦しようと思えるときがあって、それはたいてい他の挑戦を(たとえその結果が失敗だったにせよ)耳にしたときなのだ。本プロジェクトは当然社内でも話題になり、様々な刺激を生み出した。

誰しもがそれを少しずつ自分のカタチに直して受け入れる。1ヶ月でもエンジニアでもないにせよ、今躊躇している何かへの後押しとして。

もともと本プロジェクトはただの社内のイチトレーニングだ。メディアに載ったりするようなものではないし、こうやってスライド作って外部にまで出していくのは気恥ずかしい部分もある。けれど、それによって刺激を受ける人がいれば、それもうちの会社のビジョン実現に至る一つの過程だと思う。

エンジニアへの転身志望者の多さ

実は一度社会に出てからのエンジニアへの転身事例はそんなに多くないし、転職を介さずに社内で転身する事例はさらに少ない。なんとなく予想していた事実だったが、今回メディアに取り上げて頂いたり、その反響を見る中で改めて気づいたことでもあった。

実社会とソフトウェアの交差点で戦うリブセンスでは、技術一辺倒のエンジニアのみでなく、多種多様なバックグラウンドを持った多様性のあるチームを組成したいと思っており、この転身をさらに増やしていきたいと考えている。

そこで今回新たにWantedlyで「未経験からエンジニアへの転身志望者」を募集することにした。 https://www.wantedly.com/projects/15926

まだそこまで拡散していないにも関わらず、既に多くの「話を聞きたい」という申し込みを頂いて、反響の大きさを感じている。

単純に転身したい人だけでなく、社内でそういう事例を作りたい人も含め、ぜひ話を聞きに来て頂ければと思う。

トレーニーの学びも聞いてみました

改善可能な状態にすることの大変さ

この１ヶ月、学ぶことだらけでしたが、一番の学びは、「サービスを継続的に改善できるようにしていくことは、動くものを作ることとは全く別物」だということです。

あまりうまく説明できないのですけど、車の製造に例えると、一度完成した普通車に対して、オープンカーに仕様を変更して！って言っても、簡単には変更できないじゃないですか。場合によっては新しく一から作り直すしかない。変更できるようにするためには、初めからオープンカーにも対応できるような仕様じゃないといけない。

Webサービスのコードもそれに近くて、何も考えずにただ動くものを作ると、その後変更に耐えられないんですよ。 新しい機能を付けたり、既存機能を変更できるようにするためには、ちゃんと変更可能なようにコードを作っていかないといけない。

しかも困ったことに、同じ人がずっと作っているならコードの仕様が分かっているため変更しやすいものの、作り手は定期的に変わっていきます。 新しく入ってきた人でもコードの変更ができるようでなければ、サービスとしては持続していかないのです。 なのでエンジニアさんは、ただ動くものを作るだけでなく、長期にわたって改善可能なものにしていくということに対して、多大な労力をはらっていました。

ディレクターをしていた時は、サービスを改善可能な状態にすることの大変さ、重要さについてそれ程深く考えたことがなかったです。そういうことにも注力しながら施策を実現していたんだなと、エンジニアさんに対する敬意の念がより一層深くなりました。

最後に、プログラミングをこれから学ぶみなさんへ。

このスライドから掴み取って欲しいこと

このスライドには欲していたものがあったでしょうか。恐らく多くの人は期待していたものを手に出来なかったのではないかと思います。なぜならこのスライドはあくまで一企業の中のひとつの研修の記録でしか無いから。

トレーナーが居ない人は。聞ける相手が居ない人は。レビューしてくれる人が居ない場合はどうしたら良いでしょう。その答えはここにはありません。

しかし、山浦がエンジニアになるにあたり一番重要だったことはトレーナーでもレビュー体制でも書籍情報でもありません。 一番重要だったのは、彼の熱意です。

リブセンスではこれまでこんな事例は一つもありませんでした。職種の転向・1ヶ月の業務離脱・取締役のトレーニング。全てが初めてのことでした。 それを可能にしたのは、一点、彼の熱意だけなのです。

人は誰しもが熱意で何かを動かすことが出来るのでしょう。実際今回、関係者以外でも多くの人が自発的に彼の学習を手助けしました。

だから、まずは声をあげましょう。荒らげましょう。

そして、熱意が伝わるだけの行動を起こしましょう。

プログラミングは独学で学ぶのが難しい分野のひとつだと思います。最初はピントが外れた行動になってしまうかもしれません。効率の悪い学習の仕方になってしまうかもしれません。初めからメンターが見つかればそれに越したことはありません。

しかし、その状況にないならば、それを呼び起こすだけの行動を続けてみましょう。それを続けることで周囲の誰かを動かすことはできるかもしれません。

事実彼はそれを成しました。

その一つの事実こそが、このスライドが誰しもに示す、ゆいいつの価値かもしれません。

本スライドがこれを読んだ方の現実を何か一つでも変革する手助けになればさいわいです。