ボクココ

サービス開発を成功させるまでの歩み

少数精鋭チームでサービス開発を続けるためのヒント

ども、@kimihom です。

f:id:cevid_cpp:20171123200450j:plain

最近は色々な企業がサービス開発は少人数でやる方がいいことに気付き始めて実践しているように見受けられる。もちろん、最初の 0->1 フェーズでは設計して開発するだけなので誰でも少人数で開発していけるだろう。しかし問題はその後でサービスを公開してユーザーが増えてきたときに人が足りないみたいな状況になってしまってどんどん人を増やしてしまうケースが見受けられる。本記事では少数精鋭チームで開発を続けられるようにするためのヒントを記していく。

問い合わせを減らそう

サービス公開してユーザーがどんどん増えてきたときに、問い合わせがそれに比例して増えていくようでは、当然のことだけど運営側も人が必要になってくる。問い合わせ、つまりユーザーが疑問に思ってしまう点をいかに減らしていくかが少数精鋭を続けるために重要な点となる。

そのためには、ユーザーを悩ませないサービスを目指していけば良い。使えば誰でもわかるサービスだ。少数精鋭だからこそ、サービスに最も必要な機能だけに重点を絞り、そのほかのあったらいいな程度の機能はあえて実装/提供しない。こうすれば、ユーザーはどうすればいいのか迷うことがなくなり、最終的に問い合わせそのものを減らすことができる。

私がこの話で例をよく出すのが appear.in というサービスだ。このサービスは話したい相手と URL を共有するだけでビデオ通話ができてしまうサービスである。ビデオ通話だけできるサービスなので、ユーザーは一切迷うことがないし、"誰かとビデオ通話したい" = appear.in というユーザーの意識の紐付けが簡単にできるため、再び気軽に使える強力なフックがある。appear.in で使い方がわからない っていう問い合わせはまず来ないだろう。そうして appear.in はサービスにおいて最も大切な通話品質を高めることに注力することができるのだ。

誰も悩まないレベルのサービスを提供できれば、問い合わせは劇的に下がり、少数精鋭を保ち続けることができるのである。 上記のために間違ってもわざとメールや電話の問い合わせ窓口をわかりづらくさせるみたいなバッドノウハウを実践しないようにして欲しい。

単純な手作業を全て自動化しよう

普段の仕事の中で、単純な手作業で入力している項目がないか?こうした時間は無駄以外の何物でもない。単に仕事をしている気になっているだけだ。こういう作業こそコンピュータの得意な分野なのに、それを活用しないってのはあまりにも勿体無い。

ここで必要になってくるのはやはり一定のプログラミングの知識だと思う。何かがあったら自動でプログラムが動いて手作業を自動化させる。毎日5分くらいの作業だからとか言って単純作業を許容してみるとしよう。それは 1年経てば営業日を300日だとすると1500分(25時間)を無駄にしている。そういう作業がどんどん増えていってしまうと、やがて人が必要になってしまうのである。

だからこそ、エンジニアでなくても業務の効率化を身につけている人はエクセルのマクロを勉強したりするし、サービスの自動化の仕組みを学んだりするようになる。それは少数精鋭でやる上ではとても大事な意識づけだと思う。

余計な仕事を増やさない工夫をしよう

サービス開発に関わること以外は、できる限り少なくすることが大切だ。仕事においてどうしても時間をかけてやらないことがあった場合には、それらを外の人に手伝って(外注して)やってもらう方法を検討しよう。そこでサービスの良し悪しは変わるものではないので、時間をお金で解決するってのは大事な考え方だと思う。これを勘違いしてサービス開発の根幹である開発やデザインを外注するってのは当然ながら NG だ。

また、余計な仕事を増やさないようにするために、サービスのターゲットとなる顧客だけを相手にしていく努力も必要だ。ターゲットでない人がサービスを使ってしまうと、その時点で "~はできないですか?" といった問い合わせが増えるし、その検討や対応に時間を取られることになる。少数精鋭チームであれば、百万ユーザーなんて必要なく、数百 ~ 数千の顧客を相手にすれば十分にうまくやっていくことができる。そんな理想な顧客とだけ相手にしてサービスをどんどん良くしていくってのこそ、少数精鋭チームでのサービス運営の醍醐味である。

終わりに

今回は少数精鋭チームを続けるために必要な考え方について記した。

来月、"自己資本主体で少数精鋭チームでサービスを成長させるには" ってテーマでイベントをやる予定だ。本記事で書かれたこと以上に有益な情報が共有されるはずなので、残り席少ないけども興味があれば参加いただけると幸いだ。

selfree.connpass.com

少数精鋭チームで最高のサービスがどんどん出ていくと、それぞれの顧客にとって"最適な"サービスを選べるようになり、みんなが幸せになれるはずだ。

全ての企業がテックカンパニー化する世界

ども、@kimihom です。ちょっと気分が優れなくて一時的にブログ止まっちゃったけど、またコツコツ再開しようと思う。

f:id:cevid_cpp:20171115203603p:plain

さて近頃は、日経電子版がめちゃくちゃ速いみたいな感じで話題になっている。

リニューアルした日経電子版が高速すぎてヤバイ件|こんぴゅ|note

本記事を読むと、確かに従来のウェブ開発に乗っ取った設計ではなく、Web や HTTP プロトコルの最新の機能を駆使してとんでもない高速化を実現したことが理解できる。日経のような大きな組織でこのチャレンジは本当にすごいことだと思う。

その技術力もさることながら、それを実現したのが新聞社だということが新しい時代を感じさせてくれる。本来であればニュースの記事を取材してそれを公表するのが新聞社のはずだ。それなのに、日本の Web 企業ですらなかなかチャレンジしづらかった最新技術への適用を日経がやってのけたってことが私にとってもっとも衝撃的だった。

そしてこの点から一つの真理が言えるだろう。これからはどの業界でもテックカンパニー化していくという点だ。"自分たちは専門外だから"といって技術を丸投げするような企業は改めてこの点について考えるべきだと思う。

テクノロジーが今後を左右するワケ

どんなビジネスにおいても情報は宝の山だ。顧客が何を望み、現状の何に満足しているのか。本気で情報を解析している組織にはそれをカンではなく確かな情報として理解することができる。どの時間に何をすれば顧客は購買してくれるのか。そんな傾向がわかれば、どこへ重点的にリソースを割くかといった戦略を立てることが可能になる。

これは例えるならマグロ漁師が沖へ出ていって、単なる勘で探しに行くのではなく、海の中をセンサーを使って覗きながら確実にいるとわかった状態で網を投げるといったのに近い。どちらが確実にたくさんの成果が得られるのか、想像に容易い。情報が全て筒抜け的な話でいうと怖くなるというか嫌だなと思う方もいるかもしれないが、そうしたちゃんと根拠に基づいた行動ができるようにならないと、今後どんどん相手が利益をかっさらって行くだけの状況となってしまう。

こんな話は今までそれなりの規模でエンジニアを抱えている企業だったら当たり前の話だったかもしれないけど、これが今後は他のどの業界にでも必須になってくる。そう考えると日本にエンジニアが足りないって言われるのは当たり前の話なんだと思う。

ちなみに今回の日経電子版は相当の知識や経験がないと踏み込めないところまでやってのけていることを考えると、優秀なエンジニアを自社で抱えてやっているように思う。実際何度かテック系のイベントを日経社が会場提供していたし、すっかりテックカンパニーになったように見える。

ページの表示速度が2倍速くなったってなら、他のニュースサイトに比べたら3倍以上は早いだろう。数秒ならあんま気にならないという話があるかもしれないけど、何百万ユーザーレベルの視点で見れば確実にユーザーにとってプラスに動く改善だ。

こんな変化が実はあらゆる業界で発生している。飲食チェーン、金融、商社、運送、農業まで全てがテクノロジーを駆使して業務の改善や分析をベースとした経営判断を行うようになってきている。そしてそれができるトップ企業だけが、海の中のセンサーを活用してマグロ漁をするかのように大量の成果を得られるような時代が既に来ている。

私たちはどうすべきか?

自分はエンジニアなので引き続き技術を学んでいくってところだけども、そうじゃない人でもプログラミングやコンピュータの基礎知識は持った方がいいと思う。そうじゃないとそもそも何ができるのかもわからない状態になってしまう。これではどんどん先を越されていってしまう。

テクノロジーを駆使した企業がどんどん成功して、そうじゃない企業はどんどん取り残されると、業界トップ1~2位の企業がほとんどを独占するような感じになると思う。上下の差がますます広がっていってしまうけども、競争社会ってのはそんなもんだろう。個人的にはあんまガツガツしたくないけど、それでもしっかりとテクノロジーを駆使するところはブレずにやっていきたいと思う。

終わりに

一部ではエンジニアを崇拝しすぎるのもどうかっていう意見もあると思うけど、エンジニアを軽視しているところは間違いなく今後取り残されるだろう。程よい関係を構築しながらエンジニアが長く、そして成長できる基盤を整えていくことがこれからの企業に求められることだ。

今回の日経電子版のニュースはそれほどまでにすごいと個人的には思った。

サービス開発者が本当の喜びを味わえる瞬間

ども、@kimihom です。

サービスをゼロから作り上げて、そのあと顧客を抱えて運営を続ける。サービスを育てていく期間の中で、開発者にとって喜びが得られる瞬間ってのはいくつかあると思っている。今回はこの長いサービス開発/運営の期間の中で、個人的に嬉しかった瞬間を挙げていきたい。

1, サービス構想を思いついて実装する瞬間

「これはいける!」というアイディアやテクノロジーに出会った瞬間の気分の高揚は未来のワクワク感がある。今持っている自分のスキルをフル活用して、どうすれば最終的にサービスとして作り上げるまで持っていけるか。そんな構想をしている時間は実に楽しい。ハッカソンなどの開発コンテストの良さはここに集約されていると思う。

私はこの段階でデメリットやリスクは全く考えないようにしている。とにかく良い点を見つけてそれをより良くするために方法はないか。そんなポジティブな側面からサービスを考えるようにしている。なぜなら、ここでリスクやデメリットを探そうとしてしまうとチャンスがその時点で終わってしまい、そこから先が続かないからだ。私は今まで "開発はできるけどネタがない" もしくは "アイディアはあるけど開発ができない" と言い訳を続けて何も行動しない人をたくさん見てきた。そういった人たちの特徴はこのデメリット探しが得意な人のように思う。ここのハードルの時点でサービスがそもそも出来上がらないってのがほとんどかもしれない。

んで幸運にも開発できるスキルと時間を持っていた場合のみ次に進むことができる。意気揚々と設計して開発している間は良いんだけど、今度は一通り自分の思い描いた機能を開発し終わったら途端にやる気をなくす現象が発生する。このハードルもとても大きく、ゼロから作ってうまくいくサービスがほとんど出てこない原因の一つだ。

だから、サービス構想を思いついて意気揚々と開発し終わった後、次の喜びを見つけなくてはならない。

2, 最初の"本当の"顧客を見つけた瞬間

本当のとつけたのには理由がある。大抵はサービスを作り上げてローンチしてやっていくぞとなった時は、友人を始めとした誰かからの力を借りたりすることで仮の顧客を獲得することはできる。それは別にあまり嬉しくなくて、サービス改善の途中くらいにしか思わない。 しかし、本当に課題を抱えてやってきてサービスを導入し、有料顧客になってくれた。この瞬間は特別な気持ちになる。作ったサービスに対してお金を払うってことは、それだけの魅力を感じてくれたということだし、品質や管理を期待してくれているということの裏返しだ。この瞬間を体験すると、より良いシステムを目指そうという気持ちが改めて芽生えることになる。

この喜びを感じずにスタートダッシュをかけてしまう企業を多く見る。ローンチ記念だとかで一気に広告かけたり無料キャンペーンでガッと獲得しにいくことだ。この時点でそれをするってのは、自分たちの原点を見つけることを難しくさせる。事業がうまくいかなくなった時に露頭に迷うことになる。

そうじゃなくて、"最初に獲得した顧客を最高に幸せにしたい"という思いを最初に持つことで、その後もブレないサービス開発を続けることを可能にさせるだろう。この考えを持てるようになれば、最終的に利益を目標にするのではなく、顧客を幸せにすることを目指すことができる正しい企業になることができるはずだ。

やがて、同じような課題を抱えていた顧客は自分からその評判を聞きつけてサービスにやってきてくれる。この好循環を生み出せた時、その次の喜びを味わうことができるようになる。

3, 顧客に会う瞬間

1,2 こそサービス開発をゼロからやる醍醐味だと考えている方がいるかもしれない。実際に私も 1,2 を達成することを夢見てサービス開発を続けていた。でも、それ以上にもっと嬉しい瞬間があることを知った。

先日、私の運営するサービスのユーザーさんが一堂に集まるイベントを開催した。十数人のこじんまりとしたイベントだったけど、全ての参加者は自分のサービスを使ってくれていて、さらにイベントまで足を運んでいただいたのだ。一部の方は既に問い合わせ対応などで話したこともあったから初めてという感覚でもないけど、それでも新鮮な気持ちとして話すことができた。自分のサービスに対する想いを伝えたり、現在の利用状況や要望など、サービスの未来について語り合うこの時間は率直に言って最高だった。

ユーザーさんの中で、実際に自分のサービスを使ってどうやって事業を伸ばしてきたか。どういう思いで使っているか。どんな良いことがあったか。そんな話をイベントの中で登壇して頂いて話を聞く瞬間はサービスを作った側からすると涙が出るレベルで嬉しい。この喜びは 1,2 では味わうことができないほどのものだ。それはきっと、長い時間をかけて努力した結果だからだと思う。

終わりに

給料が上がった、昇給したなんて社内だけの自己満で本当にいいのか?

本当の喜びはそこにはないはずだ。ユーザーのためにサービスがあって、誰かに貢献しているという思いが大事だと思う。その上で達成するための近道はあるんだろうけど、手を抜いたら近道した分だけ幸せは生まれない。いかに地道な努力を続けることを大切に思えるか。そこがサービス開発者の喜びが得られる得られないかの分岐点だ。

開発アイディアがある > 開発ができる > 顧客を見つけられる > 顧客が自ずと集まる仕組みが作れる > 顧客がサービスを愛してくれる

3を達成するには、上記の全てのハードルをクリアしなければならない。もちろん難しいことだけど、やる価値があるほどの喜びを最終的に味わうことができる。なぜならそこまで達成するのは本当に難しく険しい道のりだからだ。

だからこそ、辛い時でも目的を見失わないようにするために、サービス開発当初の想いは大事だ。熱い想いで生まれたサービスはきっとユーザーにも響くはずだ。

てことで変に近道をしないで本当にいいサービスを生み出す努力のできる企業が今後も増えてきて欲しいなと思う。

Rails 5.1 の First Impression

ども、@kimihom です。

f:id:cevid_cpp:20171105213739j:plain

この連休はひたすらプログラミングやってた。そんな中で手をつけ始めた Rails 5.1 について感想を書いてみるとする。こういうちょっとしたことでも記事にできるのがブログのいいところよね。

Yarn マジ便利

JavaScript の パッケージ管理の Yarn は本当に便利だと感じた。今までの Rails の AssetPipeline での外部ライブラリの管理って、専用の Gem をインストールして application.js に書く感じだった。例えば momentjs-rails 。これの大きな弱点ってのは、Gem の管理者が更新をやめれば バージョンは古いままだってこと。そもそもフロントエンドの JavaScript の管理も Gem でやろうって時点でモヤモヤ感を感じてはいた。

そこで Yarn の登場だ。Rails プロジェクトのトップで yarn add moment ってするだけで moment をインストールすることができる。すると Rails 直下にお馴染みの node_modules フォルダができるので、それを見ながら application.js を以下のように追加するだけで OKだ。

//= require moment/moment

これは Yarn を入れた後の JavaScript ライブラリの構成によって、 require 以降の書き方は変わるので注意する必要がある。例えば JavaScript ライブラリ hoge の実体ファイルが dist/hoge.js だったら //= require dist/hoge って感じにすれば OK だ。

これで例えば moment をアップデートしたいってなら yarn upgrade moment で終わりだ。最高にクール!

フロントエンドの選択

以下の記事を読んで、自分が Rails プロジェクトの中でフロントエンドをどうしていきたいかを考える必要がある。

blog.toshimaru.net

私は現状の Asset Pipeline に大満足している派だったので Asset Pipeline を使い続けることにした。この記事では ES6 使いたいなら browserify-rails を使うやり方が紹介されていたけど、普通に Asset Pipeline 使ってでも ES6 使えるような気がするため、メリットがいまいちピンとこなかった。唯一 require が使える? 的な話を他のページで見かけたけど、結局 Asset Pipeline で一発でまとめてくれるから require 自体必要ないよな、とか思ったりした。ここら辺詳しい方いたら教えて欲しい。

-- 2017/11/19 追記 -- rails server で普通に開発してる分には問題起きないけど、assets:precompile で ES6 形式で書くと失敗することが判明。。やはり Asset Pipeline では ES6 構文を書くのに対応させることは難しいようだ。

今までは AssetPipeline のコンパイルとかで ES6 の書き方をするとエラーになってたりしたけど、それがスラスラ書けるようになったのは嬉しい限りだ。

以下の本は是非読んでおくといいかと思う。このために Kindle の Mac アプリをインストールして読んだ甲斐があった。この値段でこのコンテンツはありがたすぎる。

let, class, Arrow Function.. こうした新しい JavaScript コーディングによって、 Rails のフロントエンドの書き方も大きく変化する。んで意気揚々とアロー関数を定義しまくってたら、this の挙動で悩まされることになるので、これも勉強しておいたほうがいいかもしれない。こんなん、初めて書いたら絶対ハマるやろっていう感想しかなかった。特に メソッド Callbasck 内での this の挙動が怪しい。。ここら辺、いい書き方を今後模索していきたい。

【JavaScript】アロー関数式を学ぶついでにthisも復習する話 - Qiita

おまけ: 地味に使えなくなってる

render text: "ok" 的な書き方ができなくなってたw render plain: "ok" って書くのが適切なようだ。まぁそもそも render json とかにしろって話かもしれないが。

終わりに

Rails 5.1 といえばフロントエンドの大きな変化なので、そこに焦点が移った。ひとまず Yarn の導入と ES6 形式で Asset Pipeline が書けるってのが個人的には嬉しい点だった。

Rails 5.1 のレールにも乗っていけそうで、一安心した週末となった。

Heroku Addon 「Scout」 の紹介

ども、@kimihom です。

Heroku Addon の1つである Scout はRuby on Rails 専用のメトリクスサービスだ。一般的にこの類の Addon だと NewRelic が一般的だけども、重いしメモリも食うので Scout を使っている。今回はそんな Scout について簡単にご紹介しようと思う。

f:id:cevid_cpp:20171031203903p:plain

概要

Heroku は Heroku 自体が Metrics を提供しており、ここでサーバー全体でどんなパフォーマンスを発揮しているのかを見ることができる。しかしあくまで概要しかわからないので、具体的にどの URL のアクションが問題を起こしているのかまでは教えてくれない。そのため Scout や NewRelic のような、より詳細を見ることのできるメトリクスの Addon が存在する。

以降は Scout のスクショ見せながらの方が早いと思うので、色々と貼りながらアプリのチューニングについて解説していく。

1, 概要チャート

f:id:cevid_cpp:20171031201220p:plain

まずは直近でのレスポンスタイムや、メモリの上昇具合などをグラフで表示してくれるチャートがある。チャートとして表示する項目自体は Heroku の Metrics と何ら変わらないのだけど、Scout のすごいのは日時で限定して、その詳細を表示してくれるところにある。例えば上図のようにレスポンス速度が遅かった時間帯にフォーカスすると、具体的にどのアクションが最も遅かったのかを一発で表示してくれる。

特定の1アクションが裏でめちゃめちゃ重い処理をしていて、ユーザーがたまにしかそこにアクセスしないような場合を考えてみよう。この場合、そのアクションを実行された瞬間に一気にレスポンス速度が遅くなるし、メモリが上昇することもあるだろう。そんな時は上記の図のような感じで期間を指定しながら最も遅かったリクエストを調査していくことが可能になる。ちなみに "Slowest Resopnse Time" が現在選択されているが、その他に Largest Memory Increase がある。

2, Memory Bloat Insights

f:id:cevid_cpp:20171031201735p:plain

特定の1アクションが原因で、サーバー内のメモリが急上昇するのが Memory Bloat と呼ばれる現象だ。Scout ではそれを一発で見つけてくれる。私の経験則としては、上図のように 単一リクエストで 10M くらいだったらあまり気にする必要はないと思う。全てのリクエストで Memory Bloat が 50M 以上だったりする場合は、それは明らかに直すべきという感じで見るのがいいと思う。

じゃあ具体的にどんな原因で Memory が増えるのかってのは、以下のようなケースがある。

  • 重い DB クエリ
  • 1度に大量のクエリを発行
  • ファイルアップロード
  • blob など大容量のデータを読み込んでしまう

それぞれに最適化の方法があるので、もし原因がわかった場合には調べて対応していこう。

3, n+1 Insights

Rails において N+1 は深刻なコードミスだ。簡単にいうと、毎回 SQL のクエリを投げるコードを each の中に書いちゃった場合に発生する。

@artilces = Article.all

<% @articles.each do |article| %>
  name: <%= article.user.name %>
<% end %>

残念ながら、このコードを書いた時点で N+1 が発生してしまう。aritcle.user の時点で Article に紐づく User を View のループの中で SQL で探しに行かないといけないからだ。具体的には @artilces = Article.includes(:user).all とするのが正解だ。これでわざわざ View の中で 複数の SQL を発行しに行かなくなる。

てな対策をしろってのを Scout が教えてくれる。本来ならローカル環境で Bullet Gem を入れたりして見つけるべきことなんだけど、本番データとしてちゃんとある場合にしか見つけられないケースとかたまにあったりするので便利だ。

各アクションの分析

どのアクションが重いかわかったら、具体的にその中のどの部分が遅いのかを見ていこう。アクションの詳細にいけば、それが全てわかる。

f:id:cevid_cpp:20171031203311p:plain

今回はわかりやすいようにわざと外部への HTTP リクエストを送るコントローラーを例にしてみた。上記のように、このリクエストの大部分は HTTP が原因であることがわかる。これが例えば DB クエリが遅いってなら SQL のチューニングなどをしたり、コントローラー自体が重いってならコントローラーのロジックを再検討する必要があるということがわかるというわけだ。

終わりに

こんな感じで遅いアクションを見つけて、その原因を1つ1つ取り除いていくっていう地味だけど大事な作業が安定したサービス運営につながっていく。Scout はこの他にも DB クエリのメトリクス、Github 連携、アラート通知機能などを提供している。無料でもそれなりに原因を見つけられたりするので、まずは試しに入れてもらえたら幸いだ。課金はそれなりにサービスが運営できるようになったらでいいと思う。

こういうのって実際にそれなりの Web サービスを運営していないとわからないことなので、当てた Web サービスを作った後にはぜひ知っておいていただきたいと思う。

"このサービス重すぎて使えない" ってなった時にはもう遅いので、その悲劇が起きる前に一つずつ解決していこう。

Webフロントエンド ハイパフォーマンス チューニング

Webフロントエンド ハイパフォーマンス チューニング

人を心から応援したくなる瞬間

ども、@kimihom です。

皆さんには、心から応援したいと思えるようなことをしている人はいるだろうか?

f:id:cevid_cpp:20170119221657j:plain

こんなことを書き出すと、まるで自分の夢を捨てたかのような思いをされる方もいるかもしれないが、決してそうではない。自分も夢を追いかけている最中でも、「この人の夢は実現してほしいな」と思う人ってのが極稀にいる。「心から応援したい!」と思うことが滅多にないのは、大抵はその人の事業をやっている理由をそこまで知る機会がないし、知ろうともしないことが多いからだ。世間話で盛り上がればいいってのが大人の社会ってものだと思われている節がある。

私はあえて「なぜその事業をやるのですか?」というのを遠回しに聞くことがある。悪い言い方をすれば試しているってのがある。んで、その話題になると突然ギアがかかったように、本気で真剣にそして永遠に自分の思いを語り続ける人がいる。一般的には、こういう人ってのは"めんどくさい人" だと思われがちだけども、私はそんなめんどくさい人をとても尊敬しているし、心から応援したくなる条件の一つだと思っている。

あなたの周りに、そんな人はいるだろうか?こんな便利で安定しきった社会の中で、そんな思いを持っている人に巡り会うことは滅多にない。でもだからこそ、たまにそんな狂った人を見つけると、感動すら覚える。

たまにそれっぽい人を見つけることはある。「俺は〜になる」系の人たちだ。でも基本的に私利私欲を目的に動いている人ってのは本気で語ることはしない、いやできない。そこに使命感を見出すのは困難だからである。そうではなく、社会をよりよくするために動いている人ってのは使命感を持つことができる。自分がこれをやらなきゃ誰がやるんだ!と言わんばかりの熱い思想である。

時代の最先端を行くベンチャー企業とかは、実は夢を持っていなかったりする。ただ単に流行に乗って一目置かれて、ビジネスが成功すればいいと思っている。そして目立って金持ちになるのが彼らの理想だ。結局のところ、その程度の熱意である。

本気で何かをやろうとしている人は時代に流されることなく、ただひたすらに自分の理想の実現のために今できることを考えている。四六時中そんなことばっかりやっているので、会うのは難しいし話を聞き出すこともなかなかできない。だからこそ貴重な存在とも言える。

原体験こそがモチベーションの源

心から応援したくなる人には、何かしらの原体験がある。その人に火をつける原体験であれば何だっていい。実はその原体験っていうのは、他の人から見ればほんの些細なことだったりすることが多い。それでも誰かからとやかく言われようとも、自らのゴールを信じて進み続けることが大切だ。

いつも単なる思いつきで行動しているだけでは、自分の信じる道ってのは開けない。「自分はこうありたい、こう変えていきたい」と思えるような原体験を通じて、人は行動に拍車をかける。例え自らの資金が尽きたとしても、諦めることなくその事業を続けることだろう。そんな意志を持って続けられる人にこそ、お金ではない最後の本当の意味での成功を手に入れられるはずだ。

このような原体験からの強烈モチベーションを持っている人こそ、心から応援したくなる人の条件である。

心からどうやって応援しようか問題

心から応援したくなる人がいたとして、「頑張れ〜」とフルマラソンを走っている人に旗を振っているようなのでいいのだろうか。とはいえお金っていうシンプルな解決策は、応援している人そのものを変えてしまう麻薬のような効果を持っている。私はそれはしたくない。

私と一緒に走ろう!私も自分のペースで目標に向かって走り続ける。どちらが早いか遅いかではない。それぞれのゴールに向かってちゃんと走り続けられるかが大切だ。途中疲れたとしても、お互いが励ましあいながら進んでいけば、時間がかかってもいつかゴールにたどり着けるはずだ。

このブログや運営しているサービスが一緒に走っている人を支え、それぞれの目的が達成できるような何かを提供し続けられれば良いなと思う。だからこそ、まずは私が先にマラソンのスタートを切って走り続けている。まだスタートを切っていない方は、私についてきてほしい。

終わりに

人は心の底で何か思いを持っていても、ほったらかしにしているとどんどん冷めていく。定期的に自分を振り返り、方向を見失わずに続けていきたい。 そのためにも、心から応援したくなる人と一緒に走り続けたいと思うのである。

Rails 5.1 のフロントエンド周りの所感

ども、@kimihom です。

常に話題に上がってくる Rails のフロントエンド事情だけども、今回 Rails5.1 を色々みた中で自分が感じたことについて書いていく。予め断っておくと、自分もまだそこまでフロントエンドをマスターしている身ではないので間違った考え方の部分もあるかと思う。その場合はぜひコメントなどいただけると幸いだ。

Rails Guide は今でも rails-ujs

jquery-ujs が rails-ujs に変わったなどで、脱 jQuery を果たした Rails5.1。この時点で他のフロントエンドフレームワークに移ることを検討した方も多いかもしれない。

そもそも、jquery-ujs って Rails において結構大事な役割を果たしていると思うので軽く説明すると、要は <%= form_for @article, remote: true %> なフォームで Submit した時に、 Ajax でリクエストを送って対象 Form のイベントに ajax:success などの形式でコールバックが呼ばれる仕組みだ。これが今までは jQuery 依存だったけど、その依存が取っ払われた感じになる。Rails 5.1 では form_with ってのが登場した。

この rails-ujs についてよくよく考えてみると、その他のフロントエンドフレームワークを使おうと思った時点で、rails-ujs のような仕組みは不要になっちゃう気がする。なぜなら、その他のフロントエンドフレームワークでも Form を作る機能を兼ねそろえていて、そっちを使っていくことになるはずだからだ。特にモデルを フロントエンド側で管理しているなら、完全に form_with などは機能が重複してしまうので rails-ujs 自体要らない子になる訳だ。

でも Rails Guide には今でも rails-ujs を使ったサンプルがあるし、残り続けている。それはつまり モデルのデータバインディングの仕組みのない何か を使うことが今でもベースになっているように思う。これはとても理にかなっている。なぜならサーバー側でフォームを生成すれば、フォーム生成は form_with を使って生成できて、I18n は Rails 側で管理された言語ファイルから読み出すことができ、バリデーションやエラーメッセージの表示など、全て Rails の ActionView 側に一任することができるからである。Rails を使っているのに、これらの処理をフロントエンドフレームワーク側でやるってのは機能の使い方として重複しており、それやるんだったら ActionView 自体の機能をごっそり削ぎ落とした RailsAPI 使ったほうがよくね、となるのは当然のことだ。だから Rails API が Rails5.1 から標準で使えるようになったのだろう。

link_toform_withremote: true な Ajax 通信を行い、フロントエンドではレスポンス時の UI 更新だけをする。こうすればフロントエンド側の責務はシンプルになる。Gmail や Facebook 並みのガリガリのリッチな Web アプリケーション作りたいってなら話は別だけど、たいていの Web アプリケーションは "検索して詳細見てフォーム投稿" といったオーソドックスな仕組みだろう。それをわざわざフロントエンドフレームワークに適用するのは、やはり Too Much だと考える。ちょっとしたページ遷移を素早くしたいってなら Turbolinks を使えばうまく History API をラップしてくれるし、Rails はあくまでもそうした用途向きに作られているのだと以下の動画で教えてくれる。

RailsConf 2016 - Turbolinks 5: I Can’t Believe It’s Not Native! by Sam Stephenson - YouTube

f:id:cevid_cpp:20171027225345p:plain

そう、あなたは Google でもないし Facebook でもないのだ。 個人的には Turbolinks は使わないで History API を自前で作ってるのだけど、基本的な Rails のフロントエンドの考え方について上記の Rails Conf での動画は参考になる。

で、お前は Rails 5.1 のフロントエンドでどうするの

まだ模索中である。少なくともバインディングがあるような Too Much な機能は必要とせず、素の JavaScript が簡素化されたくらいのものでちょうどいいと考えている。素の JavaScript で書くのが面倒だったら、もしかしたら jQuery 3.0 の採用もありうる。

そんで ActionView をちゃんと使って form_with でフォームを作成する。Ajax 通信時に断片的な HTML もしくは JS を返してあげて、jQuery でいう $().html()$().append() などで動的に HTML を変えていくシンプルな実装にしたい。部分的なところだけをアップデートするみたいなことをするのは正直複雑になるだけだと思ってて、だったらページごと body.html() で変えたり、大枠の div だけをごっそりと変えるような Turbolinks 的な方法で問題ないように思う。こうすることで、ちゃんと Rails のレールに乗って開発効率を高めて無駄な時間を省き、良いプロダクトを作ることに専念できるはずだ。

もちろん Gmail 並みのガリガリのプロダクトを自分が作るってなら話は別だ。でも、そもそもそういうのを作るんだったら、Rails 自体を採用するのがナンセンス だと私は思う。

終わりに

Rails 5.1 フロントエンド周りの所感についてまとめてみた。当然それぞれ考え方はあるだろうから、1つの考えくらいな感じで参考にしていただければと思う。

少なくとも私は Rails の提唱する実装方法に素直に従って開発し、Rails と共に 良いサービスを作ることに専念していきたい。そういう考えのもとで得た答えが、上記のような開発スタイルである。

今後 Rails 5.1 でちょいちょい開発していく予定なので、何か新しいことがわかったら記事にしていく予定だ。