Reports

Why Choose Ruby on Rails?に参加しました。

 Author:fumiyasac

20140510

ゴールデンウィークも明けて休みボケが若干残っている中ではありましたが、久しぶりに勉強会に参加しました。普段はPHP(CakePHP)をメインにしているのですが、Ruby On Railsでも自分で何かサービスを作ってみたいという思いもありまして今回参加しました。

1. 技術的なTips紹介というよりもRailsの導入事例とその奥にあるもの

今回のメインはRailsを採用するに至った経緯の紹介やサービスの裏側の紹介がメインの勉強会でした。
最近ではRailsを採用している企業さんも、自分がITの仕事を始めた当時に比べて増えましたし、勉強会やコミュニティ・開発手法のTipsも多くあるので、Web/アプリのサーバーサイドにも積極的かつ前向きに採用されつつあるんだなと自分の肌で感じることができたように思います。

2. 内容のアーカイブ

以下、自分がまとめた今回のアーカイブになります。

第1部 名刺管理アプリ「Eight」を育てるチームと技術 宍倉功一さん
(SanSan株式会社)

■理由:素早くユーザーへ価値を届けるため

・Eightの使用技術
Ruby on Rails
Sinatra
Rubyスクリプト

<Railsを採用した決め手>
1. Webアプリケーションをシンプルに作る
2. 周辺ツールが充実している(ライブラリがたくさんある・コミュニティが活発)
3. 爆速開発

※2013/12時点(現在ユーザー数50万人)

<サービスの成長で起きた問題>
1. 大量の名刺データ化処理
(Amazon Simple Workflow Service)
2. 新規サービスを迅速に
(Amazon Relational Database Service / Amazon Dynamo DB)
3. DBデータの増加
(Spider for MySQL)
※テーブル単位でのDB分割
※IDのレンジでの水平分割
※検索要素での垂直分割

・解決策
1. AWSの採用
2. DB分散

・DB分割の概念参考資料
http://www.slideshare.net/infinite_loop/socialgame-db-slice

<チームビルディング>
・仕様策定ミーティング(仕様の理解を深める)
・実装検討ミーティング(全員で見積もり、設計)
・Github(Ver管理)にRSpec(単体テスト)でtopicブランチで数日で開発→レビュー→Masterへマージ
・施策Feedbackミーティング(次のイテレーションへつなげる)

第2部 Railsとアジャイルで変える受託開発
(株式会社メンバーズ)

■理由:マーケティング+技術

北海道Likers
http://www.hokkaidolikers.com/

2週間でのPDCA運用(打ち合わせにはプログラマも参加)
アジャイル開発 ※見える化、KPI意識

・AWS, Git, JIRA, Jenkins等も使用している

・TDD (RSpec) に関する本
http://www.amazon.co.jp/RSpec-Book-Professional-Ruby-Series/dp/4798121932

・課題点
ブランチ開発上では、非エンジニアが確認しづらい。
→deap(自社独自の取り組み:sinatra)を使用している

CIに重きを置くようにしている。
(開発者としてのマインド)
1. 開発者もユーザーとクライアントの声を聞く
2. 一体感のあるチームづくり
→受託開発でも目的ややりがいが持てるように!(Rubyとアジャイルをもって)

第3部 変化を産み出すための組織文化作り
株式会社FeedForce

■変化について
・スクラム(アジャイル開発の手法の一つ)との出会い
・具体的な取り組み
1. ブラウンバッグミーティング
2. コミュニケーションツール(Qiita, HipChat)
3. 読書会

■キーワード
・管理より信頼
・クローズよりオープン
・上司の査定より同僚の賞賛

第4部 国内最大級のクラウドソーシングサービス「クラウドワークス」のつくりかた

■理由:高い生産性と人材確保

1. 高い生産性
・Ruby on Rails
→あらかじめ必要なものがある(サービス開発に集中)
・豊富なライブラリ群
→スピード重視で使えるものはすべて使う(サービスのキモは自前で)
・メタプログラミング
→柔軟にフレームワークを改造可能(やり過ぎ注意)

2. 人材確保
・ソースコードによるスキル判別がしやすい
・Railsっぽく / Rubyっぽく書けているかの審査にもなる。

<よかった点>
・早期立ち上げとニーズへ迅速に対応
・管理機能とサービスも合わせて作り込み
<改善すべき点>
・機能の増加と密結合
・RubyやRailsが最新バージョンに追いついていない

・Github, Redmine, ChatWork, Semaphore
・レガシーコードの改善
・RedShiftの導入(KPI採取等)

<これから始める方へ>
・CIやテスト、本番、ステージング環境の構築自動化を後から入れるのは大変。
・Deployment Pipelineをはじめに考えてからサービスを作ろう!

アーカイブをまとめていた時に思った雑感にはなりますが、「開発スタイルも提供するサービスもエンジニア自身が納得できる形」を実現することにも注力している感じがしました。
むろん他の言語やフレームワークでも実現可能ではあるのですが、どんなプロダクトであっても作り手自身の納得度合いが出るので、その部分にも意識が向いているのは本当に素晴らしいことだと思います。

イベントのURL

3. 自分よりも若い技術者との出会い

久しぶりに自分より若い世代が多く集まる勉強会に参加したので、とてもよい刺激をこちらを頂くことができました。彼らの純粋でなおかつ自然な意識の高さや作ることを楽しむモチベーションには本当に頭が下がりますし、エンジニアって職業は本当に深いと思った瞬間でした。
キャリアの長さの延長に頼るだけではなくて、常に知識や好奇心は維持して、楽しむことを忘れないようにしようと思います。