Railsでのバックグラウンド処理を考える

こんにちはCDOの山下です。

今回は、新規サービス開発にあたりRailsのバックグラウンド処理について考えることがあったので記事にしようと思います。

現状のRails環境下でのバックグラウンドジョブ

Railsでバックグラウンドジョブを扱うといえばresquesidekiqが有名で多くのサービスでも実運用で使われていると思います。弊社の主力であるANDPADでもサービス開始当初からsidekiqが使われてきましたが、Redisを仲介してジョブを処理するサーバーをアプリケーションサーバーとは別で運用する必要がありサービス規模が大きくなるにつれてインフラ管理コストが負担になってきました。

f:id:oct88:20200312210620p:plain

図1:sidekiqのインフラ構成

主な利用用途としては、以下に上げるようなもので、数10msecで終わるようなものから数時間単位で終わるものまで様々な処理がバックグラウンドジョブに放り込まれています。

主な用途

  • リアルタイム通信連携(10msec~1sec)
  • 外部連携(10msec~1sec)
  • 画像処理、加工(100msec~10sec)
  • インポート、エクスポート系処理(1min~6h)

また弊社では、新規で開発するサービスに関してはマイクロサービスとしてkubernetes(k8s)のクラスタ環境にアプリケーションをデプロイする機会が増えてきましたが、バックグラウンドジョブを今までのsidekiqサーバーに相乗りしていくと加速度的に負担が増えていく状態になるため別の方法を検討し始めました。 

SQS + Lambdaでバックグラウンドジョブを処理する

2018年6月よりAWS LambdaのイベントリソースがSQSに対応したことからSQSにenqueueしたイベントからLambdaを起動して処理をすることが可能になりました。Lambdaの実行時間も最大15分に拡大していることからインポート、エクスポート系の処理以外はLambdaに移行しても問題なさそうな雰囲気です。弊社では、新規サービスと既存サービスで切り出しやすそうなところから徐々にSQS + Lambdaの構成にバックグラウンドの処理を移行し始めています。serverless frameworkを採用することでLambda関数のデプロイを簡易に実行できるようになっています。

f:id:oct88:20200313094640p:plain

図2:SQS + Lambda構成

SQS + Lambda構成のメリット・デメリット

SQS + Lambda構成のメリットとデメリットを上げておきます。Railsエンジニアにとっては開発負担が増えるのでより良い方法はないかと色々模索しましたが、サーバー管理の必要のないスケーラブルな構成はとても魅力的だなと感じています。また、Lambdaの実行時間制限があるので既存のバックグラウンド処理の全てを網羅できなかったのが悩ましいところです。少し時間のかかる処理(インポート、エクスポート系の処理)は別の方式を模索中です。

メリット
  • スケーラブル
  • 従量課金になるのでコストが抑えられる
  • 言語の選択肢が広がる
デメリット
  • Railsでまるっと管理できなくなる
  • 簡易にアプリ側の資産を使えなくなる
  • Lambdaの実行時間制限(15分)があるので全てを解決できない

まとめ

Railsのバックグラウンド処理の作り方としては、世の中にsidekiqやresqueなどの定番的なものはあるもののインフラ的な側面ではコンテナ化やサーバーレスなどRailsの枠を超えた選択肢もありなかなか悩ましいなと思ってます。k8sクラスタの中にバックグラウンドを処理するコンテナを抱え込む方法も模索はしていましたが、管理コストが上がるので結局断念しました(より良い方法があるよって方は是非情報交換しましょう)。今回この方式を採用するデメリットとしては、今までRailsの中で書けていたバックグラウンドの処理をLambda実行用に別に記述しなければいけなくなったことがあります。ただ、言語の制限なく実行できるという面ではメリットにもなっています。Railsエンジニアとしては手間が増えることも事実ですが、SQSやLambdaをうまく使うことで関心が分離されスケーラブルな構成に少しずつできていければと思っています。

 

ピンポンゲームで学ぶ、アジャイルな「見積もりと計画づくり」

「見積もりと計画づくり」を学ぶ会を開催したよ

エンジニアのからまげです。

先日、アプリチームで、アジャイルな「見積もりと計画づくり」を学ぶため

ワークショップを開催しましたが、今回は「ピンポンゲーム」を行いました。

 

みんなでワイワイ楽しく盛り上がりましたので、その様子をリポートさせていただきます。

f:id:karamage88:20200219173950j:plain

 

ピンポンゲームとは

ピンポンゲーム(正式名称:Ball Point Game)は、アジャイルスクラム開発の体験の定番のワークショップのひとつです。 

 

ゲームの目的 

「ピンポンゲーム」の目的は、1分間で、できる限りたくさんのピンポン球を、チーム全員でパスし、触ることです。

 

ゲームのルールと進行方法について

ルール

  • 全員が大きなチームの一員となる(今回の参加者は6人で1チーム)
  • チームの全員が、ボールに触れなければならない
  • 全員が触ったピンポン球が「リリース可能なプロダクト」とする
  • ボールをパスする際、空中に浮いている時間がなければならない
  • 「リリース可能なプロダクト」を最大化するために「見積もりと計画づくり」を行う
  • 全部で3回のスプリントを行う

進行方向

  1. チームは、スプリントの最初に2分間「見積もりと計画づくり」として、チームのプロセス方法や作業計画を決める
  2. チームには、いくつの「リリース可能なプロダクト」を達成できるか、数を見積もる。
  3. 1分間のワークを行う。
  4. プロセスを改善する方法を議論するため、チームに1分間、「ふりかえり」の時間を与える。
  5. 3回のスプリントを繰り返す。

 

実際のゲームの様子

まず見積もりと計画を立てよう

「見積もりと計画づくり」を話し合うチームメンバーたちの様子です。全員、やったことないことに対して、どう見積もるか悩んでいます。結局、当てずっぽうで、「30個ぐらい」 と見積もりました。

f:id:karamage88:20200219173959j:plain

 

ワーク開始! 

実際に、1分間のワーク開始!

 

近くに集まって、小さな輪を作ってパスしていく作戦のようです。

でも、受け取りそこなってポロポロ落としています。

f:id:karamage88:20200219173943j:plain

 

 一度に受け渡す量を増やすと、ボールをこぼすリスクも高まります。

f:id:karamage88:20200219174010j:plain

 

ふりかえり! 

ワークを終え、2分間の「ふりかえり」の様子です。みんなでカイゼン案を話し合っています。ボールをこぼしすぎたので、「もっと近づいて受け渡す量を調整したほうが良い」といった意見がでました。

f:id:karamage88:20200219174021j:plain

 

結果発表 

以下は、3スプリント回した時の「実績値 /  見積もり  」です。

f:id:karamage88:20200219174031j:plain

 

  

ワークショップを終えて、学んだことまとめ

  • 初回見積もりは、当てずっぽうになるから、大きく外しやすい
  • やったことないことは見積もれない
  • スプリントを回すほど、見積もりが収束してくる
  • ふりかえりでカイゼンすることによって生産性があがる(下がることもある)
  • 継続的に同じやり方を繰り返すことによって、だんだん早くなる
  • やり方を変えるのは大きな不確実性があるが、抜本的なカイゼンを生むことがある
  • 見積もりは前回実績が最も頼りになる見積もりの根拠になる

 

以上が、今回の学びです。

 

みんなで盛り上がって楽しかったですね〜

 

皆さんも一度この「ピンポンゲーム」を試してみてはいかがでしょうか?

 

認証機能追加を、ユーザーストーリーマッピング的なもので整理してみた!

はじめに

初めまして!オクト デザインチームの小久保です。

普段は、グラフィックデザイン(パンフレットなど、主に紙の制作物)からUIデザインまで、幅広くデザインに携わっています。

 

その中でもUIデザインは、ユーザーがやりたいことを、ストレスなく達成できる画面をデザインしていく作業が主になります。

 

…が、UIはユーザーの使い勝手を左右する、超重要な部分。

日々、黙々と画面デザインをしてる訳ではなく、時には要件定義から関わり、ユーザーにとって理想のフローはどんなものかを、プロダクトチームや開発チームと一緒になって整理していきます。

 

今回は、そんな「要件定義」フェーズの前段階として、ストーリーマッピング的なもので要件洗い出しを行なった事例を紹介します。

 

ユーザーストーリーマッピングとは

詳しくはこちら↓↓を読んで頂けば概略が掴めると思います。

qiita.com

 

基本的には、考えられるユーザーストーリーを1つずつ 付箋に書き出し、
【横軸=時間】【縦軸=ストーリーの粒度】とした平面上に
その付箋をマッピングして、ユーザー体験を整理する手法です。

 

そして最後に、どのストーリーをリリースの範囲とするか、を決定します。

 

なぜ、ユーザーストーリーマッピングを利用したのか?

今回、対象となった案件は「認証機能の追加」でした。

 

当初、簡単だと思っていたこの案件は、要件を整理していくうち、実はストーリーが結構複雑なことに気が付きました。

 

理由は以下。 

  • ユーザーが使用する認証アプリには色々種類がある
  • アプリ版とWeb版で、少し要件が異なる
  • イレギュラーストーリーが多数考えれる

 

 そこで、一旦考えられる全てのストーリーを洗い出し整理し、どこまでをANDPADとして担保するのか?を整理することに。

 

その際、この複雑なストーリーを、わかりやすく整理出来る方法はないか?
と思っていたところ、たまたま社内の方がオススメしていた、ユーザーストーリーマッピングが向いているのでは?と直感し、トライしました!

 

(なお、今回はブレストツールのMiroを使用しました。)

 

実際マッピングしてみた

こんな感じになりました。

時系列にシナリオを並べつつ、右上に想定されるユーザーの軽いペルソナもお記載し、
誰がこの機能を使うか?を、整理していく時も常に意識出来るようにしました。

ストーリーマッピングしてみました

ストーリーマッピングしてみました

 

実施時のポイント

  • シナリオの文型は、「ユーザーが●●できる」とした。

    →「●●する」だと「ボタンを押す」など動作に注目がいきがちですが、
     「●●できる」だと動作の目的(例えば「設定できる」)に自然と視点がいき、要件を整理しやすかったです。

  • 一旦私が叩き台を作っておき、チームメンバーには、それを元にシナリオが合っているか確認していく形にした。

    →チームメンバー其々が書き出したシナリオをマッピングしていく形がメジャーですが、ストーリーマッピング自体、今回初めての試みだったので、文法合わせなどのお作法の認識合わせで時間がかかることが予想されました。
    ともすれば、本来の目的である「認証機能のシナリオを抜け漏れなく書き出す」ことが、時間内に達成できない可能性があったため、この形を取りました。

  • リリース範囲選定は、プライマリユーザーが必要な機能はどれか?に主眼を置いた。

    マッピングとは別に、想定ユーザー(プライマリ・セカンダリ)を記載しておき、そのユーザーにとって必要な機能か否か?を、ストーリーのリリース範囲の選定基準としました。

 

ユーザーストーリーマッピングして良かったこと

今回トライしてみての振り返りです。

良かった点が多く、今回の課題を解決するのにマッチした手法だったと思います。

  • 口頭や文章でやり取り時は、複雑に見えていた要件が、マッピングすることによってスッキリした。
  • ストーリーの中でも複雑なところ・単純なところが可視化されて、注力しなければならない点が見えてきた。
  • 視覚化されたので、イレギュラー時のストーリーや、派生したストーリーなど、抜け漏れに気づけた。
  • 整理していく中で、実はプライマリユーザーは別にいるのではないか?と気づくことができた。
  • 想定ユーザーのペルソナも併せて記載しておいたおかげで、「ユーザーAはこの動作はしないのでは?」的な、ユーザー目線での整理ができた。

ユーザーストーリーマッピング、ピンと来た方は、ぜひ活用してみてください!
あなたの課題を解決する一助になるかもしれません。

より詳しく知りたい方は、こちらの本がオススメです!

www.oreilly.co.jp

 

仲間募集中!

そんな、幅広いフェーズにコミット出来る、オクトのデザインチームは、
一緒に働く仲間を募集中です!

気になった方は、ぜひお気軽にエントリーお願いします!

hrmos.co

 

新機能開発ってどう進めてるの?

f:id:mikakato:20200225115358p:plain

はじめに

初めまして、12月にPdM(プロダクトマネージャー)として入社した加藤です。

 

現在ANDPADチームの一員として、新機能の開発に従事しています。

PdMとしてはせっかく作った機能があまり使って貰えない...という事態は避けたいものですし、かといって開発に無限の時間・リソースを割ける訳でもない...。
そんな中で、どうしたらスピード感を持ちつつ良い機能が作れるのかを日々チームメンバーと共に考えています。

 

建設業界未経験(IT業界出身)かつSaaSサービスのPdMとしてもまだまだ勉強中の身なのですが、実際にどんな感じで進めてるの?という部分を簡単にお伝えできたらと思います。

とりあえず作るの前に

ANDPADは建築・建設現場向けに特化したツールであるため、新しい機能を追加開発するにあたっても「業界で働く方々が、真に必要としているものを作るという意識」を手放さない事が大切です。

書くと当たり前な事に思えますが、意外と難しいなと感じます。特に私のような業界未経験の身だと機能的なアイデアが先行しがちです。

何となくで作ってしまう=失敗パターン...の轍を踏まないためにも、まずはリーンキャンバスを使い、作ろうとしているプロダクトのターゲット/課題/価値/ソリューションが一貫性を持っているかを整理しました。

  • ターゲットとなるセグメント(事業規模や拠点数はどのくらいか、新築なのかリフォームなのか、注文住宅なのか分譲住宅なのか...)はどこか?ユーザーはどのような人(現場監督、営業、設計士...)か?
  • その人は日々の業務で具体的にどのような課題(ペイン)を感じているのか?
  • 課題に対して、ANDPADとしてどのような価値を提案できるか?
  • 価値を実現するソリューション(機能)は何か?

リーンキャンバスについてはこちらで詳しく紹介されています。

media.bizmake.jp

設定した仮説はエンジニアを含むチームメンバー全員で確認し、認識をそろえることも大切な要素だと思います。

ユーザーの声をきく

ユーザーの解像度が低いままでは、どんなに良いプランを描いても顧客ニーズと開発するプロダクトが乖離しかねません。

そのため、リーンキャンバスで設定・整理した仮説が本当に合っているのか?を、実際のターゲット層となる方にプロダクトインタビューを重ねました。

インタビューをするにあたっては一旦仮説に基づいてプロトタイプ(UIイメージが伝わるワイヤーフレーム、モック)を作成し、極力具体的なイメージをお見せするようにしています。

実物を開発する前にユーザーのリアルな反応やフィードバックが得られますし、もしこの段階で仮説がズレていた場合は随時修正していきます。

 

プロダクトインタビューの手法や観点については、こちらの書籍を参考にしています。

www.nikkeibp.co.jp

 誰が見ても分かる言葉に翻訳する

 仮説設定についてもインタビュー内容についても同様ですが、情報を整理する際はとにかく誰が見ても分かる言葉や表現を選ぶことを意識しています。

PdMの性質上、社内外あらゆる役割・属性の方々から情報を集め・整理し・展開しなければなりません。情報源も展開先も多様です。

ただ小さいチームで動いていると、どうしても「共通の文脈をあらかじめ理解している」前提で話が進んでしまいがちです。

その後の認識のズレを正す手間も時間も積み重なると大きな負担になるので、地味かつ至極当たり前のことですが、PdMとして極力コミュニケーションコストを下げるためにできることを実践しています。

  • 書き手の独りよがりな表現を使わない
  • 極力、図で表す(言葉よりコミュニケーションのずれが少なくて済む)
  • ユーザーが読んでも営業マンが読んでもエンジニアが読んでも同じ意味にとれる表現を選択する
  • 曖昧な言葉はできるだけチーム内で意識を合わせる

 

おわりに

最後まで読んでいただきありがとうございます!
オクトでは一緒に働く方募集しております。よろしければこちらも是非ご覧ください。

engineer.88oct.co.jp

「コミッターと読み進めるRailsリーディング会 #1」を開催しました!~ Rails v1.0.0を読み進める! ~

はじめに

はじめまして!オクトのRailsエンジニアの @KanechikaAyumu です!

弊社では、日々色々な勉強会が開催されています。

先日は、ANDPADの技術顧問をして頂いている松田さんにRailsリーディング会の勉強会を開催して頂きました!

prtimes.jp

貴重なお話を聞ける機会なので、社内の勉強会に閉じるのがもったいないと思い、外部の方も参加できるような形式を取らせて頂きました。当日参加してくださった方、平日の日中のお忙しい中にご参加頂き、ありがとうございました!!

oct.connpass.com

Railsソースコードを読んだことない人や、どこから読み進めて良いのか分からずな方は、参考にして頂ければと思います!

  1. 当日の様子
  2. Rails v1.0.0
  3. コミッター紹介
  4. Active Record
  5. Action Pack
  6. alias_method
  7. 最後に

当日の様子

当日は社内のエンジニアに加えて、数名外部のエンジニアの方にご参加頂きました。ご参加ありがとうございます!

松田さんの画面操作を見ながら、参加者全員でリーディングを行いました。Railsだけではなく、ソースコードの読み方やコマンド操作などたくさん学ぶことができました!

f:id:ayumu-kanechika:20200216175542j:plain

f:id:ayumu-kanechika:20200216175608j:plain


Rails v1.0.0

松田さんのオススメのOSSの読み方は、「First Commitから読み進めていくこと」とのことです。作者の本当に実現したかった内容が、ノイズ等がなく、シンプルに書き下されている為です。今回の勉強会でもv1.0.0から読み進めて行くことになりました。
 
皆さんもお手元にチェックアウトしてみて下さい!
$ git clone git@github.com:rails/rails.git
$ cd rails
$ git checkout v1.0.0
 

Railsは、フルスタックのMVCフレームワークです。
Mのモデルレイヤーは、O/Rマッパーも兼ねて「Active Record」が担います。
Cのベースとしては「「Action Pack」があり、当時は「ActionController」や「ActionView」が担っておりました。MVCの糊付けとして、「Railtise」があります。

勉強会では、中核な処理の「Active Record」「Action Pack」を読み進めました。

コミッター紹介 

その前にコミッター紹介です。生産者の顔が一番大事とのことです!

 

Railsは、DHHのファーストコミットで、大枠は出来上がっていました。
Action Mailer、Action Pack、Active Record、RailtiseなどMVCの中核の部分はだいたい全部入っていました。2004年にBase Camp(当時、37signals)のWebApplicationから切り出した為です。(とある1つ企業のフレームワークの切り出しで、この設計力の高さは驚愕です!!)
 
その最初のコミットがこちら
Initial
綺麗なコミットが積まれているのは、DHHがそういう性格の人だそうです。
 他にもコミットやRails Contributors をなどを見ながら、名前の挙がった方をつらつらと記載します!
$ git shortlog -sn db045dbbf6..v1.0.0
 
1771 David Heinemeier Hansson
278 Jeremy Kemper
205 Jamis Buck
79 Nicholas Seckar
77 Leon Breedt
70 Marcel Molina
42 Sam Stephenson
14 Thomas Fuchs
13 Tobias Lütke
12 Scott Barron
9 Florian Weber
8 Michael Koziarski
  1. DHH(David Heinemeier Hansson
    ファーストオーサー 37 signals CTO
    当時では珍しいRubyを使って、プロダクトを作り始めた。
    当時25歳。コードが書けて、設計できて、イケメン!!

  2. Jeremy Kemper
    No.2の重要人物
    Base Campにあとからジョインした。
    20世紀の頃からRubyを触っていた。
    Railsを影から支えるNo.2
    今の名前は、Jeremey Daer。
    結婚して、夫婦の名字を足して2で割ったらしい

  3. Jamis Buck
    Base campに後からジョイン
    代表作は、Switch Tower(?)。Rubyでピッとデプロイができる代物。
    商標などの兼ね合いで、のちにCapistranoに変わる。

  4. Nicholas Seckar
    主にActiveRecordを開発

  5. Marcel Molina
    当時は最年少。シンボルにProcを導入!

  6. SamStephenson
    まだ尚、社員
    JS系を色々と作っている。
    Asset Pipelineを作った人。Sprocketsも。

  7. Tobias
    社外の方。MySQLに強い。カナダ人。ActiveRecord
    Shopifyを起業をして、「CTO」ではなく「CEO」をやっている。

  8. Michael Koziarski
    ニュージーランドRailsコミッター。セキュリティ周り

  9. Eric Hodel
    シアトルRubyの親玉

  10. JoshPeek
    Railsコミッター。Rack。
    サンフランシスコの小さい企業Githubを立ち上げた。
    Rails魔改造をし続けて、Githubが2系を使い続けていた。

  11. Chat Fowler
     Rubyconf

  12. Shugo Maeda
    Railsのv1.0.0で唯一コミットが取り込まれた日本人

 

Active Record

当時のv1.0.0では「activerecord/lib/active_record/base.rb」の約1800行にコアの処理が全て書かれていました。他はおまけとのこと!
 
Railsも当時は新出のフレームワークだったので、ソースコードのコメントもかなり丁寧に書かれているので、キャッチアップしやすいです。
 
findメソッドにinteger渡すとプライマリキーとして検索されるなど、既に今と同じ形式でした。 機能としては、大枠できており、最先端という感じでした。最近の開発では、DSLが増えているという感じ。
 当時はfindしか使っておらず、relationとかなかったので、即SQL発行がされていました。
 
#find が面白いので、読み進めていきます!
def find(*args)
  ...
  case args.first
    when :first
      find(:all, options.merge(options[:include] ? { } : { :limit => 1 })).first
    when :all
      records = options[:include] ? find_with_associations(options) : find_by_sql(construct_finder_sql(options))
      ...
    else
      ...
      conditions = " AND (#{sanitize_sql(options[:conditions])})" if options[:conditions]
 
引数にfirst、all、それ以外の何を渡しても最終的に「find_by_sql」に「construct_finder_sql」が呼び出されています。
 
#construct_finder_sql はストレートに処理が書かれています!
def construct_finder_sql(options)
  sql = "SELECT #{options[:select] || '*'} FROM #{table_name} "
  add_joins!(sql, options)
  add_conditions!(sql, options[:conditions])
  sql << " GROUP BY #{options[:group]} " if options[:group]
  sql << " ORDER BY #{options[:order]} " if options[:order]
  add_limit!(sql, options)
  sql
end
 
#find_by_sql は今でも残る重要なAPIとのことです!
def find_by_sql(sql)
  connection.select_all(sanitize_sql(sql), "#{name} Load").collect! { |record| instantiate(record) }
end
 
次に、#save を読み進めていきます。
def save
  raise ActiveRecord::ReadOnlyRecord if readonly?
  create_or_update
end
 
中では、#create#update を呼び出すことになり、そちらも愚直にSQLを構築しています!
def create
  if self.id.nil? and connection.prefetch_primary_key?(self.class.table_name)
    self.id = connection.next_sequence_value(self.class.sequence_name)
  end
  self.id = connection.insert(
    "INSERT INTO #{self.class.table_name} " +
    "(#{quoted_column_names.join(', ')}) " +
    "VALUES(#{attributes_with_quotes.values.join(', ')})",
    "#{self.class.name} Create",
    self.class.primary_key, self.id, self.class.sequence_name
  )
  @new_record = false
end
 本当にRailsのコアの処理はv1.0.0に詰まっています!
 
他に大事なのはなどがあるのですが、時間が足りずなので、次回以降のお楽しみになりました!
続きを読む

React Native経験者がFlutterをさわってみた


 はじめに

はじめまして、アプリチームの伊藤です。

オクトでは複数のアプリをリリースしていますが、その中でもReact Nativeを使っていたりFlutterを使っていたりと、同じクロスプラットフォーム開発ツールでも複数の技術が使われています。アプリチーム内でもよくこの話題があがっていたりして、もりあがっているテーマです。

そんな中、個人的にはReact Nativeか、Flutterかどちらかに注力して、ナレッジを蓄積したり、開発できるエンジニアを増やしたりすることも必要なのではないかと感じることがあります。そこで自分は前職でReact Nativeを使った開発をしていたこともあり、今回はFlutterをさわりながらその違いを学びつつ、今後の開発方針の検討材料にしていこうと思いました。 

 

2つのツールを比較する

まず、よくある2つのクロスプラットフォーム開発ツールのざっくりとした比較をまとめていきたいと思います。

 

x-plat tool React Native Flutter
開発者 Facebook Google
主な開発言語 JavaScript Dart
初版 2015年3月 2017年5月
IDE VS Code, Nuclide Android Studio, IntelliJ, VS Code
描画方式 ネイティブコンポーネントを使用 独自レンダリング

 

どちらも大手IT企業により開発されたツールですし、開発も活発なため今後のサポートに期待が持てます。開発言語や使えるIDEによってエンジニアの好みが分かれそうです。描画方式の違いはネイティブに近いアプリを作りたいか、プラットフォームが違っても差異が少ないUIで提供したいかなどでデザインの要望が関わってきそうです。

 

トレンドを見る

f:id:tomo-ito:20200209232443p:plain

React NativeとFlutterのトレンド

Google Trendsで日本での過去3年の動向をみてみました。React Nativeはあまり変化がないですが、Flutterは昨年の5月くらいから急上昇しています。Google IOのタイミングですね。人気というところではFlutterに軍配があがるようです。

 

サンプルを作って動かしてみる

技術は実際に自分の手で動かして確認することを信条としてますので、サンプルアプリを作りながら使い勝手などを試していきたいと思います。

 

CLIでプロジェクト作成・アプリ起動

環境構築については完了していることを前提とします。プロジェクト作成はIDEから行うやり方もありますが、シンプルなCLI操作による場合で両者を比較します。環境構築さえ済んでいれば、プロジェクト作成からシミュレータでのアプリ起動までスムーズに行えます。

 

React Native

$ npx react-native init react_native_sample_app
$ cd react_native_sample_app
$ npx react-native run-ios
または
$ npx react-native run-android

Flutter

$ flutter create flutter_sample_app
$ cd flutter_sample_app
$ flutter run

 

画像とテキストを表示するサンプルコード

アプリ起動の確認ができたら試し簡単なコードを書いてみます。React NativeではHTML・CSSライクなJSXで記述します。FlutterではWidgetツリーと呼ばれる階層構造で記述します。

 

React Native

import { AppRegistry, View, Image, Text, StyleSheet, } from 'react-native';
import React from 'react'; 
import {name as appName} from './app.json'; 

AppRegistry.registerComponent(appName, () => MyApp);

class MyApp extends React.Component {
  render() {
    return (
     <View style={styles.container}>
        <Image 
          style={styles.image}
          source={{uri: "http://bit.ly/39f0IkW"}}
        />
        <Text>明日から使えるカンタン施工管理アプリ</Text>
        <Text>by React Native</Text>
      </View>
    );
  }
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center'
  },
  image: {
    width: 250, 
    height: 50
  }
});

Flutter

import 'package:flutter/material.dart';

void main() {
  runApp(MaterialApp(
    home: Scaffold(
      backgroundColor: Colors.white,
      body: Container(
        child: Center(
          child: Column(
            mainAxisAlignment: MainAxisAlignment.center,
            children: <widget>[
              Image.network(
                "http://bit.ly/39f0IkW",
                width: 250,
                height: 50,
              ),
              Text("明日から使えるカンタン施工管理アプリ"),
              Text("by Flutter"),
            ]
          )
        )
      )
    )
  ));
}

 

結果

簡単なアプリなので見た目はほぼ同じです。

f:id:tomo-ito:20200210023739p:plainf:id:tomo-ito:20200210161030p:plain

 

補足

ここまで書いてアレですが、Flutterの公式サイトではReact Nativeとの違いについて丁寧なドキュメントを用意してくれておりとてもわかりやすいです。こういうところはとても好感が持てますね!

flutter.dev

 

さわってみての感想

  • FlutterはReactにインスパイアされて開発されたと言われているが、実際使ってみても共通する部分が多く、React Nativeでの開発経験がツール理解の助けになった。
  • 宣言的UIで記述し、かたやComponentを積み重ねて、かたやWidgetを積み重ねる。それぞれ用意されたコンポーネントの種類や使い方を覚える必要があって、肝心なハードウェアに近い部分はネイティブコードで記述し連携できる。
  • 後発のFlutterの方が洗練されているように感じた。JSXよりもWidgetツリーの方がスッキリしていて、CLI操作、静的型付け対応、IDEのバリエーション等から優れいている。
  • React NativeもTypeScript等を駆使してより良い環境を構築できるが、このあたりはWebフロント開発に慣れているエンジニアのみが力を発揮できる領域になる。

 

さいごに

 まだまだFlutterの勉強をはじめたばかりで、React Nativeに関しても経験豊富というわけでもない自分ですが、現在の印象としてはエンジニアの好みでどちらを使っても良いのかなと思いました。開発コストとしては大差なく、言語の普及率や学習コストなど勘案してもどちらが良いかの選択はエンジニアによってまちまちではないでしょうか。

アプリエンジニア(iOS/Android)ならFlutter、フロントエンドエンジニアならReact Nativeを選びそうです(バックエンドエンジニアならどちらだろう?)。

とはいえはじめに提起した課題の解消に向け、今後アプリチームでよく議論していくつもりです!

とある日の&ANDPAD開発部の1日

はじめに

はじめまして、開発アシスタントのしおざきです!

開発部はどんどん仲間が増え続け現在約60名。オクト内では大所帯です。
今回は、そんな開発部が日々どんな雰囲気で仕事をしているかお届けしたいと思います!

開発部の1日

10:00

大所帯の開発部ですが、この時間はまだひっそりしています。
集中できる時間に開発をしてもらうため、フレックス制を導入していますが、どうやら朝型はそんなに多くないようです。

 

11:00

この時間になるとだいぶ賑やかになります!

この日は週に一度の開発部会が開催される日。全員が集まると人数の多さを実感します。

 

f:id:shiiiio:20200203121214j:plain


 部会では、VPoEやVPoPがメンバーに伝えたい想いを話してくれます。
情報共有はもちろん、人が多くなると様々な考えや思いが交錯しがちですが、目指すべきところはみんなでひとつ、ということを改めて認識させてくれる場だったりもします。

 

12:00

ランチに出る人が多いこの時間帯。
特に時間が決まっているわけではないので、好きな時間にランチに行けます。

美味しかったお店などは「ここ行ったよ!」と共有しあったりするのですが、移転後によく目にするものが… 

 

f:id:shiiiio:20200130133045p:plain

メイド喫茶でお絵かきしてもらったオムライス。さすが秋葉原です。

 

13:00~15:00

ネタを探しにぷらりとしてみると、ミーティングをしているチームを発見。

f:id:yohei-fujii:20200203191707j:plain



真剣な様子が伺えます。

 

執務室内には大人数のMTGからちょっとした相談までできるフリースペースがたくさんありますが、気分転換したい時には近くのカフェに行くことも。

 

ということで、この日はCTOとカフェMTGをしてきました。

 

f:id:shiiiio:20200203144913j:plain


カフェが好きなCTOはいつもおしゃれなお店へ連れて行ってくれます。
エンジニアではなくても業務で困っていることなどをフランクに聞いてくれるので、とても心強い存在です。

 

16:00~18:00

作業に集中している人、気分転換に筋トレをする人、技術書を読む人など様々。
開発部にはたくさんの本があります。(恐らく社内でダントツの保持数)
そんな勉強熱心なメンバーはよく社内勉強会も開催しています。
勉強会の様子は記事になっているのでぜひ御覧ください!

 

tech.88oct.co.jp

tech.88oct.co.jp

tech.88oct.co.jp

 

19:00

平和な1日のようで、実は慌ただしい時間が流れていたりもする開発部。
この日も多忙を極めていたVPoE、なんとお誕生日ということが判明。忙しそうなので、みんなデスクの上にそっとプレゼントだけ置いて帰宅しました。

 

f:id:shiiiio:20200130131703j:plain

以上、とある日の開発部の1日でした。

おわりに

最後まで読んでいただきありがとうございます!
一緒に働く方募集中ですので、少しでも気になった方はこちらもぜひ!

engineer.88oct.co.jp