nanapi創業当時のエンジニアは自分しかいなかった
和田修一氏（以下、和田）：おそらく私だけじゃなくて、CTOしかいない場で話すことってなかなかないと思うんですよ。結構どういうことを話そうかなっていろいろ考えました。
タイトルは一応こんな感じなんですけど、本日話すことといたしましては、テクニカルな技術選定基準っていうものは、そんなに話さなくてもいいかなって思っていて。
タイトルの通りなんですけど、CTOとして、こういう立場だからこそ考えていることとか、こういう風にして技術選定してますよ、といったところをお話していきたいなと思います。
いくつかあらためてとなるのもあるかと思うんですが、自己紹介をさせてください。私、和田と申します。1981年生まれで33才ですね、結構近い方も、昨日のアンケートだとこの線がボーダーだったかなと思います。
立場なんですけども、nanapiのいろんな肩書きがついてるんですけどCTOやってます。さっき言い忘れたんですけど、好きなAWSのサービスはお約束だなと思って、好きなAWSのサービスはS3かなというところですね。
自己紹介の続きなんですけども、ここ1年でよくわからない取材をいっぱい受けていて、自転車のってるとかですね、マラソンしてるとか、あとギター弾いてる取材とかも受けてるんですけども、基本的には迷走してるんですけども、普通にnanapiでCTOをやっています。
今までどんなことをやってきたかなんですけども、2005年に新卒で楽天という会社に入って、今の会社の前身となるロケットスタートという会社を今から5年前に始めたという感じですね。
私は途中からCTOになったという形ではなくて、本当に始動から私しかエンジニアがいなかったので、この時点でCTOになりました。
ユーザー情報が入っているデータをtruncate（削除）した
社名変更を2011年にいたしまして、私の会社としては大きなニュースだったんですけども、今年の10月ですね、KDDIグループへジョインいたしましたというところです。
（前のセッションの）田中（慎司）さんもやっていて、CTO事件簿というのを私もいれなきゃいけないのかなと思って。すごい近いの。スケールや条件を入れ忘れたみたいな話がありましたけど、僕はさらに酷いことをやってしまって、開発環境をいったん壊して直そうと思って。
ユーザーの情報が全部入っているデータをtruncateしたんです。これでスッキリしたなと思って、よく見たら「これ、本物じゃね？」ってことに気づいて。
顔真っ青になってですね、バックアップはしてあったので。あとは新規ユーザーの登録情報の復旧を必死にやりました。これCTO事件簿って言ってるんですけど、私1人しかいなかったので。
本当に泣きそうになりながらですね、復旧していたというようなことをやっていました。結構昔の話ですけどね。一番デカかったのがこれです。
最初の紹介に戻ってしまうんですけども、株式会社nanapiでこんなサービスをやっています。これはウチの代表サービスなんですけど、nanapiというサービスをやっています。
これがウチの会社で最初に作ったサービスで、2009年から10万件を超えるハウツーが集まるCGMサービスとなっています。ユーザー数もそれなりにいて、サービスとしてそれなりになっていますよというところです。
これ以外にもさまざまなサービスを運営する会社になっています。いくつか紹介しようかなと思うんですけども、もしかしたらご存知の方もいらっしゃるかなと思うんですが、アンサーというサービスをやっています。
これは今から1年前ですね、QAアプリとしてはじまって、iOSで最初始まったんですけど、現在はQAだけじゃなくてユーザー同士がコミュニケーションとるようなアプリケーションとしてリリースをしています。
書き込んでからすぐにレスがもらえるのが特徴で、匿名性が高いサービスとなっています。現在はAndroidでもリリースしていて、順調にいっているかなというところです。
その他、海外向けのサービスというか、これ日本語版は作ってないんですけど、Media for Inspiration and Motivationということで、気付きとかを与えるメディアということでやっています。
英語圏のみがターゲットとしてリリースしておりまして、現在引き続き運営してますよというところです。こんなサービスを運営する会社になってきています。
CTOだけが技術の意思決定者ではない
簡単にチーム体制をお話しようかなと思うんですけど、縦切り組織か、横切り組織かっていろいろあるかなと思うんですが、ウチはサービス単位で縦に切っています。
今、代表サービスのnanapi、アンサー、いくつかありましたけども、それ以外にいろんな新規事業をやっています。
ウチはエンジニアが兼任したりとかではなくて、基本的に各プロダクトにアサインしてその人がいろいろやってくみたいな感じですね。
エンジニア間の連携っていうのは、私とかがCTO室っていうのをもっていまして、そこでいろいろ見ていると言った感じです。
ウチの会社においては、意識しているところはまず、サービス間で基本的にシステム連携を無しにしましょうというところです。横のサービスに引きずられて会員連携しましょうよとか、重要だったりする時もあるかと思いますけど。
ウチはnanapiサービスに引っ張られずに新しいものを作ろうというので、その連携は原則無しで今やっています。ただ、結果的にプロダクトごとにいろいろ考えてもらうよというところですね。
さっきお話したように、エンジニアとかデザイナーの横断ってのはCTOが横断的組織を作っていたりします。
各チームにエンジニア、デザイナーがアサインしているので、極力そういうようなチームに裁量を与えるというようなことをやっています。
技術選定ってお話になってくるんですけども、いろいろあると思うんですけど、私はCTOだけが技術の意思決定者ではないというのが正しいと思っていて、さっきオートファームってお話がありましたけども。まさにそれが正しいんじゃないかなと思っています。
私が全部わかっていて、できるなって思い込むのは危険で、ある程度社員に任せようっていうのが会社の技術選定の時の基準だったりします。
なんでこんなことを考えるように至ったのかなんですが、結構よく言われる話で「赤の女王仮説」。まあご存知の方もいらっしゃるかと思うんですけども、要するに変化とかに耐えるためには頑張らなきゃいけませんよって話なんですよね。
普通に頑張っているだけだと、時代にギリギリついていけただけでものすごい頑張んないと大変だよみたいな話だったりします。これ結構生物学上言われたりするみたいなんですけど、まさにこんなことを言っているような仮設だったりします。
これは組織や技術においても同じで「変化を続けて変化に耐えなければいけない」というのが基本的な考え方として組織をつくっています。
結局自社のやっている技術は変わらなくても、時代って変わり続けるんですよね。たぶんこの数年でビジネスやってる方もまさに経験されていると思うんですけど、それまでフィーチャーフォンでやっていたものがスマホへいったと。
ついていけてる会社も、いけてない会社もありますよ、そこで自社が変わらなくたって時代は変わるので、それに対してなんらかの手を打っていかなければいけない。結局進化し続けて、変化に耐えられる組織ってのが一番重要になってくるんですよね。
それは技術だけじゃなくて、技術選定も大事で、5年前は当たり前だった技術が今は当然古くなってるってあると思うんですよ。
そういったものをいかに選択していって、事業の中で使っていけるのかってところについては経営組織にかかる分なのでそういったところをどうやって組織をふまえてやっているのかってところをお話できればなと。
ただ、ウチも完璧にできてると思いませんし、いろんな試行錯誤があって現在に至るわけですけれども、今十数名の組織になってきたりするので、経緯の中でいろいろお話できればと思っています。
やっぱり組織ってできてくる中でいろんな経緯があると思うんですね。さっきお話したようにまだまだ試行錯誤している途中だったりします。
それに組織って、これだけやっておけばオッケーっていうんじゃないなって思っていて、やってる事業だったりとかすでにいるメンバーだったりとかCTOとしての性質だったりとか、さまざまなものに引っ張られて組織のやり方って変わってくるって思っています。
あとは私がこうやってきたっていうだけのお話にすぎないんですけれども、少しでも参考になればなと思っています。
とにかく安くあげることが最優先だった
CTOという立場になって5年ちょっと、会社をやってきているんですけども、私CTOという立場でいろんなフェーズがあったかなと思ってるんですが、大きく分けて4つのフェーズがあったなと思っています。
この中で技術選定基準だったりとか、組織の考え方ってのがそれぞれ変わってきていたりするので、そこら辺をお話できればなと。
まず「じぶんが開発」というフェーズなんですけども、多分初期の頃にジョインした方とか、代表と一緒に創業した方なら経験してるんじゃないかなと思っています。
さっきお話したように2009年nanapi創業時に当時ロケットスタートって社名だったんですけども、会社を始めた時でした。
この時はどんなことをやっていたのかというと、nanapiってサービスを開発していたんですけども、とにかくキャッシュがなかったんですね。マジでお金がなかったんですよ。
どうやって生きてるのかっていうと、受託開発ってのが当時私の選択肢でした。まあ、赤字なんですけども、受託開発をしつつ、nanapiを開発してなんとかしていくというところですね。
本当にキャッシュがなくて足りない時は、役員報酬を減らすことで運営をやってきていました。
自分が何をやっていたのかというと、全部で、インフラもサーバーサイドも、フロントもですね。当時まだネイティブ開発ってやってなかったので、そっちのほうはなかったんですけども、関わるのはすべてやっていたというのが当時の開発の内容だったりしました。
その時は1人しかいなかったので、とにかく安くあがることっていうことが最優先ですね。なのでレスポンスの早いアクセスをかけて、とにかく安くいきましょうと。
正直、ちょっと1人だから許されるアーキテクチャもあったりして、複雑で自分しか理解できなそうなところも結構あったりしたんですけども。
でも上の2点を満たせればいいやっていうので、むちゃくちゃなアーキテクチャ作っちゃってっていう反省も当時あったりしました。
技術選定の基準は「自分が死んでもなんとかなる」
リリースした後ですね、3日くらいで100万PVとかいってしまってそれなりにアクセスはきてしまったので無茶な構成だったんだけど、安くさばける構成をとっておいてよかったなあというのがあったりします。
結局PVがあっても売上げってなかなかメディアみたいに上がるものではないので、安く上げるっていうのが課題だったなってことですね。当時は9800円の何とかサーバーみたいなものを3台で頑張っていたみたいな感じでした。
あとはプライベートネットワークで繋がっていなくてグローバルIPしか持っていないサーバー3台みたいな感じで、結構大変じゃないですか、何かすごいめちゃくちゃな構成を組んで何とかさばいていた時代ですね。
それでもこのPVは余裕でさばけていたなあという、それなりにむちゃな構成であったんですけど、1人だからこそ、ある意味できたのかなと思ったりします。
そういったのをふまえた上で、当時の技術選定っていうのは本当に安くあがるってのがすごく重要だったのかなと思いますね。
現在VPSとか安くなっているので、VPSをたくさん並べるのもありなんじゃないかなと。当時まともに使えるVPSはあまりなかったので、専用サーバーだったんですけれども、こんな構成をやってましたと。
あと言語ですね。当時PHPとCakPHPを使っていたんですけども、これシンプルでエンジニア僕しかいなかったので、僕が死んでも何とかなるってことで言うと、代表が若干コード書けるんですよ。書けるコードがこの2つのセットなんですよね。
なので、これにするよって話でこの構成を組んだっていうのが当時の選定基準だったりします。結構むちゃくちゃな選定基準なんですけど、これは本当にこれで選びました。これが私が1人でやっていた技術選定基準だったりします。
