エンジニアtype - エンジニアのシゴト人生を考えるWebマガジン
  • TOP
  • キーパーソン
  • 旬ネタ
  • コラボ
  • ノウハウ
  • 女子部
  • キャリア

ビズリーチ竹内真氏×BASEえふしん氏、2人のCTOが答える「成長するチーム」を作るための3つの問い【特集:1を100にする開発戦略】

タグ : BASE, えふしん, スタートアップ, ビズリーチ, マネジメント, 技術選択, 竹内真 公開

 

ゼロイチを果たしたベンチャー企業が、イチヒャク、すなわちさらなる事業の拡大を果たすためには何が大切なのか。BASEとビズリーチという成長著しいベンチャー2社のCTOが、成長期に直面する課題と解決策について語るトークイベントが5月14日、ビズリーチ本社で開かれた。

登壇した2人は、ひと口で「成長ベンチャーのCTO」と言っても立場が大きく異なる。

BASEのCTOえふしん氏は、複数のスタートアップなどでの経験を買われて昨年8月にBASEに入社し、現職に。BASEに続いて決済サービスのPAY.JPも公式リリースに向けて準備中だが、エンジニアはまだ15人とそれほど多くなく、まさにこれからいかに成長させていくかを託された立場。

対してビズリーチのCTO竹内真氏は、創業メンバーとしてサービスや組織を設計してきた立場であり、さまざまな成長の局面を経て、現在は従業員500人超、エンジニア120人以上の大所帯を束ねている。収益事業もビズリーチを含めて5つある。

会社のフェーズが違えば、直面する課題も違うし、最適な解決策もそれぞれ事情の異なる会社の数だけある。2人が考える、イチヒャクに伴うエンジニアリングチームの成長痛とそれに対する処方箋を、【1】技術選択、【2】マネジメント、【3】ビジネスとエンジニアリングの関係——の3つの観点からまとめてみた。

【1】技術選択はどう考えればいいのか?

竹内氏

「開発言語の選択は5年後10年後を見据えて行っていると」竹内氏

竹内氏:5年後をイメージできることが大事。アーキテクチャでリスクヘッジ

ビズリーチ創業初期の2009年ごろは、新興会社がどこもRuby on RailsやPHPを開発言語に選んでいた。Javaを選択したのは逆に張る発想。採用マーケットでは、比較的安く採用費で良い人材と出会えると考えたから。

ゼロイチだけ考えたら開発言語は何でもいいが、ビズリーチはBtoBサービスであり、5年10年と続ける必要があった。サービスが大きくなった時にイメージできる言語であることは大事ではないか。

一方、途中からJavaと並行して使っているScalaについては、使い始めた当時はまだ入門書も少なく、初心者に優しくない言語だった。そのことが採用を難しくさせ、ビジネスを計画通りに進める上でのボトルネックになった。

選んだ言語が思うように流行らないかもしれないというリスクは当然ある。そのために最初からマイクロサービスアーキテクチャで設計し、言語を切り替える逃げ道を作っている。

ただし、この構造には間をつなぐインターフェースを設計しなければならず、リーンスタートアップには向かないという課題もある。その辺のバランスをどう考えるかが大事。

えふしん氏:サービス、言語の横展開には採用の幅を広げるメリットも

BASEはCakePHPで書いているが、PAY.JPはピュレカ社がBASEの子会社になる前からPythonで書かれていたことから、今もPythonのまま。

2つのサービスは親和性が高いもので、全く別の事業というわけではないが、新しいサービスを始めることで、採用の際にPythonで書きたい人や、決済サービスに興味のある人にも目を向けてもらえるというメリットがある。

BASEは機能拡張をBASE APPSというアプリのような形でリリースしている。現状はこれらが密結合してしまっているが、今後のことを考えると、いずれは粗結合に分離させていきたいと考えている。

【2】CTOやマネジャーはコードを書く仕事から離れるべきか?

竹内氏:食卓に料理をサーブする仕事と捉えれば、チームが7人になればほぼ限界

ビズリーチではマネジャーのことを「サーバントマネジャー」と呼んでいる。上から管理する一般的なマネジャーのイメージとは違い、こぼれ落ちた漏れそうな仕事を下から受け止める役割を担う。

その仕事は、食事をサーブする人のことをイメージすると分かりやすい。

食卓に2、3人しかいなければ、料理の作り手が台所と往復しながらでも、一緒に楽しい食事の時間を過ごせるかもしれない。しかし食卓を囲む人数が増えるにつれて、中にはコース料理のように順番に出されることを望む人も出てくるから、作り手は料理をサーブすることに専念せざるを得なくなる。

マネジャーの仕事もそれと一緒で、3人くらいのチームならコードを書きながらでも束ねられる。だが5人を超えるとマネジメントのコストが増え、7人までいくと同じ志向の人を集めたチームだとしても限界、10 人までいくとコードを書きながらではほぼ不能となる。

だから、エンジニアの組織づくりでは2、3人目にジョインするエンジニアが重要になる。

自分と同等か、自分以上の実力を持つ優秀なエンジニアを採れるかどうか。そこで妥協すると、その2人を指導することで手一杯になってしまう。ビズリーチの場合は、2人目が仕事を任せられる人間で、3人目は若かったがキャッチアップの速い人だったことが良かった。

ゼロイチの会社にジョインする人は報酬よりも思いに惹かれていることが多く、そういう人は大概、技術力はスーパーだが、組織的な動きの重要性を理解してくれないことも多い。だから、技術的にはそうした人よりも劣った人がマネジメントを行うことになる。スーパーなエンジニアのプライドを傷つけずにうまくマネジメントするという意味でもサーブという言葉がしっくりくる。

ビズリーチではスーパーなエンジニアにも組織でさらに成長していってほしいと思っているので、スーパーなエンジニアに新規事業を託し、タイトなスケジュールを要求することで、1人では立ち行かなくなる状況を意図的に作る。

どうしても周りの助けが必要になることで、スーパーなエンジニアも感謝の気持ちを覚え、マネジメントの必要性を自然と理解してくれるようになる。

えふしん氏

リーダー育成のためには覚悟を決めて仕事を任せることが必要。えふしん氏自身にも苦い経験があった

えふしん氏:フォローできる仕組みを整えつつ、失敗覚悟で仕事を手放せ

エンジニアtypeの連載でも書いたように、自分はCTOになってから「基本的にはコードを書かない」という宣言をしている。求められているのは組織固めであり、目の前の課題を解決するより1年後を見据えるのが自分の仕事。

サービスのコアの部分をいつまでも組織のトップが抱えていると、2番手3番手の人がその経験を積めない。だから、ある程度のリスクを想定した上でまずは現場に渡す。

小さな失敗を経験させつつも、ビジネスとしては失敗しないように、こぼれ落ちたところをサポートする人がいれば大きな問題はない。

自分自身も、モバツイ時代にAWSの管理コンソールのカギを、データが消えるのが怖くて最後まで渡せなかったという反省がある。本来は、何か失敗が起きても大丈夫な仕組みを考えなければならなかった。

BASEの場合、リードエンジニアが技術に加えてリーダーシップも持ち合わせている。現在はまだコードを書いているが、BASE APPSはアプリケーションなので、現状はエンジニアが1人で作り上げる仕事が多いが、今後はリーダー育成の観点からも、2、3人が分担する仕事を作りたいと考えている。

【3】エンジニアにはビジネス視点が必要か?

竹内氏とえふしん氏

エンジニアにビジネス視点は必要だが、それだけで十分とは言えない。議論は熱を帯びた

竹内氏:開発を工場のようにしないためにも必要。危機に直面することで身に付く

ビズリーチでは、どの機能を追加するかといった優先順位付けは、ビジネスにどれだけ効くかを基準に決めている。

エンジニアにそれを任せると、一つの機能で全てをまかなうような、最大公約数を求めがち。だがビジネスでは多くの人にパーソナライズできるような最小公倍数的な機能がしばしば必要とされる。

一方で、全ての判断をビジネスサイドの人間が行うと、エンジニアリングは工場のようなものになってしまう。

だから、エンジニアにはビジネスを理解できるようになってほしい。そのために評価制度を変えたりもしたが、ビジネス視点を持つことはなかなか難しい。

ビジネスと技術を天秤にかけないといけないような瞬間に直面すると、気付くのだと思う。技術者出身の経営者を見ていると、多くの社員を抱える立場にあって、経営の危機に陥った時、自分の技術へのこだわり以上に重要なことに目覚めているように私には映る。

将来的に巨大な収益事業ができて会社として余裕ができたら、サイバーエージェントが行っているように小さな事業をたくさん作ることで、個々のエンジニアにも挑戦とそれに続く危機を経験できる機会を作り、ビジネスを理解してもらえるようにするのもひとつの選択だと思う。

えふしん氏:必要だが、ビジネスから離れたクリエイターでもあってほしい

エンジニアにどの機能を追加すべきかといった優先順位付けは難しい。なぜならエンジニアは、Aという機能を付けるのにBという機能も付けないと論理的におかしいとすれば、Bを削ることはできない思考法だから。

だが、実際にはBという機能は削るのが正解。ECという業界には巨大な先駆者がいるわけだから、生き残るためには機能を絞って研ぎ澄ませるしかない。

BASEではそこを、センスを持った経営者である鶴岡(裕太氏)が担っている。エンジニアがリスペクトできる人であるならば、サービスの方向性を示すのはエンジニアである必要はない。納得できる空気を作ったり、翻訳するのは、自分のような周りの人間がやればいい。

実現可能性と、機能そのものを一緒に考えてしまうのは、エンジニアの悪い癖。エンジニアにはもっと楽しく作ってほしい。

ビジネスの大事さもありつつ、クリエイター気質とは何だろうかと考える。それは、目の前に困っているユーザーがいたら、技術を使って今すぐ解決したいと思えるかどうかだと思う。ビジネス的観点から見ればそれは正解ではないかもしれないが、そのバランスを取るのは自分のような立場の人間の仕事だから。

構成/鈴木陸夫 撮影/川野優希(ともに編集部)

>>特集:1を100にする開発戦略




人気のタグ
業界有名人 スタートアップ 開発 SE 転職 エンジニア プログラマー Web スキルアップ ソーシャル アプリ シリコンバレー キャリア プログラミング Android 起業 えふしん スマートフォン アプリ開発 SIer 技術者 UI btrax Webサービス クラウド Apple スペシャリスト CTO Twitter Brandon K. Hill ギーク 英語 村上福之 Facebook Google デザイン IoT SNS ツイキャス 世良耕太 モイめし IT 30代 採用 赤松洋介 コーディング 20代 UX 勉強会 プロジェクトマネジメント Ruby ITイベント Webエンジニア 中島聡 ビッグデータ 法林浩之 ウエアラブル iOS 五十嵐悠紀 LINE ドワンゴ ひがやすを ロボット 受託開発 モノづくり IT業界 コミュニケーション イノベーション ハードウエア MAKERS tips ゲーム 女性 ソーシャルゲーム Webアプリ SI インフラ iPhone 女性技術者 高須正和 マイクロソフト 研究者 UI/UX トヨタ 自動車 ノウハウ チームラボ 息抜き システム ソニー プラットフォーム Java メイカームーブメント オープンソース 和田卓人 エンジン グローバル 開発者 教育 イベント サイバーエージェント ソフトウェア 女子会 コミュニティ メーカー 家入一真 スーパーギーク 増井雄一郎 GitHub 人工知能 IPA 40代 日産 テスト駆動開発 ソフトウエア 音楽 TDD ニュース モバイル PHP TechLION

タグ一覧を見る