おもしろwebサービス開発日記

Ruby や Rails を中心に、web技術について書いています

良いエンジニアを採用するにはどうしたらいいか

以前ソフトウェア開発者採用ガイドの読書感想文を書いたときに反響が思ったより大きかったので、エンジニア採用というテーマは関心が高いのだなと感じました。

上記感想文のエントリでも書いていますが、お手伝いしている会社の方などから「どうやったら良いエンジニアを採用できますか?」と聞かれることがよくあります。先のエントリでは「頑張るしかないですねとしか答えようがない」と書きましたが、頑張るとはいったい何を頑張るのか、きちんとまとめておいたほうが良いなと思いエントリをしたためる次第です*1

あくまで僕はこう思いますという話で、この通りにしたからといって必ず良いエンジニアを採用できる保証はありません。あしからず。

想定読者

良いエンジニアを採用したい偉いひと、もしくは人事のひとです。

前提: 良いエンジニアとは

このエントリでの「エンジニア」とはいわゆるweb系のエンジニア(例: サーバサイドエンジニア、フロントサイドエンジニア、iOSエンジニア、Androidエンジニア、インフラエンジニア)を指します。

さらに「OSS活動をしたり、勉強会に積極的に参加・登壇するなど、目に見えるアウトプットのある勉強熱心なエンジニア」のことを「良いエンジニア」としています。もちろん、勉強熱心に見えて実は大して能力がない人もいるでしょうし、特にアウトプットはないけど優秀な人もいるでしょう。前者は選考でうまく見極めてください。後者は運以外で採用する方法が思いつかないので今回は取り上げません。

どうやったら採用できるか

大きく2つの施策に取り組む必要があると思います。

  • 良いエンジニアとの接点を作る
  • 社内の開発環境を整える

良いエンジニアとの接点を作る

企業が社員を採用しようとしたとき、まず人材紹介会社や求人サイトを利用するのが一般的なやり方かと思います。しかし良いエンジニアは人材紹介会社や求人サイトをあまり使いません。それらを使わずとも転職することが難しくないからです。もちろん人材紹介会社と求人サイトを活用すること自体はよい*2のですが、良いエンジニアを獲得したい場合は他のやり方も並行して実施する必要があります。

特に統計をとったわけではないのですが、自分の周りの良いエンジニアは社員の紹介経由で転職することが多いです。また、気になっている会社の社員に対してSNSで連絡を取り、遊びに行って会社の様子を知り、そこから選考に進む、というケースもよくあります。

このような転職経路をとるエンジニアを獲得するには「エンジニアたちと普段から接点を作っておくこと」と「エンジニアが転職を考えたときに選択肢の一つにしてもらえるポジションにいること」の2つが重要です。

ではどうやったら接点を作ったり、よい会社だと認知したりしてもらえるのでしょうか?たとえば次のようなものが考えられます。

  • テックブログの開設
  • カンファレンスのスポンサーをする
  • 勉強会の参加

テックブログの開設

エンジニアが会社選びをするときに重視することの一つとして「どんな技術を使っているか」があります。これは「どんな事業を行っているか」よりも遥かに重視されます。テックブログに今使っている技術や達成したこと、便利な知見について書いておくと、外部のひとからはその会社の技術スタックを想像しやすくなります。

また、社員がアウトプットする機会を増やすことにもなりますし、エントリがバズれば会社自体の認知度も上がります。やらない理由はないのではないでしょうか。

ただし、ブログを継続して書き続ける文化がないと逆効果です。例えば最終更新日が1年以上前のテックブログだと「あーこの会社はブログエントリを継続する暇もないくらい忙しいんだな」と判断される可能性があります。テックブログをブランディングとして活用するには最低でも月に一回程度の投稿は必要でしょう。

もし投稿が継続できそうになければ、採用の前に投稿を継続できない原因を解消するべきでしょう。そのような会社に入りたい人は少ないはずです。ブログを書くことを業務の一つと位置づけて、きちんと工数を確保することが必要です。

もしかしたら、現在の社内の技術力が低いのでブログを書きたくない、と考える会社もあるかもしれません。しかし、このような態度はよくありません。仮に会社の技術レベルを知らない優秀なエンジニアが入ってきたときに、実態を知って幻滅してすぐに転職してしまう、となったら双方にとって不幸です。技術力が低いとしたらそれを向上するための活動をブログとして公開していくとよいでしょう。

エンジニアと長期的な関係を築きたいのであれば「本当にまずい情報以外はすべて公表する」くらいの態度であるほうがよい結果をもたらします。

「本当にまずい情報以外はすべて公表する」を実践している例として、就業規則をオープンソースとして公開している企業があったり面接時に使用する資料を公開している企業があったりします。このように情報をオープンにする態度は多くのエンジニアにとって好感が持てるものです。

カンファレンスのスポンサーをする

近年では毎日のようにweb技術に関する勉強会が開催されています。ここでは便宜的に、参加者が数百人になるような大規模な勉強会のことをカンファレンス、それ以外の小規模なものをミートアップと呼ぶことにします。

カンファレンスではたいてい企業スポンサーを募っています。ここでスポンサーに名乗りを上げると知名度向上が期待できます。例えば日本最大のRubyカンファレンスであるRubyKaigiをスポンサーしたら「この会社はRubyに力を入れているのだな」と認知されるでしょう。

しかし、単にスポンサーをしただけだと効果は限定的です。カンファレンスによっては、スポンサーになるとブースを出せたり、チラシやノベルティを配れたり、エンジニアの前で話す機会がもらえたりします。ここで工夫してエンジニアに刺さるアピールができると大幅知名度アップ(好感度アップ)になるでしょう。ただ、ここは「こうすれば刺さる!」ような決まった手法はありません。いろんな会社のやり方を研究して、独自のアピール方法を模索する必要があります。自社のエンジニアと相談していろいろ試してみましょう。

ミートアップはどこかの企業の会議室を借りて開催されることがほとんどです。カンファレンスのスポンサーほどではありませんが、ミートアップの会場を貸すだけでもエンジニアにとっての知名度・好感度は上がります。ほどよく大きく、社外の人間を招いても問題ない会議室を持っている会社であれば検討する価値はあると思います。

勉強会への参加

エンジニアの社員が勉強会やその懇親会に参加して知り合いを増やし、知り合いが転職を考えた時に「うちに遊びに来ます?」と声をかけるのはよくある転職パターンです。

社員が勉強会に参加するかどうかはその社員の趣味嗜好次第ですが、ミートアップの参加を奨励したり、カンファレンスへ業務として参加できるような制度があると参加する回数が増えるのではないでしょうか。

例えばSmartNewsさんは、半年に1回、海外のカンファレンスへの参加を補助してくれるそうです。他にも、例えば「RubyKaigi 業務」のようなワードで検索すると、「弊社はRubyKaigiへの参加は業務扱いで、参加費・交通費・宿泊費を会社負担としています」と表明している会社を多数観測できるはずです。

また、単に参加するだけではなく登壇したり運営に関わったりできると会社のアピールにもなるので、それらを奨励することも重要です。

(少し話がずれます)ときどきエンジニア以外のひとが懇親会に参加し採用のために声掛けなどをしている事例を見かけますが、これは逆効果ですのでやめましょう。懇親会に参加しているエンジニアはあくまで技術の話がしたいのであって、転職の話がしたいのではありません。仮に転職を考えていたとしても、そのようなデリカシーのない会社に入りたいとは思わないでしょう*3

社内の開発環境を整える

ここまで、良いエンジニアは他とは違う転職手法をとるために、それに合わせたアピールやブランディング、接点づくりが重要である、という内容を書いてきました。しかし、これだけを行ったのでは不十分です。

もし仮に頑張って良いエンジニアとの接点を作り「よかったらうちに来ませんか?」と口説いたところで、社内の開発環境が整っておらずエンジニアとして働きにくかったり、技術的に成長できなかったら採用には結びつきません。仮に運良く採用できたところで、すぐに辞めてしまいます。もっと良い環境の会社はたくさんあるからです。これでは接点を作った意味がないですよね。

先ほど書いた「社員が知り合いを誘ってくれる」という話も、働きやすい環境があってこそ成り立ちます。不満がたくさんある会社に仲の良い知り合いを誘うような人は少ないでしょう。それよりも、今在籍している社員がより良い環境を求めて旅立ってしまう可能性の方が高いです。

ではどのようにしたら、エンジニアが働きやすい環境にできるでしょうか?

まずはじめに、エンジニアが重視する価値観を理解する必要があります。エンジニアは、技術的な成長機会をとても重視しています。この話題についてはすでに素晴らしい記事が書かれているのでこちらを読みましょう。

ITエンジニア採用に欠かせない原則とは (1/5):IT人材ラボ

その他にも、エンジニアは合理的でない慣習を嫌います。簡単な例を挙げると、顧客と面会する必要がない職種なのにスーツ着用が義務付けれている、とか事前に準備をしておけば5分で終わる会議に準備せず臨みダラダラと1時間かける、というようなことです。

もちろん開発の進め方にも合理性を求めます。例えば、機能の拡張や修正をするときに間違いを少なく実施できるように、事前にテストコードを書いて不具合を検知できるようにしておくというプラクティスがあります。これはエンジニアたちの中で一般的に合理的だと考えられているやり方です。しかし上層部に理解がなく、テストコードを書くための工数を十分に与えられない、という現場があるとします。そうすると現場のエンジニアは修正の結果を修正のたびに目視で確認していかなければいけません。もっと合理的に解決できる手段があるのに…。

このようなケースでエンジニアたちの声に耳を傾け、状況を改善していけるとエンジニアにとって魅力的な職場になっていきます。

状況を改善するための前提として、権限を持ったひとを巻き込むことが大事です。現場のエンジニアだけでもある程度の改善は可能ですが、必ずどこかで行き詰まります。働きやすい環境を作るためには、上で書いたようにエンジニアの工数確保が必要なものがあったり、有償のツールの導入が必要だったりするからです。これらは権限を持った人がいないとできません。もしこれを読んでいるあなたに権限がなければ、権限のある人にこのエントリを読んでもらい「採用するためにはまず社内環境を改善する必要がある」ということを理解してもらってください。

権限を持った人の協力を得られる状況になったら、働きにくい要因を減らしていきましょう。会社によって要因は異なります。洗い出しには、社内のエンジニアにやりにくいと感じている点について聞くのが手っ取り早いです。他にも、定期的にKPTを行って改善点を都度挙げていく、というのも効果的だと思います。ただし、社内のエンジニアは現在の環境に慣れてしまっているため、改善できるポイントに気づかないこともありえます。もしツテがあれば、社外のエンジニアに頼んでアドバイスを貰うのも有益でしょう。

まとめ

良いエンジニアを採用するためには、接点を作ること、社内の開発環境を整えることの2つが重要であるという話を書きました。ここまで書いてきたことを実行すると、ようやく他の会社と同じラインに立てるかと思います。エンジニア採用は年々激化しており、エンジニア採用に力を入れている会社にとって、このエントリで書かれている内容は当たり前のことばかりです。一歩抜き出るには、ここで書かれていることを踏まえ、さらにその会社なりのやり方で工夫していくしかありません。頑張っていきましょう💪

*1:聞かれるたびに何度も同じ回答をするのは面倒なので、一度文章としてまとめておいて、次回以降は「このエントリ読んでください」で済ませたいという思いもあります

*2:アウトプットはないけど優秀な人が運良く来ることがあるかもしれないし、良いエンジニアが来る可能性もゼロではない

*3:エンジニア以外は勉強会やその懇親会に絶対参加してはいけない、ということではありません。採用以外の話であれば快く応じてくれる人は多いはずです

技術的負債を貯めずに開発するには

先日行われたMedBeer -Rails開発での技術的負債との付き合い方で、「Rails Good Parts, Bad Parts」というタイトルで発表しました。

資料はこちら。

内容を要約すると、技術的負債を貯めずに開発するには

  • (Railsプロジェクトであれば)Railsの便利な機能を活用する
  • 要注意と言われている機能について、対応方法も含めて把握する
  • 上記をチームで共有して、負債になりそうなものをmasterブランチに入れないように頑張りましょう
  • つまり勉強と教育をがんばりましょう

という話でした。あとは clean-rails.orgの紹介をすこしだけ。

所感

たいていどの会社でもコードレビューはしていると思いますが、少数のシニアエンジニアが全ての変更点をレビューしきれるとは限らないし、設計をコードレビューの段階で指摘するのは難しいことです。かくして負債となるコードや設計がレビューをすり抜けてmasterブランチに入り、それを真似したコードが量産され、僕らは雪だるま式に膨れ上がった負債を前に立ち往生するしかないのでした…。

これを避けるには、チーム全体の技術力底上げをひたすら地道にやっていくしかないんですよね。勉強と教育にどれだけ時間を割けるか、というのが数年後のチームの治安を決めます。やっていきましょう💪

社内読書会のススメ

ということで、僕が色んな会社でやっている社内読書会(輪読会)についてまとめます。

社内読書会の流れ

Rails Developers Meetup Day3で話したように、複数のお手伝い先で社内読書会をファシリテートしています。今となっては技術顧問業の一環としてやっていますが、顧問業を始める前から、お手伝い先での社内読書会を頻繁に開催していました。

その時々で多少違いますが、次のような流れで本を読み進めていくことが多いです。

  1. 出席者の誰か一人が声に出して内容を読む
  2. キリの良いところで止めて、みんなで感想を話したり質問をしたりする
  3. 1に戻る

出席者の誰か一人が声に出して内容を読む

基本的に予習の必要がない形式で、その場で読み進める形でやっています。なので、一冊の本を読み終わるまでにかなりの時間がかかります。

参考までに実例を上げておくと、いまメドピアさんで週に1回、1時間づつ読んでいるプロを目指す人のためのRuby入門は4~5ヶ月くらいで読了しそうな雰囲気です(4月から読み始めて今月読み終わりそう)。

予習前提で感想だけ話し合う形式にすればもっと短期間でたくさんの本を読むことができますが、それだと参加者によっては予習が追いつかず、十分な学びを得られないひとが出てくるだろう、と判断してこのようなやり方でやっています。参加者が少人数で予習をやってこれそうな状況であれば、予習前提でやるのが良いと思います。

別の進め方として「本の章ごとに担当者を決め、担当者が内容を要約したものを共有し、共有したものについてみんなで話し合う」形式もあります。実際にEveryday Railsという書籍を読むときにやってみました。この書籍はRSpecについて書かれた本で、参加者は全員すでに業務でRSpecを使っているので、全部音読するよりは要点を共有したほうが効率が良いのでは?と考えたためです。

やってみた感想としては「決して悪くはないが、音読形式でも良かったかもしれない」でした。各自担当している箇所についてはそれぞれ学びがあったようですが、担当外の箇所については興味が薄くなりがちで、短い期間で読み終わるメリットとのトレードオフがある印象です。

キリの良いところで止めて、みんなで感想を話したり質問をしたりする

ここが読書会の肝です。読んでいて疑問に思ったところの解消だけでなく、単純に感じたことを共有することを奨励しています。会話をすることで淡々と読んでいくよりも記憶に残るはずだし、場合によっていはよい方向に話が発散することもあります。

あとは例えば読んでいるのがRuby関連の書籍で、あるRubyの機能が紹介されていたとすると、

  • お仕事でこの機能を使うことがあるか?
    • あるとしたらどういうとき?
    • ないとしたらなぜ使われないのか?
  • 社内のプロダクトでこの機能を使っているところがあるか?
    • 今後適用したほうが良い箇所があるか?

などはみんな気になるところなので、積極的に話題にしています。

社内読書会の課題

社内読書会は楽しくて勉強になるので是非ともお勧めしたいのですが、とりあえずでやってみると「これ難しいな…」とか「思ったよりうまくいかないな…」となるケースがあります。

その中で大きい課題は

  • 題材の選定
  • 参加率の維持

の二点です。

題材の選定

参加者の人数やレベル感によりますが、社内のエンジニア全員を対象にした読書会の場合、シニアエンジニアとジュニアエンジニアが混在する形になります。このとき全員に適した書籍を決めるのはとても難しいです。

エンジニアのレベルごとに別の読書会にしてしまうのも一つの手かな、と思ってはいますがまだ実施したことはありません。

また、僕がやっているような週1、1時間くらいのペースで実施する場合は、「以前読んだ章の内容を忘れがち」というのも課題の一つです。本の途中で、「以前のn章で書かれていた内容は実はこういうことで…」のように書かれていても、それが数ヶ月前の内容だと「n章 で書かれていた内容ってなんだっけ?」となります。週1など、ある程度間隔をあけて進める場合は、1章ごとに内容が独立している書籍の方が向いていると言えます*1

あとは会社の業務時間内に実施できるかどうか、というのも題材に影響します。業務時間内に実施するのであれば、なるべく直近の業務に関係する内容が求められる可能性があります。業務外であれば自由に選定することができるはずです(その代わり書籍を自費で購入することになるでしょうが)。

参加率の維持

業務時間内に業務として読書会を開催した場合、社内のほぼすべてのエンジニアが読書会の参加対象になることでしょう。しかし、毎回全員が参加できるようなケースはめったにありません。業務が忙しくて欠席したり、会社を休んで欠席するということはよくあります。ただこれが続くと、読書会に参加しないことが普通になってしまい、回を重ねるごとにだんだんと参加者が減っていくことになります。先ほど書いたような「以前書いた内容を参照することの多い書籍」が題材だと、休めば休むほど次回参加のハードルが上がるため、復帰しにくくなってしまいます。

今のところ、この課題の対策としての有効な手は打てていません。読書会に出席できないほど忙しい業務を減らしていくしかないのかな、と思います。

また、業務時間外に読書会を開催する場合はさらに気を使う必要があります。なるべく大勢に参加してほしい場合は、各章独立しているタイプの書籍の方が望ましいでしょう。また、業務開始前に読書会を実施したこともありますが、朝の強い人以外は継続して参加できませんでしたね…

まとめ

僕のやっている読書会の内容と課題について紹介しました。楽しくて勉強になるので、まだやったことのない人はぜひ一度試してみてください。

*1:とはいえ、それでも読みたい!という本はたくさんあるのでそういう時は覚悟を決めて読んでいきます

「技術顧問という働き方」について発表した

Rails Developers Meetup 2018 Day 3 Extremeでの登壇機会を頂いたので、技術顧問という「なんかすごそうだけどよくわからないお仕事」の内容について話をさせていただきました。以前書いたブログエントリをもう少し深掘りして、現状僕が感じている課題感を共有した感じです。

スライドの最後の方でも書いているのですが、僕がやっている仕事(知見を伝えてレールから外れるのを防いだり、外れた軌道を修正する)を生業にするひとが増えるとwebエンジニアの幸せの総量も増えると思うので、「このくらいの内容なら自分でもできるかも?やってみようかな」という人が出てきてくれたら嬉しいなあ。

また、これもスライドに書いてるけど技術顧問と会社とのマッチングに課題があると感じているので、間を取り持てる人や会社がでてくるとよさそう*1*2savanna.io でも将来的にそういうところまで持っていきたいなー。と考えています。

次回のRails Developers Meetupは2019年3月開催予定とのこと。次回はひたすら技術の話をするつもりです(( ⁰⊖⁰)/)

*1:もうあるのかもしれないけれど

*2:ベンチャーキャピタルがそういうのをやりやすい位置にいそう

headless chromeでcookieを扱う方法

poltergeistからheadless chromeへ移行する時に気をつけること - メドピア開発者ブログ の続きです。poltergeistとheadless chrome(selenium-webdriver)でcookieの扱い方が違うので、違いを簡単にまとめておきます。

poltergeistの場合

専用のAPIが用意されています。簡単。

page.driver.set_cookie('name', 'value')
page.driver.cookies['name'].value

詳しくは公式を参照してください: teampoltergeist/poltergeist: A PhantomJS driver for Capybara

headless chromeの場合

headless chromeにはpoltergeistほど気の利いたAPIがありません><ヘルパメソッドを作ってあげるとやりやすいです。次のようなmoduleを作って、適宜includeしてください。

module FeatureHelper
  def cookie_value_from(name:)
    cookies = page.driver.browser.manage.all_cookies
    cookie = cookies.find { |c| c[:name] == name }
    cookie && cookie[:value]
  end

  def add_cookie(name:, value:)
    page.driver.browser.manage.add_cookie(
      name: name,
      value: value.to_s
    )
  end
end

注意

add_cookieする際には、必ず一回はページをリクエストしておく必要があります。つまり

add_cookie(name: 'hoge', value: 'fuga')
visit users_path

のようなコードはエラーになります。適当なページを一度ロードしておくとうまく動きます

visit root_path
add_cookie(name: 'hoge', value: 'fuga')
visit users_path

Railsの可読性の高いコードについて議論するコミュニティを作りました

Railsで可読性の高いコードを書くにはどうしたらいいのか。コミュニティやブログなどで個別の事例について言及されることはありますが、横断的なまとまった情報はほとんどないのではないかと思います。みんな、散らばった情報を集めて自分なりのやり方を模索しているのではないでしょうか。

そこで、自分なりのやり方を研ぎ澄ませるような、可読性の高いコードについて議論できる場所を作ってみました。clean-rails.orgというドメイン*1です。コミュニティ本体はサブドメインのdiscourse.clean-rails.orgで、オンライン上できれいなコードについて議論できるようにしています。

可読性の高いコードを書くのが好きな方、参加してコメントいただけるとうれしいです(\( ⁰⊖⁰)/)

これまでの経緯

はじめの一歩としてGitHubのIssue上で情報やり取りできるかな、と思って試したのですが反応がイマイチだったので、仕切り直して再出発という感じです。

運営に参加してくれる人も若干名募集しています。最近まとまった時間を取りづらいので、いろいろ手助けいただけると><興味ある方は何らかの形で前島(willnet)までご連絡ください。

コミュニティが盛り上がって議論に足る情報が出揃ったら、オフラインでミートアップなどできるといいなーと考えています。よろしくおねがいします(\( ⁰⊖⁰)/)。

*1:名前が強すぎる感じがしますが、jpドメイン高かったのでついorgにしてしまいました…><

技術顧問業を始めて2年がたった

2年ほど前から「フリーランスRails技術顧問」みたいな肩書で複数社のお手伝いをしています。すると知り合いに、技術顧問って実際どんな感じで仕事してるの?と聞かれることが多いので、「これ読めばわかるよ」と言えるように実際にどんなことをしているのかまとめておこうかと思います。

ざっくりどんなことしてるの

お手伝いしている会社によってやっていることが違うので一言では答えにくいですね。基本的に「僕の身につけたRailsとシステム開発の知見を提供する」というのが共通しているところ。僕はCTO経験などないのでエンジニア組織についてはあまり触れず、技術寄りの知見について特化して伝えている感じです。

だいたい次のような会社が対象。全部Railsを使っているか、これから使おうとしている会社です。

  • 創業から数年たち業務が拡大してきたが、負債が溜まって身動きが取りづらくなってきたのでちゃんと体制を整えたい
  • 負債がたまるのを防ぐために、最初から専門家の知見を取り入れて開発したい
  • 多言語からRubyに乗り換えたいが社内のエンジニアにRubyが分かる人が少ない

もう少し具体的に

基本的には週1程度出社して、その間いろいろやりますという契約形態が多いですね。基本リモートでやっている会社もありますが、個人的に出社する方が性に合っているのと、リモートで顧問っぽいバリューを出すの難しいなと思っているので、なるべく出社する方に寄せています。

いろいろやりますの内訳はだいたい次の4つ

  • 技術相談
  • 技術的に難しいところを任せてもらう
  • 社内教育
  • その他

技術相談

一番技術顧問っぽいお仕事ですね。いろいろな相談や質問をうけています。普通にコードレビューもしてます。

  • Aという機能を実装したいんだけど、こういうテーブル設計で大丈夫ですかね
  • Bをする時のgemで一番いいのなんですか
  • Cという機能をつくったのだけど、もっと良い実装の仕方がありそうなのでレビューして指摘してほしい

技術的に難しいところを任せてもらう

相談されたときに「これはちゃんと調べないといけないやつだ」となったらちゃんと時間をとって調べます。たいてい、gemやrailsのソースコードを読んで裏を取って回答することが多いです。

あとは納期的に余裕があって、ある程度実装が難しいと思われる機能は普通にコード書いたりもします*1

社内教育

自分の知見を社内のエンジニアに伝えることで、単純に僕が一人でコードを書くよりもバリューが出るのでは?と思いいろいろやっています。

社内勉強会&読書会

エンジニアチームの技術力向上を目的として、どの会社もだいたい週1、1時間程度を勉強の時間として確保していただいています。もちろん業務時間内です。

読書会で読むものは会社によって異なります。参加メンバーやその時の業務内容見てなにを読むのか決めています。

うちも読書会やってみたい、という会社にオススメしたいのはRuby on Rails ガイドの読書会です。web上にあるので購入稟議などを通さずに始められ、かつRails始めたての人から経験の長い人まで幅広い人が学ぶことができます。Railsを数年やっていても「あーこの機能知らなかった!」となることがあるのですよ。

読書会をやるときはたいてい輪読形式で、かつ予習の必要のない形でやっています。キリの良いところまで誰かが音読し、内容について話し合い、次の人がキリの良いところまで音読する、というような流れ。なので一冊読みきるまでに数ヶ月かかるのですが、参加者の業務の忙しさや知識レベルのばらつきを考えるとこのやり方がベストかなと思っています。扱う題材や参加者によっては別のやり方を取ることもあります。

社内勉強会も会社によっていろいろです。以前お手伝いしていたFiNCさんではOSS活動をやっていく勉強会をしていました。詳細は@ota42yさんがスライド上げてるのでそちらを見てもらえれば。

ペアプロ

ペアプロを通じて、普段僕がどんなことを考えながらコードを書いているのかを共有しています。これは最近始めたので効果の程はまだまだ未知数。

ペアプロ以前は、新しい機能を作り始めるときにお手本となりそうな感じでコードを書いたり、既存のコードをリファクタリングすることで知見を伝えようとしていました。たいていのプロジェクトでは一番最初に作成されたコードがお手本となり、そのやり方がいろんなところにコピーされる宿命なので、最初にちゃんとしたお作法で書くのがとても費用対効果が高いやり方です。が、前述したとおり僕は週1程度のコミット量なのでタイミングが合わずにお手本を書くより前にまずいお作法のコードが大量生産されてしまうことが多いのでした><。なので代表的な箇所をリファクタリングして「こういう風にやるといいんですよー」と啓蒙するのをやっていたのですが、やってみた結果あまり良い感触が得られなかったので、ペアプロでじわじわ知見を伝えていくのが良いかなあと思い今に至るのでした。

別件で、多言語からRubyに移行したい会社さんから、お手本となるRailsアプリケーションをまるっと作る、というお仕事を請けたことがあります。こういうケースだと、「最初からちゃんとしたお作法で書く」がワークしやすいかもしれません。

その他

技術ブランディングのお手伝いもしています。たとえば技術ブログに寄稿したり、その会社の主催する勉強会に登壇したりとか。

あとは採用についてアドバイスしたりもしています。どうやったら良いエンジニアを採用できるのか、というのは非エンジニアの人にとっては馴染みがない領域ですよね。具体的にどのようにやるとよい(と僕が考えている)かは別エントリでまとめようと思っています。

いまの課題

これまでのお仕事は基本的に知人からの紹介で決まっていますが、共通の知り合いのいない、Rubyコミュニティなどから遠い会社にこそ大きな技術顧問需要があるのだろうな、と思っているのでその距離をどうやって埋めると良いのかな、と考えたりしています。

あとは上の方でも少し書きましたが週1程度のコミット量だと細かい問題についてはスルーせざるを得ないのがうーん、という気持ちになりますね。だからといってうまい手段はないのですが…。

技術顧問業をやっての所感

最初は「技術顧問業の需要ってあるのかな」と思いつつやってましたが、2年やった結果、技術顧問を潜在的に必要としている会社はそれなりの数あるのだな、という結論に至りました。

特に、ベンチャー立ち上げの時期に、週に数時間でも良いので知見のある人にアドバイスを貰えると、明らかな落とし穴やまずい設計を避けることができ、数年後の開発効率に大きな違いが出るのではと思います*2

もっと技術顧問をやる人が増えたり、技術顧問を採用する会社が増えると良いですね。

*1:簡単なコードでも依頼されれば書きますが

*2:ただし数年後に会社が存続しているかわからないベンチャーが顧問を頼めるか、を考えると現実的でないでしょうね。ある程度お金に余裕があるところ限定かも