創業105年の旅館運営企業が実現した毎週リリースするチームの作り方

2.8K Views

June 20, 22

スライド概要

Developers Summit 2020の登壇資料になります。

創業105年の星野リゾートでは、他社と差別化を図るために、多くのシステムを独自に作っていたが、旅館運営企業を生業であったため、ほぼ全てのシステムを外部に発注していました。
そのため、近年の技術の進化やビジネスの展開にシステムが追いつかず、システムが企業のボトルネックになっていました。
本セッションでは、非IT企業である星野リゾートが、システム開発の内製化を目指し、どのように毎週リリースするチームを一から構築したのかお話いたします。

profile-image

星野リゾートでエンジニアリングマネージャをやっています。 入社後、エンジニアが全くいない状態からエンジニア組織を立ち上げました。 SIer出身で、Javaを中心にシステム開発していますが、転職後は、AWSを触ったり、フロントエンドも触ったりと幅広く開発しています。 エンジニア組織で登壇する機会が増えてきていますが、アジャイル開発が好きで、アジャイル関連での登壇もよくしています。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

【13-D-4】創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方 ( Developers Summit 2020) 2020/02/13 藤井 崇介 1

2.

自己紹介 @ZooBonta 名前・所属: 星野リゾート 情報システムグループ 藤井 崇介(2018年入社、京都勤務) 資格: Scrum Inc. 認定スクラムマスター(LSM) 家族: 双子の父親、育児にも奮闘中。 趣味: カプセルホテル巡り?? 2

3.

星野リゾートのご紹介 3

4.

1914 長野県軽井沢に星野温泉旅館が開業。 「リゾート運営の達人」を企業ビジョンとして掲げ、 ホテルを所有するのではなく、運営のみを担うビジネスモデルへと転換 1990 山梨県のリゾナーレ八ヶ岳の再生事業を皮切りに 福島・北海道・青森と大型リゾートの再生案件、日本各地の旅館再生を担う。 2001 2005 星野温泉旅館を改築、「星のや軽井沢」が開業 マスターブランド戦略を展開 「星のや」「界」「リゾナーレ」の3つのサブブランドを展開。 2009 2013 2014 星野リゾートREITを上場 個人投資家が観光産業に投資できる環境を誕生させる。 海外施設の運営開始 4

6.

サーフジャック ハワイ 6

7.

情報システム(情シス)の構成 情報システムの皆さん 7

8.

星野リゾートの組織文化 ◼ Ganhoな組織 フラットな組織 ◼ みんなで意見を出し合う ◼ 誰でも対等に意見交換する ◼ 全員が同じ情報を共有する ◼ 一人一人が判断する ◼ チームワークによる解決 ◼ 部署の枠を超えて、問題を解決する ◼ 著者:Ken Blanchard (ISBN: 0-688-15428-X) 8

9.

星野リゾートの システム開発について 9

10.

独自システムが多い 星野リゾートでは、長年、自社の独自システムと外部サービスを併用する ことで、企業の運営・施設の運営を行ってきた。 予約システム 販売管理システム マーケ支援システム 独自システム 予約システム・販売管理システムは、特に 力を入れており、要求・要望も多い。 財務管理 kintone 勤怠管理 予約管理 G Suite カード決済 外部チャネル連携 ・・・ 外部サービス 10

11.

予約システム・販売管理システム 宿泊客 6割超え 施設の情報を閲覧 予約する ¥ 非日常な体験 オーナー 所有 自社 HP 運営施設 予約チャネル 送客 旅行 サイト ・ ・ ・ 予約サイトの開発 運用 ¥ 運営ノウハウ スタッフ 星野リゾート 運営費 ¥ ¥ 売上 11

12.

外部に依存した開発体制 ◼ 2016年、情報システムはわずか5名 ◼ システムの導入からPCのキッティング、ネットワークの管理までやっ ていた。 ◼ 内製するだけの余力はほぼなく、開発は外部委託に頼らざるを得な い状況だった。 人手不足と外部依存の体制で、度々事件が発生 12

13.

事件1 やるやる詐欺事件 (2016年) 13

14.

予約サイトに銀行振込決済機能 を入れられますか? 販売チーム担当者 はい、(開発工数は)3か月くらいです。 (いつから着手できるか分かりませんが…) 情シス担当者 (今から3か月でできる…) 販売チーム担当者 14

15.

予約サイトに銀行振込決済機能 を入れられますか? 販売チーム担当者 情シスあるある はい、(開発工数は)3か月くらいです。 (いつから着手できるか分かりませんが…) 工数を答えたのにスケジュールだと思われる。 情シス担当者 (今から3か月でできる…) 販売チーム担当者 15

16.

事件2 絶対に予約ができない広告 (2017年) 16

17.

(完成したからリリースしよう) お待たせしていた機能を本日リリースしました。 開発会社 (リリース予定してたっけ?) ありがとうございます! 情シス担当者 広告出しているのに、予約ができないです!! 販売チーム担当者 ※広告については、後日、情シス費用で出し直させていただきました。 17

18.

(完成したからリリースしよう) お待たせしていた機能を本日リリースしました。 開発会社 外部委託あるある (リリース予定してたっけ?) 肝心な日にリリースが行われ、失敗する。 ありがとうございます! 情シス担当者 広告出しているのに、予約ができないです!! 販売チーム担当者 ※広告については、後日、情シス費用で出し直させていただきました。 18

19.

エンジニア組織の内製化には消極的だった ◼ 消極的な理由 企業の母体はリゾートの運営会社である ◼ よってエンジニアが自社の中にいるイメージが経営陣にはない ◼ 餅は餅屋的な考え方があった ◼ システムは外部ベンダーに発注した方がよいのでは? 19

20.

考えた作戦 既成事実を作ろう 20

21.

既成事実とは? 外部に依存した体制を脱却したい。 ◼ 一方で、いきなり内製化は、社内で合意できない。 ◼ まずは1人増やして、成果を出す。 21

22.

そんな状況の中 2018年に入社 22

23.

内製化のスタートラインに立った 毎週リリースするくらいの勢いで改善して! 予算は確保するから。 CIO (まじか・・・) やりましょう。 自分 23

24.

そもそもの問題はどこにあるか? 24

25.

社内の問題点 1. あらゆる合意形成フローがなかった 依頼者は要望だけ伝えて終わる 2. 情シスは可能なリソースの中でスケジュールを立てる 1. 2. 優先度が決まらない 1. 各部署から要望が来るため、ステークホルダーが多すぎる。 25

26.

ステークホルダーが多い理由 サービス現場 オペレーション 販売関連 販売チームA 顧客問い合わせ関連 販売チームB コールセンター 情報システム 販売チームC ・・・ 海外販売 開発会社 26

27.

ステークホルダーが多い弊害 色々言われるんだけど、 どれが優先なの? 情シス 優先度を付けろって言っても、 ちょっとしかお願いしていないのに・・・ 販売担当 27

28.

Ganhoな組織を活かして 問題を解決 28

29.

部署を越えて話し合う ミーティング 29

30.

部署を越えて話し合う 開業の予定は変えられ ない(販売チームA) どこにリソースを割くべき (情シス) ミーティング もちろん協力します (情シス) 販売関連はとりまとめます (販売統括) 海外展開が優先では? (海外販売) 30

31.

合意形成フローの整理 オペレーション 販売チームA 販売チームB コールセンター 情報システム 販売統括 販売チームC ・・・ 海外販売 31

32.

合意形成フローの整理 オペレーション 販売チームA 販売チームB コールセンター 情報システム 販売統括 販売チームC ・・・ 開発まで分かるエンジニアが入り 、合意形成の体制を強化。 要望を取りまとめる場を設けた 海外販売 32

33.

工数をポイント制に変更 ◼ 人日/人月の見積もりを辞めた理由 ◼ 人日/人月で見積もりは、人に依存するので、あてにならない。 ◼ 金額の話を混ぜて話してしまう。 ◼ ポイント(※)の方が、みんなにとって作業量をイメージしやすい。 ※Fポイントと呼ばれています 33

34.

Fポイントの仕組み 開発着手 ポイント設定 登録 自動連係 開発者(藤井) 開発依頼 フォーム 登録 優先度決定 依頼者 藤井さんのポイントだから、 Fポイントと呼ぼう 全体会議 34

35.

Fポイントの仕組み 溜まったFポイントで何しようかな♪ 販売チームの皆さん ※星野リゾート社内の共通基準単位です 35

36.

開発体制の構築 36

37.

2018年入社当初の体制 自分 (京都) 1人 2人 2~3人 社内 社外 フロントエンド (東京) サーバサイド (島根) 1人 インフラ (大阪) バラバラの拠点で開発を開始 37

38.

体制構築当初の状況 1. 2. 3. 動いているシステムを知っているのは自分一人だけである。 フルリモートで初めて仕事をする人ばかりなので、お互いが分 からない 物理的にも文化的にも会社がバラバラである。 効率だけを重視した開発を進める 38

39.

改善当初の状況 1. 改善が進みだし、社内からは好評だった。 →2週間に1度はリリースできる体制になった。 2. 自分1人負荷が高かった。 →仕様の指示から修正箇所の指示まですべて1人でやっていた。 →改善結果の受入がボトルネックだった。 39

40.

もっと改善していきたい♪ これ以上、無理・・・ 販売チームの皆さん 自分 40

41.

もっと改善していきたい♪ 開始3ヶ月で限界を迎える これ以上、無理・・・ 販売チームの皆さん 自分 41

42.

案件の増加に伴い、体制は強化 自分 (京都) 2~3人 フロントエンド (東京) 2人 2人 サーバサイド① (島根) 1人 サーバサイド② (東京) 3人 サーバサイド③ (福岡) インフラ (大阪) やり方を変えるしかなくなった。 42

43.

そんなときに出会った1冊の本 目の前に起きている現実がそこにあった。 著者:市谷 聡啓 (ISBN-13: 978-4798153346) 43

44.

スクラム導入 44

45.

スクラムを導入した理由 1. コミュニケーション機会を増やす 全員で同じ情報を共有したい。 2. チーム間で説明内容や議論を共有したい。 1. 2. フォロー体制の強化 1. 3. 溢れそうな場合に、チーム内の判断でヘルプに入ってもらう。 開発効率の改善 1. 一人で指示を出すのが限界だったため、開発メンバー間で 協力してもらいたかった。 45

46.

スクラムを導入した理由 3つのロール 5つのセレモニー 3つのアーティファクト 46

47.

取り入れたツール アーティファクト ツール プロダクトバックログ Backlog、StriesOnBoard スプリントバックログ Trello / Googleスプレッドシート / Zenhub インクリメント Jenkins / Circle CI 47

48.

スクラムのやり方 セレモニー タイミング スプリントプランニング 毎週木曜日 デイリースクラム 毎朝 スプリントレビュー 毎週月曜日 スプリントレトロスペクティブ 毎週金曜日 バックログリファインメント 第一火曜日(月一回→週一回) スプリントを期間を1週間とし、ひたすらリリースを繰り返す。 48

49.

スクラムで良かったこと 1. 2. 3. 機能横断でチームを作る 改善に時間を使う 生の声を聴いてもらう 49

50.

機能横断でチームを作る 自分 (京都) フロントエンド (東京) サーバサイド① (島根) サーバサイド② (東京) サーバサイド③ (福岡) インフラ (大阪) 50

51.

機能横断でチームを作る 自分 (京都) チームを分断すると、 どちらかがボトルネックになる フロントエンド (東京) チーム1 サーバサイド① (島根) サーバサイド② (東京) サーバサイド③ (福岡) インフラ (大阪) チーム2 51

52.

機能横断でチームを作る 自分 同じ機能を改修する人は、 (京都) 同じチームとする。 フロントエンド (東京) サーバサイド① (島根) チーム1 サーバサイド② (東京) サーバサイド③ (福岡) インフラ (大阪) チーム2 52

53.

改善にも時間を使う フロントの標準をNuxt + Vue.JSにしたい Dockerで開発環境作れば、構築楽になるのでは? プルリクの承認でビルド・デプロイできるようにしたい 53

54.

改善にも時間を使う フロントの標準をNuxt + Vue.JSにしたい 時間があれば、改善したいことがたくさんあった Dockerで開発環境作れば、構築楽になるのでは? プルリクの承認でビルド・デプロイできるようにしたい 54

55.

生の声を聴いてもらう ◼ 以前の体制 要件/受入 要望 コールセンタースタッフ 開発者 質問/納品 情シス担当者 報告 販売チーム担当者 55

56.

生の声を聴いてもらう ◼ 現在の体制 開発者 情シス担当者 スプリント レビュー コールセンタースタッフ 販売チーム担当者 56

57.

スクラムを導入した結果 1. 2. 3. 毎週リリースができ、継続可能なDevOpsサイクルができた。 改善が進んだことで、問い合わせの件数も半減した。 会社・働き場所を越えて、改善できる体制を構築できた。 スクラムのノウハウを活かし、DevOpsサイクルが構築できた 57

58.

Ganhoな組織とScrumの関係 考え方 ◼ フラットな組織 ◼ 組織を横断した体制 ◼ 全員で合意形成 ◼ 全員が同じ情報を持つ 実践 ◼ 3つのロール ◼ 機能横断チーム ◼ プロダクトバックログリファインメ ント、スプリントプランニング ◼ 朝会の実施、スプリントボード ScrumはGanhoな組織文化とマッチ度が高かった。 58

59.

改善が進めば内製化も進む ミーティング 59

60.

改善が進めば内製化も進む 今のシステムだと、海外 に展開しても厳しい 未来を見据えて、シス テムを再構築したい 改善してほしいことが他 にもある ミーティング ビジネス展開をするためには、 エンジニアを増やすべき エンジニアを増やして 内製化をもっと進めよう 60

61.

改善が進めば内製化も進む 今のシステムだと、海外 に展開しても厳しい 未来を見据えて、シス テムを再構築したい 改善してほしいことが他 にもある 内製化を始めたことで改善が進み、 拡大する流れが出てきた エンジニアを増やして ミーティング ビジネス展開をするためには、 エンジニアを増やすべき 内製化をもっと進めよう 61

62.

成果が出れば経営者も言うことが変わる https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00677/120400034/ より抜粋 62

63.

エンジニアは何の価値をもたらした? 63

64.

意志決定の速さ 意志決定の速さ 1. 2. 3. = ビジネスの進化 世の中のあらゆる仕組みにシステムが関わっている。 意志決定には、システムの知識も必要である。 エンジニアが入ることで、意思決定しやすくなる。 64

65.

旅館運営企業だからこそ生み出したエンジニアの価値 要求者 意志決定者 コールセンタースタッフ 経営者 販売チーム担当者 現場スタッフ 65

66.

旅館運営企業だからこそ生み出したエンジニアの価値 要求者 投資価値は? 実現時期は? 意志決定者 投資額は? お客様の利便性を 向上したい 魅力的な売り方をしたい コールセンタースタッフ 経営者 販売チーム担当者 現場スタッフ お客様を喜ばせたい 66

67.

旅館運営企業だからこそ生み出したエンジニアの価値 要求者 投資価値は? 実現時期は? 意志決定者 投資額は? お客様の利便性を 向上したい 実現者 魅力的な売り方をしたい コールセンタースタッフ 経営者 販売チーム担当者 現場スタッフ お客様を喜ばせたい 実現方法 時期 金額 エンジニア 67

68.

旅館運営企業だからこそ生み出したエンジニアの価値 要求者 投資価値は? 実現時期は? 意志決定者 投資額は? お客様の利便性を 向上したい 実現者 魅力的な売り方をしたい 経営者の意志決定速度が上がった コールセンタースタッフ 経営者 販売チーム担当者 現場スタッフ お客様を喜ばせたい 実現方法 時期 金額 エンジニア 68

69.

まだ、改善は始まったばかり 69

70.

越境を乗り越えるのはこれから 1. 2. 3. スクラムを取り入れられていない開発は多い。 大きな新規案件が増えた分、複数のチームが連携して、 スクラムを回す必要が出てきた。 情シス以外の社内へのスクラムの認知度は低い。 70

71.

現在の活動 全ての案件を(F)ポイントで管理 71

72.

現在の活動 スクラム共有会 ストーリーボード 72

73.

現在の活動 スクラム共有会 ストーリーボード スプリントボード 73

74.

現在の活動 よりよいプロセスを日々、研究中。 スクラム共有会 ストーリーボード スプリントボード 74

75.

お伝えしたかったこと 1. 2. 3. 4. 外部に依存した体制からの脱却が大事である 改善には支えとなる組織文化と、マッチするスクラムがあった。 非IT企業だからこそ、エンジニアがビジネスを大きく進化させ る価値を生み出せた。 価値を続けていけば、経営陣も変わる。 75

76.

ともにつくる 非エンジニア×エンジニアで 新しい価値を提供したいと思います! 76