なぜ開発言語にRubyを選んだのか？　SmartHRが明かす、成長の軌跡と技術選定 - Part1

スタートアップの銀行口座残高と技術選定

内藤研介氏：お疲れ様です。素晴らしいプレゼンばかりでしたね。もう、まつもと（ゆきひろ）さんの話も聞いたし目当てのプレゼンも聞いたし、花金だし。「そろそろ帰りたいな」なんて方もいらっしゃるかもしれないですが（笑）、もう少しだけお付き合いいただけたらと思います。

人って、お金の話がすごい好きだなと感じることが多いんですね。やれ皇室の行事にウン十億かかるぞ、国のお金で賄うのかそれとも皇族の方のお財布からお支払いするのかとか。どこどこの大きな会社の社長さんが、退職金として50億円、投資家に黙って積み立てていたぞとか。ファッションECの社長さんがウン百億円かけて月に行くだとか。そういったお話が、世間では話題になるわけです。

一方で、とくに日本人は、自分自身とか家族や親戚、いわゆる自分に近いところですね。自分自身と関わりの深いところでは、お金の話を避ける傾向があるのかな、と思います。他人のお財布事情には興味津々なわりに、自分自身の懐は明かさないという、私たちはなかなか罪深い性質を持っているわけなんですね。

（会場笑）

私も例によって、スタートアップのお金の話は非常に大好物です。「どこそこの売上はいくらだ」「あそこはいくら調達したぞ」「あそこのエンジニアいくらもらってるぞ」と、そういった話を聞いて「なるほど、なるほど」と思いつつ、自分たちの身を振り返ったりするわけですね。

スタートアップを起業して運営する中で、お金の集め方とか使い方について、なかなか生の声を聞く機会っていうのが少ないのかなと思います。そういったこともあって余計に興味をそそられるのかな、というふうに振り返ってみるわけです。

本日は、お金の話と、あと技術選択の話。そしてコミュニティへの貢献というお話を、弊社の経験してきたことを交えて、簡単にお話しできればと思います。お金がないときの戦い方、あるいは多少余裕があるときの戦い方について、少しでもみなさまの参考になればうれしいです。

スタートアップの方だけじゃなくて、大きな会社を経営されてる方も、例えば新規事業を作るときなんかの参考になれば非常にうれしいなと思いますので、よろしくお願いいたします。

SmartHR CPOが語る創業まで

まずは簡単な自己紹介をさせていただきたいと思います。

SmartHRでCPOをしています、内藤と申します。ちなみにSmartHRという名前を「聞いたことあるよ」っていう方いらっしゃいますか？

（会場挙手）

ありがとうございます。「CPOって何だ」って思われるかもしれないですが、こちらは「チーフプロダクトオフィサー」の略です。いわゆるプロダクトの責任者をやっております。

経歴としては、新卒で大手のITコンサルの会社に入社しまして、研究開発部門に配属されました。自社製のメッセージングミドルウェアの開発とか、あとは分散データストアの研究開発などをやっていました。

しばらくすると「前線で戦ってこい」ということになりまして。企業のR&D部隊というものは、景気のいいときは自由気ままにいろいろやらせてくれるんですが、景気があまり良くなくなってくると風当たりが強くなるんですね。そこらへんの話は置いといて（笑）。

研究開発部門で働いてたんですが、いろんな事情があってプロジェクトに配属されるようになりました。その中で、主に地銀とか証券会社とか、わりとお堅い金融機関向けのシステムをJavaで作るようなことが多かったです。

そんな中で5～6年くらい経った頃ですか、要領の悪いながら、大人の働き方ってこんなもんなんだ、みたいなことが見えてきて、ふと自分を振り返るわけです。若さもあったんですね、自分自身の力でどこまでいけるかを確かめたい気持ちと、あと自分自身のサービスを作ってみたいという気持ちもあって。そんな中で今の共同創業者と出会って、意気投合して、創業に至りました。

お金のない創業期

そんなこんなで会社を設立することになりました。会社を作るなんて、もちろんしたことなかったわけです。なにが必要かもわからないし、友人から紹介してもらった税理士さんにいろいろ聞いて、諸々手続きをしてもらうわけです。当時、3人で起業したんですけど、なけなしの貯金を切り崩して資本金としました。

今でも覚えているんですが、資本金が1人当たり170万円でした。スライドに出ている数字が、3名分の資本金をがんばって積み立てたお金ですね。個人的には、あまり積極的に貯金をするタイプでもなかったので、なかなか厳しいなぁと思いつつお金を払ったことを覚えています。オフィスの敷金礼金とか、家具やなんやかんやの購入で、みんなで出し合ったお金がじりじり燃えていくんですね。

（会場笑）

そういった様を見ているのは、なかなかつらいものがありました。周りの若いベンチャー企業を見ると「給与なしで朝から晩まで働いていくぜ！」みたいな会社はたくさんありました。でも私たちは創業した当時20代後半で、めちゃくちゃ若いわけでもなくて「給与なしで働くなんて考えられないよね」と。そういう状況も怖いということもあって、1人当たり25万円くらい役員報酬を払ってサービス開発していこうぜ、というふうになりました。

これは今、多少知識がついてから考えると「もうちょい工夫できたかな」と思う部分もあります。税金がもったいなかったな、みたいな話ですけど。いったん会社に入れてから自分たちに入れると、それだけでまた税金がかかっちゃうんですね。なので、もしこの中で起業しようという方がいらっしゃるんでしたら、ある程度貯金して、その中で自分の生活をやりくりしたほうがいい（笑）。

初めて自社サービスを作るまで

それで、オフィスも借りたし家具も揃ったし、自分たちのサービスを開発するぞ、となったんですけど。なんの後ろ盾もなく、売上もない状態でサービスを開発しても、1年ももたないことはあらかじめ見えていました。資金がショートするということですね。

私たちは慎重だったので、仕事を請けながら自社サービスを開発しよう、と決断いたしました。いろんな仕事を受けてきました。例えばスマートフォン向けのアプリのデザインの開発とか、Web開発のディレクションとか、あとセキュリティの診断のお仕事とか。珍しいところだとスマートフォン向けのゲームの攻略記事を1本数千円で書くという、今までぜんぜん経験なかったような仕事もやったりしました。

もともとは、自分でサービスを作りたくて創業したわけです。なのに気が付くと受託の仕事ばかりしていて、なかなか自分のサービスを作れない状態が続いていました。受託の仕事をしていると、やっぱりそちらについつい頭が向かっちゃうんですね。

でも、忙しい合間を縫ってサービスを作ったんですね。1本目は「Webクリエイターのスキルを可視化する」というものを作りました。エンジニアとかデザイナーとかWebディレクターの方々向けの、質問に答えていただくと自分のスキルが数値化されて見えるというサービスです。今考えると「それ誰が使うんだ」みたいなものなんですけど。

実際ユーザーが定着することはなくて、もちろんマネタイズなんかもできなくて、結局サービスは閉鎖されました。

2つ目のB to Bサービス

そうやって1つ目を閉鎖した後、2つ目を考えるわけです。2つ目は、B to Bサービスの比較サイトみたいなものを考えました。サービスを比較して、ユーザーが口コミを投稿できる、みたいなサイトですね。最初のうちは友人とか知人に頼んで口コミを投稿してもらって、ある程度のデータは集まったんですけど、こちらも結局、マネタイズするまで非常に時間がかかるよねという判断が下されて、閉鎖されました。

こちらも今思うと、サービスをローンチする前にけっこうわかることがあったんじゃないかなと後悔することが多いです。もともと自分たちのサービスをやりたいと思って起業したんですけど、実際やったことは受託の開発ばっかりで、作ったものは中途半端なサービスばかりで。なけなしの資本金はじりじり減っていくわけです。

このままだとまずいよねということで、Open Network Labというインキュベートのプログラムに参加することになりました。株式の数パーセントを渡す代わりに数百万円の活動資金と、あとはサービスの作り方とかメンタリングとか、そういったものを得られるプログラムです。そこからは受託を一切断って、背水の陣で挑みました。

そんな中で、今のサービスであるSmartHRが生まれて、初めて自社サービスの売上が立つということになりました。結果、今に至っています。個人的には、初めてユーザーさんがクレジットカードを登録してくれて、そこから課金された瞬間が非常にうれしかったなと思い出すところです。

お金のないスタートアップの3つの教訓

ここで、初期フェーズで得られた教訓が3つあります。

1つ目は、広告に頼るビジネスモデルは、マネタイズまで非常に時間がかかるということです。広告の枠の販売は、to C向けのサービスなんかではよく見られますけど、こういったビジネスは「広告主にとってどれだけ質の良いユーザーがたくさんいるか」が勝負になります。

サービスが爆発的にヒットしてユーザーがガンガン集まればいいですが、現実はそんなに甘いものではないです。多くの場合、ユーザーが集まるまで時間がかかりますし、創業したばかりのベンチャーにとって、キャッシュを燃やしながらユーザーをじりじり待つという状況は非常につらいものがあります。

教訓の2つ目は、創業したばかりの会社にとって、受託しながらの自社サービス開発は難易度が高いぞということです。もちろん、不可能ではないです。例えば「Pairs」のエウレカさんとか、あとは請求書を発行するサービスBoardを開発しているVELCさん、そういったところは受託と自社サービスのバランスをうまくとってやられたりもしています。

ただ、難易度が高いということですね。無理ではないけど、なかなか難しいということです。とくに私達のような「自社サービスをやりたい」という気持ちを持って創業したスタートアップにとっては、受託を受けながら自社サービスをやるのはブレーキをかけながら自転車をこぐような感じで、なかなか難易度が高いものです。

そして3つ目の教訓は「ユーザーの課題から始めよう」ということです。私たちは、2つのサービスを作って、結局マネタイズできずに失敗してしまいました。最初に「マネタイズするまで時間がかかる」ってお話もしたんですけど、私たちの作ったサービスについていえば、時間をかけてもどうしようもなかったかなと思います。

なぜかというと、自分たちが作りたいものを作っていたんですね。ユーザーの欲しいものを作ってなかったという部分があります。ユーザーの課題は解決してなくて、結局、自己満足のサービスを作っていました。知人や友人とか、ネットメディアに掲載されたら少しはユーザーが集まるかもしれないですけど、それが継続的に進むかどうかは、なかなか怪しいものだったなぁと思っております。

スタートアップにとって、時間は死活問題です。少ない資金で、少ない人で、少ないリソースで、いかにサービスを開発して提供していくべきか。そのためには、ユーザーの課題（の解決）から始めるべきだなと思っております。

開発言語にRubyを選んだ理由

先ほども申したように、お金も開発者も少ないスタートアップにとって、スピードは最優先事項です。素早く決断して実行して、学習することでサービスの爆発的な成長を実現します。そして、柔軟な言語は、この決断・実行・学習の素早いサイクルを助けてくれます。

そんなこんなでSmartHRのサービス開発が始まったんですけど、サービスの開発言語になにを選択するか、非常に迷いました。最終的に、私たちはRubyを選択しました。

私自身、先ほどもちらっと申し上げたんですが、新卒から長い間Javaを使って開発していたので、一番慣れていたのはJavaだったんですね。けれどもプライベートでRubyを使っていて、その体験がすごく良かったんです。

楽しく開発できましたし、あとはRubyのコミュニティはナイスな人が多いと聞いていて、実際そう感じることも多かったです。

案の定、慣れない言語で、初めは非常に効率が悪かったんですが、時間が経つにつれて「良い選択だったな」と感じることが多くなってきました。例えば、Rubyでは「こんなメソッドがあればうれしいな」というメソッドは、たいてい用意されています。Rubyの作法に慣れてくると、思いついたメソッドが用意されていない場合は、逆にその考え方が間違ってるという場合もけっこう多いな、と思うようにもなりました。

Rubyはクラス名メソッド名のネーミングに一貫性があって理解しやすいですし、gemも豊富ですし、やっぱりコミュニティのメンバーはナイスですし。非常に良い言語を選択したな、と思うようになりました。

私自身の経験とか想いもそうですし、あと私たちのサービス自体も、Rubyとの相性が非常に良いなと思う機会が多くなってきました。結果的にユーザーにヒアリングをする中で生まれたSmartHRのアイデアなんですけど、Rubyを使うことによって、サービスの企画から開発まで、わずか2ヶ月で最初のリリースまでこぎつけました。

Rubyの活用事例

Rubyの活用はリリースした後も非常に良い効果をもたらしていまして、日常的なサービスの開発もそうですし、リリースのサイクルも非常に短期間でできるようになっています。

プロダクションでのRubyの活用例を、1つだけご紹介させていただきたいと思います。先ほど、SmartHRをご存知の方も何名かいらっしゃったんですが、SmartHRは、社会保険とか労働保険関係の手続きを簡単にするためのクラウド型のサービスです。

SmartHRには、そういう手続きの書類をたくさん作る機能があります。そういう書類には、多いときには数十、数百の項目があるわけです。それらの項目を正規化して、データベースに保存して、書類によってその保存した形式を変換する必要があるんですね。

例えば日付なんかはすごく分かりやすい例で、日付はほとんどの書類で必ず出てくる項目です。しかしその表現方法は、種類によってもそうですし、項目によってもさまざまなんですね。西暦で表示するのか和暦で表示するのか、和暦の場合は平成とか昭和とか年号をそのまま表示するのか、もしくは平成の「H」とか昭和の「S」というふうに省略して出力するのか。

和暦の年だけを出したい場合もある。例えば平成30年の「30」だけ出したいとか。そういった感じで、いろいろ変換する必要があるわけです。つまり、DB上はDATE型として保存しているけど、日付情報を書類が要求するさまざまな形式に変換する必要があります。

Rubyの優れた柔軟性を利用すると、こういった問題は非常に簡単に解決できます。例えばオープンクラスを利用してDATEクラスを拡張することもできるんですけど、さすがに影響範囲が大きいので、私たちは簡単なコードを書いて対応しました。

（スライドを指して）ちょっと細かくて見えないと思うんですけど、プロダクションで利用されているコードのイメージです。モデルの中で日付型のフィールドを指定するだけで、書類上でよく使うようなメソッドを動的に生成してくれるモジュールですね。ActiveRecordの、例えば書類1に対してアトリビュートを指定すると、動的にメソッドを生やしてくれます。

昭和とか平成とかの年号を返すメソッドとか、年号だけじゃなくて和暦の年を返すメソッドとか、そういったものを動的に必要なときだけ生やしたりもできるわけです。SmartHRでは、こういうRubyの柔軟性を活用したコードがたくさんあって、素早い機能開発を助けてくれています。

Rubyコミュニティへの貢献

実際のプロダクト開発では、Rubyコミュニティや数え切れないほどのOSSコミュニティに助けられてきました。そして私たちSmartHRは、それに恩返しをしたい・貢献をしたいと常に考えています。

そういった活動は、売上がまだないときから、ユーザーがいないときから、お金がないときから実践していました。お金がなくても貢献はできるんですね。少しだけ紹介させてください。

例えばSmartHRでは「kiji」というOSSを公開しています。総務省が公開している「e-Gov」というシステムがあります。社会保険の資格取得届など、行政上の手続きをブラウザ上からできるシステムです。InternetExplorer限定なんですけど。

2015年に総務省がe-GovのAPIを公開して、これまではIEでしかできなかったWebサイトの手続きが、そのAPIを各ソフトウェアベンダーが使うことでどこからでもできるようにしてくれました。非常に素晴らしいんですけど、ただこのAPIの仕様書が、非常になんというか、けっこうつらくて。

APIの仕様書って聞くと、普通のWeb開発者がイメージするのはこんなものだと思います。まず、Webで公開されてます。それから、レストフルなインターフェースが用意されていて、リクエスト・レスポンスはJSON形式だよね、という。普通のWeb開発者がイメージするAPI仕様書って、こんな感じだと思うんですね。

ただ現実はそんな甘くなくて、（スライドを指して）こういう感じ。

（会場笑）

これがe-GovのAPIから送信するデータの仕様書です。

もちろんお国が出す仕様書なので、Excelですよね。これが数百あったりする。数の多さもそうなんですけど、そもそもMacにExcelが入ってなくてけっこうつらいという状況もあったりします。

リクエスト・レスポンスの中身がJSONだったらうれしいんですけど、実際はxml形式。あとは電子証明が必要だったりして、普通のWeb開発だとなかなか見ないような仕様だったり、仕様書だったりする。普通のWeb開発者には、これはけっこうつらい。

ということで、つらい思いをするのは私たちだけでいいと。私たちはこれを簡単に扱うための、kijiというe-GovのAPIクライアントライブラリを作成して公開しました。kijiを使うと、先ほどの仕様書をあんまり深く読まなくても、わりと簡単に使うことができます。

kiricoを作った経緯

ほかにも「kirico」というOSSも公開しています。先ほどのkijiは、e-GovとのAPIを使った通信部分をサポートするライブラリです。こちらのkiricoは、データの中身の作成をサポートするライブラリです。

電子申請に利用するデータについては、年金機構が公開しているアプリがあるんですよ。

こちらのWindowsのソフトを使って、送信するデータを作る必要がある。せっかくAPIを自社ソフトに組み込んでも、データはこの年金機構のソフトを使ってくださいとなると、片手落ちというか、中途半端なわけです。

そもそも最近はWindowsを持ってないユーザーさんも多いですし、UIもなかなか味わい深いんですね。

これで作られるデータってどんなものだろうと思って見てみると、こんな感じのCSVフォーマットです。私たちがふだんイメージするCSVとは、ちょっとだけ違う感じですかね。管理とかデータとかってところがあったりとか。なかなか味わい深いデータが作られる。

これを自分たちのサービスから作れるようにしたいと思って、どうしようと考えていると、こちらも実は年金機構が仕様書を公開してるんです。素晴らしいですね。「よし、作ってやろう」と思って開くと、PDFで、なかなか厳しい感じの仕様書なんです。

昔はあのフロッピーとかMOで出してたんですか。これがまた200ページくらいある。

（会場笑）

これはつらい。今回も、こんなつらい思いをするのは私たちだけでいいんです。ということで、kiricoというOSSを公開して、先ほどの仕様書をあまりじっくり見なくても使えるようにしました。

これを利用すれば先ほどの仕様書を見なくていいですし、普通にRubyでオブジェクトを指定するだけで作れるようになるので、簡単に電子申請用のファイルを作れます。

再利用可能なモジュールはライブラリとして公開

ほかにも「tsubaki」っていうgemも公開してます。マイナンバーとか法人番号って、バリデーションがあるんですね。「チェックデジット」という言葉を聞いたことがある方はいらっしゃるかもしれません。

クレジットカード番号の検証とかによく使われる、チェックデジットっていう仕組みがあるんです。マイナンバーとか法人番号にも、この仕組みが使われています。

特定の桁を元に計算を行って、その結果をチェック用の桁とすることで、入力間違いとかを防ぐ仕組みです。

マイナンバーの場合は、最後尾がチェックデジットとして使われてます。法人番号は、頭がチェックデジットになっています。

これの計算方法は、そんなに複雑ではないんですけど、まあまあめんどくさい。

スライドの例は法人番号で、これはそんなにつらくはないんですが、みんながみんな同じ開発しても馬鹿らしいよねと。車輪の再発明を防ぎたいということで、これのバリデーション用のジェムを、小さなgemですけど公開したりもしています。これを使うと、見なれた宣言方法でバリデーションを定義できたりもします。

このほかにもいくつか、サービスの開発途中で生まれた再利用可能なモジュールは、ライブラリとして積極的に公開しています。お気づきかもしれないですが、かなりニッチな、日本中を探しても使う企業はそんなに多くないんじゃないか、みたいなgemばかりです。

OSSに貢献するメリット

ここで言いたかったことは「この分野はつらみが多いよ」ということ……だけじゃなくて。それもあるんですけど「お金がなくても貢献はできるよ」ということを言いたかったわけです。

本日参加されてる方にとっては釈迦に説法かなと思いますけど、OSSを公開することによって失うものはほとんどなくて、得られるものばかりなんじゃないかと思っております。会社の技術ブランディングだったり、情報の公開によって得られる情報だったり。あわよくば、ライブラリに対してバグ報告いただいたり、さらに運が良かったらパッチをもらったり。

とくに有用なのは、OSSの公開によって、会社のカルチャーに良い影響を与えることだと思っております。実際私たちも、サービスの初期のフェーズでOSSを公開したことによって、優秀なエンジニアの方が興味を持ってくれたり、行政の方から声をかけてもらったり。あとはなによりも、会社に「積極的に情報公開する姿勢」をインストールできたんじゃないかな、と考えております。

RubyKaigiのスポンサーに

サービスが成長してきてうれしかったことの1つに、お世話になったRubyコミュニティに、ほんの微力ではありますが、貢献できたということがあります。売上が上がりユーザーが増えるにつれて、私たちは大小さまざまな技術者向けのイベントのスポンサーをさせていただきました。

とくに大きかったものが、RubyKaigiのスポンサーです。2017年はゴールドスポンサーで、今年2018年はRubyスポンサーとして参加させていただきました。いずれもRubyという言語に対する恩返しだったり、あとはRubyコミュニティがより一層盛り上がることを期待して、参加させていただきました。

もちろん本音の部分では「優秀なRubyエンジニアに興味を持ってもらいたい」というような期待もありつつ、スポンサーをさせていただいたわけです。本日参加されている企業のみなさまは、既にたくさん貢献されていると思います。今後より一層Rubyコミュニティを盛り上げるためにも「こんないいことあったよ」というお話を、数字を交えてお話ししたいと思います。もちろん各社状況は異なると思うので、ご参考程度に聞いていただければと思います。

良い言語というものは、優秀なエンジニアを惹きつけるわけです。カンファレンスに参加するエンジニアは、好奇心が高くて学習意欲が高い方が多いと思っております。今年のRubyKaigiにRubyスポンサーとして参加したとき、うちの社長がこんなプレゼンをやりました。

「転職して欲しい」「技術顧問になってほしい」「採用にアドバイスして欲しい」「口コミをしてくれるだけでもいい」……。

（会場笑）

あまりにどストレートな内容で。ちょっと上品じゃなかったんですけど。その場の空気としては、まあまあ好意的に受け取っていただけたのかなと思っております（笑）。

結果どうだったかを、今日はさらっと共有したいと思います。蓋を開けてみると、このイベントへの参加がきっかけで、優秀なエンジニアを1名採用できました。

（会場拍手）

あっ、ありがとうございます（笑）。

技術顧問のほうも素晴らしい方が1名見つかって、ジョインしていただいてます。すごく微力ではあるんですが、Rubyコミュニティに恩返しするつもりだったのに、また恩をいただいてしまいました。今後どうやってまた恩返ししようかなと考えているところです。

ここまでのまとめです。

お金がなくてもコミュニティへの貢献はできるというお話をしました。OSSの公開はメリットばかりというお話もしました。お金があれば直接的な貢献もできますし、技術イベントのスポンサーは直接的なメリットがあるかもしれないよというお話も、ちらっとしました。