読者です 読者をやめる 読者になる 読者になる

ボクココ

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

今プログラミング教育に最も必要なのは「革命児 」

雑談

ども、@kimihom です。

f:id:cevid_cpp:20160720235140j:plain

最近はプログラミング教育がとても盛んになってきているが、ここで自分の思っていることを記そうと思う。先に断っておくと現在のプログラミング教育はどんどん進んで欲しいと思っているし、プログラミング教育を否定するつもりはない。

子供の自主的な成長を促すのは「夢」

現代の子供達の革命児は誰か。いつの時代も子供達は"世界を救う・変える"革命児に憧れる。

その最も典型的な職業がプロスポーツ選手だろう。最もスキルが高くて活躍する選手は、他の誰よりも試合を変える力を持っているし勝ちに導く大きな影響力を持つ。テレビなどで見ていれば誰でも目に触れるし、目標としやすい人物である。だから子供達はそんな選手になることを夢見て近くのグラウンドで野球教室やサッカー教室に自ら通うのである。

さて、スポーツで言えば大谷選手とか本田選手とかすぐに思い浮かぶんだけども、プログラミング業界で活躍できる分野である我々インターネットやソフトウェア業界での革命児といえば誰だろう?誰が世界を変えているほどの活躍をしている?今でいうと正直誰もいないというのが私の感想だ。私が学生の頃は孫さんや堀江さんなどがいて、野球やテレビ局などあらゆる分野で日本の構造を変えようとしていた真っ只中だった。ITバブルとも言われていた時代だからこそ、私もそういう影響力のある人間になりたいということでプログラミングを勉強し始めたものだった。(案外そういうモチベーションでプログラミングを勉強し始めたという人が周りにいないのがちょっと驚き)

アメリカだとその時代に合わせてネット業界の革命児 がどんどん出てくるのよね。現在だと Twitter の Jack Dorsey だろうか。もちろん Facebook の Mark Zackerberg でもいいだろう。そんな社会に影響を与えるレベルの典型的な革命児 がいるから、子供達はそんな存在を目指してプログラミングを勉強するようになるのである。圧倒的なプログラミングに対するモチベーションを得たところで、そのはじめの一歩としてプログラミングスクールなどに行けば、群を抜いて勤勉に勉強するだろう。そんな子供たちを増やすためには、やはり日本でのネット業界の革命児 が必要なのだ。

革命児 の条件

ではどんな人がいれば子供達の革命児 になれるのだろうか。やはり子供達(と言っても高校生くらい?)の目に触れるレベルにまで達しないといけないってことでかなりハードルが高い。

  • 尋常じゃないほどの情熱
  • 若くして成功した存在であること。
  • 既存の汚れた業界をぶち壊すような存在 (ケンシロウ的な)
  • SNS で圧倒的なフォロワー数(まずは大人の支持から)
  • 頻繁にテレビのニュースで取り上げられる程の思い切りの良さ

こんな人が日本のネット業界に1人でもいればいいのだが・・。やはり若くして成功するってところが難しい部分である。

最近は ベンチャーキャピタルで学生起業した若い人に出資するケースも増えていると聞く。そんな中でブレイクする企業が出てきてほしいものである。ただし、ここには一つ大きな問題がある。どうしても素人がアプリやサービスを作っても爆発的に成功するほどのものは作れないのだ。なぜなら、最近のスマホ世代の子供達はいいアプリ・悪いアプリの判断はすぐにできて、それぞれがSNSで影響力を持っている。この状況でサービスを成功させるのに必要なのは、圧倒的な操作感と素晴らしい体験だ。このセンスや技術を学生のうちに身につけるのは至難の技である。ネット業界のどの社会人も躍起になって研究している分野なのだ。

そう考えると、20代前半で人気サービス・アプリ開発の経験を積み、20代後半で一気にチャレンジするようなスタートアップに私は一番可能性を感じている。30歳前後(できれば20代が望ましい)で大成功した存在になれば、子供達の夢となれる存在くらいにまでなれるだろう。ただ、20歳後半にでもなると結婚とかも考え出す年齢になるのが難しいところ。そこを断ち切り、人生一度の大勝負に20代後半で toC 領域でチャレンジできる起業家を私は応援したいと思う。

20代の起業家は、ただ単に事業を成功させるだけで終わらせて欲しくない。子供達の憧れになるレベルの人間を目指すことのできる起業家が増えれば、日本のプログラミング教育はもっともっと盛り上がることだろう。

私自身も20代後半で起業した身として、そんな存在の一人としてなれるよう引き続き頑張っていきたいと思う。まぁ私は Jobs を陰で支えた Wozniak 的な存在の方が憧れているんだけどねw

サバイバルエンジニアのすすめ

スタートアップ

ども、@kimihom です。

最近は「グロースハックエンジニア」とか「フルスタックエンジニア」とか色々な言葉が飛び交っている中、自分は何エンジニアなのかを考えてみた。いくつかあった中で「サバイバルエンジニア」ってのが適切な気がしたから今回この記事で勝手に定義したいと思う。

サバイバルエンジニアとは

さて、サバイバルエンジニアとは何かってことなんだけども、端的に言えば「自社サービス開発で得た収入だけで生きて行く」という働き方を実践するエンジニアだと意味づけたい。自社サービスってのは当然のことながら受託開発と違って最初のうちから給料の出るものでもないし、将来収入が入ってくるかどうかもわからない。最低限生きる給料を得られるようになるだけでも1年やそこら普通にかかることだろう。減り続ける貯金と真摯に向き合い、その限られたリソースと時間の中で、サービスを成功させるために自分にできることを全力やりきる。エンジニアとはいえ開発以外でもサービスを成功させるためなら何でもやる。それがサバイバルエンジニアだ。

ほとんどの人はバカなんじゃないかと思われるかもしれない。ベンチャーだったら出資を受ければいいし、受託で食いつなぎながら自社サービスを開発することだってできるじゃないかと思うのが普通だ。それでも俺ならできるという根拠のない自信がサバイバルエンジニアに必要だ。

サバイバルエンジニアのメリット

ではサバイバルエンジニアの何がいいのかというと、全て自分の思い通りにサービスを運営し、本気で改善し続けることができるという点だ。

思い通りに運営することは非常に重要だ。第三者が事業に絡み始めると、その途中でアドバイスという名の色々な横槍が入ってくるのである。その横槍は、当初サービスを作り始めた創業者たちが思っていたのと全く違う方向に進んでしまう結果を招きかねない。それを良い意味でピボットと呼ぶのかもしれない。でも、それよりも本当に大切にしなきゃいけないのは自分たちのやりたいことや夢なのだ。良いサービスってのは、何かしら作り始める前に創業者の体験から生まれることが多い。「あの時自分が不便に思ったから、それを解決するために作ってるのです」と言える状態は、サービス開発において成功を生む大きな要因となる。その軸をブラさない程度にピボットをしていくべきであり、その軸がなくなってしまうようなピボットはチームの崩壊を生む要因となりうる。大切な軸は第三者が絡むことよっていとも簡単になくなってしまう。そうなると何のために起業したのかがわからなくなるような状態となり、何のために起業したのかもわからないような状態になる。

何も言わない第三者の投資家であればいいってことなのだろうか?それはそれで一理あるし、本当に資金が必要なのであれば資金提供を受けることも致し方ない部分はある。それでも出資を受けないのは一種のプライドであり、自分の力だけで何が何でも成功させるという強い意志を生むにはサバイバル的状態が必要だと私は思うのである。金があれば楽をしてユーザーを獲得したいと思うだろうし、人を雇って嫌いな仕事を任せたいとか、そういうことを考え始めるようになる。結局のところ他人の金なので、どんなに大事でも自分の金ほど本気で大切に使おうなどとは思わない。

何より、自分の力で成功させたと自信を持って言えなくなる。「私が成功したのはあの時お金を出してくれたあなたのおかげです」となってしまう。

本気で改善ができるという点も重要だ。自分が本気でサービス開発をやって、それでユーザーが獲得できずにサービスが失敗してしまったなら納得がいく。純粋に自分の力不足だったと言えるからだ。しかし、サバイバルエンジニア以外で作られたサービスは、他にいろいろな言い訳ができてしまう。まぁこれは単なる精神論っぽい話だけども、心の奥底で感じるものってのは今後の人生にも影響を与えることなんじゃないかと私は思う。

サバイバルエンジニアになるために

似た記事を以前書いたのだけども、そうすると結局「金持ちしかそんなことできないだろ」みたいな意見が出てくることに私は悲しみを覚える。なぜそうやって環境のせいにするのだろうか。しばらく企業に勤めて勉強をしながら給料をコツコツ貯めていけばいいではないか。4~500万もあれば1,2年は給料なくても生きていけるだろう?その貯金もせずに旅行とかデートとか要らないものを買ったりして金を消費して、それで金がないとか言うような人にはサバイバルエンジニアになることなんてできない。別に今からなる必要なんてないのだから、じっくり自分の夢の実現のために貯金をし、技術を磨いていけばいいだけの話だ。

今の時代、必要なのはプログラミングのためのPCとプログラミングするための場所と食費くらいだ。運動は外を走ればお金は何もかからないし、食費も自炊すれば月3万いかないくらいで収まる。ただ単に本気でやるかやらないかだけの差であり、それが生まれ持っての金持ちかそうでないかなんて関係ない。

本当に金がなくなった時の心配は必要ない

ではサバイバルエンジニアが 1,2 年しても事業がうまくいかなかったらどうなるのか?全く心配ない。その1,2 年でもがき続けて磨かれたビジネス感覚と技術力はどんな企業でも欲しがる能力だ。どこかにまた就職するには、今まで死ぬ気で作り上げたプロダクトを見せて、「このシステムを私一人で作りました」と言えばいい。自立したエンジニア、ビジネスと技術を兼ね揃得たエンジニアは今 市場で最も求められる存在だ。何も恐れることはない。そしてまた金を貯めてチャレンジすればいいのだ。

1,2 年経った時に金がなくなった時のことを心配をするレベルのエンジニアにしかなれなかった場合は、その程度の努力しかしてこなかったということだ。そういう人は間違いなく普通の企業で給料をもらいながらのんびり生きていたほうがいい。これには向き不向きがあるので、素質のある人にだけオススメしたいと思う。

思想のあるサービス

思想のあるサービスってのは必ず作った人の想いがサービスに反映されている。その思想に共感したユーザーを獲得することは、広告をばらまいて獲得するユーザーの10倍くらいの力を持つ。思想に共感したユーザーはプロダクトを使い続けてくれるだけでなく、他者にまで紹介してくれるようなユーザーになってくれる。

思想を持つサービスを作るには、誰から言われることもなく自分の意思だけで作り続けられることが条件だ。サバイバルエンジニアはそれを実現する最もシンプルで確実にできる素質を持った職種ではないだろうか。

誰かに言われたことをそのまま実現して満足するだけのエンジニアで留まりたくないというみなさん、ぜひ人生をかけて本気でサービスを開発し、人々に喜んでもらえるサービスを実現してみてほしい。そのチャレンジをした人にだけ、素晴らしい未来が待っていると私は信じている。

スタートアップのサービス開発における「スケールしないこと」とは

スタートアップ

ども、@kimihom です。

f:id:cevid_cpp:20160715001510j:plain

スタートアップをうまく成功させるには、 スタートアップはスケールしないことをしよう ということはとても大事だと思う。スケールしたいんだけどあえてスケールしない努力をすることで、今後のスケールを実現することができるのである。そのことについて理解を深めたい場合は以下のスライドがとても参考になる。

www.slideshare.net

端的に言うと「スタートアップにマーケティング担当者は害。いない方がマシ」っていうことだ。となるとエンジニアとかデザイナーみたいな直接プロダクトを改善していくような立場じゃない人は、人々の話を聞きに行ったりすることになる。

ではエンジニアはどうすべきか? 今回はスタートアップエンジニアにおいて、"やるべきでないスケールすること" と "やるべきであるスケールしないこと" についてそれぞれ考えてみようというのが本記事のテーマである。

やるべきでないスケールすること

色々とあるのでそれぞれ挙げて解説しよう。

技術選択の失敗

よくある話として、「あの有名なスタートアップ(と言いつつもう従業員が100人以上いるようなところ)がこんな最新技術を使っている!自分たちもこれを使って実現しよう!」という本来のスタートアップの目的とかけ離れた理由で技術選択をしてしまうパターンがある。

そういうのって、いわゆるインフラをよりクールにする技術だったり、よりたくさんのアクセスを捌けるような技術だったりするわけだ。そんな技術がスタートアップに必要かというと、 No なのである。ああいう"クールな技術使ってるぜアピール"は、基本的に最新技術に興味のあるエンジニアを採用するためにやっているのであり、スタートアップがその技術を採用すべきとは誰も言っていないのだ。

サービスのコアとなる重要な技術でもないのに、その技術勉強に時間をかけたり、よくわからんエラーで無駄な時間を使ったりするようではスタートアップの技術者として失格である。

今後うまくいったことを考えてスケールするような技術を使う必要はないのである。うまくいくかどうかもわからない段階でね。

"豊富な"何か

豊富な"機能"に関しての問題は以前記事にした。

www.bokukoko.info

豊富なページ数, 豊富な資金、豊富な人材、豊富なサーバー。豊富なツール。

どれもこれも必要ない。

制約のある場に創造は生まれる」のである。

マーケティングツールの導入

これは先ほどのマーケティング担当者が必要ないって話にもつながるんだけど、"ユーザー獲得のための~" みたいなプロダクトは全て導入する必要はない。ユーザーの分析とかそんなことするくらいだったら自分で直接顧客に聞きに行けばいいだけなんだから。直接使っているのを見て、聞いてフィードバックを得るような努力をすることこそがスケールしないことなのである。

ああいうマーケティングツールってのは大企業が楽してユーザー数を獲得して上司にいい顔見せたいという人間が、偽りのユーザー獲得をするために必要なシステムなのである。私たちエンジニアにできることは何か。誰かが踏み誤ってそういうツールを導入しようとしていても、そのツールのHTMLなどの断片コードを自分のシステムに埋め込まないことだ。自分が実装しなければそもそも導入できないので、誰が何と言おうと関係ないだろう?



やるべきスケールしないこと

さて次はやるべきスケールしないことについて。

メイン機能の改善

メイン機能を少しでも早く、精密に、美しく。2秒速くなったことに最高の喜びを感じ、精度がちょっと上がったことに喜びを感じ、機能を1つ減らしたことに喜びを感じよう。基本的には最新技術ではなく既存の成熟した技術を使おう。そして差別化要因として必要な技術だけは最新技術を使い、自分たちの強みとして誰にも真似できないくらいの改善を続けていこう。メイン機能で使われている、この技術だけに関して言えば誰にも負けないってのを持つことが、エンジニアとして最高の強みになる。

その最新技術は1個に絞るべきだ。あれもこれもってのはやはり難しいし限界がある。凄いんだけどもちょっとクセのあるもの。1つに絞る技術はそういうのがいいと思う。周りからすれば実現に時間がかかってやりにくいって思っているからこそ、スタートアップの存在価値が上がるのである。

素晴らしいスタートアップであれば、必ず「この技術だけは誰にも負けねぇぜ」ってのがあるのである。

ユーザーサポート

"エンジニアは集中している時間が長いから、電話やメール対応をできるだけしたくない"。そんなエンジニアが多いと思う。だがそれは単なる甘えに過ぎないと私は思っている。思い出して欲しい。私たちがやるべきことはスケールしないこと。つまり開発そのものを止めて、ユーザーサポートに時間を取るということなのだ。

ユーザーからメールや電話で問い合わせが来た時に、システム関連であれば早く答えられるのは当然エンジニアである。だったら進んでその仕事を引き受けるべきだ。ユーザーと直接話すことで見えてくる新しい発見が必ずあるし、モチベーションにもつながるだろう。

電話で取次をしないで即答する。メールも1つの返信で全てが解決する。そんなサポートをすることでユーザーの満足度に差別化を与えることができるのだ。

記事を書きまくる

とにかく記事を書きまくろう。それは技術ブログだけに限った話ではなく、自分たちのサービスの思いや、オウンドメディアなどもあるだろう。とにかく書かないことには検索にすら引っかからないし、誰も読んでくれない。バズ狙いやシェア狙いといったところで記事を絞るってやり方もあるかもしれないが、そんな一過性のものを目指すのではなく、ロングテールで検索でしっかりと出てくるようにするには記事を書きまくるしかないのだ。

最初は全く読者もいないし何のフィードバックも得られない。それでも自分たちの思いを発信することはとても重要なのだ。書いていけばいくほど文章力は上がり、洗練されたものになっていく。だから最初はぐちゃぐちゃでもとにかく書いてみよう。

ここまで読んで頂いた読者なら、記事を書くのに外注したり誰かを雇ったりするのがいかに愚かな行為なのかがわかっていただけると思う。



終わりに

エンジニアだからといってプログラミングばかりやればいいというのはスタートアップ的考え方ではないと私は思う。もしそうしたいんだったら大企業の研究開発部門とか新規開発部門いったほうがよっぽど幸せになれるだろう。

ではなぜエンジニアがスタートアップをやるのか。それは"自分がゼロから作ったものが世の中に影響を与えている"ということを実感するためではないだろうか? プログラミングってのはその中の一つの手段にすぎない。それ以外に必要なことがあるんだったらエンジニアの仕事の枠を超えてどんどん働きかけていくべきなのだ。

スケールしない努力のできるスタートアップエンジニアが増えることを祈っている。

Firebase はアプリ開発者のヒーローとなるか

Android Firebase iOS

ども、@kimihom です。

f:id:cevid_cpp:20160713231835p:plain

今日 Firebase の勉強会に行った。あらかじめ動画とかで Firebase の予習はしてたんだけど、今回の勉強会で実際のユースケースとか具体的な使い方を知ったことでよりイメージが湧いた。そこで感じた Firebase について今回はちょろっと語ろうと思う。

アプリ開発におけるサーバー/サービス選択の歴史

基本的にネットワークを使わずにアプリだけで完結するアプリってのは単純なものが多く、ユーザーを獲得することは困難になりつつある。より良いアプリにするには、クラウドと連携して"つながる"とか"最新情報がある"アプリにすることが大事であることは自明なことかと思う。

そんな中でエンジニアがアプリ開発している時に大抵決まって同じような悩みを抱く。その典型が"サーバーどうするの"っていう話。サーバーがなければ画像を置くこともできないし、ユーザーを管理することもできず、情報を取得/更新することもできない。要するに何もできないってわけだ。

今までは自前で API サーバーを持つことが一般的だった。これは今までの Web 知識を用いれば多少時間がかかっても実装が可能だし、Webアプリとの連携もデータベースを共有することで可能になる。 だから大手とか小さいところでも自前で API サーバーを持つことが多かった。というよりそれくらいしか選択肢がなかった。

でもみんなやるよねって機能はやはり楽をしたいもの。 AWS をはじめとしたモバイルのプラットフォームがどんどん出てきて、アプリ開発者が自前でサーバー実装しなければならないことを極端に少なくしてくれた。アプリエンジニアはそれらを活用することでより早くより高品質なアプリを作り出すことができる。

しかし、次に問題になってくるのは色々なアプリ開発のモバイルプラットフォームを使うと、アカウント登録がその都度必要で、クレジットカードとか登録情報とかいちいち管理しなければならない問題が出てくる。またそれらの情報を統合的に管理することができず、それぞれがそれぞれのデータを持って分断された分析や機能の追加しかできなかったわけだ。AWS のモバイル系のサービスは各種機能を統合することを実現してはいるが、"アプリ開発に特化した"って意味では弱い部分があると個人的に思う。AWSをはじめとした総合的な開発プラットフォームでは、各種サービスが Webでもモバイルでも使える汎用的な部分が多く、アプリだけで欲しい特化したサービスが弱いと感じている。

そこでつい最近に進化した Firebase である。進化した Firebase は"モバイル開発において必要だよねー"ってところを基本的にすべて統括的に提供している。Firebase にまとめて情報を管理するようにすれば、断片的だったデータを一元管理できるようになり、使う SDK も最低限のものだけにすることができる。いろんなSDKを詰め込むようなことはしなくて良いし、余計なコードを書く必要もない。(Firebase の各機能は Gradle 経由で簡単にインストールできる)。 確かに機能的には他の専門ツール(例えば分析系)に劣る部分はあるかもしれない。ただそれも時間の問題で、ゆくゆくは Firebase だけですべてがまかなえるような、そんなプラットフォームになっていくだろう。

特に Firebase では Web とアプリの垣根をなくしていくという点で、Deep Link や App Indexing などの Google 検索などに親和性の高い機能も提供しており、これらは Firebase ならではという感じがしている。今までのFirebaseであるリアルタイムデータベースもそうだし、 Remote Config もまさにアプリだからこそ欲しい機能であり、AWS など汎用的なクラウドプラットフォームでは提供できていない部分である。

開発プラットフォームの選択

私はこのような思いからアプリ開発に特化した開発プロジェクトを始めるなら Firebase を使う。というか使い始める予定である。

しかしアプリに特化というよりも、 CGM(ユーザーがログインして投稿しあうようなサービス) のような従来の Web サービスをそのままアプリにするっていうのであれば、 Rails の Turbolinks などを活用したアプリ作成の方がいい選択になる場合もあると思っている。最近のHTML5の技術と、それ+@ 程度の機能の要件のサービスであれば、Webベースのアプリを検討すべきである。この場合は Firebase を使う必要はほとんどないだろう。詳細は以下の記事に書いた。

www.bokukoko.info

当たり前の話ではあるが大事なのは適材適所である。

私の Firebase に対しての唯一の要望

そんな私が絶賛する Firebase だが、あと一つ欲しいものがある。それがサーバーサイドでロジックを実行できる、 Cloud Functions と Firebase の連携だ。やはりどうしてもサーバーサイドで実行したいようなロジックがあるときに、Firebase で Cloud Functions と同等の機能があれば、もう他のアプリ開発サービスを使う必要はなくなってくると思う。わざわざちょっとしたロジックだけのために Google App Engine や Google Cloud Platform などは使いたくないってケースは大いにあるだろう。

この願いを持っている人は他にもいるみたいで、今 Google では検討中? な感じのようである。

Google グループ

終わりに

この記事を書いた背景としては、まず進化した Firebase がすごいと感動したからであり、その凄さをまだほとんどの人は知らないんじゃないかという思いで書いたというのがある。

一部の熱狂的なアプリ開発者だけが使われて、それらのアプリだけが差別化してどんどん成長していくってのはもったいない気がしたので、ぜひ経験の浅いアプリ開発エンジニアでも Firebase にチャレンジしてみて欲しいと思う。

ドキュメントはやはり英語だから辛い部分もあるかと思う。でも英語を読むだけで実装のほとんどをやらなくて済むようになるので、頑張ってみて欲しい。

私もこれからどんどん Firebase を使っていくが、そこで得た知見は適宜このブログで書いていきたいと思う。

はてなブログで1年以上前の記事にアラートを出す方法

ども、@kimihom です。

某企業の技術ブログをリスペクトし、記事が1年以上前のものは この記事は公開から1年以上経過しているため、情報が古い可能性があります。 と表示するようにしたので、実装メモ。

例えばこんな感じになる。1年以上前の適当な記事を貼っておく。

記事の上下のカスタマイズ

まずは HTML と JavaScript を書いていこう。デザイン設定の記事 -> 記事上or下 のエリアに以下のコードを書こう。

<script>

var timer = setInterval(function() {
    if (typeof jQuery != 'undefined') {

//////////////
// check if the article is old or not
var currentTime = (new Date).getTime();
var articleTime = Date.parse($(".entry-date time").attr("datetime"));
var day365 = 1000 * 60 * 60 * 24 * 365;
if (currentTime - articleTime > day365) {
    $( "<div/>", {
      "class": "old-article",
      "text": "この記事は公開から1年以上経過しているため、情報が古い可能性があります。"
    }).appendTo( ".entry-header" );
}
//////////////

        clearInterval(timer);
    }
}, 1000);

これだけ。今回は jQuery の書き方講座じゃないので詳しい解説はしない。適宜コードを入れ替えて条件を2年以上前にするとか、文言を変えたりだとか、挿入場所を変えたりとかしていただきたい。

CSS の設定

ここら辺はもう書くまでもないかもしれないが、一応自分のブログの CSS を貼っておく。自由にコピペしてもらえれば。

.old-article {
    border: 1px solid grey;
    padding: 8px 12px;
    margin-bottom: 24px;
    border: 2px solid #ecd218;
    color: #533900;
    background-color: #ffffe4;
}

終わりに

もしはてなブログの改造に興味を持ったなら、以下の記事もよく読まれている。是非トライしてみただけたらと思う。

はてなブログで記事下に関連記事を出すカンタンな方法

より良いブログにしていっていただければ幸いである。

アイディアがパクられることを恐れる必要はない

雑談

ども、@kimihom です。

自分が特許とか著作権とか知的財産とかがクソだと思う理由を書こうと思う。

アイディアとかパクられることを恐れる人は、そのあとの改善ができない単なる思いつきだけで勝負している人だと私は考えている。なぜならアイディアがパクられたところで、改善をずっと続ければパクってるものは常に古いものになるではないか。それを恐れてこうしたアイディアにしがみつく人は、そのあとの改善ができない人なのである。

アイディアがパクられたところで、そもそものプロダクトに対するコンセプトや信念まではパクることはできない。顧客と築き上げたブランド、信頼関係、今後の開発方針。そうしたところこそが最も大切にしなければならないことである。似たようなことをしだした人を追い払うような、くだらないことに時間をかけるより自分のプロダクトをもっとよくしていく努力をすべきなんじゃないだろうか。結局、「俺が思いついたんだから真似すんじゃねーよ」という人は、そのあとの努力ができない無能な人間が言う戯言にすぎない。

自分のプロダクトで同じようなパクリが発生しても全くビビっていない。真似されようとも、自分の持つプロダクトのクオリティと同程度のものを作り上げるのは相当の時間と困難を持つことは、作った自分がよくわかっている。そんで真似されたプロダクトで一気に金をつぎ込んで広告を打ったところで、そのやり方で獲得したユーザーはロクでもないユーザーであることを私は知ってる。そういう顧客対応に時間をかけるより、理想的で自分たちが一番使って欲しいと思う顧客に精一杯のサポートをすべきなのである。だから他社がどんなことをやろうと私は気にしない。私にはそう言える自信と覚悟がある。

アイディア人間と情熱人間のどちらを大切にすべきなのか

世間は、パッと思いついたアイディアでまずは知的財産を申請し後で同じようなアイディアを思いついてやった人を陥れるような人間と、たまたま同じアイディアで思いついた人が信念を持って顧客のために開発し続ける人間のどちらを守るべきなのだろうか。今後の将来のことを考えると、明らかに後者だと思う。そう考えると、単なるアイディアや仕組みを保護するような制度って本当に必要なのだろうか。アイディアだけに固執する人ってのは、改善を続けられない信念を持たない人であり、そんな人たちのためのくだらない法律にしか私には思えないのである。

実際に大きな会社では知的財産をたくさん持とうと、社員から出た単なるアイディアに対して報酬を払って知的財産権をなるべく多く得ようと躍起になっている。たくさん知的財産を持っておけば、他の会社からアイディアに関して侵害を訴えられた時、自分たちの知的財産もあなたたちは侵害しているから、お互い様だよねっていう守りを持とうとしている。知的財産がないと守りがなくなり、結局多額のお金を支払う羽目になるという世界らしい。

私がそうした現実を知った時、そもそも知的財産という制度があるせいでこんな不毛な戦いに時間を割かなければならなくなってるんじゃないかと思った。これは単なる言い争いだ。そこで何かが生まれるようなことは何一つない。お互いがお互いを消し合うだけ、時間を消耗するだけの時間である。まぁ勝てば賠償金がゲットできるってのはあるけど、そんな金に何の価値があるのだろうか。私は顧客に正しい価値を届け、役に立つことができた証としてお金を得るべきだと思っている。そのお金こそ額はどうであれ最も価値があって大切にできるお金だ。それ以外の方法で得たお金は得てして無駄遣いすることにつながる。

話は逸れたが改めると、アイディアなんて価値はない。 そのアイディアをいかに信じることができて、実際に顧客に価値を届け続けられるかの方が大事なのだ。だから私はアイディアを守る法律がクソだと思うのである。

Rails5 が示したサービス開発の新しい指針についての考察。

Rails

ども、@kimihom です。

f:id:cevid_cpp:20160702014256p:plain

Rails5.0 の正式版がついにリリースされた。

Riding Rails: Rails 5.0: Action Cable, API mode, and so much more

Rails 5といえば、 ActionCable での WebSocket によるサーバープッシュのリアルタイム処理が注目されがちだが、個人的には今後のシステムの開発指針を Rails が示した重要なリリースになっていると感じている。その原動力となっているのが、 あの "Turbolinks" だ。

マルチプラットフォーム開発に対する提案

ではどんな話かっていうと、まず Rails としては JavaScript で複雑なロジックをたくさん書いたり状態を管理するような処理を書かないことを選んでいる。以下の動画は今後の Rails において非常に重要な意味を持っている。

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

ではどうするのかっていうと、 Turbolinks によるページの書き換えだ。処理は全て Ajax を通じてサーバーサイドのHTMLレンダリングを通して中身を JavaScript で書き換える。そうすれば状態管理をしなければならないのは相変わらず Rails の DB 側になり、フロントエンド側のロジックが一気に減ることになる。

これだとスマホアプリが作れない? それが最新の Turbolinks のすごいところで、 iOS, Android 用になんと Turbolinks がネイティブと WebView を組み合わせてスマホアプリとスマホWebの垣根を限りなく少なくしてくれたのだ。そうすると各ネイティブアプリで書かなければならないロジックは本当に少なくなって、最も重要な部分は Web で統一化されているのである。私たちが Web の開発によりフォーカスを当てることができる。

この考えは確かに割と前からあった。ただし、 ネイティブの WebView があまりにも残念だったため、やっぱネイティブのJavaやSwiftで書かないとダメだよねーってのが共通認識だった。しかしながら スマホとHTML5 の発展により、そうした問題が解消しつつある。満を持してついに Rails が Turbolinks と WebView ベースを組み合わせたアプリの開発手法を提案してくれたのだ!

レスポンシブ対応な Webアプリケーションを作れば、 PC Web, Tablet Web/App, SP Web/App の5つに対応したものが高速で開発できる。これが次の世代の Rails のレールなのである。

Rails API で他の道も示している

このような開発手法だと、 Webアプリベースのサービスを アプリ化するにはちょうどいいのだけど、ネイティブビルドに大きく依存するようなサービスを開発する上では Turbolinks だけでやるのは不可能なことである。その場合は Rails API を使って JSON ベースでやりとりするような設計になるだろう。作りたいサービスが Turbolinks にマッチしなければ Rails API もあるよって意味合いで Rails API を公開している感が強い。

もちろん React や Angular 好きのためにってのもあるんだろうけど、それは付随的なものであって Basecamp 的主張で言えば、React や Angular を Rails で使うのはあまりイケてない感がある。なぜなら上記プレゼンの中にも「We are not Google. We are not Facebook」 ってある。これはそんな大規模なアプリを作れるようにするために Rails が存在するのではなく、小規模のスタートアップがより早く優れたものを作れるようにするためのフレームワークであるからって意味でとても納得できる。 ま、それらを使っても Rails のレールから外れるっただけなので、苦労してでもやりたきゃやればって感じなのだろう。

Rails 5 へのアップデートは。

こうやって正式リリースが出ると早くアップデートしたくなるものではあるが、Rails 4を本番で稼働している場合はまだやるべきではないと思う。依存 Gem の問題もあるし、まだ出たばかりなので激しい頻度でアップデートが繰り返されていくことだろう。そこまでしてアップデートした先にあるメリットって自慢できるくらい? あとは ActionCable とか 新しい Turbolinks を使わないといけないみたいな場面だったらアリかもくらいか。

この辺は個人の好みなのでやりたければどうぞと言ったところである。

私はそんなことよりも新規プロジェクトを Rails 5 で作り、 Turbolinks の新しい設計思想に触れてみたいと思っている。これは誰にとってもバージョンアップ作業をするよりも大事なことであろう。

今回の Rails 5 の登場がサービス開発手法の新しいスタンダードになることを期待している。