これはドリコム Advent Calendar 2020 の20日目です。
19日目は Egliss さんの「WPFでノードエディタを作ってみる」です。
目下、ゲームカンパニー長が取りこぼしそうな仕事と、ゲームプロダクトのプロデューサー、SREを強化する取り組みが主務になっています。
SREを管掌するものとして、たまにはものを書けという突き上げを感じたので、今回はドリコムでのスクラムの広がりの話をしたいと思います。
いつの時代も、ウォーターフォールVSアジャイルみたいな議論がよくなされています。
個人的なスタンスとしては、プロジェクトがうまくいくのであれば、手法はなんでもよいと言う考え方ではありますが、短いプロジェクトや、作るプロダクトや目的がはっきりとしていて、ゴールや計画が変わりにくいものは、ウォーターフォール、長期的なプロジェクトや、作るプロダクトや計画への不確実性が高いものはアジャイルぐらいの感覚でいます。
ただ、アジャイルのほうが好きです。
今回のアップデートは、スクラムが世界に広まりつつも、「スクラムあるある」の一つであるスクラム自体の実践が目的化され、成果をあげることに集中できていない、ソフトウェア開発以外のドメインでも採用され始めていることなどを背景としたアップデート内容となっています。
主な項目は以下の通り、詳しくはスクラムガイド2020を参照ください。
約3年前、enzaプラットフォームの開発開始当初に、これからどうやってプロジェクト運営していくか？という話になったとき、ちょうど当時のゲーム組織で、正しいスクラムを理解する人を増やして、組織的に理解度を高めようと動いていました。
スクラムを始めるときのセオリーは、アジャイルの考え方や、正しいスクラムを、チーム全員が理解することが大事です。
そのセオリーに則り、ゲーム組織の取り組みに乗っかる形で、プロダクトオーナーやスクラムマスターを担当するメンバーに社外のスクラム研修(すごく高い)を受けてもらい、共通の教科書をチームメンバーに読ませることから始めました。
プラットフォームの開発は、ゲームプロダクトに比べて、職種の細分化は激しくないことと、チームメンバーが前向きに取り組んだことにより、軌道に乗り、現在も割とstrictなスクラムに近い方法で運用されています。
私も、PO、スクラムマスター、Scrum@Scaleの研修を受け、たくさんのお金を会社に払ってもらったので、それを還元するべく当時100人以上いた組織全員に、社内のスクラム研修を行い、スクラムの理解を促進しました。
その動きから3年たち、プロダクト開発では当たり前のようにスクラムで始めることが標準的(これは強制ではなく、プロダクトがうまくいくためであれば原則何でもありです)になり、今年度から、ものを作る以外の部署でもスクラムを導入し始めました。
想像を超えた言い間違いや、書き間違いが多く、代表作は、「アントレプレナー」を「アントプランナー」、「Doneです」を 「Donです」、「ホワイトボード」を「ホワイトベース」。
普段は笑い話で済むが、たまに微妙な言い間違いをして、各所に間違って伝わることがあるが、人間力でカバーしている。
POでありながら、担当のチームメンバーに様子を聞くとプロダクトバックログを書いているのを見たことないという情報が入った。
そんな前衛的なPO見たことないと本人に伝えると、誰でも書いていいって先生は言っていたし、優先順位付けはしている。
そもそも価値は提供できているとスクラムガイド2020でのスクラムのあり方を早期に体現している可能性がある。
この二人も3年前に、enza、ゲームプロダクトのPOとして、スクラム研修に参加し、正しいスクラムを学んでいます。
プロダクト開発でスクラムを実践した経験から、ソフトウェア開発以外でも適用できると判断し、現在管掌している部署でスクラムを導入して運用しています。
実際に導入してみて実践しているメンバーにヒアリングしてみました。
この中でも、スクラムには振り返り(レトロスペクティブ)が、フレームワークとして、組み込まれているため、振り返りの習慣化と、改善活動しっかりとストーリー化することにより、普段の活動に改善活動を組み込みやすいというのが大きいようです。
経営企画では、仕事の見える化が促進され、仕事を分業しやすい状態になり、実行力が上がったことが最大の効果であったようです。
スクラムのバイブルである「スクラム 仕事が４倍速くなる“世界標準”のチーム戦術」※1を読むと、ソフトウェア開発以外でも使えるフレームワークであることは理解はできるのですが、他社さんの話を聞くと、社内のエグゼクティブを始めとした社内の理解を得るのが難しかったり、スクラムやウォーターフォールは、ソフトウェア開発で使われる用語なので、なかなか浸透できないなどの話がよく上がります。
ドリコムでは、プロダクト側でスクラム採用しているという話を良くしているので、結果的に、ソフトウェア開発以外のビジネスドメインの人材にも割と抵抗なく受け入れられてるようです。
こうして、世界的に、ソフトウェア開発以外でも導入され始めている流れと同様に、3年前の取り組みがきっかけでドリコムでも浸透してきています。
あくまで、ドリコムは事業会社です。
スクラムの実践が促進されたとしても、事業寄与が出来なければ意味はないので、積極的に導入という姿勢ではありませんが、執行役員チームの運営もスクラム化され、執行役員チームで作られたバックログを各部署につなぐ仕組みや設計まで実行できたら、Spotifyモデル※2相当のものが構築できるかもしれません。
また、折を見て、その後については、お話できればと思います。
明日の記事は 渡辺 祥二郎 さんの「【3Dディレクター＆アニメーター必見】 モーション工数大幅削減でこのプロジェクトを乗り切れ(ﾟДﾟ)2020」です。
ドリコムでは一緒に働くメンバーを募集しています！
募集一覧はコチラを御覧ください！
19日目は Egliss さんの「WPFでノードエディタを作ってみる」です。
自己紹介
ドリコムの主力事業であるゲーム組織のゲームカンパニー副長と、それを裏で支えるバックエンドのSRE部を執行役員として管掌している佐藤です。目下、ゲームカンパニー長が取りこぼしそうな仕事と、ゲームプロダクトのプロデューサー、SREを強化する取り組みが主務になっています。
SREを管掌するものとして、たまにはものを書けという突き上げを感じたので、今回はドリコムでのスクラムの広がりの話をしたいと思います。
いつの時代も、ウォーターフォールVSアジャイルみたいな議論がよくなされています。
個人的なスタンスとしては、プロジェクトがうまくいくのであれば、手法はなんでもよいと言う考え方ではありますが、短いプロジェクトや、作るプロダクトや目的がはっきりとしていて、ゴールや計画が変わりにくいものは、ウォーターフォール、長期的なプロジェクトや、作るプロダクトや計画への不確実性が高いものはアジャイルぐらいの感覚でいます。
ただ、アジャイルのほうが好きです。
スクラムガイドのアップデート
先日、スクラムガイドが3年ぶりにアップデートされました。今回のアップデートは、スクラムが世界に広まりつつも、「スクラムあるある」の一つであるスクラム自体の実践が目的化され、成果をあげることに集中できていない、ソフトウェア開発以外のドメインでも採用され始めていることなどを背景としたアップデート内容となっています。
主な項目は以下の通り、詳しくはスクラムガイド2020を参照ください。
- 指示的な部分を削減
- ひとつのチームがひとつのプロダクトに集中する
- プロダクトゴールの導入
- スプリントゴール、完成の定義、プロダクトゴールの居場所
- 自己組織化よりも自己管理
- スプリントプランニングの3つのトピック
- 幅広い読者のために全体的に文章を簡略化
ドリコムにおけるスクラムの浸透度
もともと、ドリコムでは、ゲーム系の開発も運用もほぼスクラムベース(カスタマイズしすぎてオレオレ手法になっているものも含む)でプロジェクト運営されていることが多かったのですが、ある時期からゲーム外にも広まりました。約3年前、enzaプラットフォームの開発開始当初に、これからどうやってプロジェクト運営していくか？という話になったとき、ちょうど当時のゲーム組織で、正しいスクラムを理解する人を増やして、組織的に理解度を高めようと動いていました。
スクラムを始めるときのセオリーは、アジャイルの考え方や、正しいスクラムを、チーム全員が理解することが大事です。
そのセオリーに則り、ゲーム組織の取り組みに乗っかる形で、プロダクトオーナーやスクラムマスターを担当するメンバーに社外のスクラム研修(すごく高い)を受けてもらい、共通の教科書をチームメンバーに読ませることから始めました。
プラットフォームの開発は、ゲームプロダクトに比べて、職種の細分化は激しくないことと、チームメンバーが前向きに取り組んだことにより、軌道に乗り、現在も割とstrictなスクラムに近い方法で運用されています。
私も、PO、スクラムマスター、Scrum@Scaleの研修を受け、たくさんのお金を会社に払ってもらったので、それを還元するべく当時100人以上いた組織全員に、社内のスクラム研修を行い、スクラムの理解を促進しました。
その動きから3年たち、プロダクト開発では当たり前のようにスクラムで始めることが標準的(これは強制ではなく、プロダクトがうまくいくためであれば原則何でもありです)になり、今年度から、ものを作る以外の部署でもスクラムを導入し始めました。
プロダクト開発以外での浸透
ここで、二人の人物が登場します。enzaと経営企画を統括しているK
PO歴3年、下支えタイプ。スクラムでのPOの経験を通して、リーダーとは何かを学ぶ。想像を超えた言い間違いや、書き間違いが多く、代表作は、「アントレプレナー」を「アントプランナー」、「Doneです」を 「Donです」、「ホワイトボード」を「ホワイトベース」。
普段は笑い話で済むが、たまに微妙な言い間違いをして、各所に間違って伝わることがあるが、人間力でカバーしている。
総務人事を統括しているF
PO歴6年、スクラムの浸透前から、スクラム実践者。POでありながら、担当のチームメンバーに様子を聞くとプロダクトバックログを書いているのを見たことないという情報が入った。
そんな前衛的なPO見たことないと本人に伝えると、誰でも書いていいって先生は言っていたし、優先順位付けはしている。
そもそも価値は提供できているとスクラムガイド2020でのスクラムのあり方を早期に体現している可能性がある。
この二人も3年前に、enza、ゲームプロダクトのPOとして、スクラム研修に参加し、正しいスクラムを学んでいます。
プロダクト開発でスクラムを実践した経験から、ソフトウェア開発以外でも適用できると判断し、現在管掌している部署でスクラムを導入して運用しています。
実際に導入してみて実践しているメンバーにヒアリングしてみました。
人事
- 事業部がほとんどスクラム導入しているので採用メンバーにとって現場との共通言語になりコミュニケーションコストが下がった（特にエンジニア）
- 小さいサイクルで改善を意識するフレームワークはプロダクトも人事も変わらず効果があった
- 扱う情報的に一人親方になる仕事が多く、複数人で1ストーリーというよりかは、担当者を決めることが多い
- プロダクト開発のような明確なアウトプットがないため、スプリントレビューに工夫が必要かも
この中でも、スクラムには振り返り(レトロスペクティブ)が、フレームワークとして、組み込まれているため、振り返りの習慣化と、改善活動しっかりとストーリー化することにより、普段の活動に改善活動を組み込みやすいというのが大きいようです。
経営企画
- チームでの業務がやり易くなった（これまで属人的でブラックボックスになりがち）
- ストーリーマッピングを皆で作成することで、今後半期くらいの時間軸でどういった優先度で何をやっていくのかの目線合わせができるようになった
- 意識してスウォーミングするストーリーを作ることで、リモートでも一緒に仕事をしていく環境をより作り易くなった
- ストーリーマッピングとあわせて成果物を社長などスクラムメンバー以外に共有しやすくなった
- 総じて個の出力から、チームでの出力になったことで実行力があがった
経営企画では、仕事の見える化が促進され、仕事を分業しやすい状態になり、実行力が上がったことが最大の効果であったようです。
スクラムのバイブルである「スクラム 仕事が４倍速くなる“世界標準”のチーム戦術」※1を読むと、ソフトウェア開発以外でも使えるフレームワークであることは理解はできるのですが、他社さんの話を聞くと、社内のエグゼクティブを始めとした社内の理解を得るのが難しかったり、スクラムやウォーターフォールは、ソフトウェア開発で使われる用語なので、なかなか浸透できないなどの話がよく上がります。
ドリコムでは、プロダクト側でスクラム採用しているという話を良くしているので、結果的に、ソフトウェア開発以外のビジネスドメインの人材にも割と抵抗なく受け入れられてるようです。
こうして、世界的に、ソフトウェア開発以外でも導入され始めている流れと同様に、3年前の取り組みがきっかけでドリコムでも浸透してきています。
これから
事業側、バックオフィスまで浸透しているスクラムですが、全社の課題解決にあたっている執行役員チームなど、まだ導入できていないチームは存在します。あくまで、ドリコムは事業会社です。
スクラムの実践が促進されたとしても、事業寄与が出来なければ意味はないので、積極的に導入という姿勢ではありませんが、執行役員チームの運営もスクラム化され、執行役員チームで作られたバックログを各部署につなぐ仕組みや設計まで実行できたら、Spotifyモデル※2相当のものが構築できるかもしれません。
また、折を見て、その後については、お話できればと思います。
※1「スクラム 仕事が４倍速くなる“世界標準”のチーム戦術」
プロジェクト管理法「スクラム」をケン・シュウェイバーとともに確立し、アジャイルソフトウェア開発宣言の執筆者の一人であるジェフ・サザーランドが書いた教科書。スクラムの考え方や、概念を学ぶのに一番適している。
※2 Spotifyモデル
スポティファイ・テクノロジー社が公開したアジャイル開発手法
https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify
今年に使ってないから、そのままは真似しないでという記事が公開されている
https://www.jeremiahlee.com/posts/failed-squad-goals/
明日の記事は 渡辺 祥二郎 さんの「【3Dディレクター＆アニメーター必見】 モーション工数大幅削減でこのプロジェクトを乗り切れ(ﾟДﾟ)2020」です。
ドリコムでは一緒に働くメンバーを募集しています！
募集一覧はコチラを御覧ください！
