読者です 読者をやめる 読者になる 読者になる

すでに配属6ヶ月経ってしまったけど新人研修の話をする(3)

前回はよくなかった話ですが、今回はよかった話とちょっと微妙だった話です。技術研修がよかったという話ができるのがテクノロジを仕事とする人としては非常に救いの持てる内容ですね!

まずプログラミングの話に行かなかった

やった内容がこちら(再掲):

  • 1週目
    • ソフトウェア品質の考え方
    • Gitの使い方
    • ソフトウェアベンダのビジネスモデルについて
    • ユニットテスト(JavaScriptQUnit)・CI(Jenkins)
    • 営業・管理から見たできるエンジニア像
    • Redmineの使い方
    • @t_wadaさん講演会 - part1 part2
  • 2週目
    • 開発実習(4日)
    • 途中1日営業の全体ミーティングに召集

今考えたらめっちゃつまらん感想文書いてますね…まあ「社会人」の「お行儀」に慣れてなかったから当たり障りのない方向に倒れたんでしょう。

それはともかく。プログラミングの話は2週目からでした。ただこれはプログラミング軽視というわけではなく、ある程度プログラミングできることを前提としているからこそ可能になる内容だと思っています。

大学でプログラミングをしてきたとはいってもそれはだいたい個人でやるもので(非常にセンシティブな問題なのであとでこれについて思うことは書きたい)、ソロ弾きを習ってきた人がオケ弾きに対応しなければならないようにチーム開発・会社としての開発を知る必要があって、その導入として品質管理の話から入るのは非常に納得がいくわけです。Git・ユニットテスト・CIなんかも「よい開発の作法」を当たり前のものとしてできるようになるための導入です。学生のときはGitこそ使ってたし論文のCIツールみたいなの自力で書いたこともあったけどテストとかめんどくさくてまともに書いてなかったのですよね…。とにかく、テストを書いてコードの健全性を保つとか、ビルドを定期的にするとか、そういうのを「当たり前のこと」としてみれるようになったのはかなり大きいと思っていて、「リソースガー」「スケジュールガー」でuntestedなレガシーコード垂れ流すようになることを未然に防げます。実際そういうところを正すことも期待されてましたし、現にそうしt(銃声

ビジネスモデルの話も早いうちに聞けたのがよかった。利益構造がわからないことには営業さんとはお話ができないし何をすることが価値を生んでいるかという感覚を持つことができない。さらにプログラマは前線でお金を扱うわけじゃないのでなかなかお金の感覚を醸成しにくい。ディスコミュニケーションを避けるためにも有益な内容だった。

開発実習はチームでRailsのWebアプリを作るというもの。やったことあったので特に苦労はなく。一方で余裕があったのだからせっかく習ったようにユニットテスト書いてCIするということまでできればよかったがいつものように押し切ってしまった。

こんだけよかったのに2週間で、かつ他のところに優先度取られたのがほんともったいない

ともかくかなり濃厚な内容だったのですが、もう少し時間があったらやり方は変わったのだろうし(Ruby/Rails初心者には明らかに導入が早すぎた)、しかも他の研修行事に優先度を奪われていた感はありました。もうちょいうまいやり方あるだろということでここは締めておくことにしましょう。