ボクココ

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

今更ながら Rails 5.1 にアップデートした話

ども、@kimihom です。

f:id:cevid_cpp:20180121202451p:plain

先日、ようやく Rails 5.1 にアップデートしたので、それについて簡単にまとめを書いていこうと思う。

アップデートの経緯

前までは Rails 4.2.x の最新をアップデートし続けている形で運用していた。 Rails 5 以降の新機能はチェックしてきたんだけど、どうしても使いたい機能とかがなかったため、 Rails 4.2 のままでいいやと そのままにしてきた。最近になって Rails 5.2 の話も出てきたので、いよいよアップデートしないとレールに乗り遅れるってことで Rails4.2 からRails5.1 に一気に上げることにした。

Rails のアップデートに関しては Gem の依存関係をクリアして本元 Rails をアップデートした後、ひたすら失敗したテストコードを直しまくるという形で対応した。アップデートの詳細な方法に関しては、他のブログなどでたくさん取り上げられている話題であるので、本記事では省略させてもらう。ここら辺の作業はコードの整備も兼ねてできたので、前より綺麗なソースコードになって良かった。

Rails5.1 からの Yarn への移設はかなり気に入っている。これのおかげで今まで 外部 JavaScript は app/assets/javascripts/vendor みたいなところに突っ込んでいたのから解放された。今後は定期的に各 JavaScript ライブラリのバージョンアップを行って、JavaScript ライブラリのレールにもうまく乗っかっていきたいと考えている。また、CDN で公開されていた JavaScript ライブラリでも、それが npm で公開されている場合は全てそちらに移した。これによって application.js として一つにまとめられた状態として読み込まれるので、余計な通信を削減することになる。

form_forform_with に一括して変更した。おそらく今後は form_with が標準になるだろうし、既存コードのほとんどが remote: true なアクションだったため、form_with を使う方が合っていた。form_with の使い方の記事は以前書いたので興味がある場合は参照してほしい。

Rails 5.1 を Heroku にデプロイする方法も特殊だったので必要に応じて参照いただきたい。

そして最後は機能の全てを手動テストした。テストコードだけでは全ての動作を保証できないので、手動テストで実行して見つけたエラーをひたすら直すことで、晴れてリリースを迎えることができた。メソッドが動くけど結果が地味に挙動が変わったりすることもあったので注意したいところだ。最終的には以下のような diff となった。外部ライブラリを Yarn で入れるようにした分でだいぶ Rails プロジェクトがスッキリした。

$ git diff master --stat
367 files changed, 13907 insertions(+), 32253 deletions(-)

アップデート後のパフォーマンスなど

Rails 5.1 にあげたことで、運用面で問題にならないかが心配だった。メモリが急上昇してしまったり、特定の処理のレスポンスが極端に遅くなるなど、これらの項目は実際に本番環境に上げてみないとわかりづらい項目である。

今の所、Rails 4.2 のころとあまり変わらない感じで安定している。これに関して今後、Puma のスレッド数やワーカー数をチューニングしてどの値が最適化を調整していく予定だ。ワーカー数は2にした瞬間にメモリが 100% を超えてしまったので、 Rails x Puma x Heroku の場合は ワーカー数は1にするしかない気がする。現状、スレッド数8, ワーカー数1で運用している。

終わりに

なかなか思い切ったソースの修正をしたけど、ユーザーには全く変わっていないように見える。そうした改善は個人的には結構好きで、バージョンアップ以外にもちょくちょく続けている。ひとまず Rails5.1 の最新版にあげられたので、一安心だ。このための自動&手動テストはかなり慎重にやってきたので、リリースできたときは嬉しかった。

こうしてアップデートをすることで、また自分のソースコードに愛着が湧いて、今後もメンテナンスを続けたいと思えるようになる。近々 Rails 5.2 にもアップデートして、ActiveStorage を使ってみたいと思う。

もし Rails4.2 を使っている方がいて、この記事が少しでも参考になったなら幸いだ。

私の考える最高のプログラミング教育

ども、@kimihom です。

エンジニアの方でプログラミング教育に深い関心を持っている方が多いようだ。私も、未来のエンジニアを増やすためにどうしたらいいかみたいなことはよく考えていて、本記事ではプログラミング教育に関する持論を展開していこうと思う。

プログラミングはどうしたら身につけられるか

何より私自身がエンジニアであるので、どんな時期に自分のエンジニアスキルが急成長したかはだいたいわかる。私が一番成長できた時には、その技術を学んで使わなければならない明確な目的があった。例えば Web アプリケーションで作りたいアイディアがあるから、そのために必要な Rails を習得したし、それを公開するために必要な Heroku の知識を学んだ。作りたい Android アプリがあったから(私が Androidユーザー)、 Java を一から学び直した。

このようにエンジニアとして飛躍的に成長するには、勉強する理由が自分から沸き起こるモチベーションでないといけないと思う。学校の授業のように受け身の姿勢のままでは、いつまで経っても教養の範囲を超えることができない。

プログラミングの場合は、誰でもすぐに始めることができる。誰だって自分のノートPCにプログラミング環境をインストールして "Hello World" のプログラムから書き始めることができる。最近はWeb上で全部できるようなサービスもあるので、ブラウザで特定のページにアクセスして始めるケースだってある。プログラミングの学習は誰がどんな状況でも始められる魅力がある。

特にプログラミングの世界ではそうだけど、新しい情報がとても大事になってくる。今まで実現が難しかったような技術が、新しい技術で一瞬で解決されることだってあるし、Alexa のような今まで実現不可能だった技術を扱えるようになったりする。そうした技術を習得することで、今まで実現できなかったようなことが実現できるようになる。

であるにも関わらず、プログラミングを受け身の姿勢で学ぼうとしている人が多すぎるように見える。誰かから教えてくれるってのは学校教育で慣れているものだからってのがあるけど、プログラミングの世界ではその程度のレベルでは例えプログラミングのテストで100点が取れたとしても優秀だとは言えない。プログラミング系の資格が色々あるけど、それを持っているからといって優秀なエンジニアであることの証明にはならないのだ。受け身で得られたスキルは最低限の一般教養があるくらいの参考情報に過ぎない。それよりも、新しく出てくる技術に対して貪欲に主体的に学び続けられるスキルが何より重要だ。

次の世代に向けて自発的な学習をどうやって増やすか

私はそうした考えを持っているため、プログラミング教育っていうもの自体に懐疑的である。そもそもプログラミングは誰かに"教えて"もらうのではなく、自分から"学んで"いくものであるべきなのだ。

その人がアプリ開発に興味があるなら Swift や Kotlin などの勉強から始めてもいいだろうし、Web であれば HTML、機械学習なら Python といったように目的によって最初のスタートが分かれる。未来のエンジニアを生み出したいと願う私たちに必要なのは、彼らにそれを学びたいと思ってくれるようなモチベーションの提供と、その入り口の指南をすることのように思う。

特に私は前者のモチベーションの提供が大事だと考えている。実際、モチベーションさえ持てば、私たちがプログラミングの入り口を指南することをせずとも、彼らは勝手にインターネットで検索して勝手に学び始めることができる時代になってきている。だからこそ、なぜプログラミングを学ぶのかってところをいかに訴求させるのかに関して私は最大の課題を感じている。

今の学生にとってそのモチベーションの一つとなっているのが、就職に困らないといった内容だ。まぁ確かにこれも一つの材料としてはあるんだけど、モチベーションというよりかは資格の一つくらいな保守的な立ち位置になってしまっていて、どうも好きではない。

プログラミングは自分のアイディアで日本中/世界中の人と繋がりが持てる、もっと大きな可能性を実現できる手段なのだ! そこについてしっかりと語ることができて、確かな説得力を与えられるロールモデル(以降、HERO と呼ぶ)となる人が出てくるべきだと思う。HERO は決してプログラミング学習者に対して"教える"という行為はしないだろう。HERO はいつまでも若者に背中を見せ続ける存在でいるのだ。そして若者はHERO の背中を追い、いつかは追い越すというマインドを持って成長していくものだ。そんなモチベーションを持った人てのは、今後間違いなく成長する。誰かから教わってぬるま湯で成長した人とは比べ物にならないくらいに。例え同じ成長を辿ったとしても、今後のプログラミングの使い方として、間違いなく自分から学んだ人の方がプログラミングを有効活用できることを保証する。受け身で学んだ人は給料や安定のためにプログラミングを活用し、前のめりで学んだ人は自分の夢の実現のためにプログラミングを利用するのである。

プログラミング界の HERO が少ないことに課題を感じている私は、まずは私自身が目標とされるような存在となって共に走り続けられる存在でありたいと思っている。数少ない読者ではあるけどもボクココを読んでくれた人へ希望を与えられるような存在であり続けたいということだ。そうした活動によって日本のプログラミング教育の発展に貢献していけるはずだと確信している。

終わりに

今回はプログラミング教育について私なりの持論を展開した。実は私は学生の頃に塾講師をやっていたこともあり、生徒達の成長について多く考える機会があった。いい生徒ってのは勉強を言われてやらされるのではなく、自分から進んでやっていく素質があった。彼らには勉強をやる理由ってのが明確にあったのだ。そんな生徒(全体の1%満たない) は未来を語り、目を輝かせるのである。

そんな未来を語れるエンジニアを増やしていくためにも、私自身が未来を、夢を語れる存在であり続けたいと強く思う。

成功するサービス開発に共通する考え方

ども、@kimihom です。

今日は一つの真理とも言える成功するサービス開発のポイントについて説明する。それは、自分が使うサービスを作る ということである。以下に理由を示す。


f:id:cevid_cpp:20180113230050j:plain

サービスを作り続けられるか

サービスってのは作った時点で成功するなんてことはほぼない。まずはサービスを作ってみて、それで出してみながら改善を続けていくことになる。この改善の時点で自分が使わないサービスを作ってしまうと、改善の度にターゲットとなる人に聞きに行かなければならなくなる。

自分がターゲットでないサービス開発の場合、聞きに行くってのがめんどくさくなって手抜きを始める。新サービスの開発運営を給料としてもらってやっている場合は、仮想のターゲットを作り出して想像で機能改善をしていく。給料すら出ていない場合には、そもそもそれを作るのを止めてしまう。どちらにしてもサービス開発がうまくいかなくなるのは目に見えている。これは BtoC でも BtoB でも、全てのサービス開発において共通する事実だ。他人から「お金を払うから作ってくれ」というものは、お金のために働くことになってしまう。それはお金が入ってこなくなってしまったらサービス開発が止まるし、その人だけの課題感の解決のために時間を費やすことになってしまう。そんな開発ではいつまで経っても作ったサービスを多くの人に使ってもらうことなんてできない。

自分が欲しいものを作っている場合にはそうはならない。常に自分の要望を満たすために開発するので、機能開発を続けることができるし、適当な開発で機能がバラバラになることもなくなる。

もしそのサービスがうまくいかなかったとしても、少なくとも自分は使う。 そんなモチベーションがあれば、初期のユーザー数が少ない期間でもサービス改善を続けられる。やがて同じような課題を持った人たちがサービスを見つけてくれれば、確実に使い続けてくれることだろう。

最近、特徴のあるバックグラウンドを持った起業家が支持されるようになっている。最終的にサービスを作るのはエンジニアだろうけど、基本的に作る側であるエンジニアが欲しいサービスってのはもうほとんどが世に出回っている。しかし特徴のあるバックグラウンドを持った人がいれば、今まで気づかれなかったニーズを自分ごととして捉えて開発できるようになる。それはつまり新しく成功するサービス開発を正しく続けられる可能性があるということだ。

自分の作ったサービスで食べていくことを目指す方へ

誰かからとやかく言われたのを作って給料をもらうのではなく、自分の意思で作ったサービスで食べていくこと。私自身、その状態になることを一つの目標として続けてきた。結果として現在はその思いを叶えることができている。

この実現の最初のステップとして、自分の中に秘めた需要を "探す"のではなく、"気づく"ことが求められる。普段、自分が欲しいものは無意識のうちに選択肢から外している場合が多い。まだ世の中にないものだから、何かの劣化した代替案を使ったり何かを諦めることで満足や慣れを生んでしまっているケースが多い。日頃の生活を改めて見直してみて、"そういえばこんなことで困っていて、こんなサービスがあれば少なくとも自分は使うな" ってのに出会おう。

それが何もないって場合は、無理して新しいサービスを作る必要なんてない。現状はこの世の中に満足しているのだから、新しく何かを作る意味はないのだ。適当にサービスを作ったらほぼ間違いなく失敗するので、やらないほうがマシである。いつか「これは作ったら自分が使う」 ってのを見つけた時に、コツコツとサービスを開発していけばいいだけだ。

その何かを見つけるためにも、現状は欲しいものが何もない場合には色々な経験をすることをオススメする。色々な仕事や職種にチャレンジしてみたり、外で色々な刺激を受ける。その中にヒントは埋まっているはずだ。私の場合、実際にサポートの仕事とかイベント登壇などをしている中で課題を見つけることができて、サービス開発を進めることができている。ここまで続けられているのも、自分ごとの課題感で得られたモチベーションがあるからだ。

終わりに

この課題はオレが解決する。そんな熱い想いを持ってサービスを作り上げよう。自分がそのサービスを使い続けながら改善をすると、やがてそのサービスでユーザーを抱えるようになる。そしたら自分の課題だけでなく他の同じような課題を持った人をも幸せにできる。自分でサービスを作って成功させると、そんな素晴らしい未来があなたを待っている。

実際に成功しているサービスってのはこの条件をほぼ確実に満たしている。

あなたが "給料のためにサービス開発やってます" なんてつまらない事を言うのは早すぎる。新しい未来を自分の手で作っていこう。

読者数300に到達するまでの軌跡

ども、@kimihom です。

本日、「ボクココ」の読者数が300を超えた。改めて、日頃から本ブログを読んでいただいている方には御礼を申し上げる。

ありがたいことに、本ブログは全はてなブログユーザーの中で800番台の読者数を持つブログとなってきた。この順位を上げたいとかそういう目的でやっているわけではないけども、結果として今この地点にいられるのは、やはり読者になって頂いた皆さまのおかげだ。

はてなブログ読者数ランキング

去年は結果的に107個の記事を上げることができた。これも、読んでいただいて反応をいただくことの喜びがあるからこそ続けられたと思う。以前に記事を書き続けるための秘訣みたいなのは書いてあるので、どうすればこのように記事を書き続けられるのかみたいな話は以下を参照いただきたい。

www.bokukoko.info

その上で、記事を書き続けるためのコツと読者を増やすってのは似てるように思う。

  • 自分のための日記ではなく、読者のために書く
  • 仲間を増やす感覚でターゲットを絞る

特に重要なのは上記2点だ。昔のボクココの記事を読んでみてもらえればわかると思うが、昔は完全に個人の日記だった。それはそれで日記としての目的を果たせているから良かったけど、今のボクココはあくまで読者のために記事を書き続けている。そしてそれを始めた数年前から、明らかに読んで頂く機会が増えたように思う。

ターゲットを絞ることも大切だ。日頃からこのブログを読んで頂いている方なら、なんとなくこのブログのターゲットはお分かりだと思う。「スタートアップ至上主義」「大規模主義」「独自インフラ構築主義」「縛られた生活」。。こうしたものに対して私は "No" と言い続け、自分の信じる道について記事を記してきたつもりだ。同じようなことを何度も言っていると思われる方もいるかもしれないが、それを繰り返し言い続けることが重要だと考えている。新しくその記事を読んで共感してくれる"仲間"をこれからも増やしていきたい。

そういう意味で、誰のために書いているのかよくわからない、ありきたりなブログほどつまらないものはない。本当に面白いブログってのは、その人ならではの心情やエピソード、技術などが折り込まれた記事であると考えている。だからこそ、私はあえて記事の中で 信じている というワードを使っている。これは、書いていることが正しいか間違っているかというよりも、私がそう思っているという、私なりの考えを記事に反映していることの証明である。

以前までは炎上に近いエントリー数を稼ぐことに楽しさを感じて激しい論調で書くこともやっていたが、最近は読者の方から頂く10数個のはてブやスター数が付くくらいの規模に幸せを感じている。最も読んで欲しい人に届き、その人からフィードバックを得られることの喜びのほうが、炎上してたくさんの人から読まれるより素敵なことだと感じるようになった。しかし、それが落ち着いてしまったということかというとそうではない。これからも自分の心の中に秘める想いを伝えていく予定だ。

ボクココの想い

このブログを書き始める原点となったのは、大学生の頃のことだ。-僕はここにいる- という歌や歌詞にひどく共感した私が、仮でつけたブログ名が今でも続いている。結果として自己主張の激しいブログとして続いているのも、このブログタイトルのおかげなのかもしれない。言うなればもう7,8年前の想いが今も続いているという訳である。こうして記事が残り続けていること自体が、私にとっては宝物のようなものになりつつある。

これからの旅の途中で辛く険しい道のりが待っているかもしれない。それでも私はこのブログを書き続けるし、残り続ける。そうしてまたここに、僕はいるということを証明できるのである。

Rails アプリの国際化の実装と考察

ども、@kimihom です。2018年もどうぞよろしくお願いします。

さて、今回は Rails アプリを世界へ向けて展開したい人向けの記事を書いていこう。

基本的な参考資料

まずは Rails の I18Nドキュメント を読むことから始めよう。ここに基本的なことは全て書かれている。

Rails国際化 (I18n) API | Rails ガイド

I18N で立ちはだかるのは大きく2つの事項がある。言語と時差だ。以下にそれぞれ記す。

多言語化対応

まずは多言語化から見ていこう。基本的に Rails では config/locales の中に en.yml ja.yml などを定義していって、 View の中に t('home.title') みたいな感じで指定すれば勝手にそれぞれのロケールの言語で翻訳してくれる。てな訳で開発中の多言語化の際には上記 yml ファイルの中に記載していく習慣を持っておけば基本的には問題ないだろう。

ただし、JavaScript 側でアラートメッセージなどを出したいって場合には Rails 側で管理できないので工夫が必要だ。自前でやる上で一番簡単な方法は、View のなかに display: none な Key-Value のセットを保存しておくやり方がある。ただこの方法だと量が多くなると管理が相当めんどいので、量が多い場合は i18n-js などを検討しよう。

<div style="display: none;">
  <span id="error1"><%= t('error.msg1') %></span>
  <span id="error2"><%= t('error.msg2') %></span>
  <span id="error3"><%= t('error.msg3') %></span>
  ...
</div>

<script>
console.log($("#error1").text());
</script>

そして重要なのが、ユーザーごとに言語を切り替える設定の部分だ。デフォルトのロケールは config/application.rb で書く。以下の例では 何も指定がなければ、日本語になる。

    config.i18n.available_locales = ["en", "ja"]
    config.i18n.default_locale = :ja

ではどうやってユーザーごとに最適な言語を表示させるのか。それは先ほどの Rails 国際化のリンクに方法が書いてあるので、検討してみてほしい。地理やブラウザ言語などで分ける方法もあるけど、私としては URL で完全に分ける方法が最も良いと考えている。なぜなら 基本的に Google や SNS でシェアした URL に言語設定が入っていれば、それがアクセスする人にとっての最適な言語に間違いないからだ。

てな訳で、ルーティングの設定のなかに locale が入るようにセットする。

Rails.application.routes.draw do
  get '/:locale' => "home#index", as: :root
  get '/' => redirect("/ja")

  scope ":locale", locale: /ja|en/ do
    resources :contacts
    # ...
  end
end

URL でロケールを明示する方法の場合、Root URL だけ ja or en のどっちかがわからないのでリダイレクトさせる必要がある点に注意しよう。https://www.my-worldapp.com/en/contacts/1 のような URL 構成になる。

さて、この URL に params[:locale] が入るようになるので、あとはコントローラ側で表示の出し分けをすれば OK だ。

class ApplicationController < ActionController::Base
  before_action :set_locale

  private
  def set_locale
    I18n.locale = params[:locale] || I18n.default_locale
  end

  def default_url_options(options = {})
    { locale: I18n.locale }.merge options
  end
end

default_url_options を指定することで、link_to の時も勝手にロケールが入るみたい。ついでに ActionMailer 側も以下のように設定しておくと、メールに URL 含める場合でもロケールが考慮される。

class ApplicationMailer < ActionMailer::Base
  default from: 'support@my-worldapp.com'
  layout 'mailer'

  def default_url_options(options = {})
    { locale: I18n.locale }.merge ActionMailer::Base.default_url_options
  end
end

タイムゾーン

さてタイムゾーンの話に移っていこう。時差がある中でどうやってユーザーに最適な日時を表示させるかという問題である。

当然のことながら データベースでの日時は UTC で保存しよう。config/application.rbtime_zone の設定がなければ勝手に UTC になる。

Rails 側で勝手に作られる created_atupdated_at は基本的にサーバー側で UTC で保存されるようになるから問題になることはないだろう。あとはどうやってユーザーに時差付きのタイムゾーンを表示させるか、となる。

んで JavaScript には時差をとってくる方法があるので、JS 側でみんなやっちゃえばいいやんという考え方が1つある。しかし、その方法だと日時のパースのためにユーザーの表示を待たせてしまう必要があるし、そもそも日時を処理する必要があるため非効率的だ。何かしらの SPA フレームワークを使ってない場合はあまり良い方法ではない。

てことで今回は、ユーザーごとにタイムゾーン情報をデータベースに保存する方法を案内する。

1. User に time_zone を保存

stringtime_zone を用意しよう。そんでモデル側で以下のようなバリデーションを用意する。

validates :time_zone, inclusion: { in: ActiveSupport::TimeZone.all.map(&:name) }

これで、例えば Tokyo のようなタイムゾーンをユーザーごとに保存する土台が整う。

2. User ごとのタイムゾーン表示

そんで app/controllers/application_controller.rb で以下のような記述をすると、ログインしたユーザーごとに DateTime を生成してくれる!さすが Rails といったところだ。

class ApplicationController < ActionController::Base
  around_action :user_time_zone, if: :current_user

  private
  def user_time_zone(&block)
    Time.use_zone(current_user.time_zone, &block)
  end
end

3. User のタイムゾーンの選択

最後に、ユーザーがどうやって自分の最適なタイムゾーンを選択するかという話に移ろう。これが厄介だ。 一番簡単なのは、ユーザー登録の時点でタイムゾーンを選択してもらう方法である。 Rails の View では <%= f.time_zone_select :time_zone %> ってのが用意されているので、これを使えばセレクトボックスを簡単に用意できる。

f:id:cevid_cpp:20180106141647p:plain

タイムゾーンを更新する場合は上記方法でも良いかもしれないけど、登録の際にこのセレクトボックスを出させるのは気が引ける方は多いと思う。だって、JavaScript でタイムゾーンを取ってこれるからね。てことで、例えば会員登録の際にタイムゾーンは JavaScript で取ってきたタイムゾーンで登録させるっていうクールな方法を紹介する。

var min = -(new Date().getTimezoneOffset());
var hrs = min / 60;
((hrs > 0) ? "+" : "-") + ((Math.abs(hrs) < 10) ? "0" : "") + parseInt(Math.abs(hrs)) +  ":" + ((min % 60 > 0) ? "" : "0") + min % 60;
// => "+09:00"

なかなかトリッキーな方法だけど、上記のコードを書くことで実現した。なんと時差で "4:30" みたいな 30分ずれるみたいなこともあるらしく、ちょっと複雑なコードになってしまった。

残念ながら、JavaScript では上記のように時差(+9:00) のような文字しかとってくることができない。データベースで保存しているのは、Tokyo といった文字列である。てことで、先ほどの <%= f.time_zone_select :time_zone %> を活用してなんとか動かすように JavaScript 側で工夫しよう。最終的に以下のようなコードで実現した。

    var min = -(new Date().getTimezoneOffset());
    var hrs = min / 60;
    var timezone = ((hrs > 0) ? "+" : "-") + ((Math.abs(hrs) < 10) ? "0" : "") + parseInt(Math.abs(hrs)) +  ":" + ((min % 60 > 0) ? "" : "0") + min % 60;
    $("#time_zone option").each(function(i, elm) {
      if ($(elm).text().includes(timezone)) {
        $("#time_zone").val($(elm).val());
        return false;
      }
    });

time_zone_select に時差を表示してくれている部分があるので、最初にその時差とマッチするセレクトボックスがあったらそれを値として登録するようにした。この方法のデメリットとして、+9:00 の場合は Osaka がデフォルトになる という点だ。まぁ時間さえ一致すればあまり問題にはならないかなということで、この方法で今やってみている。

終わりに

今回は 世界的ウェブサービスを生むために必要な、I18N について記載した。

こんな記事を書いているということは、私自身そういう想いで作っている何かがあるということである。是非みなさんも世界へ向けたサービス開発にチャレンジしてみてほしい。それに必要なのは、根拠のない自信と実際にやるという行動力だ!

2017年振り返り

ども、@kimihom です。

2017年も残すところあと30時間となったので、2017年の振り返りをしようと思う。私はこのブログの他にも、英語で今日の出来事を書き続けることを3年以上やっている。そして年の終わりに書いた記事を一気に読み返すのが一つの楽しみになっているが、全部読み終えるのに3~4時間かかるので結構大変でもある。

1日ずつ書いて行くこともできるわけだけども、このブログには象徴的なことについてまとめてみる。

自分の作ったサービスで食べていけるようになった

ここ3年で願い続けていた地点に到達することができた。自分がゼロから作ったサービスでユーザーの方から頂いたお金だけでやっていけるようになった。この話をすると驚かれることが多いんだけど、それ以前は自分の貯金を切り崩しながら生活してきた。そんな中でも自分の作ったサービスや仲間には絶対の自信があったので、途中で投げ出したりすることは決してせず我慢し続けることができた。その結果が表れたことに大きな喜びを感じている。

www.bokukoko.info

コミュニティ活動

今年はコミュニティ活動に力を入れた1年でもあった。特に以下のコミュニティの皆さんにはお世話になったので感謝する。

Twilio UG, Heroku UG, Startup Rails 勉強会, Stripe UG, カスタマーサポート勉強会

登壇履歴と資料 - ボクココ

パブリックに公開できる資料としては8つ資料を上げることができた。この活動は来年も続けていきたいし、色々な場でブログだけでなくリアルな情報発信を心がけていきたいと思う。最近は初めて会った人でも、自分のブログの存在を知ってくれている人がいたりしてブログやコミュニティ活動の成果がちょっとずつ出てきている感じがしている。

コミュニティ活動の一つとして、今年は US Twilio のイベント Signal に参加するために一人でサンフランシスコまで1週間行ったことは大きかった。そのために3ヶ月間丸々英語を勉強しまくって、実際 行った時には英語周りで問題になることがないくらいには過ごすことができた。そうやって自分にプレッシャー与えないと英語って勉強しづらいから、来年もSignal 行く前には必死に勉強してみたいに続けていくことで英語力を強化していきたい。

サービス開発

日々のブログでは色々うまくいったことを書いているけども、サービス開発は失敗の連続だ。今年だけで以下のようなサービスを考えては設計実装し、途中で頓挫することが続いた。

  • 長距離ドライブのマッチングサービス (企業としてリリースし、今年クローズ)
  • チャットしながら同じ部屋にログインしている人とビデオ通話が気軽に行えるサービス (開発まで終えてリリースしようと思えばできたが、具体的なユーザー用途が見えずクローズ)
  • インターネット公衆電話サービス InstantCall
  • Baremetrics のような SaaS 用のメトリクスサービス (設計までいったが、専門分野を活かすことができないのと実装が外部サービスの都合に影響を受けすぎるため開発未着手)

そして現在、引き続き新しいサービスの開発を年末年始で続けている。隠すつもりはないから言っておくと、企業向けリアルタイム配信を気軽に行えるサービスだ。ビデオチャットと同様、本サービスは実装のフェーズまで行っているので、このままいけば来年リリースできるかもしれない。一応注意書きしておくと、これらサービスは完全に本業の片手間の土日でやっている趣味プロジェクトに近いものである。

熱海でのリモートワーク

自由な働き方ってことで、月に1回レベルで熱海に行った。熱海に行った時には2~3週間滞在して、そこで仕事をすることができた。 日記を見返してみると、3月,5月,12月以外は全部熱海に行っていた。それだけ自由な環境で働けるようになったってのも、自分のサービスを運営しながら自由に暮らしていけるようになったことの一つの成果なのだろう。

なんでこんなにも頻繁に行ったのかというと、気分の切り替えというのが一番の理由だ。人はどんな最高の環境にいたとしても、飽きってのは必ず出てくるものだ。その対策として暮らしながら場所を転々とすると毎回新鮮な気持ちになることができる。また東京は実家暮らしだけど熱海は一人暮らしになるので、家事や洗濯、料理など一通り自分でやる機会も得られるってのも案外楽しめられる。熱海にいると人にあったりイベントに参加したりとか一切ないため、ガチでプログラミングに集中することができる。

あとは実家のリフォームの影響で2ヶ月もの間、住み続けるくらい熱海に滞在することになった。これはこれでいい経験になったと思う。

プライベート

上記のような感じで普段の生活や仕事やテクノロジーに関しては大変充実していた。

その反面、プライベートの方を充実させようとということも頑張ってはきたものの、今年は(も)うまくいかず。 来年も引き続き相手探しから頑張っていきたいと思う。関係各位に探しているってことを伝えておくと、紹介してくれることもあると思うので書いてみたw 紹介してもらうってのが一番いい知り合う方法だと思った。

終わりに

今年は自分の人生の中の1つの大きな目標を達成できた年でもあり、感慨深いものとなった。来年は次の目標へ向けて引き続き活動を続けていく次第だ。

毎日日記を書き続けると、忘れかけていたその日の出来事を思い出すことができる。これは来年に向けてのより良い活動のために便利なものだと思う。日記を書くことを習慣にして、毎年この時期に一気に読み返すってのはおすすめなので、もし来年の抱負など決まってない方は毎日日記を書くってのにチャレンジしてみてはいかがだろうか。

最後に読者の皆様へ

2017年もお世話になりました。来年も本ブログをよろしくお願いします。

相手を成功させるという考え方を持つべき理由

ども、@kimihom です。

今回は私の考える成功や目標の定義について書いてみる。

自分の成功を考えると失敗する

よくある話として、「"自分が" 金持ちになりたい」「"自分が"影響を与える人物になりたい」っていう目標がある。これはこれで素敵な話ではあるんだけども、実際にそれを続けるとうまくいかないケースが多々ある。

ビジネスってのはお客さんがあってのビジネスだ。しかしその反面、自分が成功しようと思った時に真っ先に考えるのは"利益"や"名声"だろう。利益は誰にでもわかる簡単な指標だから、何も考えずに目標として設定できる魅力がある。自分本意な目標を設定すると、以下のような行動を優先してしまう。

  • 新規顧客獲得を優先するために営業やマーケティングに力を入れる
  • メディア受けしやすい目立つ機能を実装する
  • 急速に規模を拡張する
  • 短期的に稼げるビジネスをする
  • 広告や採用などで背伸びをする

しかし、上記の対応は顧客にとっては何も嬉しくない対応だ。てなると、新規顧客が来たとしても、その顧客はサービスを他人に紹介するどころか、そのサービス自体を使い続けることも危うくなる。サービス運営者の目的の主語が自分たちである場合は、ろくなサービスを生み出すことはできないのはこれが理由だ。

その反面、自分の成功ではなく相手を成功させるというマインドを持つと、以下のような考え方に変わる。

  • 新規顧客よりも既存顧客を支援する
  • やみくもではなく、使って欲しい正しい顧客を選ぶ
  • 作ったサービスをコントロール可能な最適な人数規模に留める
  • 背伸びをせず正しく説明し、正直でいる

こうしたビジネスの考え方によって、顧客はサービスを信頼してくれるようになる。それが結果的にサービスを使い続けることになり、紹介までしてくれるようになる。

自分が成功したければ、"自分が成功する" という目線を完全に消し去り、相手を成功させ続けることだけを考える

一見矛盾したように見えるんだけど、上記の真理が成り立つと考えている。言うのは簡単だけど実施するのは本当に難しい。自分視点で言えば人の欲望は尽きないものだし、第三者の視点で言えば短期的な成長を求められる。これらの誘惑や期待をいかにして封じ込み、顧客視点を持ち続けられるかがビジネスの成功のカギを握るだろう。

社員の成功も考える

自分の成功ばかりに目がくらむと、顧客だけでなく社員の成功を考えることを忘れてしまう。社員にとっての成功とは何か。そしてそれに向かって進んでこれているのか。常に一人一人違う成功の定義を話し合ってすり合わせをしていくことが何よりも重要だ。

社員同士の成功の定義や目標を知らずして事業を進めていくことは、やがてビジネスやサービスそのものを変えてしまったり、最悪の場合終了してしまうほどのリスクがあるので気をつけよう。

基本的に何も考えていない人は、目の前のお金等の欲求だけを結論に持っていきたがる。結局そうした人は自分のための行動を優先するがゆえに、組織としてろくな成果物を生み出すことはできない。目の前の欲求に生きる人は先ほどの矛盾で指摘したのと同じで、いつまで経っても自分の欲望の縄に縛られ続けて生きていくことになる。お金を例にすれば、自分のお金を求め続けては浪費し、さらにお金を求め続ける生き方を歩むことになる。

でも実際に金持ちになっている人は、自分が金持ちになるために働いてきたわけではないのである。周囲の成功が自分の成功だと考えられる人と働くようにしたいものだ。

難しいことだけども、周囲のために働くって思いを持ち続けるためにも、改めてメンバー間で成功について話し合い続ける努力が必要だと思う。その思いが会社全体で一致した時、組織として最高の成果を挙げられる仕事をすることができると私は信じている。

終わりに

今回は私が普段心がけている一つの考え方について共有した。

これからも自分の成功ではなく、周囲へ成功を与えられるようにしたい。そんな素敵な信頼関係を構築できれば、ビジネスや人生がより豊かになるはずだ。