©hey, Inc EC Tech Talk -カラーミーショップとSTORESを支えるチームづくりと開発の裏側 2022/05/26 勝亦 亮（@katsumata_ryo ） 在籍6年間のチームの裏側とチーム作り 

自己紹介 勝亦 亮（@katsumata_ryo） hey株式会社 テクノロジー部門 リテール本部 サービス改善グループ エンジニアリングマネージャー 経歴 Web制作の営業兼ディレクター・総務・ホスティングサービスの運用を経て29歳でWebアプリケーションエ ンジニアに転身。2016年に株式会社ブラケット(現ヘイ株式会社)に入社しSTORESの開発全般を担当。 現在 エンジニアリングマネージャーという職責でピープルマネジメントとプロダクト開発を中心に、採用活動につ いて頭を抱えたり、開発組織に思いを馳せたりしています。 どうでもいいこと ・4月はポケモンアルセウスで現実逃避をしてました ・2児の父で仕事と家庭のバランスにも思いを馳せています ・仕事部屋に弾いていないギター・ベース・電子ドラムがあります ・佐久間宣行のオールナイトニッポン0 を毎週聞いています 

目次 ● 自己紹介 ● 発表の概要と背景 ● チーム状況の変化 × 自分視点 ○ ソロ・バディ・チーム・職能横断チーム ● まとめ 

発表の概要と背景 5 → 40 人の組織で起こったこと 残り時間目標 13:30 

発表の概要と背景 私が入社した 2016年(Bracket、Inc) では5人だった開発体制か らheyになり現在では全サービス合わせると100名近い開発組織に なりました。私の関わっている STORES の範囲では 約8倍程に なっていて開発の体制は大きく変わりました。 その変化をなぞりながらその時身の回りで起こった変化と適応に ついて私の目線からお話したいと思います。 「それな」「そんなことも起こることがあるのか」とラフに聞い ていただけますと幸いです。 

発表の概要と背景 下の図は STORES の開発チームの変遷をざっくりと書いてみたものです。 STORES は2012年からサービス提供を開始しました。10年目のサービスです。 10年の中で「グループ参入」「MBO」「経営統合」「新サービス提供」...と様々なことが起 こりました。 2012 2016 2018 2019 2020 2021 2022 

発表の概要と背景 本日のテーマの「チーム作り」ですが、機能開発の持ち方はフェーズと開発チームの拡大で機 能開発の持ち方は変化した。 2012 2016 2018 2019 2020 2021 2022 0→1 フェーズ※ イ ケ イ ケ フ ェ ー ズ ※ 混 沌 フ ェ ー ズ ※ 独立第2 フェーズ ※ hey経営統合後 個人 主副 担当 個人（チーム） チーム（個人） チーム ※実際の動き方はチームによって異なる ※※は後述する資料からの命名を拝借 

発表の概要と背景 2018年までの組織の変遷に関してはこち らの資料に詳細があるためご興味がありま したらぜひご覧ください。 ■ 参考：「STORES.jp 開発組織の変遷」 https://speakerdeck.com/tyabe/rails-developers-meet up-2018-day4 

発表の概要と背景 2016年から入社して開発チームに関わってきました。 赤枠の部分のメンバーとして見てきたいろいろな変化を「チーム作り」「開発の裏側」という 軸でお話をさせていただければと思います。 2012 2016 2018 2019 2020 2021 2022 ここのおはなし 

発表の概要と背景 とここまでが背景となります。 ざっくりなので以下だけ認識いただければ大丈夫です - 2012年から今も運営されているサービス - 2018年から経営統合されheyという会社になって変化が増えた - なんかチームの変化が分岐しているぞ？ - フェーズ、組織、人の数は変化への影響でかそうだぞ - このあとの話はかつまたが関わっている部分が話されるのだな、ふむふむ。 こんな感じで大丈夫です！ 

チーム状況の変化 × 自分視点 プロダクト開発チームに関わった6年 残り時間目標 11:00 

大きな流れ ソロ バディ ソロ in チー ム チーム 2016年から入社して開発チームに関わってきました。 赤枠の部分の1メンバーとして見てきたいろいろな変化を「チーム作り」「開発の裏側」とい う軸でお話をさせていただければと思います。 職能横断 チーム チーム in 組織 

ソロ ■状況 担当：メンバー | チーム規模：4-7人 私が入社したときはすでに開発チームとしての活動となっていて、完全なソロプレイではなくチーム開発の形が取られてい た。機能開発に関しては1人が担当し、個人の裁量は大きい状態でチームのレビューを受けながら開発が進んでいた。 デイリースタンドアップや振り返りがチームで行われていた。 ■開発の裏側 ✓ 機能・仕様理解の属人化 ✓ 問い合わせ対応、運用対応、障害対応の偏り ✓ 機能のリリース頻度は早い ■チーム作り ✓ チームでレビューを行い仕様共有を行う ✓ 仕様やTipsなどをドキュメントにす ✓ Issue/PR のフォーマット整理 ✓ 問い合わせ対応・運用業務・障害対応もみん なで対応 ✓ デイリースタンドアップでの情報共有 

ソロ CEO デザイナー 機能の骨子 を固める 開発チーム全体 エンジニア エンジニア エンジニア エンジニア CTO それぞれのエンジニア が機能の仕様・設計・ 実装をまるっと対応 相互にレビューや相談 も行う。 都度連携・相談 

バディ ■状況 担当：メンバー | チーム規模：4-7人 個人が裁量を大きく取って開発していくのでフットワークが軽い反面、前ページの課題があった。特に属人化が進んでいて、 仕様理解の偏りや問い合わせ対応や障害対応にも差が出ていて負荷が偏っていた。 その偏りを減らすため機能開発に副担当をつけたり、運用対応を分担制にするTryを行ったりした。 ■開発の裏側 ✓ 主/副担当 みんなが主担当をもっている状態は変わらなかったた め、どうしても副担当まで目が届かず仕様理解/相談の 助けにはなったが予想した効果は得られなかった ✓ 運用分担 こちらも仕様理解が深い人に助けてもらうことも多く 大きな負荷軽減の効果は得られなかった ■チーム作り ✓ 一定規模の機能開発に主担当/副担当を割り 当てた ✓ 運用担当を分担制にし、機能開発に集中する タイミング、運用担当に集中するタイミング に分離した 

バディ CEO デザイナー 機能の骨子 を固める 開発チーム全体 エンジニア エンジニア エンジニア エンジニア CTO それぞれのエンジニア が機能の仕様・設計・ 実装をまるっと対応 相互にレビューや相談 も行う。 都度連携・相談 

チーム in 組織 ■状況 担当：リーダー | チーム全体規模：おおよそ9-20人, 担当チーム規模：3-6人 heyとなり組織が拡大期に入ったタイミングでいくつかの変化があった。開発者の増加で大きな開発組織の中にチームができ たこと。プロダクトマネージャーが入社したこと。時が進むと組織上のチームは職能で専門性を持つチームとなっていった。 今までとは違った意味でチーム開発を考える必要が生まれた。また、プロダクトマネージャーが生まれたことで、ビジネス側 とプロダクト側という境界線が組織拡大とともに明確になった。 ■開発の裏側 ✓ チームの分化が進み専門性の高いチームが出てきたこ とで急速にいろいろなものが整い始めたのがこのタイ ミング ✓ 同時に機能開発の関係者が増え始めたのもこのタイミ ング ✓ ピッタリはまる方法が自身で思いつかなかったためス クラムをチームにインストールしてみた。一旦フレー ムワークに乗ってみるのは良いと感じた ✓ スクラムを導入したものの思想を深く理解したもので はなかった。恩恵は十分にあった。 ■チーム作り ✓ 人数増加に伴いマネジメントの階層構造がで きた ✓ チームをリードするリーダー/マネージャー が生まれた ✓ 要求管理・チームでのタスク管理が必要にな りスクラムの導入を行った ✓ 新メンバーのオンボーディング強化 ✓ ペアプロ・モブプロを多用し共有することで チームでタスクを共有するようにした 

チーム in 組織 組織図の分岐 フルスタックでやっていたところからSREにおまかせできたり（私はバッ クエンドなので）フロントエンドやそれ以外にも専門性の高い人にお願い できることが増えた。 

チーム in 組織 https://speakerdeck.com/katsumataryo/railsdm-katsumata ■スクラム導入 最初期の様子 

職能横断チーム ■状況 担当：EM | 開発チーム全体規模：おおよそ20-40人, 担当チーム規模：3-9人 前ページでは実態の開発チームの組成はプロジェクトごとに開発に必要な人をあつめてプロダクト開発チーム を作っていた。プロジェクトが終わるとチームが解散してしまうため、プロジェクトの振り返りなどが有効に 活用されなかったり、せっかく出来たチームワークが解放されてしまう課題感があった。そこで開発チームを 固定し、そこで機能開発を運用していく体制を作った。 ■開発の裏側 ✓ 1リポジトリに関わるエンジニアの数が多くなってきて いる。加えてプロダクト開発ラインも複数ラインが動 いているため施策コンフリクトが発生しやすい ✓ そのため各ラインのロードマップ調整を行うようにし ている ✓ ここ数年で顧客の課題を更に意識した開発になってい る ✓ 最近の機能開発は複雑性をいかに早く紐解くか、ドメ インエキスパートとの協力、メンバーがエキスパート になっていくことが重要になっていると感じる ■チーム作り ✓ 職能横断チームを組成し、固定化した ✓ 同じ組織上のチームではないのでチーミング を取り入れた ✓ EMとしてはプロダクトマネージャーと開発 チームの間に立つ位置取りで動いた ✓ チームの実運営をリーダーに移譲 

職能横断チーム プロダクト開発の体制はプロジェクトによって異なります。 下記は一例ですが、プロジェクト実行に必要な職域の人を一つのチームとすることで コミュニケーションの円滑化、チーム内で意思決定できる量を増やす、 継続的にチーム開発を継続するという目的で組成しています。 プロダクトマネージャー フロントエンドエンジニア バックエンドエンジニア デザイナー フロントエンド バックエンド プロダクト マネジメント デザイナー プロジェクトチーム 

職能横断チーム ■チーミング ● ドラッカー風エクササイズ ○ ペパボテックブログ 「ドラッカー風エクササイズ」で期待をすりあわせて安全なチームに ● 価値観ワーク ○ 提示されている価値観一覧から「大事」「大事ではない」と思う物を 3つずつ選んで選んで理由やエピソードをみんなで共有する ● 16personalities を相互理解のネタにする ○ https://www.16personalities.com/ ○ 結果について共有したり、結果を象徴するような仕事のエピソードを 共有したりする ○ （ちなみに私は提唱者でした） ● 他チームでも色々と取り組んでいるようでした 

職能横断チーム 現在も組織体制は変化していて チーム課題も変化していて、適応中だったりします。 最後に現在追っている課題を紹介します。 

現在の課題 運営をされているオーナーさんをエンパワーす るためにまだまだ出した機能がたくさんありま す。また安心して利用いただくため、更に生産 性をあげていく必要があります。 プロダクトの価値向上 #1 STORESプラットフォームの中でご利用用途に合 わせて便利に使っていただくため、プラット フォーム内をよりシームレスな連携へしていき たいと考えています。 プラットフォームでの強み強 化 #2 サービスとしては歴史があるため正直に技術的/ 仕様的負債が存在している状態です。継続的な 開発を続けていくため走りながら改善していく 事が必要です。 技術的負債の返却 #3 仲間が増えて組織もサービスの規模も大きくな る中で現在のアプリケーション構造のアップ デートを考えていく時期になっています。より 早く高く跳ぶための構造を模索しています。 未来を見据えたアプリケー ション構造 #4 

まとめ 残り時間目標 02:00 

まとめ ● チーム状況の変化は外的要因も内的要因も発生しうる ● 課題を明らかにしてみていろいろ試してみると良い ● 試した結果を評価する ○ ダメそうならやめればいいぐらいの気持ちで ● 多くの課題は過去に誰かが体験しているかも知れない、社内/ 社外にアンテナを張ってみると良さそう ● これからも課題をやっていきます 

No content