Upgrade to Pro — share decks privately, control downloads, hide ads and more …

プロダクトに集中し続けるために 開発組織が向き合ってきた課題

uuushiro
November 17, 2021

プロダクトに集中し続けるために 開発組織が向き合ってきた課題

uuushiro

November 17, 2021
Tweet

More Decks by uuushiro

Other Decks in Technology

Transcript

  1. 自己紹介 2 松谷 勇史朗  株式会社スタメン 執行役員CTO 愛知県出身 2016年: 創業期の株式会社スタメンに参加 2018年:

    サービス基盤やデータ基盤の構築及び運用を担当する 2020年: 執行役員CTOに就任 技術と組織づくりという側⾯からプロダクトチーム全体の成果最大化を担っ ている。
  2. 3 社名    株式会社スタメン 設立    2016年1月29日 所在地   名古屋本社 愛知県名古屋市中村区井深町1-1 拠点    鎌倉支社 / 大阪支社 代表者   加藤 厚史 従業員数  68名(2021年6月末時点の正社員数)

    資本金   6億730万円 事業内容  エンゲージメント経営プラットフォーム       「TUNAG」の企画・開発・運営       オンラインサロンプラットフォーム   「FANTS」の企画・開発・運営 会社概要 - 会社について
  3. 4 事業紹介 Our Business 2つのエンゲージメント事業 スタメンでは「ITとリアルの融合」をテーマに事業を展開しており、 現在、エンゲージメント領域において、2つのSaaS型サービスを提供しています。 また、2021年度より新規事業立上げを一層強化すべく、 役員主導の新規事業立案コンテスト「STAR PROJECT」を年に2回行っています。

    SaaSモデルの "社内制度運用クラウド" と "組織コンサルティング" をワンストップサービスで提供し、顧 客企業の組織課題に貢献するプラットフォーム事業です。 エンゲージメント経営プラットフォーム TUNAG コミュニティ運営に必要な機能をワンストップで提供し、コミュニティのエンゲージメント向上と収益化を支 援するプラットフォーム事業です。 オンラインサロンプラットフォーム FANTS
  4. TUNAG - 主な機能 社内の情報がリアルタイムに蓄積されていく カスタマイズ性の高いクローズドSNS • 社内制度の活用内容がタイムラインに流れ込み、制度の自走化を 促す • オリジナルスタンプや必読投稿、メンションコメントなどコミュニケー

    ションを活性化させる豊富な機能群 • 社内ポータルとしても活用できる柔軟なカスタマイズ性が特徴 クローズドSNS 会社で運用している社内制度や福利厚生を 一括で管理・運用できるプラットフォーム • 社内制度をカテゴリー毎に整理したり、要件や項目を自在にカスタマ イズできるTUNAGのメイン機能 • 申請や報告といった形でワークフローを設定したり、利用条件や公 開条件を設定したり、利用履歴を蓄積したりと細かな設定が可能 社内制度一覧 社内の組織ツリーを一覧で見える化でき、 社員のプロフィール情報も一括管理できる人材DB • 組織毎に担当上長や、組織の説明、構成メンバーなどを一覧で管理 でき、会社の全体像を見える化 • プロフィール項目は自在にカスタマイズでき、制度の投稿内容と連動 して自動更新をかけることも可能で、動的な人材DBの構築が可能 組織一覧 情報セキュリティや組織ガバナンスに配慮した 運用が可能なチャットコミュニケーション機能 • 人材DBと連携してチャットルーム管理が可能 • 個別チャットやグループ作成などの可否が権限設定可能 • オリジナルスタンプにも対応 • チャットルーム毎にファイル管理機能も搭載 ビジネスチャット 組織のエンゲージメントスコアを即時調査、 データで組織状態を見える化する組織診断機能 • 部署や役職毎など、組織に合わせてセグメントした分析が可能 • 経年比較や属性比較など、様々な角度から組織の状態変化を可視化 • 診断結果に合わせて、TUNAG上で改善施策を設計・運用することが可能 • 独自のカスタマイズ設問を追加することも可能 組織サーベイ 制度に合わせて自在に設定し、柔軟なインセンティブ設計やゲーミフィ ケーションが可能なリワード機能 • 利用時にポイントを自由に付与したり消費したりと、柔軟なカスタマイ ズが可能 • ポイントの名称も自由に命名可能で、ポイントを社員同士が相互に 送り合うことも可能 社内ポイント 申請・承認などの社内業務手続きを、部署や役職に 合わせてスムーズに電子化する社内決裁機能 • 社内制度毎に自由で柔軟な電子決裁の導入が可能 • 決裁履歴は、検索機能でいつでも簡単に遡り、確認することができる • 決裁者不在時のスキップ処理や、部署単位の決裁フローなども簡単に設定 • スマートフォンには決裁依頼の通知が飛ぶので、やり取りもスムーズ ワークフロー 社内の活性化状況や組織運営におけるアクションデータをワンタッチ で確認できるダッシュボード機能 • ログイン率や制度利用率、コメント率といった各種指標が一目で確認可能 • 日次、週次、月次など期間や、部署、役職でセグメントした分析も簡単 • エンゲージメント向上において重要な企業毎のヘルススコアも算出 • 反響の大きい投稿やユーザーもランキング形式で把握ができる データ分析 SNS を中心に、ワークフローやビジネスチャットなど企業での運用に備えた多彩な機能を提供
  5. 12 これまでの歩みと特徴 スタメン = 人と組織の強みを、技術と事業に活かし、プロダクトを通して感動と幸せを広げる会社。     = 常に成長と変化を指向し、新規事業を矢継ぎ早にリリースするずっとベンチャー。 2016 1月 設立

    8月 創業 2017 1月 東京支社設立 3月 総額2.8億円を 資金調達 4月 TUNAGをリリース 2018 5月 大阪支社設立 7月 『週刊東洋経済』の すごいベンチャー100に選出 HR Tech GP 2018にて オーディエンス賞を受賞 2019 6月 Startup Architecture Of The Year 2019にて グランプリ受賞 11月 TUNAGグローバル版を リリース 2020 2月 働きがいのある会社 ランキングにて第1位 5月 新規事業 FANTSリリース 12月 マザーズ市場に上場 日本テクノロジーFast50 にて 第1位受賞 2021 4月 デロイトトーマツG アジア太平洋地域 テクノロジーFast500 にて第6位受賞 関東拠点を 鎌倉支社に拡大移転 2019.6 2020.2 2020.12 2020.12
  6. カルチャー 「浸透」するためには運用が命 • 朝会で「Star Code」をテーマに最近の出来事をカジュアルに発表する • 「Star Code」を意識できるようなフォーマットの日報を用意 • あらゆるシーンで「Star

    Code」を引用する ◦ チームメンバー向けのコンテンツ(ex. CTO通信) ◦ ポストモーテム ◦ プロジェクトMTG ◦ 1on1 MTG • 採用フローや入社オンボーディングで知ってもらうきっかけを作る • 定期的な内容の見直し
  7. 20 技術的負債 事業の成長期にスケーラビリティの課題が大きくなり、サーバー管理に多くの時間を割いてきた プロダクトの成長フェーズに合わなくなったインフラ運用方式を見直すことに 2016 8月 創業 2017 4月 TUNAGをリリース

    2018 2019 導入企業数増加 エンタープライズ企業の増加 障害件数増加 2020 新規事業 FANTSリリース 12月 マザーズ市場に上場 2021 • EC2上でRailsを動かし、 Chef Solo でサー バー管理をすることを選択 • 増設の必要があれば、都度手動でEC2イン スタンスを立ち上げ、Chef Solo でサーバー をプロビジョニングする運用 • 導入企業数も少なかったため、増設の頻度 は少なく運用コストはほぼ無し • SREチーム発足(2人) • アプリケーションのパフォーマンスチュー ニングをしたり、手動でサーバーを構築し 本番環境に投入 • SREチームとはいえインフラ専任ではなく 手動でのインフラ運用コストは無視できな くなっていた
  8. 21 技術的負債 これまでのインフラ管理方法への懸念が膨らむ • 冪等性を考慮する難しさ ◦ 冪等性を考慮してコードを管理することが難しく、様々な状況を考えないと一発で サーバー設定を完了させられなかった ◦ サーバー設定の確認作業によって、少なくない時間を使っていた

    • 本番稼働中のサーバーを変更する不安 ◦ オンラインで適用しても問題ないことを確認しているとはいえ安心できない • 一部メンバーへの負担の偏り ◦ 負荷対策は緊急度が高く、他メンバーに経験してもらう機会を作りにくい ◦ 作業そのものが危険なため、慣れている人が毎回実施してしまう ◦ 今後 Chef Solo が更新されないことが分かっており、今から学ぶモチベーションが生 まれづらい
  9. 22 技術的負債 事業の成長期にスケーラビリティの課題が大きくなり、多くの時間を割いてきたサーバー管理。 プロダクトの成長フェーズに合わなくなったインフラ運用方式を見直すことに。 2016 8月 創業 2017 4月 TUNAGをリリース

    2018 2019 導入企業数増加 エンタープライズ企業の増加 障害件数増加 2020 新規事業 FANTSリリース 12月 マザーズ市場に上場 2021 • EC2上でRailsを動かし、 Chef Solo でサー バー管理をすることを選択 • 増設の必要があれば、都度手動でEC2イン スタンスを立ち上げ、Chef Solo でサーバー をプロビジョニングする運用 • 導入企業数も少なかったため、増設の頻度 は少なく運用コストはほぼ無し • SREチーム発足(2人) • アプリケーションのパフォーマンスチュー ニングをしたり、手動でサーバーを構築し 本番環境に投入 • SREチームとはいえインフラ専任ではなく 手動でのインフラ運用コストは無視できな くなっていた コンテナ化 プロジェクト始動
  10. 技術的負債 • SRE業務は圧縮され、プロダクト開発に集中でき る状態に • SRE作業の安全性が高まったことから、経験の 少ないメンバーも巻き込むことができるようにな り、負担の偏りも減ってきた • コンテナを他事業へ横展開しインフラ運用効率を

    上げ、プロダクト開発に集中できるような体制に 近づいてきた 約5年間、EC2で本番運用してきたRailsアプリ ケーションをコンテナ化🐳 コンテナ移行をきっかけに組織課題が大きく前進 🔥 https://tech.stmn.co.jp/entry/2021/11/11/130328
  11. 学習効率と開発効率のバランス 25 行動指針の「最高よりも最速」を体現していた創業期 2016 8月 創業 2017 4月 TUNAGをリリース 2018

    2019 2020 新規事業 FANTSリリース 12月 マザーズ市場に上場 2021 • インフラの運用コストも無く、全エンジニアがプロダクト開発に集中できていた • 当時は扱える技術領域にも制限があり、仮説検証の段階だからこそ、RailsでViewを管 理し、動きのある画面は最低限のjQueryで対応 • 手段は問わずとりあえずカタチにしてリリースすることに集中していた
  12. 学習効率と開発効率のバランス 26 2016 技術領域毎のベストプラクティスから外れた開発が、プロダクトの価値向上にブレーキをかけ始めた。 専門性を高めるために学習効率を重視した技術領域毎のチーム構成に。 8月 創業 2017 4月 TUNAGをリリース

    2018 2019 プロダクト規模が拡大 テクノロジートレンドの移り変わり 2020 新規事業 FANTSリリース 12月 マザーズ市場に上場 2021 • バックエンド領域では、信頼性を向上させるためのベストプラクティスとしてサーバレスやコンテナな どを活用しアーキテクチャを進化させた • クライアント領域では、エンドユーザーの体験価値を最大化できるように、技術的負債の返済や Next.jsなどフレームワークの導入を進めてきた • ベストプラクティスの導入においては、必要となる専門性が高く、技術領域毎に分担をして知識を獲 得してきたことは学習効率の高い良い選択だった
  13. 学習効率と開発効率のバランス 27 2016 8月 創業 2017 4月 TUNAGをリリース 2018 2019

    プロダクト規模が拡大 テクノロジートレンドの移り変わり 2020 2021 • 技術ごとにチームを分けたことで、エンジニアの稼働率と顧客への価値提供スピードの バランスとりが難しくなってきた • エンジニアの稼働率への関心が必要以上に大きくなってしまい、顧客へ価値を届けるス ピードに少なからず影響が出てしまっていた 新規事業 FANTSリリース 12月 マザーズ市場に上場 学習効率を優先した一方で、開発効率の課題が徐々に大きくなってきた
  14. 学習効率と開発効率バランス This is Lean を共通言語に、アジリティを高めていきたい フロー効率性が高い状態: 顧客のニーズが満たされるまでの時間が最短である状態 リソース効率性が高い状態: エンジニアの稼働率が100%に近い状態 •

    不確実性が高いプロダクトでは、半年先のロードマップが常に変動してくる • だからこそ開発組織を決められたロードマップに合わせにいくのではなく、ロードマップの変動を前提と した組織づくりをしていきたい • バックエンドエンジニアとかフロントエンドエンジニアなどと技術領域で厳密に分断してしまうとアジリ ティは向上しづらい リソース効率性だけに意識を奪われることなく、フロー効率性も意識した開発プロセスに近づけたい • 最適な組織構造とアーキテクチャを選ぶ (フロントエンドとバックエンドを超えるハードルを最小化したい) • マネージドサービスやSaaSを積極的活用し、コア開発以外のコストを限りなく圧縮する