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

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

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

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

星野リゾートのご紹介
3

1914 長野県軽井沢に星野温泉旅館が開業。
1990
「リゾート運営の達人」を企業ビジョンとして掲げ、
ホテルを所有するのではなく、運営のみを担うビジネスモデルへと転換
山梨県のリゾナーレ八ヶ岳の再生事業を皮切りに
福島・北海道・青森と大型リ...

6
サーフジャックハワイ

情報システム（情シス）の構成
7
情報システムの皆さん

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

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

独自システムが多い
予約システム
販売管理システム
マーケ支援システム
予約管理
kintone G Suite
独自システム
財務管理
勤怠管理カード決済
外部サービス
外部チャネル連携・・・
予約システム・販売管理システムは、特に
力を...

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

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

事件1 やるやる詐欺事件
（2016年）
13

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

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

事件2 絶対に予約ができない広告
（２０１７年）
16

広告出しているのに、予約ができないです！！
（リリース予定してたっけ？）
ありがとうございます！
（完成したからリリースしよう）
お待たせしていた機能を本日リリースしました。
情シス担当者
開発会社
17
※広告については、後日、情シス費用で出...

広告出しているのに、予約ができないです！！
（リリース予定してたっけ？）
ありがとうございます！
（完成したからリリースしよう）
お待たせしていた機能を本日リリースしました。
情シス担当者
開発会社
18
※広告については、後日、情シス費用で出...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

開発体制の構築
36

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

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

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

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

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

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

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

スクラム導入
44

スクラムを導入した理由
1. コミュニケーション機会を増やす
1. 全員で同じ情報を共有したい。
2. チーム間で説明内容や議論を共有したい。
2. フォロー体制の強化
1. 溢れそうな場合に、チーム内の判断でヘルプに入ってもらう。
3. 開発...

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

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

スクラムのやり方
セレモニータイミング
スプリントプランニング毎週木曜日
デイリースクラム毎朝
スプリントレビュー毎週月曜日
スプリントレトロスペクティブ毎週金曜日
バックログリファインメント第一火曜日（月一回→週一回）
スプリント...

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

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

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

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

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

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

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

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

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

Ganhoな組織とScrumの関係
58
◼ フラットな組織
◼ 組織を横断した体制
◼ 全員で合意形成
◼ 全員が同じ情報を持つ
◼ ３つのロール
◼ 機能横断チーム
◼ プロダクトバックログリファインメ
ント、スプリントプランニング
◼ 朝...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Share SlideShare

Facebook
Twitter
LinkedIn

Embed

Size (px)

Show related SlideShares at end

WordPress Shortcode

Link

Share
Email

2024 State of Marketing Report – by... by Marius Sescu 31036 views
Everything You Need To Know About C... by Expeed Software 15669 views
Product Design Trends in 2024 | Tee... by Pixeldarts 6664 views
How Race, Age and Gender Shape Atti... by ThinkNow 4696 views
AI Trends in Creative Operations 20... by marketingartwork 32927 views
Skeleton Culture Code by Skeleton Technolo... 35402 views

Top clipped slide

1 of 76 Ad

1 of 76 Ad