チームを作る中で経験した自律的に成長するチームの作り方
16.2K Views
September 18, 22
スライド概要
星野リゾートに入社してから約４年。たった一人の状態から内製化を始めた私は、 開発者として仕事を進みながらも、プロダクト開発チームやエンジニア組織など、４年間のうちのたくさんのチームを作り上げてきました。
しかしながら、知識や経験が不足しているなか、チームを作り上げていたので、よいチームになる場合もあれば、いまいちうまくいかないチームになることもあり、自分の中でも限界を感じ、チームについて見つめなおし、再度新しいチームを作ってみました。
本スライドでは、私がチーム作りとしてどのようなことを学んだのかということをお話しするとともに、
実際にチームに適用して得られた効果を報告いたします。
チームに作りをこれから行う皆様やチーム作りに悩んでいる皆様のヒントになれば幸いです。
星野リゾートでエンジニアリングマネージャをやっています。 入社後、エンジニアが全くいない状態からエンジニア組織を立ち上げました。 SIer出身で、Javaを中心にシステム開発していますが、転職後は、AWSを触ったり、フロントエンドも触ったりと幅広く開発しています。 エンジニア組織で登壇する機会が増えてきていますが、アジャイル開発が好きで、アジャイル関連での登壇もよくしています。
関連スライド
各ページのテキスト
チームを作る中で経験した自律的に成長 するチームの作り方 2022/09/17 株式会社星野リゾート 情報システムグループ 藤井 崇介
藤井 崇介 星野リゾート 情報システムグループ IPAアジャイルWG EM @ZooBonta ・SIerとして10年働いたのち、18年に中途採用で入社。 ・入社後は1人からエンジニア組織を立ち上げ、 内製化を促進 ・アジャイル大好き／双子の父 「アジャイルのカギは経営にあり」 https://www.ipa.go.jp/files/000097991.pdf Hoshino Resorts Inc. 2
Hoshino Resorts Inc. 3
今までの開発経験 ◼2007年～(受託会社：下積み時代) ◼受託会社でメンバー～サブリーダーを経験 ◼社内プロダクトや小規模のシステム開発を経験しながら、 １年に1回、プロジェクトのヘルプに入る ◼サーバサイドの開発がメイン ◼ほぼ社内メンバーで開発 Hoshino Resorts Inc. 4
今までの開発経験 ◼2013年～ (受託会社：リーダー時代) ◼1～2次受けでリーダー/サブリーダーを経験 ◼開発案件やコンサル案件など、様々な開発を経験。 ◼サーバ、インフラをメインに活動。 ◼社内メンバー＋パートナー会社と一緒に開発 Hoshino Resorts Inc. 5
システム開発の経歴 ◼2018年～(星野リゾート時代) ◼事業会社で開発責任者・EMを経験 ◼開発も問い合わせも採用もやるなんでも屋 ◼社内メンバー＋パートナー会社と一緒に開発 ◼一から開発組織を立ち上げた Hoshino Resorts Inc. 6
チーム作りの経験 受託時代 星野リゾート ❏ 会社や上司が作っており、自分が作る必要がない ❏ 一から作り上げる必要があった ❏ チーム作りが、評価の指標に大きく影響しない ❏ チームの生産性を高めることが重要 ❏ 全社員会議、開発合宿、社内研修 ❏ 売上、プロジェクトマネジメント、スキルの向上 ❏ パートナーは他社という感覚があり ❏ 仕事の目的や目標が違う ❏ 採用、パートナー探し、社内研修 ❏ 顧客価値体験向上が一番の指標 ❏ スキルやPM業は単なる手段 ❏ 社外というのは単なる甘えでしかない 事業会社のマネージャーとしての 経験がない中、チームの重要性を痛感する Hoshino Resorts Inc. 7
立ち上げ当時の環境 根深い構造の問題 構造が深くなれば本質からずれる 仕様書という名の伝言ゲーム 契約の遵守が最優先 Hoshino Resorts Inc. 8
内製化への挑戦 デジタル戦略 大きく2つのテーマでデジタル戦略を描いていた システム の堅牢化 ビジネス 変化への 素早い対応 内製化への挑戦 現実 内製化には消極的 ❏ リゾート運営の会社でIT企業ではないという考え ❏ 経営陣のなかで、エンジニアが社内にいるイメージが 出来なかった ❏ システムは外部ベンダーに発注した方が良いという考 えが根付いていた 1人増やして成果を出す 9
チームの歴史 宿泊予約・販売関連のプロダクトを開発するチーム 20を超えるリポジトリ 200万行のソースコード と格闘 横断検索サイト 予約サイト 販売管理画面 ギフト券システム 歴史があるが故に、 覚える技術は多岐に渡る Hoshino Resorts Inc. 10
チームの歴史 0から立ち上げたチーム 発足4年 https://www.slideshare.net/ssuser91c7c7/105-227849243 Hoshino Resorts Inc. 11
チームの歴史 最初の１年間で上がった成果 Before 1ヶ月 約 After 1週間 意思決定タイミングや質疑応答が システム会社との打ち合わせに依存し 進捗が遅い状況が続いていた 意思決定のスピードが格段に向上し ビジネス変化への対応が可能に ちょっとした改修でも1ヶ月を要した 多数のシステムを早期リリース＆改修 エンジニア組織の内製化と組織拡大によって 従来の1/3のスピードでプロダクトリリースが可能に
チームの歴史 定期的に発生するチームの入れ替えと苦難 ◼リーダーは新規案件に移動しがち ◼会社や個人の事情で入れ替えを迫られる ◼開発はスクラムを基本 Hoshino Resorts Inc. 13
チームの歴史 うまく回らないチーム ❏ チームの雰囲気がいまいち ❏ 反省ばかりのふりかえり ❏ チーム内の会話がほとんどない ❏ チーム内でのサポートがない ❏ 分からないことを抱え込む ❏ 遅れが出ても誰も何も言わない ❏ 積極的にサポートもしない ❏ 消極的なスクラムマスター ❏ タスクを持った雑用係 ❏ 最後は力業で乗り切る うまく回っているチーム ❏ チームの雰囲気がよい ❏ 良かったこと、挑戦したいことがでる ❏ Slackなどでも会話が盛り上がる ❏ チーム内でサポートしあう ❏ 分からないことや確認したいことを自分から言う ❏ 困っている人がいれば、積極的に助ける ❏ 遅れはみんなで解決する ❏ 自律的に動くスクラムマスター ❏ 開発者と1on1を実施 ❏ うまくいかないときは自分から相談 Hoshino Resorts Inc. 14
チームについて悩みだす スキル？ マネジメント力？ マインド？ スクラムマスター 不在？ スクラムの理解？ チーム作りの見直しを行う Hoshino Resorts Inc. 15
Hoshino Resorts Inc. 16
チーム作りのポイント チームの壁ができにくい構成にする ◼職位など目に見えるものは壁になりやすい ◼目に見えない能力や経験の差でも分断は産まれる ◼チーム構成と配置を見直す ISBN-10: 4820729632 Hoshino Resorts Inc. 17
チーム作りのポイント 常に新しいことに挑戦する ◼好奇心は誰もが持っている ◼人間は新しいことに挑戦しつづける生き物 ◼育ってきた環境で好奇心が失われることもある ◼リハビリが必要 ◼挑戦できる余裕を作っておく ◼今のチームができないことは何でも挑戦 Hoshino Resorts Inc. 18
チーム作りのポイント やりたいことができる環境を作る ◼Must/Can/Will 3つのモデル インセプションデッキ 目標設定 スキルシート ふりかえり 講習会 社外研修 Hoshino Resorts Inc. 19
何でもチームで解決する Hoshino Resorts Inc. 20
何でもチームで解決する 早く行きたければ一人で行け、遠くに行きたかったらみんなで行け ◼スキルがある人がやれば早いことはたくさんある ◼一人でできることには限界がある ◼同じことをやっていてもスキルは身につかない ◼ボトルネックが減るほど、余裕も生まれる Hoshino Resorts Inc. 21
何でもチームで解決する 難しいことはみんなで悩む ◼1人で解決できないことでも、知識を合わせれば解決できる ◼全員で解決できないことがわかるだけで安心感が生まれる ◼チームで解決できないなら、チームの外に頼ればよい Hoshino Resorts Inc. 22
チームを信じて見守る Hoshino Resorts Inc. 23
チームを信じて見守る あるがままを受け入れる ◼自分たちができること、できないことを明確にする ◼ベロシティなど短期的な数値に左右されない ◼他人や他のチームと比較しない ◼チームが全力を尽くしているなら、どんな遅れも許容する Hoshino Resorts Inc. 24
チームを信じて見守る チームの方針はチームで決める ◼Whyを伝える、Whatを一緒に考える、Howは考えてもらう。 ◼チームに権限を委譲する ◼失敗から学ぶこともたくさんある Hoshino Resorts Inc. 25
Hoshino Resorts Inc. 26
経験３年未満のエンジニアでチームを組む https://www.docswell.com/s/s-fujii200/5M2L25-2022-06-18-101550 Hoshino Resorts Inc. 27
結成当初の状況 やる気はあるが、不安もいっぱい ◼何でもやりたい気持ちはある ◼経験がないので、何をやればいいかわからない ◼わからないから、何を聞けばいいかわからない Hoshino Resorts Inc. 28
最初に始めたこと 必要なことをすべて教える ◼インフラ（AWS）の作り方 ◼プロジェクトの作り方 ◼ビルド・デプロイの方法 ◼ログ設計・DB設計 etc・・・ できること を増やす 分かるまで 教える Hoshino Resorts Inc. 29
最初に始めたこと 高い壁はみんなで乗り越える ◼分からないことは全員で作業を行う ◼ペアプロ・モブプロを中心に難しいタスクを乗り越える ◼話し合うことが習慣化される ◼自然と知識が共有される ◼雑談しているうちに、話しやすいチームになる Hoshino Resorts Inc. 30
最初に始めたこと ベロシティがあがると自信につながる Hoshino Resorts Inc. 31
次のレベルにステップアップ 教えてもらうから自分たちで考えるチームに ◼チームで方針を決めるように方向転換 ◼事実や課題をそのまま伝える • 開発方針を全部決めてもらっている • 曖昧なままにしているから手戻りが多い ◼良いやり方があっても、敢えて提案しない ◼情報の共有は常に行う Hoshino Resorts Inc. 32
チームから出た提案 チケット作成の精度向上 ふりかえりの改善 導入資料の作成 etc・・・ 次々と改善されるチームになる Hoshino Resorts Inc. 33
生産性の可視化 Findy Teamsとは？ GithubやGitlab,Jiraなどでソースコードの アクティビティを解析することで、 エンジニアリング組織の生産性を可視化するサービス Hoshino Resorts Inc. 34
生産性の可視化 プルリク作成数 レビュー クローズ時間 チケットのクローズが 早くなった Hoshino Resorts Inc. 35
生産性の可視化 新チーム発足 前のチームを安定し て上回るように レビュー クローズ時間 プルリク作成数 最初は波があった Hoshino Resorts Inc. 36
1年間の成長 個人としてもチームとしても成長の連続 ◼レベルの差はあるが、全員がフルスタックエンジニアに ◼活性化しているチームに変貌 ◼新しいことに挑戦するチームに変貌 • ドメイン駆動設計の適用 • ノーコードツールの活用 • ペアプロ・モブプロ ◼チームの生産性も２倍に向上 Hoshino Resorts Inc. 37
Hoshino Resorts Inc. 38
過去の自分への反省 自分の経験が基準になっていた ◼効率を求めすぎていた • 成功したやり方だけを教えようとしていた • チームで乗り越える経験をさせていなかった ◼過去の成功体験・失敗体験にこだわっていた • Scrumをやればチームが良くなるという幻想を持っていた • 自分の成功体験や反省を相手に求めていた Hoshino Resorts Inc. 39
過去の自分への反省 チームを信じ切れていなかった ◼観察する力がなかった • できないことと苦手なことがわかっていなかった • 同じことをすれば同じ結果が得られると思っていた ◼チームを見守る忍耐力もなかった • アドバイスをしすぎて、試行錯誤をさせていなかった • どこかでできないと諦めていた • 最後まで責任を取らせようとしなかった Hoshino Resorts Inc. 40
チームの限界を勝手に決めてはいけない Hoshino Resorts Inc. 41
ありがとうございました https://www.hoshinoresorts.com/ Hoshino Resorts Inc. 42