LIVESENSE ENGINEER BLOG

リブセンスエンジニアの活動や注目していることを発信しています

エンジニア基礎を題材としてOff-JTしてみた話

こんにちは。ma2saka です。リブセンスでは C# と python を主張する役割を担っています。ふだんの仕事では bash と ruby を書いています。

ここでは、初学者の Off-JT を2週間ほどする機会があったので、その報告をしたいと思います。

背景

弊社では「Web開発」や「SQL」を特殊な職能として捉えるのではなく、誰もが*1一定程度は身に付けられるスキルと考えています。できるだけ、業務経験の有無にかかわらずトレーニングの機会を作ろうとしています。

人は一ヶ月でエンジニアになれるのか」「人は一ヶ月でエンジニアになれるのか - 詳細解説」の企画もその関連となります。未経験に近い人間を実際に育成枠のエンジニアとして配置することもあります。

経験が浅い状態で配属された場合、やっぱり相当の苦労はあるわけです。羽生善治さんの「学習の高速道路」という言葉は有名ですが、目的地も相応に遠くなっていますし出発地や車は平等じゃありませんからね。

どうキャッチアップしていくかってのは現場やその人のタイプによっても変わってきます。中には「座学とか本とか無理。モリモリ仕事でコード書いてバシバシ叩かれるのが一番」っていう人もいるし、真逆の人もいます。

今回の被験者(2名)

被験者2名について簡単に紹介しましょう。

  • サーバサイド開発に関しては二人ともほぼ初心者
  • 一人は上流SIerから、一人はWeb制作から転向してきたキャリアチェンジ組
  • 現在OJT気味でサーバサイド開発に入っているが、思うように技術が身につかない
  • ガチでエンジニアキャリアに乗りたい(乗せたい)という強い意向がある

どちらも真面目で頑張るタイプですが、けっこうスピード感の早いチームに配属されて目先の作業をこなすので手一杯になっているようで。上司の方から「エンジニア基礎みたいな部分を強化したいんだが」という相談が寄せられました。期間は2週間。

個人的にも、これから新卒向けの受けいれカリキュラムを整備しなければいけなかったこともあり、「これはリハーサルになって都合が良い」と考えて応諾しました。

エンジニアの基礎ってなにやればいいんだっけ

まずそこで悩みました。なんせ2週間ですからね。営業日で10日しかない。

下から体系的・網羅的にやるのはすぐに諦めました。二進数と論理回路、CPUやメモリ、OS、ネットワークといった部分からになってしまうのですが、どう考えても10日でやることではありません。そのあたりは秋の応用情報でも受けてもらうことにしました。いずれ絶対必要になりますけれども、そのあたりの知識がなければ解決できない問題はすぐには直面しないでしょう。

もちろん、「Ruby on Railsチュートリアルを丁寧にやる」も考えましたが、これもやめました。現場でもその種のチュートリアルは受け入れ時にやってるんです。

チュートリアルやドットインストールぐるぐるやってもうまく理解しなかった、身につかなかった何かが問題であるはずです。もっと土台のところに課題がありそうです。

最終的に、「RailsのチュートリアルをやればRailsで開発ができるようになる人」をコンセプトにすることにしました。

三つの軸: 自力救済・思考プロセス・動機

さて、だいぶフォーカスが絞られました。「チュートリアルやればわかるようになる」には何が必要だろうかと考えます。どんな人なら、自力でなんとかしていくだろうか。

要するに、やってる手順でわからなかったら調べる習慣があって、コードを読んだ時に書いた人の気持ちや設計の意図が想像できて、あとは「もっとだ、もっと勉強したい。課題はないか」となればいいわけです。そしたらほっといてもなんとかなるでしょう。

言葉にして書き出してみると、以下のようなことになるでしょうか。

  • 自力救済
    • REPLや検証コードを書いて小さく試す・すぐ試す癖
    • クラウドなどを用いて「手軽に検証できる環境を用意しておく」癖
    • RFCやGitHub、公式ドキュメントなど、標準や実コードを大事にする癖
  • 思考プロセス
    • 大きな問題を小さな問題の集合として捉え直す再構築力
    • 利用する側、提供する側の双方からメソッド等のインターフェイスを考えられる想像力
    • 標準や規約、あるいは開発チームのコンセンサスといった暗黙の補助線をコードに感じ取る視力
  • 動機
    • 強いアハ体験
    • 学習たのしい!! ✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌ マインド
    • 自分がまだ成長の余地があると同時に、今の状態では全然足りないという自覚

さて、こういったことを身につけるためにどういう過程を辿ればいいか考えました。

ぼくのかんがえたさいきょうのRSSリーダー

題材としてRSSリーダーを選びました。

どうしてRSSリーダーなのかというと、Off-JTの開始前ディスカッションのときに「どうやって情報収集とかしているんですか」という定番の質問を受けたのがきっかけです。「僕はRSSリーダーがまだ現役ですねー」「RSS...? あ、SEOで使うやつですか」「!?」という流れです。このご時世でRSSかよという指摘は受け付けておりませんのでご容赦ください。

外部通信が発生したり、定期実行タスクがあったり、XMLのパースやデータフォーマットが複数あるという課題設定上の都合もあります。

作って壊して作って壊して

以下のような順序で作ってレビューしてリファクタして作り直すことをやっていきました。

  • URLリストを入力としてとり、RSS を取得して標準出力に表示するプログラムをrubyで作成 / Nokogiriとかrssモジュールはもちろん禁止
  • 定期実行してファイルに出力
  • 素のRackでRSSリーダー的なWebアプリケーションの開発
  • DBに格納することを検討 / テーブル設計
  • Rakeでコマンドラインタスクの作成
  • Sinatra で再構築
  • ログイン機能をRSSリーダーに追加 / memcachedを使ったセッションの実装

最初は座学的な時間を挟みました。RSSを取得するプログラムをコマンドラインで作成するというスタート地点の設定上、最初は標準入出力やTCP/IP、シェルやプロセスといった部分は必要でした。そのあとは基本的に開発・レビュー・リファクタリングの繰り返しです。

途中、DBの日とかテストの日とかPHPの日とかはさみましたが、そのあたりはちょっとだけなので割愛します。

昨日の自分のコードを見て残念に思うのが自然にできればいいと思いました。

叱ったり褒めたりするのは習慣に対してする

動機付けや習慣については、古典的な飴と鞭方式を採用しました。叱責の対象となるのは怠慢であり、不注意であり、惰性です。

心を鬼にして日々巡回し、おかしなところを探して突っ込んでいきました。以下のようなありがちなミスばかりなんですが、なるべくさらっと流さずに一つ一つを「ちゃんと irb で確認して書く」とか「ドキュメントを読む」「わかってないことを適当にやらない」につなげます。

  • アプリのコード修正してブラウザリロードしてシンタックスエラーのループ
  • Locationヘッダに相対パスを書いている*2
  • データディレクトリに書き込めないからアプリケーションの実行ユーザを変える
  • 実行ユーザを変える代わりにとりあえず777にする
  • 闇雲に例外を潰しているいっぽうで、必要なところで nil チェックが抜けている
  • SQLのselectの結果が「配列なので」Viewにまるごと渡す
  • 仮引数名と実際データ型がずれている(xml_list という名前で単一の XMLDocument を渡していたり)
  • 二重ループの中で毎回トランザクション開始とコミットしている
  • initialize で意味なく return nil をしている

いっぽうで褒める対象は逆で、勤勉、注意深さ、工夫になるわけですね。

たとえばミドルウェアのセットアップ手順確認のためにVMを個別に立ち上げて並行してインストール方法の確認をしていたりとか、メソッドの動作確認をするために irb で対象ファイルを require して動作確認していたりとか、いいじゃないですか。挙動がわからないとき、地道にRack::Session周り読んで destroy と clear の違いを調べていたりとか、公式ドキュメントとスタックオーバーフロー並べて読んでたりとか、謎のエラーが起こったらエラーメッセージをググる。基本的なところだけど、そういう行動とか姿勢について「イイネ!」とやる。

ちなみに、叱るときは冷静に、そして多少偉そうにやりましょう。自信なさそうに叱ると効果が出ません。「あなたはそれを正さなければいけない」とメッセージを伝える必要があります。ただ、褒めるときはなるべくカジュアルにしていました。褒めるときに偉そうだと、いったい自分は何様なんだろうと我に返って残念な気持ちになります。なりました。

二週間の結果

案外二週間なんてあっという間ですね。

手応えとしてはそれほど悪くはありません。少なくとも、意図していた「自力救済の力」は身についたような気がするし、ドキュメントやコードは自分で探し出して読むようになったし、やりたいことを分解して小さな問題の集合としてとらえることができるようにはなったんじゃないかな。やる気スイッチも入ったのではないかと思います。

あとは現場に入ってからどう評価を受けるかですが、これは一か月くらい様子を見る感じです。

終わったあと数日後に話す機会があって、「Railsはとても便利でマジヤバイけど、裏で何やってるかわかんなくて、ちょっとこわい」という感想がでてきたので、「ちゃんと読めばこわくない」と返しておきました。彼が口にしたのはたぶん、格闘漫画で言えば「あいつの強さがわかった」みたいなものだと思うんですよね。だいたい漫画だとこっからが成長フェーズなので、楽しみです。

よかった点
  • 素のRackはちょうど良い低レベル感で、教育用にぴったりでした*3
  • 同じ題材で何度も作り直させたのもよかった
  • 相互レビューはやはりよい。そういう意味で近いレベルの子を2人同時受け入れたのはよかった
  • 個人ごとにGCP (使ったのはGCEのみ) のプロジェクトを作らせたのも面白かった*4*5
よくなかった点
  • ruby入門とかLinux入門は「エンジニア基礎」とは別にやった方がいい
  • 被験者二名にあわせた個別指導になってしまった

特に後者は大きな課題ですね。

結局、この人はこういう傾向があってこういう課題を持ってるからこのように誘導する、というのをやってしまっていたので、公式なカリキュラムへはスケールさせづらい。

今後への課題
  • 基本カリキュラムはこれでいいとして、資料作る
  • 今回やりきれなかったAPサーバのスケールアウトやデプロイまでたどり着くためのシナリオを練る
  • 事前課題まとめる
  • 紹介した書籍のまとめ / 会社に初学者用のおすすめ書架を作るとか
  • 被験者2名の事後フォローと効果ヒアリング

まとめ

ということで、エンジニア基礎研修を被験者2人にパイロット適用してみたというお話でした。

他社さんの教育の取り組みはいろいろ調べて多大に参考にさせていただきました。これからは作り込んでいかないといけないなぁ。

*1:向き不向きはもちろんあります。誰もがソリストにはなれないように、誰もが一線のプロになれるとはもちろん思いません。しかし、ある必要な水準には到達できると思っています。

*2:ちなみに Sinatra の redirect メソッドは内部で絶対パスに変換してくれます

*3:Rackで苦しんだ後にSinatraで作り直させた時の興奮の仕方はヤバかった

*4:仕事でAWS使ってるので、下手に「業務に役立つ」に関心が流れないようにあえて分けたんですが、検証環境に使う分には起動早いし安く上がるのでちょうどいい

*5:ただ、今だったらVirtualbox不要になりそうなDockerを採用したかもしれない。