Upgrade to Pro — share decks privately, control downloads, hide ads and more …

大規模な縦割り組織に LeSSを導入するまでの1年間とその後 / ScrumFestOsaka2021

Kotoe Ishige
June 26, 2021
4.8k

大規模な縦割り組織に LeSSを導入するまでの1年間とその後 / ScrumFestOsaka2021

ScrumFestOsaka2021での発表資料です。

Kotoe Ishige

June 26, 2021
Tweet

Transcript

  1. 株式会社アカツキ 石毛琴恵、増田謙太郎
    大規模な縦割り組織に

    LeSSを導入するまでの1年間とその後



    View Slide

  2. 石毛 琴恵 いっしー@oturu333

    株式会社アカツキ 

    EM / 認定スクラムマスター


    2010〜2013 受託開発、SES

    2013〜2018 BtoB Web自社サービス

    2018〜2019 フリーランスEM(常駐)

    2020〜   アカツキ


    ▼趣味

    猫吸い、旅行、お酒


    ▼最近のこと

    外飲みしたい…orz


    View Slide

  3. 増田 謙太郎

    屋号:SCRUMMASUDAR

    フリーランスのスクラムマスター


    2012〜2019 セキュリティソフトウェアメーカー

    2019〜2020 コンタクトECサイトの開発

    2021〜   アカツキ(業務委託)


    ▼コミュニティ活動

    スクラム道関西、ふりかえりカンファレンス


    ▼趣味

    ラーメン、コーヒー、朝の散歩


    View Slide

  4. ©Akatsuki Inc.
    世界をエンターテインする。
    クリエイターと共振する。
    Entertain the world.
    Resonate with creators.
    4
    エンターテインメントは、人の心の原動力になる。
    最高の体験を通じて見える世界が広がり、
    家族や友人、そしてまだ見ぬ仲間とのつながりを作ってくれる。
    人生を振り返った時、その体験はかけがえのない時間となる。
    私たちは自身の内面から湧き出る表現に加え、
    世界中のクリエイター、アーティスト達と共振し、
    人々の心を動かすエンターテインメントを創り続けていく。
    MISSION

    View Slide

  5. ©Akatsuki Inc. 5
    事業だけではなく”組織のあり方”も変化を追及し、
    創造性が発揮され続ける組織を目指します。
    組織の価値観
    個々を自立した存在として信頼すること
    を出発点に、組織のシステムを構築す
    る。
    信頼と自立
    規律と制約を設けることで自由と裁量を
    明確にし、創造性と主体性を引き出す。
    規律と創造
    挑戦と失敗を恐れない一方で計画と学
    習に情熱を注ぎ、組織単位で進化し続
    ける。
    挑戦と学習

    View Slide

  6. 本題の前にお伝えしたいこと

    ● DiscrodのチャットやSNSに、

    感想・ご意見などお気軽にコメントをお願いします!

    発表中、双方向なコミュニケーションをしていきたいと考えてい
    ます。

    ● 写真撮影、スクリーンショットは、OKです!

    SNSにアップしていただいて、OKです!

    ● 資料は、のちほど公開します。


    View Slide

  7. 目次

    1

    2

    3

    4

    LeSS導入前の状態

    LeSS導入後の変化と取り組み

    LeSS導入前の取り組み

    そして未来へ


    View Slide

  8. LeSS導入前の状態


    View Slide

  9. 体制


    View Slide

  10. プロジェクトの全体構成

    新規チーム
    エンジニアリングが必要な変更
    (機能改修、機能追加)
    運用チーム
    エンジニアリングが不要な変更
    (イベント追加、ガチャ更新等)
    Project

    新規チーム
    エンジニアリングが必要な変更
    (機能改修、機能追加等)

    View Slide

  11. 新規チームは、セクション縦割り構成

    ディレクター
 デザイナー

    サーバー

    エンジニア

    (SEN)

    クライアント

    エンジニア

    (CEN)

    QA

    エンジニアリングマ
    ネージャー

    (EM)

    プロジェクト

    マネージャー

    (PM)

    新規チーム
 60人

    Project


    View Slide

  12. リリースまでの流れ


    View Slide

  13. 計画づくり

    ガントチャート

    View Slide

  14. 実装終了後、検証を行う流れになっている

    スプリント1
 スプリント2
 スプリント3
 スプリント4
 スプリント5

    エピック1

    エピック2

    エピック3

    エピック4

    実装
 単体テスト

    実装

    総合テスト

    総合テスト

    実装
 総合テスト

    実装
 総合テスト

    FF(Feature Freeze) 
 CF(Code Freeze)

    単体テスト

    単体テスト

    既存バグ
 実装
 総合テスト

    単体テスト


    View Slide

  15. セクション ✕ バージョンのイベントを実施する

    セクションごと、バージョンごとにイベントを実施。

    バージョン朝会やプランニングではガントチャートの確認・調
    整を行う。

    毎日


    View Slide

  16. 新規チーム職種、体制

    ディレクター
 デザイナー

    サーバー

    エンジニア

    クライアント

    エンジニア

    QA

    EM

    PM

    新規チーム
 60人

    Project

    スクラムマスター
    (SM)

    いない

    再掲


    View Slide

  17. バージョンに遅延が発生した場合
 再掲


    View Slide

  18. バージョンへのメンバーアサイン


    View Slide

  19. 複数バージョンが同時に稼働する

    検証
    開発
    仕様詳細
    決定
    検証
    開発
    仕様詳細
    決定
    Ver1.0
    検証
    開発
    仕様詳細
    決定
    Ver1.1
    Ver1.2

    View Slide

  20. バージョンごとにメンバーがアサインされる

    SEN
 CEN

    検証
    開発
    仕様詳細
    決定
    検証
    開発
    仕様詳細
    決定
    検証
    開発
    仕様詳細
    決定
    QA

    v1.0

    v1.1

    v1.2


    View Slide

  21. バージョンごとにメンバーがアサインされる

    検証
    開発
    仕様詳細
    決定
    検証
    開発
    仕様詳細
    決定
    検証
    開発
    仕様詳細
    決定
    v1.0

    v1.1

    v1.2

    v1.0いくぜ!


    View Slide

  22. バージョンごとにメンバーがアサインされる

    検証
    開発
    仕様詳細
    決定
    検証
    開発
    仕様詳細
    決定
    検証
    開発
    仕様詳細
    決定
    v1.0

    v1.1

    v1.2

    v1.1いくぜ!


    View Slide

  23. バージョンごとにメンバーがアサインされる

    検証
    開発
    仕様詳細
    決定
    検証
    開発
    仕様詳細
    決定
    検証
    開発
    仕様詳細
    決定
    v1.0

    v1.1

    v1.2

    v1.2…!あれ?


    View Slide

  24. 複数バージョンに関わるメンバーもいる

    検証
    開発
    仕様詳細
    決定
    検証
    開発
    仕様詳細
    決定
    検証
    開発
    仕様詳細
    決定
    v1.0

    v1.1

    v1.2

    v1.2もやるぞ!


    View Slide

  25. スプリントのイベント

    毎日

    再掲


    View Slide

  26. 当時の状況まとめ


    View Slide

  27. この状況にいたる歴史


    View Slide

  28. 過去、チーム固定化やスプリントの導入をした

    過去、チーム固定化、スプリント
    の導入を行っていた
    ● クロスファンクショナルな2
    チーム体制の構築
    ● 上記2チームで
    2バージョンの並行開発
    ● チームごとにイベントを実施

    View Slide

  29. この状態にいたる歴史

    隣のチームのことが分からなくて

    不安

    1チームの人数が多く、振り返りで発言
    しづらい。

    イベントを

    セクションチームで行おう!

    人が足りないセクションがあり、

    慢性的にヘルプが発生

    バージョンの進捗状況に合わせ、流
    動的に人員配置しよう!

    →そして、リソース効率重視になって
    いく

    技術的負債が増えてきて、非機能開発
    が工数を圧迫し始めてきた。


    View Slide

  30. わいわいタイム!

    Discordのチャットに、今までの内容に対して、

    ご意見、ご感想を書いていただけると嬉しいです!


    View Slide

  31. LeSS導入前の取り組み


    View Slide

  32. 時系列

    時間

    石毛
    参画

    1年弱

    LeSS
    導入

    増田

    参画

    2020/01
 2021/01

    突然の

    リモート
    ワーク


    View Slide

  33. やったこと

    1. 現状把握

    2. チーム内LT祭り(ティーチング)

    3. より深い対話

    4. スモールトライ

    5. 導入準備

    入社後すぐ

    1ヶ月後


    View Slide

  34. やったこと

    1. 現状把握

    2. チーム内LT祭り(ティーチング)

    3. より深い対話

    4. スモールトライ

    5. 導入準備(話しません)

    入社後すぐ

    1ヶ月後


    View Slide

  35. 1. 現状把握


    View Slide

  36. 「どういう流れで仕事をしているのか」大枠を理解する。


    ● メンバーのことを理解する(1on1)

    ○ (自分)自己紹介とやっていきたいこと

    ○ (相手)やっていること、困っていること、改善したいと思っているこ
    と

    ● 仕事の流れを理解する

    ○ 組織図や体制の確認

    ○ MTGに参加する

    ■ ファシリテーター、参加者、内容、頻度

    大枠を理解する


    View Slide

  37. 1on1は可能な限り、広く行うとより良い

    ● 立場の違う人たちから幅広く意見を集約できる

    ● チームの全体像が理解しやすい

    ○ メンバーの自発性

    ○ どの人がどんなことに興味あるのか

    ○ セクショナリズムが存在するか、どの程度か


    View Slide

  38. メンバーから出た課題意識

    時間効率が悪い

    ● 朝会がたくさんあり、朝会だけで時間が多く取られるメン
    バーがいる

    ● 職種の責任範囲が不明瞭でボールが落ちる


    PDCAサイクルが回っていない

    ● MTGの形骸化(特に、振り返り)

    ● セクションを超えた課題解決がしづらい


    View Slide

  39. メンバーから出た課題意識

    スケジュールが遅延する、手が空かない

    ● スケジュールの終盤になってから遅延が発覚する

    ● スケジュール遅延の原因が明確にならず、対策の妥当性
    や継続性が分からない

    ● 改善タスクは「機能開発の手が空いたときにやる」状態で
    進みづらい


    自発性が低い

    ● リーダーなど、ハブとなるメンバーに頼りがち


    View Slide

  40. 分からないことを深堀りする

    ● MTGの背景

    ○ MTGの目的や歴史的背景

    ● 役割や責務の相互理解

    ○ ディレクターとプランナーって何が違うの?

    ○ (逆に)EMって何するの?

    ● プロセス、フロー

    ○ 仕様が定まるタイミング、開発が始まるタイミング…

    ○ 意思決定者、プロセス

    ○ ブランチワークどうなってるの?


    View Slide

  41. 最初は、現状理解に徹することが大事

    過去を否定しない。そして、自分の意思を伝える前に

    まずは現状と自分以外の人の立場や考えを理解していくこと


    真摯な好奇心を大事に。

    無邪気に積極的に!


    何でも相談できる人を1人見つけると

    とっても心強い。


    View Slide

  42. 現状を見て思ったこと

    ● 複雑な仕組みの中でも相互にフォローし合いながら、継続
    的に価値提供をし続けている


    ● 他責にして文句を言う人が少ない。とても良い人たちで、
    良いチーム


    ● やり方を知らないだけで、彼らが全力で走れる仕組み、流
    れを整えられれば、大丈夫だろう


    View Slide

  43. チームにとっての理想を考えた

    ● 自発的な行動ができるチーム


    ● ユーザーへの価値提供に集中できるチーム


    ● 人としてチームとして、成長し続ける


    View Slide

  44. まず改善したいと思ったこと

    過去の歴史からイベントが
    形骸化し、PDCAサイクルが
    回っていない


    イベントの目的をそろえて、
    固定化されたチームごとに
    実施し、PDCAサイクルを回
    す

    バージョン単位の流動的な
    チーム & セクションチーム
    体制による、自発性の持ち
    づらさ

    クロスファンクショナルな
    チームでの固定化をメインと
    しつつ、セクションの繋がり
    も残す体制作り


    View Slide

  45. まず改善したいと思ったこと

    ボールが落ちる
 責務の見える化

    バージョン後半で遅延発覚

    問題があったときに早期に
    変更ができるようにするため
    の、見積もり方法・タイミング
    の改善


    View Slide

  46. その理想に近いのが、LeSSだった


    View Slide

  47. 2. チーム内LT祭り(ティーチング)


    View Slide

  48. LTの立ち位置

    As is
    To be
    GAP

    解決策

    LT第1部

    LT第1部

    LT第2部


    View Slide

  49. LTをしようと思った背景

    1. 体制を変えない限りは根本的に改善が難しい。組織規模
    的にも、早期に手を打ったほうが良いと判断した


    2. 目的を理解し、納得して変化しなければいずれ形骸化して
    しまう


    3. 入社して日が浅いため、信頼関係ゼロ。こちらからの考え
    を伝えつつ、メンバーとの対話の時間を作る


    View Slide

  50. LTの進め方

    ● 週次(たまに力尽きてスキップ)


    ● LTの目的は、毎回しつこく伝える


    ● LT後にハピネスドア     でFBをもらい、発表内容の調
    整や対話


    View Slide

  51. To beで話したこと(LT第1部)

    本題に入る前に「今できていること」と「なぜ今できているの
    に、改善が必要なのか」というお話をした


    View Slide

  52. To beで話したこと(LT第1部)

    ● HRT
    ● 心理的安全
    ● 自己組織化
    ● 課題解決の方法
    チーム

    ● 不確実性
    ● 効率化
    ● 見積もり
    ● 計画づくり
    プロセス


    View Slide

  53. 解決策で話したこと(LT第2部)

    ● スクラム、LeSSの概要


    ● 大規模スクラム(LeSS)をやっていきたいけど、その目的
    は第1部で話したことを目指していきたいからだよ


    ● 先行して試しているチームからの共有


    View Slide

  54. 3. より深い対話


    View Slide

  55. 意識したこと

    ● 広く浅く共有をしつつ、関心を持ってくれるメンバーとはよ
    り深く対話を。いざ変化をおこした後は、彼らが周りのメン
    バーのサポートをしてくれる


    ● 経験主義とはいえ、完全に納得できないことには進めない


    View Slide

  56. 意識したこと

    群衆の英知もしくは狂気

    View Slide

  57. 4. スモールトライ


    View Slide

  58. 1セクションチームでイベントの改善

    ● 1チームで「振り返りが機能していない」という声が大きくな
    り、振り返り・プランニングの改善をサポートした(予定してい
    たわけではなかった)


    ● 半年ちょっとくらい


    ● 導入前に、試みと学びを、LT第二部の最後で共有しても
    らった


    View Slide

  59. チームで実施したこと

    ● 相対見積もり
    ● みんなで見積もり
    ● プランニングでの
    アサイン
    プランニング

    ● スプリント期間に
    フォーカスした振
    り返り
    ● 想定通りに進まな
    かった理由の深
    堀り
    振り返り


    View Slide

  60. チームで改善できたこと

    ● みんなで見積もりをするためには、前提知識を揃える必要
    がある。

    ○ 揃えると、考慮漏れを指摘したり、不要な開発を止めること
    ができた

    ○ 着手にあたり不安なことを事前に相談でき、ペアやモブでの
    実装を提案できた


    ● 差し込み作業が作業の予測に影響していると分かり、内
    容のカテゴライズと計測をしてみた


    View Slide

  61. チーム改善できなかったこと

    ● 予実の差分が大きくなりやすいのは、プランニングの時点
    で仕様が定まってないもの

    ○ そもそも見積もりができない

    ○ 作業途中で手が止まる


    View Slide

  62. 1セクション改善を試みた結論

    タスクをReadyにすることは大事。


    1セクションでのチームでは、プロセスの課題を解決するのが
    難しいし、時間がかかる。


    クロスファンクショナルチームになって、チャレンジした
    い!


    View Slide

  63. 導入前にやったことまとめ

    ● 現状を理解する


    ● 広く浅く目的や内容を伝える


    ● 一部の人と深く対話する


    ● 小さく試してみる


    View Slide

  64. わいわいタイム!

    Discordのチャットに、今までの内容に対して、

    ご意見、ご感想を書いていただけると嬉しいです!


    View Slide

  65. LeSS導入後の変化と取り組み


    View Slide

  66. 導入目的を改めて確認!

    ● クロスファンクショナルなチームでの固定化を

    メインとしつつ、セクションの繋がりも残す体制作り


    ● セレモニー目的をそろえて、固定化されたチームごとに

    実施し、PDCAサイクルを回す


    ● 問題があったときに早期に変更ができるようにするための、見積
    もり方法・タイミングの改善


    ● 責務の見える化


    View Slide

  67. チーム体制


    View Slide

  68. 新規チーム体制(2020年まで)

    ディレクター
 デザイナー

    SEN

    CEN

    QA

    EM

    PM

    新規チーム

    Project

    再掲


    View Slide

  69. Project

    新規チーム体制(2021年1月から)

    プロダクトオーナー
    エピックプロダクトオーナー
    デザイナー
    CEN
    SEN
    QA
    スクラムマスター
    CEN
    SEN
    QA
    スクラムマスター
    CEN
    SEN
    QA
    スクラムマスター
    開発チームA 開発チームB 開発チームC
    プロダクトオーナー(ディレクター)チーム
    新規チーム

    EM

    PM


    View Slide

  70. RACI図で役割を明確化

    ● 企画からリリースまでの各フェーズにおいて、

    プロダクトオーナー、開発者、デザイナー、

    スクラムマスター、運用チームなどの各役割について、

    RACI図を作成。

    プロダクト
    オーナー
    開発者 デザイナー スクラム
    マスター
    運用チーム
    PBIの作成 R/A C C C I
    スクラムを
    うまく回す
    C C C R/A -
    RACI図の例

    View Slide

  71. ● サーバーエンジニア、クライアントエンジニア、QAが

    1つのチームにいることで、コミュニケーションの量が増えた!

    ● 新機能の開発に対して、セクションを越えて開発する動きになり、

    開発時に気をつけること、考え方が共有されるようになった!

    クライアントエンジニア
    QA
    サーバー
    エンジニア
    役割を超えて、相談やコミュニケーションが気軽にできるように!

    わい
    わい
    がや
    がや

    View Slide

  72. ペアプロやモブプロを取り入れ開始!

    ● 1つの機能開発に1人の開発者をアサインする方法から、

    一部の機能については、

    1つの機能開発に複数人の開発者をアサインする方法に変更!

    ● 複数人の開発者がいると、ペアプロやモブプロを取り入れるように!

    ● 結果、プルリクエストレビュー工程がなくなり、

    素早くマージされるようになった!

    わい
    わい
    がや
    がや

    View Slide

  73. 開発プロセス


    View Slide

  74. 開発プロセス(2020 年まで)

    スプリント1
 スプリント2
 スプリント3
 スプリント4
 スプリント5

    エピック1

    エピック2

    エピック3

    エピック4

    実装
 単体テスト

    実装

    総合テスト

    総合テスト

    実装
 総合テスト

    実装
 総合テスト

    FF
 CF

    単体テスト

    単体テスト

    既存バグ
 実装
 総合テスト

    単体テスト

    再掲


    View Slide

  75. 開発プロセス(2021年1月から)

    スプリント1
 スプリント2
 スプリント3
 スプリント4
 スプリント5

    PBI1

    PBI2

    PBI3

    PBI4

    既存バグ

    実装
 単体テスト

    実装
 単体テスト
 不具合対応

    総合テスト

    総合テスト

    実装
 単体テスト
 総合テスト

    実装
 単体テスト
 総合テスト

    実装
 単体テスト
 総合テスト

    FF
 CF

    ● シフトレフトで、FFまでに単体テストの完了を目指す。

    ● 新機能に加えて、既存バグの対応をバージョン開発開始時に計画する。


    View Slide

  76. ● 以前は、ガントチャートで1日単位の作業を

    日々確認しているにも関わらず、FFの1週間前に

    「やっぱり開発の完了が間に合いません」とエンジニアから遅延
    を告げられていた。


    ● プロダクトバックログアイテムの見積もり結果を使った

    バージョンごとのバーンダウンチャートにより、

    開発状況の見える化を実施。

    FFの1ヶ月前には、FFに間に合わせることが

    厳しい機能を、プロダクトオーナーに

    認識してもらえるようになった。

    プロジェクトの遅延を早く検知できるように!




    View Slide

  77. ● 総合テスト期間(FFからCF)に、

    “余力があれば”既存バグの修正をしていた。

    現実は、新機能の不具合対応で、既存バグの修正に

    なかなか手が回っていなかった。


    ● 既存障害の修正をプロジェクト開始時に計画するように!

    結果、事前に対応する既存障害を

    見通せるようになった。

    既存のバグ対応を計画できるようになった


    View Slide

  78. スクラムイベント


    View Slide

  79. スクラムイベント(2020年まで)

    毎日

    動いているバージョンの数だけ、時
    間をずらして行う

    再掲

    ● 各セクションごとにイベントを実施


    View Slide

  80. スクラムイベント(2021年1月から)

    毎日

    ● 固定化した各チームでのみイベントを実施

    ● バージョンごとのイベント(朝会)をなくした


    View Slide

  81. 朝会の時間が削減!

    ● 以前は、バージョンごとに朝会を実施していたため、

    ディレクターや複数バージョン掛け持ちのエンジニアは

    午前中のほとんどを朝会に費やしていた。

    ● 各チームごとにデイリースクラムを実施するのみとなったため、

    朝会に費やす時間が30分以内にまで削減された!

    ● 結果、本来の仕事(企画作成、開発など)に費やす時間を

    増やすことができた!

    Ver.1.0の朝会

    Ver.1.1の朝会

    Ver.1.2の朝会

    デイリースクラム

    実装

    例)午前の時間の使い方 


    View Slide

  82. 見積もり方法


    View Slide

  83. ● ディレクターが要件を決めた時期に、

    ロードマップを作成するための絶対見積もりをエンジニアが実施。

    ● この結果をもとにディレクターが、

    1日単位で、ガントチャートを作成していた。

    ● 後から、仕様が変わったり、実装する機能が増えても、

    納期が変わらず、プロジェクトを進めるには、不安定な状況だった。


    見積もり方法(2020年まで)

    機能A

    機能C

    機能B

    実装7日間

    実装3日間

    実装10日間

    例)ガントチャート


    View Slide

  84. 見積もり方法(2021年1月から)

    見積もりを以下の3つに分類

    ● ロードマップを作成するための絶対見積もり

    この見積もりの結果を納期としないことを関係者に周知

    バッファを考慮したスケジューリングを実施

    ● バージョンごとの作業量を求める相対見積もり

    プロダクトの進捗見える化するためにバーンダウンチャートに利用

    ● スプリントバックログを作るための絶対見積もり

    日々のデイリースクラムで開発者が確認するために利用

    S
 M
 L


    View Slide

  85. 見積もり方法変更により、事前のスケジュール調整ができるように!

    ● ロードマップ作成時、見積もりを考慮して、

    開発する機能を選択するようになった。

    また、見積もりに幅があることを認識し、

    プロジェクトバッファを考慮して計画するようになった。

    ● 作業量を表す相対見積もりの結果を用いて、

    各バージョンごとの状況を見える化!

    バージョン間での優先度を考慮して開発を進めるようになった。


    View Slide

  86. チームを超えた取り組み


    View Slide

  87. ● チームを超えて、スクラムについて話すことができる場を

    EMが企画して実施。

    ● ワイワイと話をすることを大事にしており、

    ネクストアクションにつなげることを必須としていない。

    ● 実施したテーマ

    ○ モブワークなど仕事の進め方

    ○ チーム間コミュニケーション

    ○ デイリースクラム

    etc


    YYスクラムの実施

    わい
    わい
    わい
    わい

    View Slide

  88. わいわいタイム!

    Discordのチャットに、今までの内容に対して、

    ご意見、ご感想を書いていただけると嬉しいです!


    View Slide

  89. LeSS導入後の課題


    View Slide

  90. 導入後の課題

    ● 開催されないスプリントレビュー

    ● チャートから進捗が判断できない

    ● 変化の激しいプロダクトバックログ

    ● 「全部開発が終わるのいつになる?」




    View Slide

  91. 開催されないスプリントレビュー

    ● 増田が入場した2月前半のスプリントでは、

    スプリントレビューが開催されなかった。

    ● その後、スプリントレビューは継続して開催している。

    ただ、開発チームによって、

    レビューに出せるインクリメントがないことが、しばしばある状態。

    今回のスプリントレビューで対象となるとなる
    プロダクトバックログアイテムはどれですか?
    開発チーム
    入場直後の増田
    出せるものがないので、
    スプリントレビューは、 ”なし”でお願いします。

    View Slide

  92. ● 相対見積もりの結果からバーンダウンチャートを作成するも

    バーンダウンチャートが落ちるときは、ドカッと下がり、

    また平行線の状態になり、先が読みづらい状態。

    ● 開発は終わっているが、検証が終わっていない

    チャートに実態が反映されておらず、

    進捗を判断しづらい状況。

    チャートから進捗が判断できない


    View Slide

  93. 変化の激しいプロダクトバックログ

    ● 運用チームからの依頼や既存バグ対応など差し込みの機能開発が多く、

    プロジェクト開始時よりボリュームが膨れがち。

    ● プロダクトオーナーと開発者で仕様を固めたと思い、開発をはじめ、

    仕様の理解が深まってきてから、改めて見積もると、

    開発ボリュームが数倍になることも。

    実際のバーンアップチャート

    View Slide

  94. 「全部開発が終わるのいつになる?」

    ● 成果物ベースのコミュニケーションが、

    エンジニア個人に依存しており、ばらつきがある状態。

    ● その結果、プロダクトオーナーと開発者間でのコミュニケーションが、

    不足していることもあり、プロダクトオーナーの関心事が、

    「考えた仕様のすべてがいつまでに実装完了できるのか?」

    になってしまっている。



    機能A
    機能B
    機能C

    View Slide

  95. 深ぼってみると…


    View Slide

  96. 大きなPBIと1つのPBIに1人のエンジニア

    ● 1スプリントで完了できないサイズのPBIが、ほとんど。

    ● 大きなサイズなPBIを1人のエンジニアで仕事をしていることが多い。

    ● その結果、「スプリントレビューが開催されない」、

    「チャートから進捗が判断できない」、「変化の激しい

    プロダクトバックログ」、「全部開発が終わるのいつになる?」

    といった状況に陥っている。

    ● 現在は、PBIを小さくするために、四苦八苦中。


    View Slide

  97. 小さなPBIを目指した先の理想


    View Slide

  98. ユーザーへの価値提供を早くする

    ● 現在は、数ヶ月後のリリースを達成するために、

    開発や検証に取り組んでいる状況です。

    ● プロダクトのフィードバックサイクルを回し、

    企画からリリースまでのリードタイムを短くしようと奮闘中です。

    企画
 テスト

    実装

    現在

    未来

    リリース

    企画
 実装
 テスト
 リリース

    実装
 テスト

    企画
 実装
 テスト
 リリース


    View Slide

  99. 運用チームと連携したプロダクト開発

    新規チーム
    エンジニアリングが必要な変更
    (機能改修、機能追加)
    運用チーム
    エンジニアリングが不要な変更
    (イベント追加、ガチャ更新等)
    Project

    再掲


    View Slide

  100. わいわいタイム!

    Discordのチャットに、今までの内容に対して、

    ご意見、ご感想を書いていただけると嬉しいです!


    View Slide

  101. そして未来へ


    View Slide

  102. LeSSを導入した組織のその先へ

    自分たちの成し遂げたいこと、あるべき姿を模索
    しながらの導入初期を終えました。


    以前「課題がない」と言う人も多かったチームで
    すが、少しずつメンバーからの課題意識も出てく
    るようになってきました。🎉


    また、おそらく導入前には想像がしづらかった
    「ユーザーへの価値提供を早くしていこう」という
    会話も、最近は飛び交うようになりました。🎉


    View Slide

  103. LeSSを導入した組織のその先へ

    最終的にはやってみないと分からないし「ともに
    経験から学び、課題を早く共通認識にして解決
    していこう」という流れが、少しずつ根付いてきて
    いるのかな〜と思います。


    モバイルゲーム事業ではまだめずらしいかもし
    れないアジャイルな組織になっていきたいと思い
    ます!


    View Slide

  104. We are hiring!

    アカツキでは、互いに高め合い

    最高のゲームをユーザーに届けていけるメンバーを募集しています!

    まずはカジュアルにお話しましょう!


    ● クライアントエンジニア

    ● サーバーエンジニア

    ● エンジニアリングマネージャー

    ● スクラムマスター

    ● More…


    ゲーム事業採用サイト

    https://game.aktsk.jp/recruit/


    View Slide