【CTOインタビュー】エンジニアの成長を促進させる社内の文化づくりとは？――テモナ・中野賀通さん
CTOを、親しみやすいように「ちょっと、たのしい、おじさん」と言い換えて有名なテモナ株式会社の取締役CTO中野賀通さん。
教員やマーケティングも経験されたCTOの中野さんにテモナ株式会社のエンジニアの成長を促進させる社内の文化と組織作りについてお話をうかがいました。
目次
ITの力でフロー型ビジネスをストック型ビジネスに変える
テモナさんは「リピートIT」に特化したテクノロジーを使い、「ビジネス効率」、「ビジネス成長」、「便利な暮らし」を追求する事業を行っています。具体的な内容をお伺いしてもよろしいでしょうか？
テモナという社名は「てもなく」という古い日本語に由来しています。「てもなく」は「手も無く」と書き、手を使うまでもないくらい物事を容易にするという意味です。そこから僕らの会社は「ビジネスと暮らしをてもなくする」というビジョンを掲げ、それに沿った事業展開を行っています。 メインサービスは、定期通販や単品通販などサブスクリプション型のビジネスモデルに特化したECカートシステム「たまごリピート」です。 商品を安価にユーザーに提供する代わりに継続して購入してもらうというサービスを展開中のEC事業者さんを対象に、フロントのお買い物画面から、CRMと言われるようなマーケティングシステム、決済、出荷、問い合わせへの対応までワンストップで行うことができます。
今、僕らは「フロー型のビジネスをストック型のビジネスモデルに変えていく」という野心を抱えています。たとえば音楽を例に挙げますと、昔はDVDやCDの購入を通じて楽曲を入手していましたが、そのうちTSUTAYAでレンタルできるようになり、現在ではApple MusicやAmazon Musicなどの月額モデルで手に入れられるようになっています。 自動車も同じ。車は自分で買うものという考えが一般的だった頃から時代が下り、レンタカーが登場し、今ではカーシェアリングが台頭しています。
これからはこういう領域がどんどん成長していくと思っています。そこにサブスクリプションモデルで参入していきたい、というのが私たちの構想です。
テモナさんは「たまごリピート」など様々なサービスを展開されていますが、中野さんはCTOとしてどの開発チームを管理していらっしゃるのですか？
まず、うちのエンジニアチームの特徴から話しますと、チームの8割が「新卒文系プログラマ未経験」みたいな人で構成されています。ちなみに中途採用の人はほとんどいません。 僕のファーストキャリアは学校の先生でして、中学と高校で4年ほど先生を経験しています。元々キャンバスが真っ白な子達を染めていく、というのが得意なので、文系未経験者の人でも問題なく受け入れられるというのはあると思います。 それと中途採用者が少ないのは、僕らの理念にマッチするという人が少ないから、という理由です。もちろん中途採用には優秀な方が多いとは思います。ですが、テモナは理念経営を徹底しています。なので、理念を徹底的に追求できる、パッションがある人達を新卒で育てていくほうが、うちの会社にフィットする人を育てやすいのではないか、と思っています。
もうひとつ特徴的なところは、チームの3分の1くらいがオフショアでの勤務だというところです。業務連絡はChatWorkを使用し、使用言語は英語、日本語、ベトナム語が混ざっている感じでして、プロジェクトに参加してくれている人の内、10人くらいはベトナムにいます。日本では20人くらいが東京にいて、あとは名古屋で仕事する人もいる、という感じですね。時差3時間以内の場所ならどこでも勤務OKです（笑）。
親日感情が強く、土地の雰囲気も良いハノイから人材を獲得
上場前に、ベトナムでラボやプロダクトを作り、日本のオフィスでもプロジェクトメンバーとして活躍されていらっしゃるのですね。
結局大事なのは人と人との付き合いじゃないかな、と思います。3年前、最初の立ち上げの時期は、僕と開発マネージャー2人で3ヶ月くらいベトナムに住み、チームビルディングを行いつつ「こういう想いで俺達やっていきたいんだよ」ということを伝えました。そうした活動を通じて向こうで採用した子達を日本に呼んでおり、今はベトナム国籍のメンバーが6人くらいいます。
そもそもベトナムに目をつけたのには何か理由があるのですか？
前職で事業の海外展開を任せてもらったことがありました。当時は中国やタイなどに事業展開する予定があり、結果的に向こうでOEMにより事業提携するという話がまとまり、これは大きいことをやれそうだな、と思っていたんです。ところがその矢先に尖閣諸島問題が生じ、話がおじゃんになってしまいました。 このように国内の政治的なものでごたつく可能性があるので、当初は、海外の人と一緒に仕事をするのはリスクが大きいと考えて二の足を踏んでいました。
ただ、その過程で僕はベトナムにも行ったのですが、ホーチミンはアメリカの外資系企業が既に参入していて、その影響でジョブホッピングが盛んに行われているような状況でした。しかしハノイは少し状況が違い、「家族」みたいな雰囲気が強く残っている土地柄で、日本で言えば東北みたいなところだったんです。くわえてハノイは親日感情も強い。時差も3時間以内なので、ここはありなんじゃないか、ということでハノイを選びました。
現在はオフショア会社にラボとして契約させていただいて、人材だけをまるっと借りているという感じですね。ただマネジメントは僕らが直接行っています。
CTOとして社内の文化づくりにも積極的に取り組む
社内でのエンジニアのマネジメントや評価制度について教えて下さい。
評価自体は目標管理制度（MBO）の概念をベースに行っています。ゲーミフィケーションの一環として、チーム会計制度というものを導入しました。
チームごとに予算を割り当てて、その予算のなかでお互いに受発注をさせ、市場原理としてこのくらいの単価なので、隣のチームから依頼された時にはこのくらいの値段で売るよね、という数字感を覚えさせます。このやり取りを通じて、まずは「数字として計測する」ということを意識させるのが第1段階でした。 チーム間で数字感を揃えられたので、現在ではゲーミフィケーションを撤廃して、代わりにチームの目標となる数字を設定するようにしました。
数字の内容を大きく分けると、成果を直接的に評価するという「パフォーマンス」と、中長期的に評価する、将来的にパンチが効いてくるであろう「バリュー」、そして個人としての生産性の3つです。また、理念をどの程度遂行できているか、という点への評価もあります。
評価基準は各職能に応じて変化します。CTOクラスならパフォーマンスのほうが80％で、理念のところは20％、もう少し下のリーダーだったらどちらも50％くらい。それを半期ごとに評価しています。半期の中頃に行う中間評価と合わせて、3か月ごとに評価を行い、結果を1on1でしっかりフィードバックしてあげる、という制度です。
ちなみに教育の研修システムは中野さんが作成したのでしょうか？
そうですね。エンジニアは勉強好きの人が多いので、学習のための支援制度を作りました。また、3ヶ月に1回は開発合宿を開催しています。合宿は一応会社から助成金という形で費用を出しており、基本的には任意参加ですが、毎回皆参加します。
ほかにも勉強会や、月1回のLT大会もあります。そうしたイベントを通じて、メンバーが互いに切磋琢磨しつつ技術力を高めあい、やがて業務以外の様々な領域にチャレンジしていきます。
エンジニアの技術力や生産性の向上は、ビジネスの成功確率に直結します。なので、誰に言われずとも「俺達プロだから自分でやるよ」と、自主的に技術力や生産性を研鑽していく文化を社内に根付かせたかった。それにずっと取り組んできたという感じですね。
CTOによる技術理解のあり方は一通りじゃない
中野さんは「CTO」という言葉から一般的に連想される業務以外も引き受けていらっしゃるようです。
僕は自分自身のことを「雑草CTO」と呼んでいます。「気付いたら勝手に生えていた」みたいな意味なんですが（笑）。
実は、僕はこれまでプログラムを仕事で書いた経験がほぼありません。テモナの事業に技術顧問として携わり始めてからは、ソースコードを書いたりするなど、ミドルウェアやインフラ関連の仕事にも携わっていますが、いわゆる「王道なCTO」ではありません。
実際、CTOでも雇われCTOと執行役員CTO、取締役CTOではそれぞれ職務、職責が全然違います。会社のステージによっても業務内容は全く違う。僕自身は、アーキテクチャや全体のプロトタイプを作ったりしていますが、それ以外にも社内の文化作りや教育なども手掛けています。ただ、いずれのフェーズでも経営的な視線で技術に向き合い、戦略を見出すという点だけは共通しているでしょう。もちろん、根本的には技術について深く理解している必要はあります。ただ、その「深さ」のあり方にはバリエーションがあって良いと僕は思います。
ちなみにうちの会社では、CTOは「チーフテクノロジーオフィサー」という堅苦しい肩書きではありません。「ちょっと、たのしい、おじさん」という意味で、社内を盛り上げて、差し入れをするという役割です。
対外的に責任の所在を示すためにCTOとは名乗っていますが、あんまり構えられても嫌なので、親しみやすいように「ちょっと、たのしい、おじさん」で通しています。 まあ、僕が勝手に言っているだけなんですけど（笑）。
最後に、中野さんから読者の皆様に向けてメッセージをお願いします。
最近、社内でよく「技術は道具にすぎません」と言っています。その点を勘違いしないようにしていただきたいです。プログラム言語など道具の扱い方だけ極めますと言っても、当然その道具の限界はどうしても存在します。そこを強く意識して、限界がきたら別の道具に持ち替えるということをして欲しい。一方で、そもそも道具の扱いが上手くなければ、モノを作る、ビジネスを作る、価値を提供するといったことができなくなります。なので、むしろ徹底的に追求して欲しいというのも事実です
あとはプロダクトにどれだけ愛を注げるか、というところ。それができるエンジニアがいっぱい増えて欲しいなと思います。
企画/編集：FLEXY編集部
