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。
もっと技術顧問をやる人が増えたり、技術顧問を採用する会社が増えると良いですね。
