「"失敗のノウハウ"にこそ成長の鍵がある」ーVOYAGE GROUPのCTO小賀氏が「360°スゴイ」会社にするためにやったこと


「"失敗のノウハウ"にこそ成長の鍵がある」ーVOYAGE GROUPのCTO小賀氏が「360°スゴイ」会社にするためにやったこと
目次
  1. 5年後の会社を見据えて、採用・育成・評価を考える。
  2. 「360°スゴイ」を実現するため常にチャレンジし続ける。
  3. 「失敗のノウハウ」は人にしか溜まっていかない。失敗も活かせる体制が重要。
  4. エンジニアがコミュニケーション力をつけると、成長の時間を確保できる。
  5. 「障害報告書」を読めばコミュニケーションスキルが見えてくる。
  6. 撤退戦略を求められたベンチャーキャピタルとの交渉。
  7. 最高の仲間との物づくりが心地いい会社。

”非エンジニアが聞く「エンジニア採用」のリアル”の第4回目は、VOYAGE GROUPのCTO小賀さんへのインタビューです。失敗をどう成長に活かしていくのか、熱いインタビューになってます!ご覧ください!


小賀昌法さんプロフィール:
2010年に株式会社VOYAGE GROUPに入社し、半年後にCTO就任。
エンジニア文化醸成、採用・育成・評価戦略、セキュリティあたりに力を注いでいる。
CTO就任後の5年間のまとめはこちら
VOYAGE GROUP入社前は大手SIer、ヤフー株式会社、起業、フリーランスなどさまざまな立場を経験。芸歴24年。

【コーポレイトサイト】株式会社VOYAGE GROUP


image


5年後の会社を見据えて、採用・育成・評価を考える。

- 本日はインタビューをお受けいただきありがとうございます。早速ですが今の事業内容やポジションについて簡単にご説明いただけますか。

株式会社VOYAGE GROUPの執行役員CTOとして、エンジニア文化醸成や採用・育成・評価戦略、サービスインフラ、社内インフラ等を担当しています。

当社は1999年に創業し、2001年にサイバーエージェントの連携対象子会社になりました。その後、当社代表の宇佐美はサイバーエージェントで8年間取締役を務め、2012年にMBOで独立しました。
独立してからも、2014年にマザーズ上場、2015年には東証一部とおかげ様で順調に成長を続けていて、これまで17期連続で前年を上回る売上を達成しています。

成長の転機になったのは2004年に開始した「ECナビ」を軸としたポイントメディア事業、 次にいわゆるAdTechのSSPとして2011年に開始した「fluct」です。
広告の分野は急成長していて、今、売上に占める割合が一番大きいのも「fluct」を中心としたアドプラットフォーム事業です。

- ありがとうございます。最初、fluctへ入社されたんですよね。

はい、VOYAGE GROUPの子会社であるfluct(当時adingo)のエンジニアとして採用されCTOになり、次にVOYAGE GROUP全体のCTOになりました。

- VOYAGE GROUPはかなり事業が幅広いと思います。小賀さんは数年かけて評価体制を構築されたという記事を読みましたが、事業の広さゆえの大変さみたいなものはありましたか。

事業領域による大変を感じたことはないです。
CTOをやったのはこの会社が初めてなので、何を持って苦労というのかがわからなかったというのが正直な気持ちです。

ただ、自分なりにCTOとして意識していた点があります。

それは経営陣の一員として中長期の目標を揃えていくことです。
四半期や通期の売上は非常に大事ですが、経営陣の思い描く3年後や5年後の会社の姿が一致していることも重要です。

- では、現在のような事業の状態を想定して制度を作られたんですね。

経営陣とは常に方向性や価値観を合わせていました。

例えば、当社は元々ポイントメディアが強い会社でしたが、今はアドプラットフォーム事業が伸びています。

ただ、入社した時は「fluct」が立ち上がったばかりで、プロダクトもまだ出来ていない状態でした。
アドプラットフォーム事業の立ち上げは、ECナビやPeXなどの自社メディアの運営で得た広告ノウハウを他社へも活かせるのではないかと考えたからです。

そうした既に安定しているポイントメディア事業を今後もメインでやっていくのか、チャレンジしているアドプラットフォームを軸にした体制にしていくのか、これだけでも大きな方向性の違いが出てきます。

CEOや経営陣からは「アドプラットフォームの会社になりたいわけではないんだよ」という話もあり、難しいなと思ったことを覚えています(笑)

そこから、3年後、5年後に会社をどうしていきたいのか、そこでの自分の役割はなんだろうというのを話しながら色々な細かい点を詰めていきました。

image

「360°スゴイ」を実現するため常にチャレンジし続ける。

- 自分たちがどういう会社でありたいかを考え、何度も話し合いながら進めていったということですね。

どういう会社でありたいかでいうと、VOYAGE GROUPでは会社のSOULとして「360°スゴイ」を掲げています。

今多くの事業を展開していますが、これまでチャレンジしてきた数でいえば現在運営している事業の3倍はありました。
どんどん新しいものに取り組み、失敗や成功を繰り返した結果としての事業領域の広さなんです。

- 新規事業に関して、今はどのような取り組みをされているのでしょうか。

インキュベーション事業として、次の柱となる分野を見つけて育てようとしています。

特に力を入れているのがECとHR、FinTechの分野で、ECでは自社で化粧品の企画・販売まで手がけるといった、これまでにない取り組みも行っています。

過去にはグルーポンが流行った時には、フラッシュマーケットのサービスを作りましたし、ソーシャルゲームが伸びていた時にはソーシャルゲームを開発・運営していたこともありました。

新規事業は100%成功が約束されているわけではないですが、チャレンジする姿勢は常に持ち続けていきたいという考えは一貫しています。

- 最近のWebサービスでは、社名とサービス名が同じで1社1サービスという流れがあるように思います。そうしたものとは考え方が違うんですね。

はい、名刺をみていただくとわかるのですがVOYAGE GROUPのコーポレートカラーは白と黒です。白と黒のような対極にある色、その間にある全ての色にチャレンジしていける会社でありたいという思いが込められています。

他には「人を軸にした事業開発会社」というフレーズも使っていますが、まず、人ありき、文化ありきで考えています。

この事業をやるから人を集めようではなく、この仲間なら何ができるんだっけで考えようということです。

image

「失敗のノウハウ」は人にしか溜まっていかない。失敗も活かせる体制が重要。

- 小賀さんのインタビュー記事では、評価制度の評価担当者を増やした理由として「評価側の負担を減らすため」と答えられていました。 一般的に、評価者を増やすのは多面的な判断をするためであると思います。
- 個人的にはそこから非常に「人」を大切にされているという印象を受けたのですが、人にフォーカスしたきっかけはあったのでしょうか。
技術力評価制度の詳細ついてはこちらをご覧ください

私は1992年から20年以上この業界にいるのですが、20年前に考えていたよりもまだエンジニアがコードを書いているんですね。
働き始めた頃は、将来はAIなんかでもっと自動化されていると思っていたんですけど、相変わらずみんなゴリゴリとコードを書いている(笑)

そういうところから”プログラミングの本質”が何かを考えた時、プログラミングには機械が読めるようにする「翻訳」のコーディングとは別に「ソフトウェアをデザインする」プログラミングの2種類があるなと思うんです。

使いやすさや挙動の安定を追求し、ユーザーを意識した良いソフトウェアをデザインするには人間が介在したほうが良い部分がたくさんあるし、作るエンジニアによって出来が左右されるところがまだまだ残っています。

- まだAIでは敵わないところが残っているということですね。

はい、まだまだ優秀なエンジニアが必要です。

それに加えて「360°スゴイ」を掲げてチャレンジをする当社だからこその理由があります。

例えば、一つのメインサービスがあってそれを年単位で続けていきますというビジネスモデルなら、この時はこういう施策が成功したから次はこうしようよ、という感じで「成功のノウハウ」がどんどん蓄積されていきます。
当然、システムも洗練されていきます。

当社でも「ECナビ」のような10年以上続いているメディアなら、それ自体にノウハウがたまっています。
ただ「360°スゴイ」でどんどんチャレンジすると、一生懸命やっても短期間でクローズせざるえないサービスが出てくることもあります。

ただ、クローズしたサービスであっても、なぜ失敗したのか、何が問題だったのかといった「失敗のノウハウ」には価値があるんですね。
そうしたノウハウはその事業を担当していたエンジニアにしかわかりません。
だからこそ、人にフォーカスして、人を大事にしていく組織を作っています。

- チャレンジした結果を全て会社の成長へ生かすための人へのフォーカスなんですね。 そうした失敗を次に生かすために、評価において心がけていることはありますか。

評価会の資料にもありますが、コードを見るだけではなく「なぜ今そのシステムを作ったのか」「なぜ今そのコードを書いたのか」を評価の軸にしています。

エンジニアにも、そこをきちんとしていないと、高評価はできないと伝えています。

これは、営業のようなプレゼン力やPR力を求めているわけではなく、成長が鈍化している事業や失敗してしまった事業であっても適切に評価をするためです。

そうした難易度の高い事業には、特に優秀な社員にお願いしている場合が多々あります。
そうやって配置していくと、クローズするサービスを連続で担当することもありえます。

そうした時に、その社員個人をきちんと評価するためには、売上や利益だけの事業貢献だけで見るのではなくそのエンジニアの「考え方」や「アプローチ」が正しかったのかを評価しなくてはいけません。

そのためにも常に「なぜ」を確認しておくことが重要になってきます。

自分がどういった考え方でこのタスクを行ったのかを周りに説明できてくると、日々のタスクについてもチーム間でしっかりとコミュニケーションが取れるようにもなります。

image

エンジニアがコミュニケーション力をつけると、成長の時間を確保できる。

- エンジニアにもコミュニケーション力が重要であると。

数年前のように期間が長いプロジェクトでは最初の方で勉強して、後半に活かすみたいなことがやりやすかったかもしれません。
ただ、現在のような継続的に小さくリリースするような開発サイクルでは、そうした成長の時間は自分たちで作らないとなかなか取れません。

なぜ必要なのかの思考を鍛えてコミュニケーションが取れるようになっておくと、そういった時間を作りやすくなります。

例えば、これが欲しいと言われても、言われたまま作るのではなく、ニーズを元に今ある機能の改修ですむんじゃないかと時間のかからない方法を提案したりできるわけです。
そうして、空いた時間に新しい技術を学んだり、じっくり考える時間を作ると結果として良い物づくりに繋がっていきます。

自分の時間を作るためにも「何が必要なのかを考えて話し合えるスキル」を身につけていくことが必要なんですね。

本当に作るべきものは何なのか、本当に自分が解くべき課題は何なのかを考えられるのが僕らの思う良いエンジニアなんだと言っています。

- 本質を考える力がありコミュニケーションが出来るようになることで最小の工数でニーズを満たすサービスができて、会社の成長だけではなく、自分の成長にもつながる時間も持てるようになると。

例えば、評価会の中で、「今回はバレンタインキャンペーンのシステムを作ることになりました」という報告に対して理由を聞いた時に「いやバレンタインだから・・」と答えるようだと、「やったら何が嬉しいの」「ユーザーにどんな価値があるの」「ビジネスにどんなプラスがあるの」と指摘が入ります。

正しくは「今クォーターは〇〇のメディアでは休眠会員をxx万人アクティブにしようという目標があります。その手段として、バレンタインキャンペーンを求められていたため、実装いたしました」というようなところを理解して報告して欲しい。

その理解があるからこそ、今の方向が正しいのかの提案ができるはずです。
一エンジニアであっても、少なくとも自分がかかわるプロダクトのビジネスの状況は理解しておいてほしいです。

それがないと、言われたものをそのまま作る人間になっていってしまいます。

image

「障害報告書」を読めばコミュニケーションスキルが見えてくる。

- 小賀さんが一緒に働きたい方も、ビジネス目線を持っていたり「なぜ」にフォーカスできるエンジニアでしょうか。

最低限、なぜ自分が作るべきなのかを考えることは必要です。

採用でいうと、「360°スゴイ」以外では、8つの「CREED」に共感できるかどうかを大事にしています。
「CREED」では「仲間と事を成す。」とか「すべてに楽しさ。」をというようなチーム作りに関する事だったり、プロダクトへの取り組み方などを定義しています。

チーム作りに関してだと、当社は社内にバーを作ったりと、顔合わせて仕事していこうよという文化があります。
コミュニケーションを増やしてプロダクトも会社も良くしたいよねという考えなので、その文化の中で溶け込んでいける人はすごく活躍できるんじゃないでしょうか。

ただ、自分はそんなにワイワイやらないんだけど、ワイワイしている現場で粛々とやるのが居心地いいという人もいるので、特にリーダー的な感じを求めているわけではありません。

- 全員リーダーになれというわけではなく、あくまで人との交流を拒否するような方でなければ、心地いい距離感を保てて仕事ができる会社なんですね。コミュニケーションを重視されていますが、面接や普段のコミュニケーションにおいてアドバイスはありますか。

私がオススメするのは、まず事実を話す事です。

中には、事実と主観を混ぜて話す方がいますが、まず事実はどうなんだというところからスタートして、その上に主観を乗せるという話し方を身につけると良いです。

トラブルが起こった時に障害報告書を書きますが、これに説明のわかりやすさが現れてくるので、自分の障害報告書を見直してみるのをお勧めします。
障害報告書に、事実と主観を混ぜて書かず、きちんと事実と自分の考察を分けて書ける人は説明も上手です。

- カスタマーサポートでも同じ経験があります。主観が入り混じった報告書は読みにくいですよね。

きちんと事実を話した上で考え方を乗せていく、それが非常に重要ですね。

image

撤退戦略を求められたベンチャーキャピタルとの交渉。

- ここから小賀さん自身について伺ってきたいのですが、以前、起業されたことがあるんですね。

ヤフーにいた時に、友人から会社を立ち上げるから参加してくれないかという相談を受けました。

その時は35才で子供が1人いて、ヤフーの中でも一定の評価はいただいていたと思うのですが、5年後の40才になった自分を想像した時に、起業して頑張るという選択の方が面白いし成長にもつながるんじゃないかなと考えて参加しました。

最悪、1エンジニアとしてもやっていけるかな、という思いもありましたね(笑)

- 起業して得た経験で今に残っているものはありますか。

その会社で初めて事業計画を立てて、ベンチャーキャピタルにプレゼンをしましたが、いい経験でした。

ベンチャーキャピタルの担当者に言われて印象に残っているのは、失敗したとしても何らかの回収をしたいから撤退プランをしっかり考えて欲しいという言葉です。

ビジネスとして資金を出す方としたら当然かもしれませんが、事業をやる側で失敗した場合のリスクヘッジを考えるのはあまりないですよね。

その時は、撤退する場合でも蓄積されたものを他社へ売却できるのか、残ったリソースで一定額は回収できるのか、といった方法を何パターンか考えましたが良い経験だったと思います。

その会社の後は、フリーランスとして仕事を請け負っていた時期があります。
営業はせず、紹介で知り合いの会社を手伝っていた感じです。

image

Webサイト担当者としてのスキルが身に付く

無料カウンセリングはこちら

最高の仲間との物づくりが心地いい会社。

- プログラミングを学ぶ方の中には、会社に縛られず、フリーランスで働こうと思っている方もいらっしゃいます。そうした方へのメッセージはありますか。

皆さんより少し長くこの業界にいる者として、目の前の仕事を一生懸命やっていれば絶対に誰かが見てくれているんだと伝えたいです。

将来のためになにをすべきですかとよく聞かれるのですが、まず目の前の仕事をしっかりやって、少なくとも周辺の人たちから「あの人は信頼できる」と思ってもらうのが一番いい。

私も紹介で仕事を請け負っていたように、人というのは、めぐりめぐってどこで繋がっているかわかりません。本当に思いもかけないところから繋がってきます。

他社の方と接しない仕事だと難しいかもしれないですが、受諾の会社だったとしても、クライアントというお客様がいるわけだし、何らかの接点があればその目の前のお客様に対してしっかりと仕事をするのが確実なんじゃないかなと思っています。

日々の仕事をしっかりこなし、次はこれをやりたい、こういうチャレンジをしようという意識を持っていれば評価してくれる会社も多いのではないでしょうか。

-最後に小賀さんの思う、VOYAGE GROUPで働く良さを教えていただけますか。

誰しもではないかもしれませんが、私にとっては価値観の合う仲間と働けてとても楽しいです。

Ruby on Rails を作ったデイヴィッド・ハイネマイヤー・ハンソンというプログラマが書いた「私が億万長者になった日」いうエッセイがあります。
日本語訳

そこには、億万長者になって良い車も買えたけど、結局、これまでやってきたプログラミングやWebへの投稿といった自分のライフスタイルが心に満足を与えてくれるということが書かれています。

私はその気持ちにとても共感していて、どんなにお金を稼いでも、どういう人たちとどういう生き方をするかの方がとても重要だと思うんです。

VOYAGE GROUPに集まった仲間との物づくりはとても心地いいので、これをもっとよくしていきたいですし、VOYAGE GROUPの文化や「360°スゴイ」に共感してくれる仲間と働きたいと思っています。

-仲間への熱い思いが素晴らしいですね。それでは次回の方をご紹介ください。

ピクシブ株式会社CTOの高山温(edvakf)さんをお願いします。

-本日はありがとうございました。

ありがとうございました。


関連記事

CodeCampus編集部
この記事を書いた人
CodeCampus編集部
まずは7日間お試し!人気プログラミング講座を無料公開中
オンライン・プログラミングレッスンNo.1のCodeCamp