サイバーエージェントでの営業、MBAなどを経て起業

僕は2003年に、サイバーエージェントに新卒で入社しました。当時のサイバーエージェントは広告代理店の色が強かったので、私も代理店営業からスタートして、そのまま営業一筋でした。入社1年目で全体の新人賞を、2年目でも全社MVPをいただきました。

そこから、働きながらビジネススクールに進んで経営を学び、MBAを取得した後、Webマーケティング支援の会社で役員として3年間ほど勤め、2012年にトライフォートを立ちあげました。

弊社は高い技術力を生かし、スマートフォンアプリ・ソーシャル領域に特化したアプリケーションの開発・運営を行っています。

現在180名（2015年3月）の従業員のほとんどが、エンジニアやデザイナーといった技術系メンバーです。なぜ技術者中心の会社を立ちあげたかというと、僕みたいな営業・マーケティングタイプの人が、敢えて開発の会社をやることに勝機があると思ったんですよね。

技術者タイプの方が代表の会社は、少数精鋭の組織のことが多いのですが、自分は規模の大きな技術系の組織を作ることにチャレンジしたいと思ったんです。

高い技術力を持つエンジニアが集まり、更に技術力を極め、定着するような組織を構築し、それらを強みに様々な事業を展開して、世界に通用するモノづくりの会社を目指しています。

組織づくりには、技術系の企業ならではの難しさが…

ただ、実際に会社を立ちあげてからは、組織づくりに難しさを感じることがとても多かったです。営業組織では、営業する部隊があって、それとは別に管理する部隊があって、あとは営業をどう区分けするかだけなので、組織の構造もシンプルなんですよね。二次元でいいというか。

しかし、モノづくりをする技術系の組織の場合は、「技術」という切り口と「プロジェクト」という切り口の両方があるんです。例えば、ひとつの3Dゲームアプリを作るというケースで考えてみます。

すると、Unityのエンジニアがいて、ネイティブのエンジニアがいて、サーバーサイドでPHPを触れる人がいて、インフラのエンジニアがいて…と、技術単位で組織を区切れます。ただ一方では、ゲームプロジェクトA、ゲームプロジェクトB、のようにも組織を分けることもできる。

技術単位でもプロジェクト単位でも組織を区切れるとなると、どちらが正しいのかわからなくなってしまって。プロジェクト単位で組織を区切ると、プロジェクトごとに仕事を進めやすい組織ができますが、特定の技術を持つ人同士が組織的に交流できないので、技術を伸ばすことが難しい。

例えばPHPの技術を持つ人が、別のPHPのプロジェクトと絡むことができないと、PHPの技術自体を伸ばす機会を逃してしまうんですよね。

では技術単位で組織を分けようとすると、今度は数字の目標が立てられないわけですよ。それは会社として利益を上げる、という観点から難しいだろうと。

ひとりがふたつの部署に所属する「マトリクス制」の人事を採用

それであれば、技術とプロジェクトで縦串と横串を組んで、網の目の組織にしてしまうしかないな、と考えました。

そこで、弊社の社員は「ディビジョン」と呼ばれる技術単位の組織と「プロジェクト」単位の組織の2つの部署に所属する「マトリクス制組織」を採用しています。2016年3月現在で、10のディビジョンと、14のプロジェクトがありますね。

また、弊社は自社ゲームやサービスの開発に加えて、受託開発も行っています。プロジェクト数も多く、並行稼働するなか、開発するアプリケーションの種類・使用する技術ともに多岐に渡ることも、この「マトリクス制組織」を構築した背景にはあります。

マトリクス制の効果としては大きく2つあり、ひとつ目は、エンジニアのニーズにより応えやすい組織ができることです。エンジニアには「こういうプロジェクトがやりたい」と「こういう技術がやりたい」の両軸があるので、より幅広いニーズに対応できパフォーマンスを引き出す仕組みができています。

ふたつ目は、評価をより細かくできるようになっている点です。その人の良さを、プロジェクト単位とディビジョン単位の両方で見ることができるんですね。

例えばプロジェクトではあまり活躍していなくても、すごく技術力が高い人は勉強会を積極的に開くことで、そのディビジョンの技術力の底上げに貢献する場合がありますし、その逆のケースもあります。

そうしたところをきめ細かく見てあげることで、本人にとって適切なプロジェクトとディビジョンに配置することにつなげています。

社内が「与党と野党」状態に！？　マトリクス制組織には課題も

ただ、マトリクス制の人事は運営が難しいです。それぞれの部署に上司がいるので各社員には2人の上司がいることになりますし、プロジェクトの責任者とディビジョンの責任者同士も、しっかりとコミュニケーションをとることが求められます。

また当然、プロジェクト側は常にそのディビジョンの中で最も優れた人材が欲しいわけです。一方で、ひとつのプロジェクトに優秀な人を集めてしまうと偏ってしまうので、ディビジョン側はそれぞれのプロジェクトに対して公平でなければいけない。

そんなわけで、プロジェクト対ディビジョンで争いが起きることもしょっちゅうです（笑）。でもそれは当然想定していることで、まるで国会で与党と野党が互いに主張し合うみたいな感じですね。

マトリクス制を運用するポイントとして感じることは、こうしたプロジェクトとディビジョンがうまくバランスを保つようにすることと、責任者であるマネージャーには、マネジメントに向いた人材を採用することの2点です。

エンジニアの中には、プレイヤーとして活躍したいと思っているタイプの人がいるので、そうした人を無理にマネジメントに参加させるとうまくいかないので、人の見極めが大事です。ちなみに、弊社では、プレイングマネージャーとして活躍するメンバーもいます。

そして、これらのポイントをおさえるためには、当たり前のことではありますが、社内のコミュニケーションが円滑にできる環境が特に大切になってきます。

あらゆるコミュニケーションツールを試した末に、Slackに一本化

社内のコミュニケーション活性化のために、創業時から月1で全社飲み会を行ったり、現在では半年に1回は必ず1on1で僕と話をするなど、リアルなコミュニケーションの機会も設けています。また、社内チャットツールにも工夫を重ねてきました。

これまで、本当にたくさんのツールを試してきました。プロジェクト単位、ディビジョン単位でツールを管理していたので、結果的に種類が増えてしまいました。

SkypeやSlackに加えて、一時期はLINEも作っていましたし、自社サービスでも「StarTalk」というLINEのようなアプリケーションを作ったりして…。ありとあらゆるクラウドツールを10個以上、試しまくっていたんですよ。

あまりにも色々なものを試しすぎて、一時期はFacebookのグループもあれば、Skypeのメッセージも飛んできて、別の所ではチャットワークでやりとりするところもあったりして、もう社内コミュニケーションがぐちゃぐちゃになっていたこともありました。

そうすると日常のコミュニケーションがストレスになってしまうので、やはり統一しないといけないな、という課題感が出てきました。そこで、現在では、コミュニケーションツールは「Slack（スラック）」に1本化しています。

決め手となったのは、他のツールと比べると、外部ツールと連携しやすいことと、カスタマイズしやすいことです。また弊社は今後の上場も視野に入れているので、ユーザーのアクセスログが確認できることも良いですね。

例えば開発面では、サーバーにエラーログが発生した時に、Slackに通知が飛ぶように設定することで瞬時に対応ができています。

また、会議室の空室情報を管理しているGoogle カレンダーと連携することで、Slack上で特定のコードを打てば、Googleを開かなくても会議室に空きがあるかどうかを確認できるようにしています。

▼Slackで「/.room」と入力して、空きの時刻を入力すると…

▼空いている会議室がその場で分かる！

尚、Slack上で自由にグループを作ることを許可しているので、プロジェクトやディビジョンごとにチャネルがあるだけでなく、部活動などの課外活動のチャネルもできていて、社員の円滑なコミュニケーションの助けになっていると思います。

「組織」だけでアピールできるような会社を作りたい

会社として事業やサービスに卓越したものがあると、注目を浴びやすいと思うんです。それもそうなのですが、「トライフォートの組織ってすごい秀逸だよね」と言われる会社を作りたい、ということがひとつの目標としてあります。組織論だけで本が出せるようになる位に。

マトリクス制組織についてですが、小さい組織でいようと思うなら、マトリクス制の組織には絶対しないほうがいいと思います。組織が分かりやすいので問題も少ないですし、小規模の組織であれば、社員のこともきめ細かく全部見てあげられるので。

ただ、最初から技術系の大きな組織を作ることを目指しているのであれば、早い段階から導入した方が良いと思います。弊社も創業初期からこの体制にしていなければ、今のような規模の会社になるまで時間がかかったかもしれませんね。（了）