O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

システムを毎週リリースするために頑張ったこと

180 visualizações

Publicada em

全く進まなかったシステムの改善を、ユーザ企業の立場に立ち、どのように改善していったかを説明した資料です。
企業の体制、顧客の契約も含め、ユーザ企業が開発に積極的に入ることで改善できると実感できたので、
同じような悩みを抱えている方の参考になれば光栄です。

Publicada em: Tecnologia
  • Seja o primeiro a comentar

システムを毎週リリースするために頑張ったこと

  1. 1. KyotoLT 第24回 システムを毎週リリースするために頑張ったこと 星野リゾート 藤井 崇介 @ZooBonta
  2. 2. 自己紹介 名前: 藤井 崇介 所属: 星野リゾート グループ情報システム 家族: 双子の父親、育児にも奮闘中。 好きな言語 / フレームワーク: Java / SpringBoot @ZooBonta
  3. 3. 星野リゾートのご紹介
  4. 4. 自社開発が意外に多い 予約システム 販売管理システム マーケ支援システム 予約管理 kintone G Suite 自社開発 財務管理 勤怠管理 カード決済 外部サービス 外部チャネル連携 ・・・ 予約システム・販売管理システムは、利用者が 多いため、特に改善の要望も多い。 星野リゾートでは、長年、自社開発のシステムと外部サービスを併用する ことで、企業の運営・施設の運営を行ってきた。 ※自社システムはJavaが多いです。
  5. 5. 改善が進まないジレンマ(入社前の状態) 1. 優先度がつけられない • 要求元が多すぎて、優先度をつける人が不在 • 打ち合わせをしても決められない 2. 開発が外部に依存している • 自社には、エンジニアが2名のみ。リーダー経験も不在。 • 契約するまでが一苦労
  6. 6. 体制上が一番の問題 情報システムコールセンター 国内マーケA 国内マーケB 国内マーケC ・・・ 顧客問い合わせ関連 海外 マーケ 販売関連 開発会社
  7. 7. 情シス 社内の問題 色々言われるんだけど、 どれが優先なの? マーケ 優先度を付けろって言っても、 スケジュールでないから、判断もできない
  8. 8. 情シス 協力会社との問題 自分たちの想定以上にコストがかかる 少し変わると費用が変わる 協力会社 要件がどうせ増える リリース後の不具合も考慮するでしょ
  9. 9. 改善したいのに進まない・・・
  10. 10. 上司 入社して早々申し訳ないけど、 毎週リリースするくらいの勢いで改善して! 予算は確保するから。 私 やりましょう。
  11. 11. ボトルネックをまずは解消
  12. 12. 体制変更 情報システムコールセンター 国内マーケA 国内マーケB 国内マーケC ・・・ 海外 マーケ開発会社 マーケ統括 マーケの要望は一度まとめてもらう。 技術も分かるエンジニアが入り、 月一で工数、期間を決める。
  13. 13. 要求元に応じて予算を配分 情報システムコールセンター 国内マーケA 国内マーケB 国内マーケC ・・・ 海外 マーケ開発会社 マーケ統括 予算B 予算A 予算C
  14. 14. 協力会社との関わり方変更 1. 請負契約の廃止 1. 工数だけ確保してもらい(準委任契約)、こちらでコントロール する。 2. 作業開始後に、必要に応じて要件や優先度を変更する。 2. スクラムの導入 1. 協力会社の開発に積極的に入り込み、コミュニケーションロス を防ぐ。
  15. 15. スクラム導入
  16. 16. 協力会社の開発体制 フロントエンド (東京) 星野リゾート (京都) サーバサイド① (島根) サーバサイド② (東京) 会社も場所もバラバラ 1人 2~3人 2人 2人
  17. 17. スクラムとは? 3つのロール 3つのアーティファクト 5つのセレモニ ー
  18. 18. スクラムを入れたかった理由 1. コミュニケーション機会を増やす 1. 状況を常に把握する。 2. 会社間で説明内容や議論を共有する。 2. フォロー体制の強化 1. 依頼もとで溢れそうな場合に、適宜ヘルプに入ってもらう。 3. 開発効率の改善 1. 各社で協力して改善を目指したかった。
  19. 19. スクラムのやり方 アーティファクト ツール プロダクトバックログ Backlog スプリントバックログ Trello インクリメント Jenkins / Circle CI
  20. 20. スクラムのやり方 セレモニー タイミング スプリントプランニング 毎週木曜日 デイリースクラム 毎朝 スプリントレビュー 毎週月曜日 スプリントレトロスペクティブ 毎週金曜日 バックログリファインメント 第一火曜日(月一回) ただし、リリース予定は2週間前に通知。 スプリントを期間を1週間とし、ひたすらリリースを繰り返す。
  21. 21. 改善を進めた結果 1. 半年間、毎週リリースを継続。(2019年6月時点) 改善が早く、社内からも好評になった。 2. 改善が進んだことで、情シスへの問い合わせの件数も半 減した。 3. 会社間を越えて、改善できる体制を構築できた。 4. 中規模(1ヶ月~3ヶ月)の開発が入っても、スケジュール に影響を与えずに改善を続けられた。
  22. 22. 改善を進めてでてきた課題 1. 受入1人がボトルネック →スケジュールを最優先。品質のリスクは、体制でカバー。 2. 毎週繰り返すすると、メリハリがなくなる →必達タスクを決め、必達タスクは全力で片づける。 →振り返り方法を定期的に変更。 3. 機能が増えた分、問い合わせが増える。 →改善中。ただ、それでも総件数は減った。
  23. 23. We are hiring! https://bit.ly/2Hpkhfx

×