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

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

社内読書会のススメ

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

社内読書会の流れ

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

Rails Developers Meetup 2018でモデレーターをした

Rails Developers Meetup 2018の最後のセッション「基調Q&A」でモデレーターをしてきました。

事前に皆さんから集めたお便りとビールを元に、日本が誇るRailsコミッターたちにいろいろ話してもらいました。40分があっという間に過ぎた感じでしたね。前回のぎんざRuby会議の基調Q&A同様、楽しい時間になりました。

他の発表も面白いものがたくさんで充実した二日間でした。Railsを使っている人や企業が実際にどう開発を進めているのか、何に苦労しているか、何を頑張っているのかの実例をたくさん聞いてモチベーションが高まると同時に、自分の向いている方向は間違ってないのだな、と勇気づけられました。

最近時間がなかったので登壇や勉強会の参加などを控えてたのですが、なんだかんだあり結局フルで参加＞＜。でも参加した以上の価値があったなと思います。

次は時間を作ってなにか喋ろうと思うのでよろしくお願いします (\( ⁰⊖⁰)/)

定期的にyarn updateするには

ライブラリは定期的かつこまめにアップデートすることで辛さを減らしていく、というのは最近の開発現場では定説ではないかと思います。Railsプロジェクトの場合、Gemfileの定期更新を実施している現場も多いのではないでしょうか*1。

最近のRailsアプリケーションはjsライブラリの管理にyarnを使っているところが多いかと思いますが、これもGemfileと同じように定期的にアップデートしたいところです。

商用のものもいくつかありますが、僕は普段使っているCiecleCIを活用して定期的にyarn updateしています。

使っているツールはこちら。CiecleCIに限定されているわけではないので、定期実行できる環境さえあればどこでも活用できると思います。

taichi/ci-yarn-upgrade: Keep NPM dependencies up-to-date with CI, providing version-to-version diff for each library

設定の仕方

CiecleCIの設定は次のような感じでやっておきます*2。

version: 2
jobs:
  yarn-update:
    docker:
      - image: circleci/ruby:2.5.0-node-browsers
    steps:
      - checkout
      - run: sudo sh -c 'echo "deb http://ftp.us.debian.org/debian testing main contrib non-free" >> /etc/apt/sources.list'
      - run: sudo apt-get update
      - run: sudo apt-get install -y git
      - run: yarn global add ci-yarn-upgrade
      - run: GIT_USER_NAME=your_github_user_name GIT_USER_EMAIL=your_email@example.com `yarn global bin`/ci-yarn-upgrade --execute

これとは別に、GitHubのpersonal tokenを取得して、GITHUB_ACCESS_TOKENをCircleCIの設定画面で設定する必要があります。

設定のあと、yarn-updateジョブを実行するとこんな感じのPRができます。

image.png (258.0 kB)

定期実行のやり方

定期実行のやり方はいろいろありますね。常時使える、かつcronが使えるマシンがあればそこからCircleCIのAPIをたたいてもよいです。

Running Jobs With the API - CircleCI

herokuを使って定期実行する

僕はつい最近までherokuのschedulerを使っていました。

herobu という、拙作のシェルスクリプトをherokuにデプロイしておくと、heroku schedulerでCircleCIのAPIを定期実行できます。

毎日PRがくるとちょっと頻度が高すぎるので、週に一回だけPRを作るようにしたいのですが、heroku schedulerは週一回の実行をサポートしていません。

そこでシェルスクリプト側で工夫しています。次のように登録しておいて、土曜日に実行されたときだけAPIを叩くようにしていました。

DAY=6 JOB=yarn-update PROJECT=willnet/savanna ./fire2.sh

詳細はソースを見てください(大したことはしてません)。

circle ciで定期実行する

CircleCIのv2からはWorkflowという仕組みができたので、サーバレスでジョブを定期実行できるようになりました。workflowの仕組自体はジョブを組み合わせて一つのワークフローを定義できるというものですが、一緒に定期実行の機能も追加されています。先程のyarn-updateというジョブを定期実行するworkflowは次のようにして定義できます。

workflows:
  version: 2
  yarn-update-scheculed:
    triggers:
      - schedule:
          cron: "5 0 * * 0"
          filters:
            branches:
              only:
                - master
    jobs:
      - yarn-update

これで毎週日曜日の9時5分にジョブが実行され、定期的にyarn updateできるようになりました。やりましたね。

まとめ

CircleCIを利用してyarnを定期的にアップデートするやり方を紹介しました。CircleCI以外でもいろいろやり方はあると思うので、自分なりのやり方でライブラリを最新に保っていくと良いのではないでしょうか。

*1:Gemfile更新用のツールは商用、OSSでそれなりの数あり、情報も多いので適当にググってください

*2:jobの中でgitをインストールしているのは、たしかCircleCIのイメージ内にあるgitのバージョンが古くてうまく動かなかったからのはず