ウォーターフォール型PMと新人が半年間スクラムと向き合って感じたこと(PM編)

はじめに

こんにちは。ecbeing金澤です。
浦さんと共に、レビュー最適化サービスReviCoの開発に携わっています。

ReviCoでは、よりアジャイルにプロダクトを成長させるために、昨年秋からスクラム開発を導入しました。
私も浦さんもスクラム未経験の状態からのスタートだったのですが、特に私の場合は、長くウォーターフォール型開発をやってきたこともあってか、スクラムの考え方や進め方に最初はかなり戸惑いました(今でも完全に克服したわけではないですが…)

今日はそのあたりを記事にまとめられればと思います。

今やっているスクラムについて

体制

f:id:ecb_kkanazawa:20200312122805p:plain

POが多忙なため、金澤がPO代理としてスクラムチームに入っています。

浦さんは開発チームには入らず、差し込みタスクや実験的な機能の開発、デザイン作成＆コーディングを担当しています。

別拠点のスクラムマスター＆開発チームとは、普段の会話はSlack、ミーティングはZoomでやっています。(スプリントレビューだけは対面で実施しています)

1スプリントは2週間に設定していて、各種イベントは以下のように回しています。

スクラムイベント参加者

イベント	PO	営業	金澤	浦	SM	開発T
(スクラムイベント外)定例	○	○	○	○
リファインメント			○	○	○	○
デイリースクラム					○	○
スプリントレビュー	○	○	○	○	○	○
プランニング1部			○	○	○	○
プランニング2部					○	○
レトロスペクティブ					○	○

スケジュール

月	火	水	木	金
	定例スプリントレビュープランニング1部	←スプリント期間→
	定例リファインメント
	定例スプリントレビュープランニング1部	レトロスペクティブ

私(金澤)について

2019年3月にecbeingに入社、それまでは受託開発の会社でプロジェクトリーダー・プロジェクトマネージャーをやっていました。
担当する案件はほぼウォーターフォール開発でした。
インフラとかネットワークが好きです。

スクラムをやって感じたこと

スクラムやるにあたって

元々ボスから「スクラムの勉強しておいて！」と言われていたのですが、やったのはこのくらいでした…

ウォーターフォールとの違いに戸惑ったこと

仕様変更を喜んで受け入れる

ウォーターフォール型は後工程での仕様変更を最小限にすべく上位フェーズから詰めていきますが、アジャイル開発って変化を受け入れろ！変化は成長！変化は友達！ってめちゃくちゃ言ってるじゃないですか…
まずその考え方を受け入れるのに時間が掛かりました。

ただ実際にプロダクトの営業に同行すると、訪問先ごとに色々な要望が出てきて、打ち合わせに行くたびにPBIの優先順位リストがころころ変わっていたので、そう思わないとやってられないと思うようになりました。

というか、そもそも一括請負の受託開発とプロダクトの開発って、コミットする先が違う(完成にコミットするのか、プロダクトにコミットするのか)ので、そもそも比較にならないなぁとこれを書いてて気が付きました…。
スプリントレビューの指摘をプラスに考える

スプリントレビューって成果物に対してPOからの指摘がバンバン入るんですよね。(それが目的の場なので当たり前ですが)

ただ、スプリントレビュー＝納品後の検収 と捉えてしまっていたので、スプリントレビューを非常に億劫に感じることが多々ありました。

正直今でも若干ありますが、それはどっちかというと、次スプリントへの持ち越しが多くなるので次はPBIどのくらい消化できるかなぁ…という不安の方が大きいです…
とにかく早くリリースしてフィードバックを得る

リリースって案件のゴール、一世一代の大イベントだと思ってました。
更にリリース後の瑕疵対応の工数なんて取ってないので、本番障害が起こらないように細かいテストもするし、リリース計画も万全に練ってましたが、それよりも早く世に出せやという考え方なので、それでいいのか？と思うことがしばしばありました。

しかし、そこで詰まっているとどんどんリリースアイテムは溜まっていくし、プロダクトの価値も上がっていかないので、もうやばい障害が出なければOK！と割り切って進めるようになりました。(リリース計画はちゃんと立ててます)

ただ、後述しますが、それはそれで品質課題になってしまっているので、良い進め方を模索中です…。

今感じている課題

新機能の開発と技術的負債返済のバランスが難しい
プロダクトの成長だけを考えれば、新機能開発に全力投球するのが一番ですし、その方が作ってる実感も出て楽しいです。また、リファクタリングの場合はテストどうするのという課題も付いて回ってしまいます。

とはいえ、技術的負債には過去散々苦しめられてきたので、(長いスパンで見て)成長スピードを維持しつつ、中身を綺麗にしていく工数の配分が難しいなぁと感じています。
品質の向上が難しい
リリースを優先するとやはりテストの精度が下がるなぁと感じています。
単体レベルであればユニットテストでカバーできるのですが、画面操作系の結合テストやバッチとの連結テストはどうしても人手と時間が必要になる(と思っている)ので、そこの工数をスクラムチームで捻出するのは難しい…

リリーススプリントを設けるのかも手かもしれないですが、作りたい機能が山ほどある中で開発チームの手を止めるのもちょっと…ということで、今は別部隊のQAチームに巻き取ってもらえないかを画策しています。
受け入れ基準の明確化が難しい
2はテストでの品質向上ですが、受け入れ基準の精度アップによる品質向上もセットで考えないとなぁと思っています。

現状、ビジネス要件や機能要件は結構細かく詰められているのですが、非機能要件(性能やログ、セキュリティ)が甘かったり、過去の障害からの観点が抜けたりすることがあるので、そのあたりも第三者視点でチェックしてもらう仕組みを考えています。