複数チームによる開発におけるチーム作りについて
2.7K Views
December 11, 24
スライド概要
星野リゾートでは、レガシーな外部パッケージ製品に依存したシステム、および、それを取り巻くシステムで今まで運営を行っていましたが、変わり続ける顧客のニーズの変化や、テクノロジーの変化の追従に課題を感じ、基盤ごとシステムを刷新する挑戦を行いました。
顧客向けの予約システムや販売システム、予約管理のシステムなど、複数のシステムを運営しながら並行して置き換えることを行うため、今までにない挑戦をしましたが、失敗もたくさんしました。
本資料では、その中でもチーム作りという観点に着目し、どのようなことが起きていたのか、どのような点に注意すればよかったのかをお話したいと思います。
星野リゾートでエンジニアリングマネージャをやっています。 入社後、エンジニアが全くいない状態からエンジニア組織を立ち上げました。 SIer出身で、Javaを中心にシステム開発していますが、転職後は、AWSを触ったり、フロントエンドも触ったりと幅広く開発しています。 エンジニア組織で登壇する機会が増えてきていますが、アジャイル開発が好きで、アジャイル関連での登壇もよくしています。
関連スライド
各ページのテキスト
複数チームによる開発における チーム作りについて 株式会社星野リゾート 情報システムグループ 藤井 崇介
藤井 崇介 星野リゾート 情報システムグループ シニア・アーキテクト @ZooBonta ・Webシステム関連の開発を10年間経験後、2018年に星野リゾートに入社 ・開発体制の内製化を主導し、エンジニア組織の立ち上げを行った。 ・現在は、社内の技術標準化チームを作り、複数プロジェクトの支援を行う Hoshino Resorts Inc. 2
会社紹介 • 全国約80施設の温泉旅館・ホテル・日帰り施設のオペレーションを 担う総合リゾート運営会社 • 星のや・界・リゾナーレ・OMO・BEBの複数のサブブランドで運営 • 1914年創業、長野県軽井沢に最初の旅館を開業し、今年で110年 • 世界に通用する運営会社を目指している Hoshino Resorts Inc. 4
情報システムグループの構成 クロスファンクションで機能的に変化する組織 プロダクト オーナー ノーコード ツール 活用開発 エンジニア インフラ 権限管理 予約システム サービスチーム （現場） 出身者 30名 企画 投資判断 オペレーション インフラ 18名 10名 リスク管理 導入支援 環境構築 ソフトウェアエンジニア ITインフラ専任者 IT運用専任者 ビジネスコンサルタント 22名 プロダクト オーナー Team 開発 改善 保守運用 運営 サポート 5名 エンジニア Team 19名 Hoshino Resorts Inc. Hoshino Resorts Inc. ノーコード 開発 施設サイト 5
基盤システム刷新 Hoshino Resorts Inc. 6
Hoshino Resorts Inc. システムの基盤を刷新する 顧客体験 OTA メディア リアル 航空券付 アクティビティ AGT予約 自社予約 レストラン チェック イン CS 直せる人がいない システム データ基盤 秘伝のタレの外部 パッケージ製品 予約 個人情報 在庫・料金 レストラン PMS その他データ （社外パッケージ） アクティビティ マニュアル スタッフ体験 預り金 パッケージ作成 レストラン管理 会計 販売管理１ 販売管理２ アクティビティ管理 PMS 7
システムの刷新が求められた理由 レガシーな外部パッケージ製品の弊害 ごまかしのシステム改善 ❏ 当たり前ができない ❏ パッケージ製品をカバーする複雑なシステム ❏ 使いづらさを直すことができない ❏ 根本的なニーズに応えられない ❏ 欲しい機能が追加できない ❏ 触れる人がいないシステムも存在する ❏ とにかく不安定 生産性が 低い スケールが しづらい 売上最大化 のボトルネック 海外への 対応が難しい 全てを刷新することを意思決定した Hoshino Resorts Inc. 8
当初の計画 2023年 1月 4月 7月 10月 2024年 1月 4月 7月 10月 2025年 1月 要件検討・準備 開発 Phase1 開発 Phase2 施設展開1 施設展開2 開発 Phase3 施設展開3 並行運用するために、Phase1では、最小限の変更で運用する想定で計画 機能追加に合わせて、展開する施設を増やすことにした。 Hoshino Resorts Inc. 9
チーム構成 ◼チーム構成 ◼チームトポロジーを参考に構成 ◼ システムの共通的なプラットフォームを提供し、サポートする体制を構築 外部から部分的に協力 横断チーム 開発チーム 標準化 チーム ISBN-10: 4820729632 Hoshino Resorts Inc. 10
チーム構成 ◼要件定義・準備段階 開発準備 要件定義 基盤チーム （共通部） フロントエンド 標準化 サーバーサイド 標準化 Hoshino Resorts Inc. 販売 財務 予約 （顧客向け） 予約 （スタッフ向け） 11
チーム構成 ◼開発フェーズ 開発準備 要件定義 基盤チーム （共通部） 販売 販売 予約 （顧客向け） 予約 合流 フロントエンド 標準化 サーバーサイド 標準化 Hoshino Resorts Inc. （スタッフ向け） 12
実際 使われない標準化 計画通りに解散されない ➢チームの構成変更にネガティブ ➢別デザイナーが作ったデザイン ➢永遠に終わらない基盤 ➢プラットフォームへのフィードバック ➢度々発生する基盤の作り直し ➢ベストプラクティスの共有が不十分 ➢基盤チームが開発のボトルネック がない ➢車輪の再発明 チームが増える ➢一部のステークホルダーへの調整が 未実施 ➢手が回らないので、チームを増やす ➢類似した機能や実装の存在 ➢デザインも一から作り直される になる 結果的に、遅れが広がる Hoshino Resorts Inc. 13
リリースは完了し シンプルで使 いやすい アプリ内で完 結する かゆいところ に手が届く 業務の時間が 短くなった Hoshino Resorts Inc. 14
当初の計画 2023年 1月 4月 7月 10月 2024年 1月 4月 7月 10月 2025年 1月 要件検討・準備 開発 Phase1 開発 Phase2 施設展開1 施設展開2 Hoshino Resorts Inc. 開発 Phase3 施設展開3 15
現在 2023年 1月 4月 7月 10月 2024年 1月 4月 7月 10月 2025年 1月 4月 7月 要件検討・準備 開発 Phase1 開発 Phase2？ 施設展開1 約1年計画が遅れることとなる Hoshino Resorts Inc. 16
見直すべきポイント Point 2 Point 3 丁寧なコミュニ ケーション 小さく始める 小さな 成功体験を 作る 計画や体制は話して終わりにするの ではなく、定期的にチームとコミュニ ケーションをとり、調整する 最初から並行で進めたが、 1つずつ始めたほうが結果的 に早い 良いやり方を身に着けてから、 広げていく Point 1 Hoshino Resorts Inc. 17
Hoshino Resorts Inc. 18
ありがとうございました https://hoshinoresorts.com/jp/ Hoshino Resorts Inc. 19