こんにちは。ソリューション開発部 認定スクラムマスターの羽澤です。

開発業務を行なっていると別のチームがどのように作業を進めているか、知りたいと思うことってありますよね?

私は今、お客様(株式会社D2C様)の元でスクラム開発を行なっております。その中でどう改善していくかなど日々考えていますが、他のスクラムチームはどのような進め方をしているか、とても気になっています。今回、他のスクラムチームとの交流会を開催し、お互いに作業を見学し合うこととなりましたので紹介したいと思います。

発端

スクラム交流を行うキッカケは、別のお客様(株式会社アプレッソ様)の元でスクラム開発を実践している弊社メンバーとの情報交換からでした。お互いの悩みや問題点などについて話し合った後、「他のスクラムチーム見てみたいよね」という話になり、交流会を企画・実現したという流れとなります。快諾して頂いた両社に大変感謝致します。

それぞれの企業について

今回はアプレッソ様のスクラムチームを見学させて頂きました。アプレッソ様のチームでは、DataSpider ServistaというEAIパッケージ製品を開発しており、弊社社員がスクラムチームに参加しています。

アプレッソ開発部の土岐です。最近メインDAWをAbleton LiveからPresonus Studio Oneに移行中です(ニッチな話)。 というわけでAppresso Advent Calendarの2日目! ということで今回は「スプリント1週間」について書きます。 qiita.com はじめに DataSpider Servista...

D2C様のチームでは広告配信システムの保守開発を行なっております。D2C様でも弊社社員がスクラムチームに参加し、私もメンバーの1人です。なお、D2C様におけるスクラム開発事例については過去の記事を参照して下さい。

こんにちは。ソリューション開発部 認定スクラムマスターの飯出(いいで)です。先日、ソリューション開発部におけるスクラムへの取り組みを紹介しましたが、今回はスクラム開発の実例を紹介します。スクラム開発とは何か。につきましては、下記の記事をご覧ください。...

フロアに入ってすぐの衝撃

当日、フロアに入ってすぐ目についたのが、スクラムボードでした。またスクラムボードの前にはペンや付箋紙が沢山用意してあり、スクラムのためのスペースだと一目でわかりました。

D2C様のチームでもスクラムボードはありますが、壁全体を使うことは出来ておらず、大きめのホワイトボードで代用している状況です。このように壁全体を使って大きくスペースを取れることに対し、とても羨ましく感じました。

スクラムボードに貼られている付箋の色にも意味があるようで、計画と追加タスク(外的要因ではなく、想定より作業項目が増えた、もしくは作業時間が掛かった)などを色分けして振り返りの際に利用しているとのでした。D2C様のチームも追加タスク数はカウントしていますが、こちらの方がパッと見てわかるため真似させて頂くことにしました。

壁にはスクラムボードが貼られています。 

PBI目安箱

面白いと思ったのがプロダクトバックログアイテム(PBI)目安箱です。開発チームからの改善案など、PBIとして検討して欲しいものが付箋に書かれた状態で箱に貼られていました。開発チームから改善案が出ることは珍しくありませんが、目安箱にしておくことで気軽に自分のタイミングで残せる点が良く、すぐにでも真似したい試みでした。

アナログでの運用

PBIも全て紙に書かれておりました。課題管理システムのようなものは利用していないのか質問したところ、課題管理システムはあるが、今はアナログで試しているとの回答を頂きました。

アナログのデメリットとして、検索できない不便さや別のオフィスやフロアに対して共有したい場合に見えないことが挙げられていました。しかしメリットとして、関連するPBIがまとめて並んでいるため視認性が高く、関連がわかりやすいなどの点も感じるため、今はアナログで作業をしてみているという事です。

プロダクトバックログアイテムもすべてアナログで運用しています。

体制の違い

アプレッソ様でプロダクトオーナー(PO)を担当している方は、過去にプログラマとしてDataSpiderの開発を行なってきた方とのことでした。つまり、製品と技術に対する知識が深い方がPOをしているということです。

一方D2C様では、実際に業務を行なっている方もPOを担当しております。技術に対する知識は少ないものの、業務を知り尽くしている方です。現在は技術に対する知識を持つ方とあわせて3名体制で担当しています。

アプレッソ様ではパッケージ製品開発、D2C様では業務(事業)向けソフトウェア開発とPOが持つ背景の違いがどう出るか、一番興味を持っていた点でした。

見学したセレモニー

1日だけの見学でしたがスクラムにおけるセレモニーが詰め込まれています。

  • デイリースクラム
  • スプリントレビュー
  • ふりかえり(スプリントレトロスペクティブ)
  • プロダクトバックログリファインメント(PBR)
  • スプリントプランニング
  • 夕会(アプレッソ様独自)

私が「セレモニー、特にプロダクトバックログリファインメント(PBR)を見たい」と伝えていたため、普段のサイクルを変更して1日にまとめて下さったようです。大変ありがたいお心遣いでした。本当にありがとうございます!

スプリントレビュー

アプレッソ様のセレモニーで一番面白かったのがスプリントレビューです。スプリントレビューが1部と2部に分かれていたためです。伺った全員がそこに注目していました。

スプリントレビュー 1部

1部は、ステークホルダーを含めた関係者全員に対するデモでした。フロアにいらっしゃった方のほぼ全員が参加し、デモを見て質問していたように思います。D2C様のチームでは主にPOに対してスプリントレビューを行い、ステークホルダーの参加は稀ですので新鮮でした。ただこれは、前述した体制の違いによるものと考えています。

D2C様のスクラムチームにおけるPOは業務を行なっているメンバーですので、POへのデモがステークホルダーへのデモとほぼ同義となります。他のステークホルダーも必要に応じてお呼びしているので、実質同じことを行なっているのだなと理解しました。

スプリントレビュー 2部

2部ではスクラムチームのみでのレビューです。このスプリントで修正した箇所をスクラムチームだけで操作し、使いにくい点や気づいた点を共有、必要に応じてPBI化を行なっていました。この試みはとても新鮮でした。D2C様のチームでは、振り返りなどでプロセスの改善を行うことはあっても、成果物に対する振り返りはあまりしていなかったように思います。この点も取り入れていきたいと思います。

プロダクトバックログリファインメント(PBR)

PBRでは体制の違いが大きく出ていました。アプレッソ様のチームではPOが1名であることと、POが技術知識があるという点から以下のような特徴がありました。

  • PBIの分割がかなり細かく行われている
  • PO同士での優先度調整が不要

D2C様のチームではPOの技術知識はそれほど高くありません。よって巨大なPBIを目にすることがありました。それがアプレッソ様では存在せず、粛々とストーリーポイントによる見積りを行なっている印象でした。

D2C様でのPBRは開発チームが参加せず、POだけの意思決定・優先度調整の場でした。これはこれで必要な作業ではありますが、スプリントプランニングの前にポイント見積りが完了しないため、スプリントプランニングまで来ないと大きさがわからないという問題点がありました。PBIの優先度を決める際、開発の規模を判断基準にできないのです。

最近、D2C様のPOもこの問題を感じ始めていたところでしたので、今後は開発チームもPBRに参加するようにカイゼンしていきたいと思います。

スプリントプランニング

ここも大きく異なる点でした。アプレッソ様ではPOから開発チームへのPBI説明は行われません。PBRで説明が完了しているためですね。D2C様のチームではPBRに開発チームが参加していないため、POからの説明と見積りはスプリントプランニングで行っています。

アプレッソ様のスプリントプランニング1部では、POが決めた優先度に対し開発チームが意見を出していたのが印象的でした。「その作業を行うなら先にこちらを実装した方が効率が良い」というような意見を開発チームが提示し、それを元にPOが優先度を変更する形です。D2C様のチームではPOが決めた優先度に従うだけでしたのでとても新鮮に感じました。

夕会

今日やった作業を共有し、その日の作業の締めとなります。セレモニーで定義されているものではありませんが、体調を崩して休んでしまうと作業状況が共有されないという問題点を改善するために始めたとのことで、大変良い試みだなと感じました。休んでしまった場合だけでなく、少し作業が遅れると残業で作業をカバーしてしまうメンバーが出てくるものですが、夕会で共有すれば他のメンバーが助けることも可能です。D2C様のチームでも早速取り入れました!

終わりに

見学の合間に、アプレッソ様でスクラムを推進している方とお話させて頂きましたが、新しいものはすぐに取り入れたり思い立ったらすぐに試すなど、自分達には出来ていないことを実践している様子を見て、頑張らねばという気持ちになりました。D2C様のチームでも今以上に社内全体を巻き込んで実績を残し、色々なトライが出来るように努力しなければなりません。

1日セレモニーを見学させて頂きましたが、やはりPOの立場の違いが大きく出ていたと思います。D2C様のチームは保守開発を行っているため、システムの改善要望を業務メンバーから直接伺っています。そのため各サブシステムごとにPOを立てるという施策を行いました。POが複数人いることで、PO間での優先度調整が必要になってしまうものの、業務メンバーの声が直接届く良さがあります。業務メンバーがボソっとつぶやいた一言が重要だったりすることってありますよね。そのような細かい声が開発チームに届く環境であることは、D2C様のスクラムチームの良さであると考えています。

このようなメリットとデメリットを天秤にかけながら、今後の体制やチーム作りについて悩んでいる最中です。改善に取り組んだ後、今度はアプレッソ様にD2C様のスクラムを見ていただき、刺激を与えられるよう頑張りたいと思います。

 

この記事が気に入ったら
いいね!しよう

最新情報をお届けします

Twitter で「株式会社アークシステム」をフォローしよう!

スクラム交流会開催!他社のスクラム開発を見てみませんか?https://devlog.arksystems.co.jp/wp-content/uploads/2017/10/appresso-1200x630.jpghttps://devlog.arksystems.co.jp/wp-content/uploads/2017/10/appresso-150x150.jpghazawaソリューション開発部開発・導入事例スクラム開発カイゼン,開発事例,スクラム開発こんにちは。ソリューション開発部 認定スクラムマスターの羽澤です。 開発業務を行なっていると別のチームがどのように作業を進めているか、知りたいと思うことってありますよね? 私は今、お客様(株式会社D2C様)の元でスクラム開発を行なっております。その中でどう改善していくかなど日々考えていますが、他のスクラムチームはどのような進め方をしているか、とても気になっています。今回、他のスクラムチームとの交流会を開催し、お互いに作業を見学し合うこととなりましたので紹介したいと思います。 発端 スクラム交流を行うキッカケは、別のお客様(株式会社アプレッソ様)の元でスクラム開発を実践している弊社メンバーとの情報交換からでした。お互いの悩みや問題点などについて話し合った後、「他のスクラムチーム見てみたいよね」という話になり、交流会を企画・実現したという流れとなります。快諾して頂いた両社に大変感謝致します。 それぞれの企業について 今回はアプレッソ様のスクラムチームを見学させて頂きました。アプレッソ様のチームでは、DataSpider ServistaというEAIパッケージ製品を開発しており、弊社社員がスクラムチームに参加しています。D2C様のチームでは広告配信システムの保守開発を行なっております。D2C様でも弊社社員がスクラムチームに参加し、私もメンバーの1人です。なお、D2C様におけるスクラム開発事例については過去の記事を参照して下さい。フロアに入ってすぐの衝撃 当日、フロアに入ってすぐ目についたのが、スクラムボードでした。またスクラムボードの前にはペンや付箋紙が沢山用意してあり、スクラムのためのスペースだと一目でわかりました。 D2C様のチームでもスクラムボードはありますが、壁全体を使うことは出来ておらず、大きめのホワイトボードで代用している状況です。このように壁全体を使って大きくスペースを取れることに対し、とても羨ましく感じました。 スクラムボードに貼られている付箋の色にも意味があるようで、計画と追加タスク(外的要因ではなく、想定より作業項目が増えた、もしくは作業時間が掛かった)などを色分けして振り返りの際に利用しているとのでした。D2C様のチームも追加タスク数はカウントしていますが、こちらの方がパッと見てわかるため真似させて頂くことにしました。   PBI目安箱 面白いと思ったのがプロダクトバックログアイテム(PBI)目安箱です。開発チームからの改善案など、PBIとして検討して欲しいものが付箋に書かれた状態で箱に貼られていました。開発チームから改善案が出ることは珍しくありませんが、目安箱にしておくことで気軽に自分のタイミングで残せる点が良く、すぐにでも真似したい試みでした。アナログでの運用 PBIも全て紙に書かれておりました。課題管理システムのようなものは利用していないのか質問したところ、課題管理システムはあるが、今はアナログで試しているとの回答を頂きました。 アナログのデメリットとして、検索できない不便さや別のオフィスやフロアに対して共有したい場合に見えないことが挙げられていました。しかしメリットとして、関連するPBIがまとめて並んでいるため視認性が高く、関連がわかりやすいなどの点も感じるため、今はアナログで作業をしてみているという事です。体制の違い アプレッソ様でプロダクトオーナー(PO)を担当している方は、過去にプログラマとしてDataSpiderの開発を行なってきた方とのことでした。つまり、製品と技術に対する知識が深い方がPOをしているということです。 一方D2C様では、実際に業務を行なっている方もPOを担当しております。技術に対する知識は少ないものの、業務を知り尽くしている方です。現在は技術に対する知識を持つ方とあわせて3名体制で担当しています。 アプレッソ様ではパッケージ製品開発、D2C様では業務(事業)向けソフトウェア開発とPOが持つ背景の違いがどう出るか、一番興味を持っていた点でした。 見学したセレモニー 1日だけの見学でしたがスクラムにおけるセレモニーが詰め込まれています。デイリースクラム スプリントレビュー ふりかえり(スプリントレトロスペクティブ) プロダクトバックログリファインメント(PBR) スプリントプランニング 夕会(アプレッソ様独自)私が「セレモニー、特にプロダクトバックログリファインメント(PBR)を見たい」と伝えていたため、普段のサイクルを変更して1日にまとめて下さったようです。大変ありがたいお心遣いでした。本当にありがとうございます! スプリントレビュー アプレッソ様のセレモニーで一番面白かったのがスプリントレビューです。スプリントレビューが1部と2部に分かれていたためです。伺った全員がそこに注目していました。 スプリントレビュー 1部 1部は、ステークホルダーを含めた関係者全員に対するデモでした。フロアにいらっしゃった方のほぼ全員が参加し、デモを見て質問していたように思います。D2C様のチームでは主にPOに対してスプリントレビューを行い、ステークホルダーの参加は稀ですので新鮮でした。ただこれは、前述した体制の違いによるものと考えています。 D2C様のスクラムチームにおけるPOは業務を行なっているメンバーですので、POへのデモがステークホルダーへのデモとほぼ同義となります。他のステークホルダーも必要に応じてお呼びしているので、実質同じことを行なっているのだなと理解しました。 スプリントレビュー 2部 2部ではスクラムチームのみでのレビューです。このスプリントで修正した箇所をスクラムチームだけで操作し、使いにくい点や気づいた点を共有、必要に応じてPBI化を行なっていました。この試みはとても新鮮でした。D2C様のチームでは、振り返りなどでプロセスの改善を行うことはあっても、成果物に対する振り返りはあまりしていなかったように思います。この点も取り入れていきたいと思います。 プロダクトバックログリファインメント(PBR) PBRでは体制の違いが大きく出ていました。アプレッソ様のチームではPOが1名であることと、POが技術知識があるという点から以下のような特徴がありました。PBIの分割がかなり細かく行われている PO同士での優先度調整が不要D2C様のチームではPOの技術知識はそれほど高くありません。よって巨大なPBIを目にすることがありました。それがアプレッソ様では存在せず、粛々とストーリーポイントによる見積りを行なっている印象でした。 D2C様でのPBRは開発チームが参加せず、POだけの意思決定・優先度調整の場でした。これはこれで必要な作業ではありますが、スプリントプランニングの前にポイント見積りが完了しないため、スプリントプランニングまで来ないと大きさがわからないという問題点がありました。PBIの優先度を決める際、開発の規模を判断基準にできないのです。 最近、D2C様のPOもこの問題を感じ始めていたところでしたので、今後は開発チームもPBRに参加するようにカイゼンしていきたいと思います。 スプリントプランニング ここも大きく異なる点でした。アプレッソ様ではPOから開発チームへのPBI説明は行われません。PBRで説明が完了しているためですね。D2C様のチームではPBRに開発チームが参加していないため、POからの説明と見積りはスプリントプランニングで行っています。 アプレッソ様のスプリントプランニング1部では、POが決めた優先度に対し開発チームが意見を出していたのが印象的でした。「その作業を行うなら先にこちらを実装した方が効率が良い」というような意見を開発チームが提示し、それを元にPOが優先度を変更する形です。D2C様のチームではPOが決めた優先度に従うだけでしたのでとても新鮮に感じました。 夕会 今日やった作業を共有し、その日の作業の締めとなります。セレモニーで定義されているものではありませんが、体調を崩して休んでしまうと作業状況が共有されないという問題点を改善するために始めたとのことで、大変良い試みだなと感じました。休んでしまった場合だけでなく、少し作業が遅れると残業で作業をカバーしてしまうメンバーが出てくるものですが、夕会で共有すれば他のメンバーが助けることも可能です。D2C様のチームでも早速取り入れました! 終わりに 見学の合間に、アプレッソ様でスクラムを推進している方とお話させて頂きましたが、新しいものはすぐに取り入れたり思い立ったらすぐに試すなど、自分達には出来ていないことを実践している様子を見て、頑張らねばという気持ちになりました。D2C様のチームでも今以上に社内全体を巻き込んで実績を残し、色々なトライが出来るように努力しなければなりません。 1日セレモニーを見学させて頂きましたが、やはりPOの立場の違いが大きく出ていたと思います。D2C様のチームは保守開発を行っているため、システムの改善要望を業務メンバーから直接伺っています。そのため各サブシステムごとにPOを立てるという施策を行いました。POが複数人いることで、PO間での優先度調整が必要になってしまうものの、業務メンバーの声が直接届く良さがあります。業務メンバーがボソっとつぶやいた一言が重要だったりすることってありますよね。そのような細かい声が開発チームに届く環境であることは、D2C様のスクラムチームの良さであると考えています。 このようなメリットとデメリットを天秤にかけながら、今後の体制やチーム作りについて悩んでいる最中です。改善に取り組んだ後、今度はアプレッソ様にD2C様のスクラムを見ていただき、刺激を与えられるよう頑張りたいと思います。ARK Solution Development Division Developers Blog.