RailsによるWebサービスの開発があり、それが一段落しましたので、経緯と結果について報告させて頂きたいと思います。開発がメインだったのですが、完全新規のWebサービス開発の案件が始まるということで、技術調査を行うことにしました。訳あって決定権は私にあったのですが、技術調査を行う前に、まずジョイン予定メンバーから、どんな技術を使ってみたいか、アンケートを取ることにしました。結果を見ると、Railsが多いということがわかりましたが、今からRailsは技術チャレンジとして適切なのか?と考え、第二案であるAngular2+Goを調査しました。Goはともかく、調査当時(2016年6月)のAngular2はリリース前で、かつ、RCの状態から大幅な改修が入っていたこともあり、「恐らく大丈夫だとは思うが、本当にこれと心中して大丈夫なのか?」という感想になり、見送ることにしました。現在ならまた別の判断になるかもしれません。それ以外にも、「そもそもSPAが必要なサイトなのか?」とか「Goの他メンバーの経験の少なさを納期的にカバーできるか?」という問題もあったので、今回は見送ることにしました。Railsに戻ります。当時5.0が出る前後だったので、タイミング的に丁度よく、かつ「ノウハウが足りなくても検索すると何か出てくるだろう」というユーザー数の多さを理由に採用することにしました。まとめると普及度が高いメンバーからのリクエストという2点によるものです。これ以外にも、インフラレベルで面倒が見れるかという点も焦点になりますが、そこは複雑な仕組みにしなければ大丈夫だろうと判断し、採用しました。その判断ロジックは正しいのか?技術選定についての議論はいくつかありますが、私は「業務を完遂できること」が最優先だと考えています。その中で、出来る限りの有意義なチャレンジを用意するというのが、正しい技術選定ではないでしょうか。Railsということもあり「UUUMは技術チャレンジをしない会社なのか?」と思われてしまうかもしれませんが、Rails経験が少ないメンバーがRailsに挑戦するのも十分なチャレンジだと思いますし、その中で行われたことは言語の選択問わず有用な経験になっていると思います。等の静的検査の整備、テスト及びCIの準備などです。メンバーが入ってきた時に品質をブレなくさせることが重要です。ベースにカスタマイズしたルールを使用しております。overcommitを使うことによって、全員がコミット前チェックするようになり、コードレビューでの手間が大幅に削減されました。ルールについては、「ルールのためにソースを修正することがあまりに多い」のは不毛なので、適宜見直しを行っています。入れることにより、CIまで回さなくても静的検査を各メンバーが自主的に行えるようになっており、CIで静的検査に引っかかることはほぼない状態になっています。組み合わせで行うことにしました。}だけ覚えれば書けるという手軽さを重視しました。テストの書き方について聞かれることはほとんどなかったと思います。初期の時点である程度のテストを書いておくことで、メンバーが入ってきた時にテストの書き方がわかるようになります。このあたりを序盤でしっかり時間をかけておくと、後半でもペースが落ちなく、クオリティを保ったまま開発を続けることができます。フロントエンドについて今回の案件はあまりフロントエンドで凝ったことをするものではないので、SPAなどのような凝ったものは導入していません。パイプラインもSprockets任せにすることで、初期の環境構築の手間を削減しています。フロントエンドのライブラリの導入はnpmに任せてます。turbolinksは辛かったので切りました。フロントエンドに関しては様々な議論が展開されていますが、通常のWebアプリケーションでそこまで凝った動作をするものでなければ、無難にRailsに乗っかっておいたほうがいいのではないかと思います。リリース初期で凝るのはYAGNI原則違反になる可能性が高いので、初期はRailsに乗っかっておき、サービスが成長してフロントエンドの重要性が高まってきたらRailsから切り離すというような運用が良いのではないかと思います。責任を持つフレームワークや周辺ライブラリを選定した人は、その選定に一定の責任を持つ必要があります。Railsのような巨大フレームワークを全て把握しておけというのは難しいですが、「何故それを選んだのか」「それを使うことによりどのようなメリットがあるのか」「他のものでは駄目だったのか」「メンテナンスされているのか・今後もメンテナンスされる見込みがあるのか」というのを的確に説明できる必要があります。既製品があるにも関わらず自作するような場合は注意が必要です。良かったことぐぐると情報が出る当初の狙い通りですが、さすが有名フレームワークだけあって、情報がとにかく多いです。ほとんどのケースで検索だけで解決することが多く、コミュニティの層の厚さを実感することができました。技術者としては未知の技術を開拓していくという楽しみもありますが、短時間で効率よく開発するためには良かったと思います。ライブラリが充実しているとにかく有用なライブラリが多く、開発の快適さは圧倒的でした。開発時のデバッグなどで効果を発揮するライブラリが充実しており、問題が起こった時でもすぐ調査することができました。良くなかったことソースが追いづらいRubyの仕様上の問題ですが、困った時に該当の定義がどこにあるのかというのが非常に追いづらいです。ブレークポイントなどのデバッグ機能をフル活用することでカバーできるものの、やはりRails本体のコードを追ったりする時は辛いと感じました。ライブラリが多すぎるgithubでスターが多いライブラリでも、有用でないもの、バグがあるものなど、使えないもの、最新バージョンに対応していないようなものが多く、自作したほうが良かったものもいくつかあります。Wayがわからず、苦労されられることが多いと感じました。メンバーが揃って口にするのは「慣れるまでは大変だけど、慣れると楽」ということです。まとめ我々のような少人数ベンチャー企業で、スピード感を出して開発するにはRailsは最適ではないかと思います。逆に、一般的なWebアプリケーションでないもの、最初から大規模・高負荷になりそうなものは、Railsでできなくはないものの、他の選択肢も検討すべきかと思います。RubyであればRails一択かと思いますが、もちろん他言語を選択してはいけないというわけではないので、結局はチームメンバーの希望を重視しつつ、筋の良い選定をするということが重要になるのではないでしょうか。今回は特にメンバーの希望を重視したため、メンバーからは好評でした。UUUMでは、これからもエンジニア全員で話し合って、適切なチャレンジを行っていきたいと思います。Design(デザインブログ)はてなブログをはじめよう!uuum-staffさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。