クラウドワークスの沢田と申します。普段は主にデータ分析的な仕事をしています。得意言語は Ruby なのですが、商売柄と言うか、ここ最近よく使っているのは Python と SQL です。どうしてこうなった。ちなみに、お気に入りの Elixir の演算子は |> です (誰も訊いてない)
すでに別エントリーでも紹介があったように、バグ修正を主目的としたハッカソンをエンジニア有志で開催してきました。当日の様子は弓山さんによるエントリーを見ていただくとして、こちらでは「やってみてどうだった？」というところをご紹介できればと思います。
余談ですが、件の弓山さんのエントリーは、ハッカソン前日までにだいたいの骨格は書かれていて残るは写真をいくつか並べるだけで済むように周到に準備されていたという機密情報をここで暴露しておきます :p
ハッカソンの概要
簡単にまとめると、こんな感じのイベントでした。
- 2/6 (土) の一日だけの開催。日帰りです。
- 鎌倉にある古民家が会場でした。
- テーマはバグ潰し。機能追加とかは行わずに、ひたすら既知のバグを潰していくことに特化します。
会場について
鎌倉駅から徒歩だと20分ぐらいの場所にある、古民家を再利用した貸しスペース 鎌倉 Co-Minka を利用しました。基本は日本家屋なので、畳の部屋に座卓と座椅子がいくつか置いてあるような部屋を想像していただけれれば。参加メンバーの印象としては、程よく非日常感もあって、なんだか「合宿に来た」感が出ていて良かったと、概ね好評でした。
と言いつつも、モノが日本家屋の古民家だけに、なんでも至れり尽くせりというわけではなく。
(場所によっては) ちょっと寒い
暖房器具も置かれていたし、隙間風が気になるようなこともありませんでしたが、陣取った場所によっては少しばかり寒く感じることもありました。お好みで膝掛けとかショール的なものがあると良かったかもしれません。その一方で、エアコンの風が直撃する場所に座ってしまった人は「暑い」と言っていたので難しいところですね。見ていた感じだと、人の移動はあまり多くなかったものの、誰かが休憩で留守にした隙にポジションを変える人がちらほらいた印象です。
腰に来る
畳に座椅子 or 座布団ですので。長時間同じ姿勢で作業していると腰への負担はけっこうあります。適度に姿勢を変えるなり休憩を取るなりするのが良さそうです。反面で、ちょっと姿勢を変えると寝転がって作業という状態にシームレスに移行できるというメリットもありまして。特に午後の時間帯は「おまえの自宅かよｗ」と突っ込まれそうなリラックスした感じになっている人も現れたり。
ちなみに僕はと言うと、縁側近くの窓際にベンチ的な椅子が置いてあったのをこれ幸いと陣取っておりました。これだと腰に来る心配は少ないですね。
その他には変わり種で、押入れを開けて上の段に PC を置く形にして、さらにその前に椅子を置けば快適な作業スペースが作れるのではないかと挑戦する人も。残念ながら「押し入れを開けっぱなしにすると寒い」問題が発覚して敢えなく頓挫。
WiFi の接続数に注意
総勢15,6名だったのですが、会場にある WiFi のキャパシティがギリギリだったみたいです。一部には繋がらない人もいて、自前の回線を使っていたりしました。知識の大半をネットの向こう側に置いてあってインターネット接続がないと詰むという方は、万が一に備えて自前の回線を持っておくぐらいが良いかもしれません。
休日開催の是非
今回のイベントは土曜日に休日出勤の形で行いました。休日出勤なので、もちろん代休も取れます。あ、これは「ブラックじゃないよ」アピールでございます :)
敢えて休日開催にした理由の一つは、「不在になる日が適度に散らばる」からでした。仮に平日に敢行したとすると、普段の営業日の中に「エンジニア陣の大半が不在である」という真空地帯が現れてしまいます。これだと非技術職の人の立場から見ると、些かの不安が生じるところでもありますね。
その点、休日出勤→あとで代休を取るという方針だと、代休を取るタイミングは人それぞれで適度に散らばることになります。結果「エンジニアが一斉にいなくなる」という時間帯はなくなって (or 軽減されて)、印象がぜんぜん違う。周りのメンバーにも配慮された開催方針だったと思います。
あと、やはり休日だと割込みがほぼないのが何よりのメリットになります。平日だと何かと業務依頼が来たり会議があったりしますが、休みの日はそういう心配はほぼないので集中できます。
ちなみに、休日というだけでなく「ちょっと遠出する」というところもポイントで、参加メンバーの中には往路でグリーン車の座席を確保して車中でバグを倒し、現地に着くまでに一つ pull request を出しておくという猛者まで現れました。しまった。その手があったか。
工夫したこと
テーマを決める
単なるハッカソンじゃなくて、厳密に「バグを倒すこと」に特化しました。機能追加とかリファクタリングとか、やりたいことはいろいろあるのですが、今回はバグ潰し。しかも、当日中に pull request にしてレビューを完了するところまでが目標。さすがに当日にリリースするのは避けましたが、それでも「週明け月曜日にはすぐにリリースできるようにしておく」というところがゴールです。
テーマがここまで明確に決まっていると、事前に何を準備しておけば良いかも自ずと見えてきます。
事前に準備したこと
まず、倒すべきバグをリストアップしました。対象になるのは、「すぐに直さないといけないほど緊急性はないけど、それゆえに後回しになっていたもの」が中心になります。Redmine に積まれていたチケットなどを洗い出してスプレッドシートにまとめていく感じにしました。
次に、出揃ったバグのリストから、各人が倒そうと思っているもの・倒せそうなものを選んでいきます。こちらもスプレッドシートの「担当者」列に自分の名前を入れて「これやります」と宣言する形ですね。こうすることで、作業が衝突することを回避できるようになるという次第。
自分が倒すべき獲物が確定すれば、今度は調査や下準備に入ることができるようになります。具体的には、再現方法を確認したり、再現する方法がわからない場合はそのバグを見つけた人に詳細を訊いてみたり。
というようにして、開催前日までに準備が進んでいれば、当日はもう修正作業をするだけという状態になります。これならグリーン車に乗っても元が取れると :)
また、事前に準備しておいたバグ一覧的なスプレッドシートは、当日には進捗状況も見える化し、pull request を出したものはその URL も記載しておくようにします。こうすることで、一覧のシートを見ればレビュー待ちの案件が一目瞭然となってレビューも進みやすくなり、ゴールであるマージ可能状態までいち早く辿り着けるようになります。
などなど、事前に入念に仕組みを考えて準備しておいたのが功を奏して、当日はかなり効率的に作業を進めることができていました。 結果としては、1日で出た pull request は全部で45でした。普段の業務で出ている数だと20〜25ぐらいなので、かなり多いです。
勝因をまとめると、
- テーマを厳密に決めて
- 効率よく作業できるように仕組を準備しておき
- 調査などは事前に片付けておいた
ということになります。
ふりかえり
普段は触らない箇所のコードを見られた
日頃はインフラ周りの業務がメインの人とか、データ集計・分析をやっている人 (これは僕ですね) にとっては、サービス本体のコードを見るという機会はあまり多くありません。そういう立場の人にとっては、丸一日かけてコードを追えるという良い機会になっていました。反面で、コードレビューはやや後手に回りがちだったという反省点も。特に業務ロジックに関わるようなところは慣れていないだけに手を出しづらい面はありました。
また、コードに慣れていなと、どのバグを倒すのか選ぶときにも「これは果たして1日で片付けられるものだろうか？」というのが読みにくかったり。僕の拾ったやつは、実際に着手してみたら意外と難しいことが分かって、やや苦戦しました。バグを洗い出したついでに難易度とかもついていると選びやすかったかな？とも思いましがが、やはり普段からコードを眺めておくのが大事ですね。 というわけで、個人的な思いとしては、今後は「一日1レビュー」を目指して頑張ろうかなと。
後半戦がちょっと減速気味だった
午前中とかはまだみんな元気ですし、事前準備で簡単そうなバグを先に倒すように予定を組んでいた人もいたりして、そこそこ活発に pull request が出ていましたが、昼過ぎあたりからやや減速気味になっていました。簡単そうなやつはあらかた片付いてしまって難易度高めのものに取り組んでいる人が増えたのと、ずっと座りっぱなしは疲れるという事情もありそうです。これについては、次からはタイムキーパーを立てるなどして適度なタイミングで気分転換できるようにすると良いかも、という案が出ていました。たとえば、「この時間はみんな実装の手は止めてレビューする」とかにしても良さそうです。
今後に継続 or 挑戦してみたいことなど
テーマ縛り
たとえば「特定箇所のリファクタリングをみんなでやる」とか「ある機能の実装をみんなで頑張る」みたいなテーマでも面白いかもしれません。
チーム制
今回は、一人ひとりが単独で作業する形にしていましたが、一方で「ペアプログラミングとかもやってみたかった」という声もありました。一人だと黙々と集中できる利点もありますが、複数名で組むと各人の得意なところで互いに補いあったりして理解が早く進むこともあるので、これはこれで良さそう。ということで、チームを組む形式のハッカソンもしてみたいという意見が出ていました。
合宿
今回は日帰りでしたが、泊まりの合宿も挑戦してみたいという意見が出ました。泊まりだとやはり時間は長く取れますし、1日では片付かなそうなテーマに挑戦する余地も出てきそうです。実際、温泉宿でサービス開発合宿しようという話が進行中で、こちらは近いうちに実現しそうな見込みです。(その折には、たぶんまた誰かがブログでご紹介すると思いますので乞うご期待)
個人的な経験からすると、泊まりの合宿をすると、昼間の勢いで深夜遅くまで開発を続けて→翌朝は電池が切れているというパターンを辿る人が多い気がするのですがｗ
まとめ
- 予めテーマを決めて且つ事前準備をしておいたおかげで捗った
- ちょっと遠出して、集中できる環境で作業できたのが良かった
- 行きの電車ではグリーン車に乗れ
今回のハッカソンで得た知見や反省点を活かしつつ、また次の機会に繋げられればと思います。
最後に
完全に余談なのですが、Rails アプリケーションに詳しい人はご存知の通り、核になるモジュールはプロジェクトの名前が付けられています。クラウドワークスの場合だと当然 CrowdWorks になりそうなものですが、諸般の事情によりまして Crowdwork になっております。複数形の s がない。
これが長年の懸案事項となっていて、社内 Redmine のチケット番号 #42 に「Crowdworks」に改名するという案件が積まれたままになっています。なぜ直っていないかと言うと Rails 特有の事情で、単数形を複数形に変えるといろいろとややこしい問題が噴出するためです。実際、テストがいくつか落ちるようになるのですが、なかなか根深くて誰もまだ修正に成功していません。
とりあえず放置しておいても害はないのですが、いつか直したい。今回のハッカソンでは対象外にしました。バグではないので。とは言え、いつか Crowdwork 問題の解決を唯一のテーマにしたハッカソンやりたい (おおげさ)
そのようなわけで、クラウドソーシングのクラウドワークスでは Crowdwork を Crowdworks に直してくれるエンジニアを募集しています。腕に覚えのある方はぜひ、ご連絡をいただけると嬉しいです。
