CLOSE

シード・アーリー期のCTOの役割(全3記事)

あえて社長の知らない開発言語を使う? スタートアップのCTOが技術選定の基準を語る

freee・横路隆氏、Timers・椎名アマド氏、SpotLight・高橋三徳氏、VASILY・今村雅幸氏など、各社のCTOが登壇し、「シード・アーリー期のCTOの役割」をテーマに意見を交わしたトークセッション。本パートでは、CTOの腕の見せ所である技術選定に焦点を当て、自己紹介を兼ねて今のサービスの技術的環境と、その選定理由についてそれぞれが回答しました。(IVS CTO Night & Day 2015より)

CTOの腕の見せどころは技術選定

今井雄太氏(以下、今井):まず1本目、CTOディスカッション1「シード・アーリー期のCTOの役割」ということで、まず4名のCTOの方にパネラーとしてご登壇いただきたいと思います。

まずモデレーターの私の自己紹介をさせていただきます。アマゾンデータサービスジャパンの今井と申します。篠原(篠原英治氏)と同じですね。ソリューションアーキテクトという仕事をしております。主に広告系のお客様を担当しております。

このあと質問の中で、パネラーの皆さんに自己紹介していただこうと思います。こちらのセッションのテーマなんですけど、初日の皆様のアンケートの集計で、「CTOとして1番大事だと思うことは?」というところで、「マネジメント」と「技術」という2つにフォーカスが集まっていました。

こちらのセッションでは技術のほうを取り扱って行きたいと思います。このあとのセッションで、マネジメントとかチームビルディングの話を扱っていきたいと思います。

技術面をテーマとして扱いますということで、個人の技術というよりは技術選定ですね。さっきのQAセッションでもかなりこのへんがフォーカスされていたと思うんですが、皆様ご自身が「どんな経緯で技術選定されてきたのか?」というようなところをお話いただきたいと思います。

その前段として、昨日はてなの田中さん(田中慎司氏)のセッションでも技術選定の方針というお話が出ていました。そこである程度保守的にではあるんだけれども、重要なところはアグレッシブに、ということで、まさにこのへんの匙加減、CTOの腕の見せどころじゃないかという話があったのかなと思います。

重要な点としては判断ミス時の撤退を念頭に置くというような話がありました。このへん皆さんがどう判断されているのか等を、掘り下げて行きたいと思います。

いくつか前提条件をつけさせていただきます。2つですね。まず組織の規模としては「シード・アーリー期」とタイトルにも付けましたが、エンジニアが1人から数人くらいのエンジニアチームの時点でのお話とさせていただきます。

もちろんチームで働かれてるケースもあると思うんですが、チームも含めてここでは一人称で語っていただきます。

あとはもう少し前提を合わせるために、パネラーさんの紹介を自己紹介の前に軽くさせていただきます。

まずはfreeeの横路さん。会社の期としては3期目、現在エンジニアは30人くらいの組織で、創業組のCTOです。その隣が椎名さん、Timersの方です。同じく3期目、現在エンジニアは6人で創業組です。

SpotLightの高橋さん。会社は4期目でエンジニアは10人、こちらも創業組のCTOの方です。VASILY今村さん。7期目で、15人くらいの組織でやってらっしゃいます。今村さんも創業組です。このへん皆さんその方なりの背景として、前提条件として置いていただければと思います。

CTOにはインフラ経験者が多い?

今井:今日の本題に入る前に5人で事前ディスカッションしてる中で「CTOってインフラやってる人が多くない?」っていう話がありました。結構皆さんアプリケーションも書かれる方も多いとは思うんですが、組織の中ではインフラ部分をやっていたりということが多いんじゃないかという話を、実際聞いてみたいよねという話になったんですけども。

実際CTOとして組織の中でインフラを担当されていて、他の人、例えばチームにはアプリケーションを書いてもらっているみたいな組織体制の方ってどのくらいいらっしゃいますか?

質問者:インフラもやっているっていうのは?

今井:インフラの整備、例えばAWSでいうとEC2を作って、EC2とRDSとELB(Elastic Load Balancing)の構成を作ってそこの設計をする。そのEC2の上で動くアプリケーション部分は別のメンバーがやっているみたいな、そんなケースです。

質問者:全部やってるっていうのはどのくらい?

今井:全部やっているは……インフラもやっているで、手を挙げていただいて。

質問者:やっていた、も含む?

今井:やっていたも含め。じゃあもう1回、全部やっている、もしくはやっていたも含めってするとどのくらいいらっしゃいますか?

(会場過半数以上挙手)

じゃあ全部の方(は挙手)を降ろしていただくとどのくらいになりますか? 自分で全部やっている以外の「やっている」もしくは「やっていたと」いう方ってどのくらいいますか? 会場内の3分の1くらいですかね? 思ったより少ない。ありがとうございます。このへんももし何か、このあと議論で気になるところがあれば含めていただければと思います。

リリースまでが早い言語と環境を選んだ

今井:ここから3問、本題に入っていこうと思います。まずはパネラーの皆さん自身の自己紹介、それから今のサービスの技術的環境。例えば構成だったり言語ですね。その選定理由をお聞きして行きたいと思います。では横路さんからお願いできますか?

横路隆氏(以下、横路):freeeの横路といいます。freeeは全自動のクラウド会計ソフトと給与計算ソフトをリリースしていて、サービスのローンチから1年半で、現在14万から15万くらいのユーザーの方にご利用いただいてます。私も事故の話をすると、ドロップデータベースというのをやったことがありまして。

(会場笑)

Zabbixをぼんやり眺めてたら、線形でDBの空き容量が増えていくんですね。何が起こったのかな? と思っていたら、実は環境変数をステージングと本番で逆に配ってしまっていて、それでステージングを1回リセットしようと思ったエンジニアが、スクリプトをかけた瞬間にドロップデータベースが走るという経験が。

それで皆は鳥貴族に行って飲んでたんですけど、鳥貴族から帰ってきて皆で作り直したっていう思い出があります。RDSの自動バックアップ機能で事なきを得たんですが、チームの教訓になりました。

うちは創業時からRuby on Railsで書いてるんですけど、今も変わってないです。選定理由としては、最初僕と社長の2人しかいなくて、社長はもともとプログラミングのバックグラウンドがあまりない中で、エンジニアとして急速キャッチアップ中でして、2人で最初のリリースまでに一番スピードが出せる言語と環境を選ぼうということで、Railsを選びました。今日はよろしくお願いします。

今井:ありがとうございます。

PHP選定の理由は学習コストの少なさ

今井:では椎名さんお願いします。

椎名アマド氏(以下、椎名):株式会社Timersの椎名アマドといいます。株式会社Timersではカップル専用SNSの<a href="http://pairy.com/"target="_blank">「Pairy」っていうのやってまして、カップル2人だけで写真共有やチャット、「デートにいつ行く、どこに行く」っていうのを調整できたりするスマートフォンアプリをAndroidとiOSで提供しています。

あと同時に、半年くらい前から子育て写真共有アプリの<a href="http://famm.us/ja"target="_blank">「Famm(ファム)」っていう夫婦向けのアプリも出しました。これは最近月1で印刷通知が、無料で届くっていう機能もリリースしたりしてます。 

言語に関しては全部PHPのCodeIgniterを使ってます。バックエンドはRDS、あとチャットデータはDynamoDBを使っています。PHPを選んだ理由は当時1番僕が書きやすかったっていうのと、学生とかも簡単に採れるかなっていう。

当時僕1人でコーディングしていて、猫の手も借りたかったので、学生のアルバイトとかを募集していたとき、PHPのコードを書くのが1番学習コストが少ないよねっていうので、それを選んじゃいました。今でもそれやってます。

DynamoDBとかチャットで、writeがすごい多いものなんで最初Redis使ってたんですけどRedisは全てオンメモリーで、どんどんメモリーを圧迫したんでDynamoDBさんにお世話になろうっていうことで、今でもすごい感謝して使わせてもらってます。今日はよろしくお願いします。

社長の知らない言語を選んだ

今井:よろしくお願いします。高橋さん、お願いします。

高橋三徳氏(以下、高橋):SpotLightの高橋です。SpotLightは4期目なんですけど、去年楽天に買収されまして、楽天の子会社としてやってます。サービスとしては創業当時から「スマポ」っていうサービスと「楽天チェック」というサービスをやっています。

どちら側も来店ポイントサービスで、お店に行くだけでポイントがもらえるっていうサービスをやってます。

使用技術としては、言語としてはPythonを全部使っていて、データベースはPostgreSQLというのを使ってます。Postgreはうち、位置情報を使うので自然とそうなったっていうところです。

Pythonに関してはCTOといっても、最初はただのいちエンジニアでコードを1人で書くっていう立場なので、自分が1番テンションあがる言語っていうのが重要かなと思ってPython選んだりとかですね。あとPythonっていうとなかなかエッジの効いた人が多かったかなっていう、当時の印象があってですね。

そういうフィルターとしてちょっと選んでみたっていうのと、あと最後に大事なところが、社長がPHP書けるんですけどPythonは書けない。だから余計なことをされない。

(会場笑)

今井:これ重要ですね。こんな感じです。よろしくお願いします。

メンバーが増えてPHPに飽きた

今井:では今村さんお願いします。

今村雅幸氏(以下、今村):株式会社VASILYの今村と申します。僕らはファッションのコーディネートアプリの<a href="http://www.iqon.jp/"target="_blank">「iQON」っていうアプリをやっています。なんと今朝、ちょうど2014年Googleベストアプリに選ばれたので。すごい光栄だなあとか思いながら。

僕はもともとヤフージャパンというところにいて、PHPをガリガリ書いて独自のフレームワークとかをつくったりしていました。iQONの原型はPHPで作ったんですけど、メンバーが増えるとPHPは飽きたっていって、Rubyになりました。その頃Railsが流行り始めてきてて、チームで開発するとか便利なGemとか揃ったんでRailsでやろうって、今もRailsでやっています。

あとRubyのまつもとさん(まつもとゆきひろ氏)が技術顧問だったりするので、そういう関係もあってRailsかなぁと。でもまつもとさんが言うには「別に何でもいいよ」って。多分Matzさんに作るのは何の言語でも怒られないなと思って。よろしくお願いします。

今井:ありがとうございます。今日はよろしくお願いします。

社長の書ける言語を選択するメリット

今井:皆さん主に言語とフレームワーク等のお話をしていただいたんですけど、大体皆様今のサービスの選定理由としては、人の取りやすさだったり採用のしやすさだったり。

また学習コストも高い・低いというようなところだったのかなと思います。ちなみに横路さんと高橋さんの話がすごいおもしろかったんですけど、社長がわかる言語、社長がわからない言語と。横路さん実際どうでした? 社長がわかる言語は。

横路:うちの社長は天才なので、結構すぐマスターしてしまって。僕は最初簿記の知識が一切なかったので、会計のビジネスロジックの多くは、彼がゴリゴリ書きました。もちろんエンジニア視点から見るとメンテナブルでないコードも多いんですけど。

「ビジネスロジックに対するユニットテストは、さすがにきちんと書こう」っていうのをある程度最初にやっていたおかげで、わりときちんと動くものが提供できたというのは、素晴らしいことだと思っています。

今井:ありがとうございます。それは横路さんもしくは他のエンジニアの方がレビューをするなり、テストは他の人が書くみたいな、そんな感じなんですか?

横路:それでいうと最初はコードレビューの時間ももったいないくらいだったし、作ろうと思っていたものが結構大きくて、最初のひとつを作るのにすごく時間がかかったので。とりあえずコードレビューはスキップして、テストケースだけレビューしようというのをやってました。

今井:ありがとうございます。一方、社長の書けない、読めない言語選んだ高橋さん。実際選んでみてどうでした?

高橋:社長は手出ししてきませんでした(笑)。

今井:ということになっちゃいますよね(笑)。すみません、ありがとうございます。他にも社長の書ける言語を選びましたっていう方もいらっしゃったんですが、「社長が書けるからこの言語にした」とか「このフレームワークにした」っていう方っていらっしゃいますか? ……1人2人くらい、会場にいらっしゃいますね。ありがとうございます。

人数的には何割というような話でもあるんですが、フェーズによってはやっぱりそういうこともあり得るという、これは私自身初めての話なので非常におもしろい気付きだったと思います。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 各地方の豪族的な企業とインパクトスタートアップの相性 ファミリーオフィスの跡継ぎにささる理由

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!