SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブサミ2019夏】セッションレポート(AD)

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

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

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

 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アナリティクスのようなものができるだけだった」と手塚氏は言い切る。これはビジネスサイドだけでの問題ではなかった。開発者側も途中でおおよそできるものが予想できたにもかかわらず、その違和感を伝達しなかった。「これは自分のタスクにしか興味を持たなかったことが原因」と手塚氏は話す。

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

次のページ
ティール型組織を導入。その効果と今後の課題

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
【デブサミ2019夏】セッションレポート連載記事一覧

もっと読む

この記事の著者

CodeZine編集部(コードジンヘンシュウブ)

CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/11653 2019/08/20 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング