Slide 1

Slide 1 text

© 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 1 株式会社オプティム シニアエンジニア 今枝 スプリントレビュー(バザー形式)と それを支えるCI/CD

Slide 2

Slide 2 text

© 2019-2024 OPTiM Corp. All rights reserved. 2 自己紹介 【入社年度】 20年度入社 【現職】 株式会社オプティム シニアエンジニア 【最近主な業務・経歴】 エンジニア歴: 5年目 (Go, Typescript, Vue, NestJS, k8s, Terraform) 3/27リリースの新サービス OPTiM サスマネ 開発 【紹介】 バックエンド(Go, TypeScript)や、 たまにフロント・インフラの部分も触ったりしています。 学生時代は競プロ楽しんでいました。 今枝 いまえだ

Slide 3

Slide 3 text

© 2019-2024 OPTiM Corp. All rights reserved. 3 株式会社オプティム 英語表記:OPTiM Corporation(東京証券取引所プライム市場:3694) OPTiM SAGA(佐賀本店) :佐賀県佐賀市本庄町1 オプティム・ヘッドクオータービル OPTiM TOKYO(東京本社):東京都港区海岸1丁目2番20号 OPTiM KOBE :兵庫県神戸市中央区小野柄通7丁目1番1号 菅谷 俊二(佐賀大学農学部招聘教授) 2000年6月8日 444百万円 3月 406名(2024年4月1日現在) ライセンス販売・保守サポートサービス(オプティマル)事業 (IoTプラットフォームサービス/ リモートマネジメントサービス/サポートサービス/その他サービス) 商 号 所在地 代 表 設 立 資本金 決算期 従業員数 事業内容 会社概要

Slide 4

Slide 4 text

© 2019-2024 OPTiM Corp. All rights reserved. 4 アジェンダ  スクラム開発とスプリントレビュー  スプリントレビュー 運用時の課題  スプリントレビュー バザー形式とは?  バザー形式 運用事例  バザー形式を支えるための CI・CD 改善  まとめ

Slide 5

Slide 5 text

© 2019-2024 OPTiM Corp. All rights reserved. 5 スクラム開発とスプリントレビュー  スクラムの流れ ◼ スプリントプランニング: 計画 ◼ デイリースクラム : 検査 ◼ スプリントレビュー : 成果を検査 ◼ スプリント レトロスペクティブ : 振り返り  本日話をするのは スプリントレビューについて

Slide 6

Slide 6 text

© 2019-2024 OPTiM Corp. All rights reserved. 6 スプリントレビュー 運用時の課題  スプリントレビューを運用する中での課題 ◼十分な結合がされていないアプリでレビューされてしまう ◆開発者のローカル環境でスプリントレビューし、結合したときの挙動と異なる ◆機能を知っている前提で開発者目線で操作・発表してしまう ◼開発担当者が発表する、受け入れ条件の確認等のみになっている → アンチパターン ◆開発寄りのフィードバックが偏り、顧客目線・営業目線などのフィードバックが得られない ◆本来であれば、今後の機能についても話し合うべき… ◼クローズの場で開催されて社内にプロダクトの状態の周知ができない ◆会議室等で開催され、アプリのスプリントレビューが内輪向けの説明になっている

Slide 7

Slide 7 text

© 2019-2024 OPTiM Corp. All rights reserved. 7 スプリントレビューバザー形式とは? https://less.works/jp/less/framework/sprint-review バザー形式によって、スプリントレビューの議論の活発さの向上 小さなブースで実際に参加者に触ってもらいながらフィードバックを確認できる 参加者 • 開発・企画・営業・別チームの営業・デザイナー 周知方法 • オープンな場にするために全社メールで バザーの開催場所と時間を周知 フィードバック • 口頭での質問や、チャットにて質問 タイムスケジュール • オープニング(5分) • 1回目(15分) Aブース画面共有(リモート用) • 2回目(15分) Bブース画面共有(リモート用) • 3回目(15分) Cブース画面共有(リモート用) • POが質問回答(10分〜)

Slide 8

Slide 8 text

© 2019-2024 OPTiM Corp. All rights reserved. 8 バザー形式 の運用事例 会場・タイムボックス ユーザーストーリXX 〇〇機能の改善 ユーザーストーリYY ユーザーストーリZZ

Slide 9

Slide 9 text

© 2019-2024 OPTiM Corp. All rights reserved. 9 バザー形式のスプリントレビューで実際に得られた効果  より有意義なフィードバックが得られた ◼ ユーザーが自由に触れることでUI・UX・デザイン関連の違和感のフィードバック ◼ 確認が漏れていたバグのフィードバック ◼ 開発者への質疑応答も活発に行われていた  参加者としても有意義な効果 ◼ 営業 ◆定期的にこういった他製品に実際触れる機会があると売りやすい ◼ デザイナー ◆ユーザーの実際の操作を確認しながら、デザインシステム等の懸念点が発見できた。

Slide 10

Slide 10 text

© 2019-2024 OPTiM Corp. All rights reserved. 10 スプリントレビューの準備の課題 バザー形式によって今までのスプリント課題が浮き彫りに… ドキュメント作成の追従が間に合わない スプリントレビューにリリースが間に合わない ✓ DB・APIの仕様変更に追従漏れで 結合・認識合わせが遅れる ✓ 2チームを横断した時に仕様が わからない ✓ デプロイ回数が少なく スプリントレビュー直前の 結合ミスで動かない ✓ デプロイ準備に時間が取られる デプロイ周り・リリース頻度改善 ドキュメント生成の運用見直し CI/CD上で実現へ!!

Slide 11

Slide 11 text

© 2019-2024 OPTiM Corp. All rights reserved. 11 CI/CDの改善: 検証環境へのデプロイフローの見直し 改善前 アプリ実装 デプロイ自体は自動化されているため、 問題ないと思っていた。。。。 振り返ってみると 一部メンバーがスプリントレビュー直前にデプロイ マージ Image Push マージ デプロイ k8sのmanifest 修正・プルリク作成 アプリ実装 マージ Image Push マージ デプロイ 改善後 k8sのmanifest更新 CI CI CD CI プルリク作成 CI CD アプリの実装・デプロイまでの手順をCIで削減 kubernates(k8s)のマニュフェスト更新の認知負荷・手間 を下げ、チームメンバー全員がデプロイするように DEV・STG環境に3〜4日で1,2回 デプロイ DEV・STG環境に1日で1回 〜8回 デプロイ

Slide 12

Slide 12 text

© 2019-2024 OPTiM Corp. All rights reserved. 12 検証環境へのデプロイフローの見直し

Slide 13

Slide 13 text

© 2019-2024 OPTiM Corp. All rights reserved. 13 ドキュメント更新・認識合わせ中間成果物もCIから生成  GitLabのReviewAppsボタンから環境を参照して認識合わせ  リポジトリのバッチに配置し、瞬時に今の実装の仕様・ 定義を検索できるようにする  結合に関わる定義ドキュメントはCIで自動生成・自動更新 ◼ RDBMS: SchemaSpy でER図とテーブル情報定義を検索可能な状態に ◼ OpenAPI: Redoc で見やすいドキュメントをプルリクごとに作成 ◼ Storybook: コンポーネントカタログをプルリクごとに作成 RDBMS Migration実装 プルリクレビュー マージ レビュー用 ドキュメント作成 本番用 ドキュメント作成 CI CI OpenAPI Schema実装 コンポーネント実装

Slide 14

Slide 14 text

© 2019-2024 OPTiM Corp. All rights reserved. 14 ドキュメント作成の自動化  Schema Spyとは? ◼ SchemaSpy でER図とテーブル情報定義を検索可能な状態に ◼ データベースのドキュメントをHTMLで出力するJava製ツール https://schemaspy.org/ https://schemaspy.org/samples/epivirusurf/

Slide 15

Slide 15 text

© 2019-2024 OPTiM Corp. All rights reserved. 15 ドキュメント作成の自動化  Redocly/redoc とは? ◼ OpenAPI Specification からコードも生成しているため、簡単に見やすい仕様書の作成のために利用 ◼ Redoc は、OpenAPI (旧名 Swagger) 定義からドキュメントを生成するためのツール(npmパッケージから利用可能 → リポジトリのバッチに配置し、いつでも今のAPI定義を瞬時に確認できるように https://github.com/Redocly/redoc

Slide 16

Slide 16 text

© 2019-2024 OPTiM Corp. All rights reserved. 16 CI/CD改善について 速度を上げた開発、デプロイ頻度の増加、品質の担保、その他ドキュメントの整備、CIの高速化 に向けてまだまだ課題は多いですが... スプリントレビュー(バザー形式)を開催できるぐらいの改善はできました。

Slide 17

Slide 17 text

© 2019-2024 OPTiM Corp. All rights reserved. 17 まとめ  スプリントレビュー バザー形式を導入してみて ◼従来の受け入れ条件の確認等がメインのスプリントレビューを脱却できた ◼有意義なプロダクトを改善できそうなフィードバックが多く集まった ◼導入する際はCI・CD+運用改善も合わせて実施し回せるように ◆アプリ実装から検証環境のデプロイが誰でもできるぐらいの認知負荷を下げる ◆自動生成できるドキュメントはCIで自動生成し、アクセスしやすい動線に配置する

Slide 18

Slide 18 text

© 2019-2024 OPTiM Corp. All rights reserved. 18 OPTiMを支える技術情報をエンジニアたちが 毎週更新中 • プロダクトマネージャー • エンジニアリングマネージャー • プロジェクトマネージャー • UI/UXデザイナー • テックリード • 機械学習エンジニア • ロボティクス • バックエンドエンジニア • フロントエンドエンジニア • モバイルエンジニア • SRE • QAエンジニア • ・・・ OPTiM テックブログ OPTiM採用 エンジニア 募集中

Slide 19

Slide 19 text

© 2019-2024 OPTiM Corp. All rights reserved. © 2019-2024 OPTiM Corp. All rights reserved. 19