創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方
- 1. 【13-D-4】創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方 （ Developers Summit 2020） 2020/02/13 藤井 崇介 1
- 2. 自己紹介 名前・所属： 星野リゾート 情報システムグループ 藤井 崇介（２０１８年入社、京都勤務） 資格： Scrum Inc. 認定スクラムマスター(LSM) 家族： 双子の父親、育児にも奮闘中。 趣味： カプセルホテル巡り？？ 2 @ZooBonta
- 3. 星野リゾートのご紹介 3
- 5. 5
- 8. 星野リゾートの組織文化 ◼ Ganhoな組織 ◼ フラットな組織 ◼ みんなで意見を出し合う ◼ 誰でも対等に意見交換する ◼ 全員が同じ情報を共有する ◼ 一人一人が判断する ◼ チームワークによる解決 ◼ 部署の枠を超えて、問題を解決する 著者：Ken Blanchard (ISBN: 0-688-15428-X) 8
- 10. 独自システムが多い 予約システム 販売管理システム マーケ支援システム 予約管理 kintone G Suite 独自システム 財務管理 勤怠管理 カード決済 外部サービス 外部チャネル連携 ・・・ 予約システム・販売管理システムは、特に 力を入れており、要求・要望も多い。 星野リゾートでは、長年、自社の独自システムと外部サービスを併用する ことで、企業の運営・施設の運営を行ってきた。 10
- 12. 外部に依存した開発体制 ◼ 2016年、情報システムはわずか5名 ◼ システムの導入からPCのキッティング、ネットワークの管理までやっ ていた。 ◼ 内製するだけの余力はほぼなく、開発は外部委託に頼らざるを得な い状況だった。 人手不足と外部依存の体制で、度々事件が発生 12
- 19. エンジニア組織の内製化には消極的だった 19 ◼ 消極的な理由 ◼ 企業の母体はリゾートの運営会社である ◼ よってエンジニアが自社の中にいるイメージが経営陣にはない ◼ 餅は餅屋的な考え方があった システムは外部ベンダーに発注した方がよいのでは？
- 25. 社内の問題点 1. あらゆる合意形成フローがなかった 1. 依頼者は要望だけ伝えて終わる 2. 情シスは可能なリソースの中でスケジュールを立てる 2. 優先度が決まらない 1. 各部署から要望が来るため、ステークホルダーが多すぎる。 25
- 33. 工数をポイント制に変更 ◼ 人日/人月の見積もりを辞めた理由 ◼ 人日/人月で見積もりは、人に依存するので、あてにならない。 ◼ 金額の話を混ぜて話してしまう。 ◼ ポイント(※)の方が、みんなにとって作業量をイメージしやすい。 ※Fポイントと呼ばれています 33
- 36. 開発体制の構築 36
- 38. 体制構築当初の状況 1. 動いているシステムを知っているのは自分一人だけである。 2. フルリモートで初めて仕事をする人ばかりなので、お互いが分 からない 3. 物理的にも文化的にも会社がバラバラである。 38 効率だけを重視した開発を進める
- 44. スクラム導入 44
- 45. スクラムを導入した理由 1. コミュニケーション機会を増やす 1. 全員で同じ情報を共有したい。 2. チーム間で説明内容や議論を共有したい。 2. フォロー体制の強化 1. 溢れそうな場合に、チーム内の判断でヘルプに入ってもらう。 3. 開発効率の改善 1. 一人で指示を出すのが限界だったため、開発メンバー間で 協力してもらいたかった。 45
- 47. 取り入れたツール アーティファクト ツール プロダクトバックログ Backlog、StriesOnBoard スプリントバックログ Trello / Googleスプレッドシート / Zenhub インクリメント Jenkins / Circle CI 47
- 48. スクラムのやり方 セレモニー タイミング スプリントプランニング 毎週木曜日 デイリースクラム 毎朝 スプリントレビュー 毎週月曜日 スプリントレトロスペクティブ 毎週金曜日 バックログリファインメント 第一火曜日（月一回→週一回） スプリントを期間を１週間とし、ひたすらリリースを繰り返す。 48
- 49. スクラムで良かったこと 1. 機能横断でチームを作る 2. 改善に時間を使う 3. 生の声を聴いてもらう 49
- 57. スクラムを導入した結果 1. 毎週リリースができ、継続可能なDevOpsサイクルができた。 2. 改善が進んだことで、問い合わせの件数も半減した。 3. 会社・働き場所を越えて、改善できる体制を構築できた。 スクラムのノウハウを活かし、DevOpsサイクルが構築できた 57
- 58. Ganhoな組織とScrumの関係 58 ◼ フラットな組織 ◼ 組織を横断した体制 ◼ 全員で合意形成 ◼ 全員が同じ情報を持つ ◼ ３つのロール ◼ 機能横断チーム ◼ プロダクトバックログリファインメ ント、スプリントプランニング ◼ 朝会の実施、スプリントボード 考え方 実践 ScrumはGanhoな組織文化とマッチ度が高かった。
- 64. 意志決定の速さ 1. 世の中のあらゆる仕組みにシステムが関わっている。 2. 意志決定には、システムの知識も必要である。 3. エンジニアが入ることで、意思決定しやすくなる。 64 意志決定の速さ ＝ ビジネスの進化
- 69. まだ、改善は始まったばかり 69
- 70. 越境を乗り越えるのはこれから 1. スクラムを取り入れられていない開発は多い。 2. 大きな新規案件が増えた分、複数のチームが連携して、 スクラムを回す必要が出てきた。 3. 情シス以外の社内へのスクラムの認知度は低い。 70
- 75. お伝えしたかったこと 1. 外部に依存した体制からの脱却が大事である 2. 改善には支えとなる組織文化と、マッチするスクラムがあった。 3. 非IT企業だからこそ、エンジニアがビジネスを大きく進化させ る価値を生み出せた。 4. 価値を続けていけば、経営陣も変わる。 75