Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

縦割り組織で無駄な開発工数が増えていませんか? ティール型組織の効果と課題をスリーシェイクの成功事例に学ぶ【デブサミ2019夏】

【A-6】ティール型組織でサービス立ち上げが成功した話

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2019/08/20 12:00

 2015年1月創業、今期で4期目のITベンチャー、スリーシェイク。同社ではSREに特化したコンサルティングやプラットフォーム開発支援を行うSreake事業で蓄えた技術力をベースに、「Reckoner」というフルマネージドデータ統合プラットフォームを開発している。その開発において、採用したのがティール型組織である。なぜ、ティール型組織を採用することになったのか? また、ティール型組織の採用により得られた効果や、今後の課題についてスリーシェイク 手塚卓也氏が解説した。

目次
株式会社スリーシェイク データ分析事業部 手塚卓也氏
株式会社スリーシェイク データ分析事業部 手塚卓也氏

旧サービスを停止し、製品開発を方向転換したわけ

 スリーシェイクはDeNA出身のエンジニアである吉田拓真氏が、2015年1月に立ち上げたITベンチャーである。「今年で4期目となるが、年平均350%の成長を続けている」と手塚氏が語るように、急成長中だ。

 同社では2つの事業を展開。一つが創業以来行ってきたSreake事業で、SREに特化したコンサルティングやプラットフォーム開発支援を提供する。もう一つが、Reckoner事業で、これは今年9月にリリース予定のプロダクトである。

 Reckonerは、フルマネージドデータ総合サービスで、データサイエンティストがインフラ環境やコードを意識することなく、サイロ化されたデータを統合、ETLデータパイプラインを構築し、広告配信など外部サービスへ連携することが、グラフィカルなUIを通じてできる。

 「他社ツールとの違いは圧倒的な機能の幅広さだ」と手塚氏は力強く語る。他社ツールではデータ収集なら収集のみ、加工なら加工のみ、というようにデータフローの一部分しか実行できないものが多いが、Reckonerは収集、加工・ブレンディング、集計、可視化、外部サービス連携・データ活用までのすべてのフローを統括して実行できる。つまり「収集した多種多様なデータをReckonerに集約するだけで統一したプラットフォームで価値のあるデータが活用できる」(手塚氏)というわけだ。

 より効率的な収集や分析のために、スキーマレスのデータベースエンジンを独自に開発。「例えばAmazon Athenaであれば、事前のデータに合わせたScheme設計が必要になるが、Reckonerであれば必要ありません。データ構造も変更可能。しかもDWHに匹敵するようなパフォーマンスを実現している」と手塚氏。これを使うことで、ビジネスの戦略的な部分に注力できるようになるという。将来的にはCDP(カスタマーデータプラットフォーム)とETLを組み合わせたものを目指しており、今はその実現に向け、鋭意、開発を進めているという。

 だが、Reckonerはスムーズに開発が進んできたわけではない。「およそ3年弱かかっている」と手塚氏は振り返る。2018年4月に方向転換が確定し、旧サービスはクローズするという挫折を経験している。

 方向転換前、同社では縦割りの組織構造を採っていたという。そのため、各担当のロールは相互関係を持っていなかった。「例えば私はSREのエンジニアなのでSREしかやらないということ。フロントエンジニアならフロントしかやらないといった体制で開発が進んでいた」(手塚氏)

 そのため情報伝達が不透明となり、「ビジネスサイドが企画を決めるのだが、それがなかなか決まらないのでエンジニアが動くことができない。無駄な開発工数も増えていった」と手塚氏は明かす。

 開発工数だけではない。組織が大きくなることで、マネジメント工数が肥大化していた。しかもスタートアップである同社の場合は、エンジニアといえど開発だけにフルコミットできない。その結果、どんどん遅れていく。手塚氏は「われわれはこの時代のことを『全員ロナウド時代』と名付けた」と言う。勝つためにはメンバーがパスしたり、守備したりと、自分のロールを超えて連携して仕事をしていくことが重要にもかかわらず、メンバー全員が最前線でゴールポストに向かってボールを蹴り続けている状況だったからだ。

 整理すると、全員ロナウド時代には3つの失敗があったと手塚氏は語る。第一が企画の失敗。「明確なビジョンがないため、開発を進めてもしょぼいGoogleアナリティクスのようなものができるだけだった」と手塚氏は言い切る。これはビジネスサイドだけでの問題ではなかった。開発者側も途中でおおよそできるものが予想できたにもかかわらず、その違和感を伝達しなかった。「これは自分のタスクにしか興味を持たなかったことが原因」と手塚氏は話す。

 第二が技術の失敗である。マイクロサービスアーキテクチャーを採用していたが、メンバーがそれぞれ属人化したコードを書いていたからだ。「マイクロサービスアーキテクチャーの悪い部分が出てしまった」と手塚氏。第三が組織の失敗である。同社ではトップダウンの形式を採っていたため、マネジメントの業務が忙しい上司の、意思決定待ちが増えてしまったからだ。


  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

バックナンバー

連載:【デブサミ2019夏】セッションレポート

もっと読む

All contents copyright © 2005-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5