スクラムで進めるシステムマイグレーション / Migration-by-Scrum

スクラムで進めるシステムマイグレーション

Transcript

1. © Chatwork Scrum Fest Osaka 2022 スクラムで進める システムマイグレーション プロダクト本部 都志 典晃 2022年06月18日
2. 自己紹介 2 Chatwork 株式会社 都志 典晃（つし のりあき） @louvre2489 • 元SIerからScalaエンジニアとして入社 • 2021/10からはマイグレーション開発のPOをやってます • PO初心者です
3. 今日お話すること 3 【お話すること】 1. スクラムでマイグレーション開発に取り組む理由 2. フィーチャーチーム化への過程で生じるコミュニケーションの難しさとその対処 3. PdMとPOの分担（代理PO化）について 【お話しないこと】 1. 効率の良いマイグレーション方法 2. 『PO ﾁｮｯﾄﾃﾞｷﾙ』になる方法
4. 4 組織とプロダクトの課題 マイグレーション開発の難しさ 組織変革期におけるコミュニケーション 1 2 3 AGENDA アジェンダ
5. 組織とプロダクトの課題
6. 組織とプロダクトの課題 6 現在、Chatworkでは組織とプロダクトの両面で課題を抱えています 組織 • プロジェクトベースの開発体制のため、チームビルディングが毎回必要となる • プロジェクトベースの開発体制による知識の属人化（この部分は〇〇さんが詳しいよ） • 結果として、網羅的に仕様を把握している人が超貴重人材となる プロダクト • 積み上がった技術負債 • 負債を返そうにも、網羅的に仕様を把握している人が少数で手を出すのが困難 • そして、負債を返せずに負債の上に機能を積み上げる...
7. 組織とプロダクトの課題 7 現在、Chatworkでは組織とプロダクトの両面で課題を抱えています 組織 • プロジェクトベースの開発体制のため、チームビルディングが毎回必要となる • プロジェクトベースの開発体制による知識の属人化（この部分は〇〇さんが詳しいよ） • 結果として、網羅的に仕様を把握している人が超貴重人材となる プロダクト • 積み上がった技術負債 • 負債を返そうにも、網羅的に仕様を把握している人が少数で手を出すのが困難 • そして、負債を返せずに負債の上に機能を積み上げる...
8. 組織とプロダクトの課題 8 現在、Chatworkでは組織とプロダクトの両面で課題を抱えています 組織 • プロジェクトベースの開発体制のため、チームビルディングが毎回必要となる • プロジェクトベースの開発体制による知識の属人化（この部分は〇〇さんが詳しいよ） • 結果として、網羅的に仕様を把握している人が超貴重人材となる プロダクト • 積み上がった技術負債 • 負債を返そうにも、網羅的に仕様を把握している人が少数で手を出すのが困難 • そして、負債を返せずに負債の上に機能を積み上げる... 組織と、そこから生まれるプロダクト には密接な関係がある
9. 組織とプロダクトの課題 9 両者には密接な関係があるので、 組織／プロダクトの課題をそれぞれ解消する のではなく 組織／プロダクトを紐付けて課題を解消しなければならない 詳細は、弊社ブログ：Chatworkのリライトプロジェクトをやっている をご覧ください
10. 逆コンウェイの法則を利用して理想的なプロダクト構成へ 10 組織とプロダクトの課題 ① 理想的なシステムのカタチに合わせた機能別チームを構築し、 ② それらのチームが自チームの機能に手を加える 認証チーム 認証サービス 機能を独立したサービスに 分割／連携させてChatworkを構成する コンウェイの法則：システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう チャットチーム チャットサービス 決済チーム 決済サービス チームは自分たちのサービスを 責任を持って開発する 逆コンウェイの法則：コンウェイの法則を逆手に取って、最終的に実現したいシステムの形に合わせて組織を構築する
11. コンウェイの法則：システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう 逆コンウェイの法則：コンウェイの法則を逆手に取って、最終的に実現したいシステムの形に合わせて組織を構築する 『機能』にフォーカスしたチーム ≒ フィーチャーチームを目指す 参考URL：https://featureteams.org/jp/ 逆コンウェイの法則を利用して理想的なプロダクト構成へ 11 組織とプロダクトの課題 ① 理想的なシステムのカタチに合わせた機能別チームを構築し、 ② それらのチームが自チームの機能に手を加える 認証チーム 認証サービス チャットチーム チャットサービス 決済チーム 決済サービス チームは自分たちのサービスを 責任を持って開発する 機能を独立したサービスに 分割／連携させてChatworkを構成する
12. 現在行っている組織の変革 12 網羅的に仕様把握 している人の不足 プロジェクトごとの 関係性構築 フィーチャー チーム 【前提】 チームは解散しない ① 『人』ではなく『チーム』で 詳細な仕様を把握している 知識の属人化 ② チームメンバーの 関係性が継続される 現在感じている課題 理想の状態 有識者不足の解消 組織とプロダクトの課題 チームビルディング の必要性を最小化
13. 現在行っているプロダクトの変革 13 網羅的に仕様把握 している人の不足 積み上がった 技術負債 システムの再構築 ① 自チームの扱うサービスの 詳細な仕様を把握している ② 技術負債の返却 現在感じている課題 理想の状態 チーム結成序盤はチームに知識が無いので、 業務仕様に精通した人にもチームに加入してもらう 現在、対象機能のマイグレーション中 現在行っている開発は、ビッグバンリリースせざるを得ない事情があるため、 以降の話は、それを前提としてお聞きください。 フィーチャーチームごとに サービスを構築 組織とプロダクトの課題
14. マイグレーション開発の難しさ
15. マイグレーション開発の難しさ 15 マイグレーションってなんだっけ？ 既存システムを異なる環境で動作させるための開発作業のこと • 言語やプラットフォーム等、保守が困難になった要素を新しいものに変更する • その際に、要求や仕様は原則変更しない ◦ ただし、新環境の仕様により既存仕様が実現できない等、何らかの変更が入ることはある 私たちのチームは、フルスクラッチの現行機能を他サービスに載せ替えることを選択
16. 16 マイグレーション開発の難しさ マイグレーションって既に存在する機能を開発するんだし、 スクラムなんてする必要ないんじゃないの？ いえいえ、 マイグレーションでもスクラムする価値があるんですよ！
17. 17 一般的な機能開発において生じる不確実性 『エンジニアリング組織論への招待』より： マイグレーション開発の難しさ 開発の目的が妥当であるか （ユーザー課題を解決できるか）が不確実 正しくコミュニケーションができているか （認識齟齬がないか）が不確実 実現したいコトの実現方法が不確実 方法不確実性 通信不確実性 目的不確実性
18. マイグレーション開発において生じる不確実性 これで本当にユーザーは課題を解決する ことができるんだろうか？ 18 マイグレーション開発の難しさ ※ ケースバイケースなので一概には言えません • 価値が立証されて現行システムに残っている機能がマイグレーション対象 • マイグレーションにおいて目的（≒ 要求）の変更は原則変更しない →目的不確実性が問題になる頻度は低いと言えそう
19. マイグレーション開発において生じる不確実性 Devチームが作ってレビュー会に出してきたものが、 POがイメージしていたものと違う... 19 マイグレーション開発の難しさ • マイグレーションでは、仕様変更が発生する箇所は限定的 • 仕様が変更されなければ、作るモノに対する認識齟齬は生じにくい →一般的な開発よりも通信不確実性が発生する可能性は少ないと言えそう ただし、チーム内のコミュニケーションも一種の通信不確実性であり、これは変わらず発生する デイリーで今日の進め方を調整したはずなのに、 何か微妙に認識齟齬が発生してない...？ ※ ケースバイケースなので一概には言えません
20. マイグレーション開発において生じる不確実性 20 マイグレーション開発の難しさ ※ ケースバイケースなので一概には言えません 現行仕様を踏襲したいのに、 踏襲したい仕様がインフラの制約で実現できない... 想定していたよりも開発の進行が良くない！ これじゃあリリース予定に間に合わない！！！ • 新しい環境で現行仕様を可能な限り維持するための試行錯誤 ◦ 『現行仕様を維持しなければならない』という縛りが発生することも • いかなる開発でも切り離すことのできないスケジュール不安 →開発では常に方法不確実性が発生する
21. 21 • マイグレーション開発でも不確実なことは色々ある • 不確実のことが多い ＝ 難しい • つまり、マイグレーション開発も難しい • 難しいことを行うのは不安なので、工夫を持って立ち向かいたい マイグレーション開発の難しさ マイグレーション以外の開発ももちろん難しいので、そもそもシステム開発というモノ自体がむずかしい...
22. 22 マイグレーション開発において生じる不確実性 これらの不確実性に起因する不安に向き合うためのフレームワークとしてスクラム • 方法不確実性に対する思考錯誤のサイクルを細かく回す ◦ 不安を細分化して、スプリントごとにプランニングする ◦ デイリースクラムで日々の軌道修正を行う • 振る舞いが変わる場合は、細かいサイクルで会話を行い通信不確実性を解消する ◦ スプリントレビューの活用 • チーム内のコミュニケーションミス（＝通信不確実性）を小さくして、開発体験を向上する ◦ スプリントレトロスペクティブの実施 • これらを通して、開発完了時期に対する不安（＝方法不確実性）を小さくしていく ◦ 参考：アジャイル開発におけるスケジュールを継続的に見直す マイグレーション開発の難しさ ※ 互換性が担保されている場合など、不確実性が小さい場合はもう少し異なるアプローチもあるかもしれません
23. 23 マイグレーション開発において生じる不確実性 これらの不確実性に起因する不安に向き合うためのフレームワークとしてスクラム • 方法不確実性に対する思考錯誤のサイクルを細かく回す ◦ 不安を細分化して、スプリントごとにプランニングする ◦ デイリースクラムで日々の軌道修正を行う • 振る舞いが変わる場合は、細かいサイクルで会話を行い通信不確実性を解消する ◦ スプリントレビューの活用 • チーム内のコミュニケーションミス（＝通信不確実性）を小さくして、開発体験を向上する ◦ スプリントレトロスペクティブの実施 • これらを通して、開発完了時期に対する不安（＝方法不確実性）を小さくしていく ◦ 参考：アジャイル開発におけるスケジュールを継続的に見直す マイグレーション開発の難しさ ※ 互換性が担保されている場合など、不確実性が小さい場合はもう少し異なるアプローチもあるかもしれません
24. 24 マイグレーション開発において生じる不確実性 これらの不確実性に起因する不安に向き合うためのフレームワークとしてスクラム • 方法不確実性に対する思考錯誤のサイクルを細かく回す ◦ 不安を細分化して、スプリントごとにプランニングする ◦ デイリースクラムで日々の軌道修正を行う • 振る舞いが変わる場合は、細かいサイクルで会話を行い通信不確実性を解消する ◦ スプリントレビューの活用 • チーム内のコミュニケーションミス（＝通信不確実性）を小さくして、開発体験を向上する ◦ スプリントレトロスペクティブの実施 • これらを通して、開発完了時期に対する不安（＝方法不確実性）を小さくしていく ◦ 参考：アジャイル開発におけるスケジュールを継続的に見直す マイグレーション開発の難しさ ※ 互換性が担保されている場合など、不確実性が小さい場合はもう少し異なるアプローチもあるかもしれません
25. 25 マイグレーション開発において生じる不確実性 これらの不確実性に起因する不安に向き合うためのフレームワークとしてスクラム • 方法不確実性に対する思考錯誤のサイクルを細かく回す ◦ 不安を細分化して、スプリントごとにプランニングする ◦ デイリースクラムで日々の軌道修正を行う • 振る舞いが変わる場合は、細かいサイクルで会話を行い通信不確実性を解消する ◦ スプリントレビューの活用 • チーム内のコミュニケーションミス（＝通信不確実性）を小さくして、開発体験を向上する ◦ スプリントレトロスペクティブの実施 • これらを通して、開発完了時期に対する不安（＝方法不確実性）を小さくしていく ◦ 弊社ブログ：アジャイル開発におけるスケジュールを継続的に見直す マイグレーション開発の難しさ ※ 互換性が担保されている場合など、不確実性が小さい場合はもう少し異なるアプローチもあるかもしれません
26. 組織変革期におけるコミュニケーション
27. 逆コンウェイの法則を利用して理想的なプロダクト構成へ 27 組織変革期におけるコミュニケーション ① 理想的なシステムのカタチに合わせた機能別チームを構築し、 ② それらのチームが自チームの機能に手を加える 認証チーム 認証サービス チャットチーム チャットサービス 決済チーム 決済サービス チームは自分たちのサービスを 責任を持って開発する 再掲 現在は変革の過渡期にある 機能を独立したサービスに 分割／連携させてChatworkを構成する
28. 現在の私たちを取り巻く人たち... 28 私たちのチーム （フィーチャーチーム） プロジェクトチーム PO 職能別チーム （Scala部、PHP部、モバイル部、などなど） Devメンバー PdM 現行システムのことは職能別チームが詳しい マイグレーションによる機能変更が発生する場合はPdM判断が必要 変革の過渡期にあるので、フィーチャーチーム以外にも色々な人物／チームが存在 プロジェクトメンバーは 職能別チームから招集される PjM プロジェクト内で、 マイグレーション中の機能に 手が入る 組織変革期におけるコミュニケーション
29. 現在の私たちを取り巻く人たち... 29 私たちのチーム （フィーチャーチーム） プロジェクトチーム PO 職能別チーム （Scala部、PHP部、モバイル部、などなど） Devメンバー PdM そこの仕様のことなら 聞いてくれたらすぐ答えれたのに... え？ そんな機能変更が発生するの？その変更内容はマズいよ... コミュニケーションを疎かにすると... PjM フィーチャーチームの 成果物をリリースする時に 盛大に発生するデグレード 組織変革期におけるコミュニケーション
30. 組織変革期におけるコミュニケーション 30 関わるチーム／人が多くなるとコミュニケーションも複雑になり不確実性も増す 自チームとチーム外（非スクラムチームを含む）の コミュニケーションを整理する必要がある 最終的に目指しているカタチについては、弊社ブログ：ChatworkにおけるScrum@Scale導入への挑戦 をご覧ください そのためには、定期的にご近所さんを明確にする必要もある
31. コミュニケーション不足による事故を回避するためのアクション 31 プロジェクトチーム PO Devメンバー チャットで不明な部分を詳しい人に相談 わからない部分は相談する！ コミュニケーションと知識移転の交通整理 PjM 職能別チーム （Scala部、PHP部、モバイル部、などなど） 私たちのチーム （フィーチャーチーム） 組織変革期におけるコミュニケーション PdM
32. コミュニケーション不足による事故を回避するためのアクション 32 プロジェクトマネージャーと定期的に会話 機能レベルでの変更を漏れなくPBIに追加する マイグレーションによる変更箇所とバッティングしていたら対応方針を相談 プロジェクトチーム PO Devメンバー PdM コミュニケーションと知識移転の交通整理 PjM 職能別チーム （Scala部、PHP部、モバイル部、などなど） 私たちのチーム （フィーチャーチーム） 組織変革期におけるコミュニケーション
33. コミュニケーション不足による事故を回避するためのアクション 33 プロジェクトチーム 細かい仕様の認識合わせ 細かい実装仕様レベルの変更はDevメンバー同士で 行ってもらって情報整理し、 マイグレーション先にも反映できるようにする。 また、マイグレーション都合で既存仕様を変更する 場合は、周囲のチームに発信してもらう。 PO Devメンバー コミュニケーションと知識移転の交通整理 PjM 職能別チーム （Scala部、PHP部、モバイル部、などなど） 私たちのチーム （フィーチャーチーム） 組織変革期におけるコミュニケーション PdM
34. コミュニケーション不足による事故を回避するためのアクション 34 プロジェクトチーム PO Devメンバー PdM PdMと定期的に会話 現行踏襲が困難な機能／仕様に対する変更の相談を行う。 コミュニケーションと知識移転の交通整理 PjM 職能別チーム （Scala部、PHP部、モバイル部、などなど） 私たちのチーム （フィーチャーチーム） 組織変革期におけるコミュニケーション
35. ところで、先ほどの説明で疑問を持った人もいるかも... 35 PO Devメンバー PdMとPOは別人？ 私たちのチーム （フィーチャーチーム） 組織変革期におけるコミュニケーション PdM
36. 本来PdM責務とPO責務は密接に関連するものなので、同一人物が担うとスムーズになる。 PdM責務／PO責務を別の人に割り当てることによって意思決定権の無いPO（つまり、今 の私の状態）になってしまう。 このようなPOの状態を代理POという。 以下のブログでは代理POに否定的に説明されているが、私たちの場合は組織もプロダクト も移行の過渡期にあるため一時的な役割として代理POを置いている。 参考ブログ：What is a "Proxy" Product Owner? Why it is found so often? 36 組織変革期におけるコミュニケーション (https://www.scrum.org/resources/blog/what-proxy-product-owner-why-it-found-so-often)
37. PdM（プロダクトマネージャー）の担う責務： • プロダクトビジョンの明確化 • プロダクト課題の整理とソリューションの深堀り • プロダクト戦略に対する意思決定 • などなど PO（プロダクトオーナー）の担う責務： • プロダクトビジョンの実現 • 関係者（Devチーム、PdMなど）とのコラボレーション ◦ スクラムイベント等 • などなど 37 ビッグバンリリースが前提でなければ 責務を果たす余地はありそうなんだけど。。。 マイグレーションでは要求／仕様は原則変化しない。 そのため、この責務を果たせる要素が少ない。 組織変革期におけるコミュニケーション
38. PdM（プロダクトマネージャー）の担う責務： • プロダクトビジョンの明確化 • プロダクト課題の整理とソリューションの深堀り • プロダクト戦略に対する意思決定 • などなど PO（プロダクトオーナー）の担う責務： • プロダクトビジョンの実現 • 関係者（Devチーム、PdMなど）とのコラボレーション ◦ スクラムイベント等 • などなど 38 こちらはマイグレーション時にも発生する。 組織変革期におけるコミュニケーション
39. 代理POをどう解消していくのか？ わかりやすい選択肢 1. 組織／プロダクトが安定したタイミングで、PdMがPOを担う 2. 代理POがPdM責務も果たせるようにレベルアップする 変革の過渡期が過ぎたら代理PO問題は解消して、コミュニケーションをシンプルにしたい 39 組織変革期におけるコミュニケーション
40. • マイグレーション開発も難しい • 難しさの原因はそれぞれの開発における『不確実性』にある • 不確実性からくる不安と戦うためにスクラムを有効活用する 40 まとめ マイグレーションでもスクラムする価値がありますよ！ 状況に応じて非スクラムチームとのコミュニケーションも 必要になるので、そのあたりは（当然だけど）柔軟に！
41. 最後に：一緒に開発チームを作ってくれる方々を募集しています 41 エンジニア(オープンポジション) | Chatwork株式会社 コチラからもアクセス可！
42. 働くをもっと楽しく、創造的に