こんにちは。GameWithのエンジニアのtiwu(Taguchi Wataru)です。
今回は自分が携わっているMangaWithの開発が始まって約1年経ったので、チーム開発について振り返っていきたいと思います。
※このブログは4月に書かれたものです
目次
MangaWithとは
MangaWithは15万点以上のマンガを配信・販売するスマートフォン向け WEB マンガサービスです。
最大の特徴は、マンガの購入や閲覧など特定の条件をクリアした特典としてゲームアイテムが手に入る「ゲームアイテム付きマンガ」です。
利用している技術についてはこちらの記事をご覧ください。
MangaWith年表
インフラエンジニアはGameWithも見ているためMangaWithフルコミットではありません。
そのため、後述するスクラム体制はインフラエンジニアを除くメンバーで組んでいます。
自分は7月にJOINしました。今思うとメンバー多くなったなと感じます。
リリース直前にフレームワークをLumenからLaravelに変更するといった事件もありました（笑）
事件の内容はLaravel JP Conferenceで詳しく解説しています。
MangaWithの開発開始
12月にリリースを目指し、開発は6月から始まりました。
開発当初はMangaWithの構想が決まっており、仕様等は全く決まっていませんでした。
そのため、最初はインフラをどうするか、フレームワークをどうするか、CI/CD環境の作成、カバレッジ環境の作成、利用する外部サービスの調査等を進めていました。
開発のスタイルは
- タスクをGitHubのIssueで管理し、GitHubのProjectsを利用して管理
- エンジニアのみで朝会をして昨日何したか、今日何するかを共有
- 週1でエンジニアとPOで進捗の共有、仕様を詰める
といった進め方をし、タスクごとの見積もりはしていませんでした。
JOIN当初
自分は2018年7月にMangaWithにJOINしました。
透明性と不安
約1ヶ月MangaWithで働いてみて（この時点で8月）「このままだと12月にリリースできない気がする（漠然）（やばい）」と感じました。
この漠然とした不安は自分だけなのか確かめるためにエンジニア3人で振り返りを実施しました（KPTで行いました）。
チームで行う初めての振り返りだったので、「MangaWithの開発について」という割と広いテーマで振り返りをやってみました。
振り返りを行ったところ、自分以外のエンジニアも同じように不安に感じていることがわかりました。
特に「このまま開発を進めていたら絶対に間に合わないのでは？」という未来への不確実性が高く、課題となりました。
そこで「透明性」をキーワードに、スクラムを導入し、現状の可視化をし、どう対処していくかというステージに持っていくことを決め、POに提案をしました。
提案資料
スクラム体制の構築
POの同意を得て、スクラム導入が決定しました。
導入の際にいくつか、ワークを実施しました。
導入が決定した時点でPO1人、EN3人でした。
インセプションデッキ
インセプションデッキは本来10個の質問がありますが、ワークで実施したのは
- 我われはなぜここにいるのか
- エレベーターピッチを作る
- 夜も眠れなくなるような問題は何だろう
- トレードオフスライダー
の4つです。
ドラッカー風エクササイズ
写真には載っていないですが、5つ目の質問として「互いにどんなことを期待しているか？」を会話しました。
星取表
一度作った後、新メンバーがJOINした際にうまくメンテナンスができなかったという反省がある星取表です・・・
スプリント
2週間スプリントにして、スプリントレビュー・スプリントレトロスペクティブ・リファインメント・スプリントプランニングは1日にまとめました。
リファインメントは毎週水曜日に1時間開催しています。
リリースはまとめてリリースではなく、案件ごとにリリース可能状態になったらリリースしています。
スプリントはMilestonesで管理をしています。
プロダクトバックログ
ZenHubというGitHubの拡張アプリを利用してIssueを管理しています。
IceboxとProduct Backlogの中間的なSub Product Backlogを作っています。
カテゴリ的なもの「詳細」「トップ」「リファクタリング」等はGitHubのlabel機能を利用しています。
リファインメント
プロダクトバックログにあるIssueの詳細な設計等をし、Story Pointを振ります。
見積もりはエンジニアのみで行っており、フィボナッチ数列を利用しています。
最後の方は良い感じに相対的なポイントとして見積もりができるようになりました。
スプリントプランニング
見積もってあるIssueをスプリントバックログに移動させます。
ベロシティは80くらいに落ち着いたので、80超えないようにしています。
スプリントレビュー
CloseしたIssueのデモやアウトプットの報告をし、MangaWithというプロダクトと向き合います。
アイデアを出し合うブレストに近い感じですが、こういった機能があったほうがいいのでは？と意見を出し合います。
スプリントレトロスペクティブ
KPTでレトロスペクティブを行っています。
TRYは必ずIssue化し、次スプリントで対応できるよう調整を行います。
利用ツール関連
タスクはGitHubのIssueで管理し、ZenHubを利用してIssueをボードで表示して、GitHub Wikiを利用しドキュメント等を書いていました。
利用ツールはできるだけ行き来しないようにGitHubに閉じ込めるのを意識しました。
リリースまで
リファインメントでポイントを見積もり、毎回のスプリントのベロシティを測っていたのでリリースまでどれくらいのIssueが対応できるか見える化されていました。
そのため、取捨選択し優先度順に並べてリリースまで高速にIssueを消化していきました。
基本的にIssueの優先度はサービスとして根幹の部分から進めていました（例：漫画が読める → 漫画を買える → 一覧）
こうして無事、当初の予定通り12月にリリースができました！
リリース後
リリース後数ヶ月は、リリース時に取捨選択した入れる予定の機能の実装を行っていました。
リリース後は障害対応等々が発生し、ベロシティは安定せずぶれていました。
メンバーの増加
リリース後、3月頃になるとメンバーも増えGameWithの中でもかなり大きいチームになってきました。
メンバーが増えたので、スクラムのワークを再度実施しました（インセプションデッキ、ドラッカー風エクササイズ）
新たな不透明性と不安
リリース時に取捨選択した入れる予定の機能を作り終え、積んであったIssueが終わりかけた際に、新たな不透明性と不安にぶつかりました。
それは、大きな最終目標は見えていたのですが、道中の通過点が見えておらずどこに進めばいいかわからないという不透明性でした。
リリース前は、大きい最終目標の通過点の「リリース」があり、進むことができました。 （今思うとリリース前に、最終目標とリリースの間の通過点を決めて置くべきでした）
そのため、MangaWithチームは立ち止まってしまいました。
現在
立ち止まってしまったので、今どこに向かうべきか、課題の洗い出し、数値の分析を行っています。
通過点を明確にし、再び全力で走れるように、状況に合わせてチームをリファクタリングしています！
振り返って
リリースまではMangaWithに集中でき、全力を出せる状態だったので予定通りリリースができたと思います。
ツールの統一によるスイッチングコストの減少、スクラムによるスケジュール不安の解決、等々。
しかしリリース後は、マーケット不安をうまく解消できず現在に至ります。
スクラムを初めた頃から、最終目標からブレイクダウンした通過点をいくつか設置しておくべきなと感じています。
リリース後は軽い燃え尽き症候群みたいな状態になっていて、エンジンがかかるのに時間がかかってしまった印象がありました。
ただ、メンバーからとても良い雰囲気で良いチームというコメントを貰っており、チームビルディングはうまくいっていたと思います。
最後に
GameWithのDeveloper向けTwitterアカウントも開設しました。
もくもく会の告知やブログの更新情報などを発信するので良かったらフォロー宜しくお願いします！
