Copyright © OPTiM Corp. All Right Reserved. スクラム開発の成功と苦労を語る Optimal Biz Telework 開発秘話 OPTiM Tech Night 2020/09/29 大脇 ・伊藤

Copyright © OPTiM Corp. All Right Reserved. 2  OPTiM 2013年度 中途入社 7年目  Optimal Bizの “開発マネージャー” • 開発部門のラインマネージャー • 開発計画と品質にコミットして何でもやる人 • PdMっぽいこと、PjMっぽいこと、EMっぽいこと…  興味 • チームマネジメントやチームビルディング • Keywords : Agile, Scrum, Product Management, Engineering Management 自己紹介 – 大脇 最近猫を飼い始めました

Copyright © OPTiM Corp. All Right Reserved. 3  OPTiM 2011年度 新卒入社 9年目  Optimal Bizのエンジニア • テックリード・EMのような役割 • 技術選定・難しい実装のサポート • 歴が長いのでドメイン知識豊富  興味 • エンジニア育成 • Keywords : Career Path, Tech Lead, Ruby on Rails 自己紹介 – 伊藤

Copyright © OPTiM Corp. All Right Reserved. 4 Optimal Biz Telework サブタイトルの補足

Copyright © OPTiM Corp. All Right Reserved. 5 Optimal Biz Telework

Copyright © OPTiM Corp. All Right Reserved. 6 Copyright © OPTiM Corp. All Right Reserved. Optimal Biz Teleworkによる支援 業務サポート コミュニケーション サポート 生産性向上 サポート - New Normal Work Style - Optimal Biz Teleworkが、 デジタルな情報伝達を通じて 真にクリエイティブなマネジメント環境を実現します

Copyright © OPTiM Corp. All Right Reserved. 7 Copyright © OPTiM Corp. All Right Reserved. コミュニケーションサポート 個人ごとに業務を進める在宅勤務では コミュニケーション不足による「在宅鬱」の危険性を伴います AIチャットボットとの会話や在宅勤務の状況から 従業員の「在宅鬱」の可能性やモチベーションの状況を確認し、 最適なタイミングでヒアリングを行うことができます

Copyright © OPTiM Corp. All Right Reserved. 8 Copyright © OPTiM Corp. All Right Reserved. 業務サポート テレワークは出勤・退勤などの具体的な区切りが少ないため 働きすぎる傾向があります ⚫ 出社/退社での管理 ⚫ 登録されたジョブ、スケジュールベースでの確認 隠れ残業を防止し、より実態に近い 「働きすぎ防止」が実現できます 従来の管理方法 新しい手段 ⚫ 操作ログから作業の実働時間を確認

Copyright © OPTiM Corp. All Right Reserved. 9 Copyright © OPTiM Corp. All Right Reserved. 生産性向上サポート テレワークによってこれまで以上に 自制と生産性のコントロールが要求される時代になっています 従業員の「時間の使い方」を自動分析し、業務終わりに表示 日々の行動を従業員自身が自然に改善していくことができます

Copyright © OPTiM Corp. All Right Reserved. 10 Copyright © OPTiM Corp. All Right Reserved. 自分の「時間の使い方」をシンプルに記録 エージェントが自動的に今の業務内容を分類して記録。間違っていたら1ステップで訂正もできる また、ラップタイム方式で過去のタスク所要時間を一覧表示 自分の時間をどう使っているか自然に意識できます ※ラップタイム機能は7月以降リリース予定 今何してる？

Copyright © OPTiM Corp. All Right Reserved. 11 Copyright © OPTiM Corp. All Right Reserved. 管理者はダッシュボードから全体を把握 全社、もしくは組織ごとの業務状況や業務内容、体調などを網羅的に把握が可能。 働きすぎている従業員がいたらアラートを発出。 体調が悪い従業員など、特定の従業員に深堀りして分析することもできます 管理者画面 従業員詳細画面

Copyright © OPTiM Corp. All Right Reserved. 12 コロナの中で開発がスタート・・・ サブタイトルの補足

Copyright © OPTiM Corp. All Right Reserved. 13  Optimal Bizの機能開発チームの一つをBiz Teleworkチームとしてリビルド • もともと、10年選手製品のOptimal Bizにあって、唯一スクラム開発に挑戦していたチーム  スクラム開発実績 • Optimal Bizではほとんどスクラム開発の実績がなかった • 組織構造は職能区切り(開発チーム・検証チーム・運用チーム・サポートチームなど) • なのでそもそもスクラムのような職能横断チームに慣れていない  完全テレワークでBiz Telework開発開始 • コロナ全盛期のため、弊社も完全リモートワークに移行した • チームの中でリアル顔合わせができない状態 製品開発キックオフ時のチーム状況

Copyright © OPTiM Corp. All Right Reserved. 14 3ヶ月で1stリリース、さらに2回のバージョンアップ、増え続けるメンバー 4月 5月 6月 7月 8月 9月 ★開発開始 ★v1.0.0 ★v1.1.0 ★v1.2.0 13人 17人 22人 25人 29人 スプリント 現在は計29人のスクラムチーム １チームスクラム POは4人 増員 ２チーム体制に 増員 ３チーム体制に 増員 増員 ４チーム体制に

Copyright © OPTiM Corp. All Right Reserved. 15 開発チーム 開発チーム スクラムの体制 ステークホルダー 販売パートナー 経営層 プロダクトオーナー 4人 チーム 1 6人 チーム 2 9人 チーム 3 5人 スクラムチーム 計29人 既存製品をスクラムで開発し ていたチームを新サービスの 開発にアサイン Windows/mac/Android/iOS のエンジニアを社内各所より 集めた急造チーム ベトナムのオフショア チーム 4 5人 サーバーサイドのエンジニア を社内各所より集めた急造 チーム

Copyright © OPTiM Corp. All Right Reserved. 16  企画職の2人 • 経営層と合意のある製品戦略 • 販売パートナーとのコミュニケーション • 市場の理解 • 中期の製品ロードマップ 4人のプロダクトオーナー  開発職の2人 • どうやって着地させるか • 開発チームとのコミュニケーション • 開発上のリスクの把握 • 機能要求を機能/非機能要件として具体化 • 短期の開発計画 製品ロードマップ リリース計画 優先度付きプロダクトバックログ 週次でMTG プロダクトバックログ リファインメントも兼ねる

Copyright © OPTiM Corp. All Right Reserved. 17  専任のスクラムマスターはいない  兼任の4名 • POと兼任 2名 • 開発チームと兼任 2名  開発チーム横断のデイリースクラムの中で課題発見や議論など  スクラムに対して知識とモチベがあるメンバーで、スクラム開発をどう良くしていくかを日々話 し合っていて、その延長線という感じ スクラムマスターは兼任

Copyright © OPTiM Corp. All Right Reserved. 18  実装成果物のテストをどのタイミングで行うか • 2週間スプリントの場合は、バックログの完了条件に「テスト完了」を含める • 1週間スプリントの場合は、次スプリントにテストを行う  リリーススプリント • 細かいバグの修正 • 総合試験にあたるテスト (性能試験など) • 本番環境向けのバイナリビルド＆テスト • リリースノートなどのドキュメント テストとリリース 4月 5月 6月 7月 8月 9月 ★開発開始 ★v1.0.0 ★v1.1.0 ★v1.2.0 スプリント

Copyright © OPTiM Corp. All Right Reserved. 19 複数スクラム導入時の苦労 サブタイトルの補足

Copyright © OPTiM Corp. All Right Reserved. 20  初めて体験する複数スクラムチームによる開発  あまりにもよくわからなかったのでブログを書きました  よくわからなかったこと • 複数のスクラムイベントに参加している人がいる(兼任問題) • スクラムの足並みを揃えるのが難しい • チーム間で依存するバックログの扱い 複数のスクラムを同時にまわす

Copyright © OPTiM Corp. All Right Reserved. 21  ブログ当時 • QAを各チームに配置できない • 対処療法として、QAは複数チームのイベントに 出席 • ベロシティの信頼度は落ちたと思うし、検証メン バーの負荷は高かった  現在 • 検証の専門家を追加して、チームをまたぐ人を 減らした • 既存の派遣メンバーからの紹介 • オフショア開発メンバーの職能入れ替え 複数のスクラムイベントに参加する人がいる チーム 1 チーム 2 チーム 3 チーム 4 開発 4名 検証 2名 開発 6名 検証 0名 開発 5名 検証 0名 (発足前) チーム 1 チーム 2 チーム 3 チーム 4 開発 4名 検証 2名 開発 6名 検証 2名 開発 4名 検証 1名 開発 4名

Copyright © OPTiM Corp. All Right Reserved. 22  ブログ当時 • スプリントの期間が違う • スプリントゴールが違う • イベント実施日が違う  現在 • スプリント期間は2週間統一 • ゴールを「テスト実施完了」に統一 • スプリントの名前を二十四節気に統一 • 現在はスプリント寒露 スクラムの足並みを揃えることが難しい チーム 1 チーム 2 チーム 3 チーム 4 期間 2週間 2週間 1週間 (発足前) ゴール テスト完了 実装完了 実装完了 実施日 水曜 木曜 火曜 チーム 1 チーム 2 チーム 3 チーム 4 期間 2週間 2週間 2週間 2週間 ゴール テスト完了 テスト完了 テスト完了 テスト完了 実施日 水曜 木曜 火曜

Copyright © OPTiM Corp. All Right Reserved. 23  ブログ当時 • 「Aチームのバックログに着手するにはBチームのAPIが必要・・・」 • 全体の設計がイメージできるプロダクトオーナーのスキルで拾う • 依存する場合はチーム代表者のデイリースクラムで拾う  現在 • あまり変化なし。基本は代表者がデイリースクラムで共有 • 全体のバックログを別のJiraプロジェクトで管理して見やすくした チーム間に依存するバックログ

Copyright © OPTiM Corp. All Right Reserved. 24 その他の気付き サブタイトルの補足

Copyright © OPTiM Corp. All Right Reserved. 25  新規の寄せ集めチームは意外とスクラムやりやすかった • いろんなプロダクトを経験したエンジニアが集まった • みんなの苦労した経験がスクラムの良いパターンに寄っていった • 特にCI/CD, 単体テストなど  フルリモートスクラム • 「リモートに起因する問題」は特筆するほどなかった • 振り返りはMiroなどのホワイトボードアプリを活用 • プランニングやデイリースクラムはTeamsで事足りた その他の気付き

Copyright © OPTiM Corp. All Right Reserved. 26  変化が激しい時期は1週間スプリント • 製品戦略や機能優先度が毎週変化していた  チームがやりやすいリズムは2週間スプリント • テストまで完了できるためやり残しが生まれにくい • 走りやすいスピードに戻した 状況に合わせてスプリント期間を変更 4月 5月 6月 7月 8月 9月 ★開発開始 ★v1.0.0 ★v1.1.0 ★v1.2.0 スプリント 最初のリリースまでは1週間 2週間に変更 リリーススプリント は1週間 このリリース スプリントは 2週間とした

Copyright © OPTiM Corp. All Right Reserved. 27  LeSS、Nexusなど大規模スクラムのフレームワークを導入したい  スクラムというフレームワークの完成度の高さ • 1チームスクラムをやりやすいところから始める • 慣れてくるとスクラムに寄せていった方がやりやすくなる  大規模スクラムでも同じことを感じるところまできた（やりにくいと感じる部分の答えがLeSSや Nexusで用意されてた） • 開発チームごとに分離されがちなスクラムイベントやプロダクトバックログの管理など • Nexusチームのようなものが自然発生していたり 今後は「大規模スクラム」へ

Copyright © OPTiM Corp. All Right Reserved. 28