ホテル・旅館運営企業が毎週リリースするDevOpsサイクルを作るまでの道のり

【A-5】ホテル・旅館運営企業が 毎週リリースするDevOpsサイクルを作るまでの道のり （ Developer Summit 2019 KANSAI） 2019/09/27 藤井 崇介 1

自己紹介 名前： 藤井 崇介（入社２年目、京都勤務） 資格： Scrum Inc. 認定スクラムマスター(LSM) 家族： 双子の父親、育児にも奮闘中。 趣味： カプセルホテル巡り？？ @ZooBonta フォローよろしくお願いします。 2

星野リゾートのご紹介 3

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

5

ルーズなホテル - BEB 6

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

星野リゾートの組織文化 ◼ Ganhoな組織（Ganho = 頑張れ星野） フラットな組織 ◼ みんなで意見を出し合う ◼ 誰でも対等に意見交換する ◼ チームワークによる解決 ◼ 部署の枠を超えて、問題を解決する ◼ 一人一人が判断する ◼ 失敗を許容する ◼ 著者：Ken Blanchard (ISBN: 0-688-15428-X) 8

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

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

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

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

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

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

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

事件2 完成したはずが動かない （２０１７年） 16

DM配信システムですが、今月完成しますか？ 情シス担当者 （テスト環境で）動作しているので、 受入お願いします。 開発会社 （本番で動くようになって良かった。） 今、忙しいので、使うときになったら確認しますね。 情シス担当者 17

DM配信システムですが、今月完成しますか？ 情シス担当者 外部委託あるある （テスト環境で）動作しているので、 システム完成の定義が違う。 受入お願いします。 開発会社 （本番で動くようになって良かった。） 今、忙しいので、使うときになったら確認しますね。 情シス担当者 18

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

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

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

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

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

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

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

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

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

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

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

Fポイントの仕組み 溜まったFポイントで何しようかな♪ 販売チームの皆さん ポイントにしただけで、みんながHappyになれる！ 30

開発体制の構築 31

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

QCDのコントロール 品質 CI/CD環境の構築 ソースコードのレビュー 試験項目のレビュー Q（Quality) 仕様のコントロール ボトルネックの改善 コスト C(Cost) 朝会の実施 アサインの調整 納期 D(Delivaly) 33

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

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

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

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

ふと気づく違和感 開発がGanhoな組織文化通りになっていないのでは？ スクラムを導入して良いですか？ 自分 もちろんです！ CIO 38

スクラム導入 39

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

スクラムチームを作成 自分 （京都） 2～3人 フロントエンド （東京） チーム1 2人 2人 サーバサイド① （島根） 1人 サーバサイド② （東京） 3人 サーバサイド③ （福岡） インフラ （大阪） チーム２ 41

スクラムとは？ 3つのロール 5つのセレモニー 3つのアーティファクト 42

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

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

スクラムを取り入れて学んだこと 1. 2. 3. 機能横断でチームを作ることが重要である 1つの課題をチームでこなす スクラムチーム自体の改善に時間を使う 45

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

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

1つの課題をチームでこなす ◼ スウォーミング ◼ １つのタスクを、みんなで集中して終わらせること。 48

スウォーミング ◼ 当初の進め方 改修１ 改修2 改修３ 改修4 改修5 各自ができる改修に着手する 49

スウォーミング ◼ 当初の進め方 終わったら、対応できる次の改修に入る 改修１ 改修2 改修３ 改修4 改修5 50

スウォーミング ◼ スウォーミングを使った進め方 改修１ 改修2 改修３ 改修4 改修5 みんなで同じ改修を協力して対応する 51

スウォーミング ◼ スウォーミングを使った進め方 終わったら、次の改修を協力して対応する 改修１ 改修1 改修2 改修３ 改修4 改修5 52

スウォーミング ◼ スウォーミングを使った進め方 改修１ 改修1 改修2 改修３ 改修4 改修5 分割するほどの作業でない場合は、１人で終 わらせることもある 53

スウォーミング ◼ スウォーミング導入によるメリット 協力することで、小さな成果物を早く提供できる。 ◼ お互いに協力することで、自分ができなかった作業のやり方が分かる。 ◼ 複数人でチェックしながら進められるので、成果物が個人に依存しない。 ◼ 54

改善にも時間を使う JSPだと触れる人少ないから、Vue.js に変えたい Dockerで開発環境作れば、構築楽になるのでは？ プルリクの承認でビルド・デプロイできるようにしたい 55

改善にも時間を使う JSPだと触れる人少ないから、Vue.js に変えたい 時間があれば、改善したいことがたくさんあった Dockerで開発環境作れば、構築楽になるのでは？ プルリクの承認でビルド・デプロイできるようにしたい 56

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

改善が進めば内製化も進む 今のシステムだと、海外 に展開しても厳しい 未来を見据えて、シス テムを再構築したい 改善してほしいことが他 にもある ミーティング 58

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

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

現在の体制 1人 社員 （東京） 2人 サーバサイド② （東京） 2人 フロントエンド （東京） 自分 （京都） 社員 （東京） 1人 フロントエンド （東京） 1人 2人 1人 フロントエンド （東京） サーバサイド① （島根） 会社のビジネス展開を支えるためには、チームを増やすことが課題 61

お伝えしたかったこと 1. 2. 3. 4. 外部に依存した体制から、内製化に方向転換することで、改 善できる。 改善するためには、組織文化の支えが重要である。 内製化する立場だからこそ、スクラム開発を取り入れられる。 エンジニアが成果を出すと、経営の方向も変わる。 62

Far Together！ 今後もGanhoな組織文化を 開発にも活かていきたいと思います！ 63