モグラ叩き開発から疑似スクラム開発フローを取り入れるまで

あるアプリ系のスタートアップ企業で、プロダクトオーナー兼スクラムマスターをやっています。会社のメンバーは開発チームが自分1人で、他は全員営業系というメンバー構成です。実装自体はベンダーさんに業務委託して、社内に常駐してもらっています。

ポコポコ出てくるバグを叩きに行くモグラ叩き開発

アプリの開発をいわゆるウォーターフォール型で開発をしていたのですが、自分が急遽大きな病気が見つかってしまって入院してしまい、他の今までシステム開発経験のない社員にPMを任せて、単体テストからUAT工程の途中あたりまでプロジェクトを一時的に離れなくてはいけなくなりました。

退院して会社に戻ってきたタイミングでは、ちょうどUATの真っ最中でした。

そこで、UATの状況を社員にヒアリングしてみると、「バグを見つけて指摘して、上がってきた修正バージョンでも直りきってなかったり、今まで出来ていた部分に新たにバグが出たりとモグラ叩きみたい」ということでした。所謂デグレを頻発させてました。

問題点1.発生状況や再現方法が曖昧な指摘

UATでは、ベンダーさんで全て実施した総合テストのケースをもう一度やるのも効果的ではないということで、テスト手法としてはモンキーテストを取り入れていました。

モンキーテストはケースが定義されていない分、指摘する側にもある一定の指摘スキルが備わってないと再現が難しかったり、開発側も「何がおかしいのか？」がわからず、「どこまで直さなければ良いのか？」がわからないまま開発に入ってしまいます。

例えばですが、以下のような指摘がありました。

商品画面でタップすると違う画面に遷移しちゃう。表示されている商品詳細の内容もおかしい

指摘内容はこれだけです。

これだけでは、開発側は、バグの現象が正確に把握できず、指摘者側の意図する期待値もわからず、ざっと以下のような疑問が生まれて来ます。

・どのバージョンで発生したの？
・操作してたユーザーのIDは？
・操作してたユーザーのステータスは？
・商品画面ってどの画面のこと？画面IDは？
・タップは何の項目or領域をタップしたの？
・違う画面に遷移って今は画面IDベースでどの画面に遷移してるの？期待値の遷移画面は？
・商品詳細の内容がおかしいってどの項目のこと？期待値は？

対策1.指摘項目のフォーマットを作る

そもそも、受け入れ側のメンバーには、発生環境を伝えなきゃいけない、ということや、期待値を伝えなきゃいけない、という考慮がなかったので、「必ずこれは埋めてね」というフォーマットを作ることにしました。

・アプリバージョン：
・端末機種：
・ユーザーID：
・ユーザーステータス：
・現象：発生状況を必ずスクリーンショットか録画でエビデンスを添付すること
・再現方法：現象を再現するための操作を画面ID、項目を明示して、入力情報、操作アクションを具体的に説明すること
・期待値：どのような動き、出力情報になればいいのかを説明し、該当する仕様を要件定義書から指定すること

最初は社内メンバーからは「みんながみんなこのレベルで指摘できる訳でもないし、指摘するのが億劫になってしまう」というような反発もありましたが、このフォーマットを施行することで、指摘のレベルは間違いなく上がり、受け入れ側と開発側での現象と期待値のズレが少なくなったと思います。

問題点2.かんたんなバグから五月雨式に修正

当初は開発側で、課題に対する取り掛かり順などが全くコントロールされておらず、受け入れ側で色んなメンバーが次々とバグの指摘に関してタスク管理ツールを使ったチケットを起票して、それを見つけた開発メンバーが自由にそのチケットを拾っていくというフローになっていました。

そうすると、どういうことが起こったかというと、開発メンバーは簡単なタスクからしか取らなくなりました。

ユーザー影響レベルで言うと、絶対こっちの方が優先度高いでしょっていう機能のバグが放置されながら、文字ミスやデザイン修正などの簡単なものが次々と直されていきました。

あと、チケットの起票側は取り掛かり順を決めてる訳じゃないし、工数が見積もれる訳でもないので、各課題の期限が全く決められていない状態でした。

計画がないので、そもそも遅れてるか巻いているのかが全く管理できない、というか期限という概念がすっ飛んでいました。なる早という精神論にならざるを得ないよう状況です。

各メンバーは「今日はここまでやらないと」というのがないので、仕事のコントロールが極論、「時間が経ったら帰る」、「疲れたら帰る」、という感じでした。

対策2.プロダクトバックログへ集約して、優先順位と期限をコントロール

いわゆるプロダクトバックログを導入しました。

プロダクトバックログ：機能や技術的改善要素を優先順位を付けて記述したもの。

対策1でフォーマットを決めたバグ指摘や改善要望のチケットを取り込むことで作られるプロダクトバックログを作りました。

プロダクトバックログを運用する上で色々なツールを調べたのですが、ちょうどいいものが見つからず、結果的にExcelに落ち着きました。完了した課題などのメンテのしやすさには難ありですが、項目数・形式の自由度や取り込んだ起票されたバグチケットをvlookしたり、フィルタ機能の使いやすさなどを考えると使い慣れたExcelが1番でした。

起票されたチケットを以下の基準で優先度を4段階に切り分けて、並び替えを行いました。優先順位の並び替えは開発に取り掛かるまでは常にメンテを行い続けなければいけないのですが、新しく発生した課題や、今開発している課題に関連する課題が重要度が高く見えたりと、バックログを見るタイミングによってバイアスがかかりがちなので、いつ見てもビジネス影響の観点から並び替えられるように、自分である程度大きな基準を持つようにしています。

★★★★：アカウント管理関連バグ、決済機能関連バグ、セキュリティ脆弱性、ユーザー操作の有効性が確保できないバグ
★★★ ：最重要KPIへの影響度が強い改善、主要機能関連バグ
★★ ：ユーザーが目的達成するための効率が上がる改善、目的達成を阻害しないバグ修正
★ ：ユーザーが目的達成するための過程で満足度が上がる改善、目的達成を阻害せず発生頻度の低いバグ修正

課題を並び替えたら、一定期間で開発のサイクルを区切ったスプリントを設けて、それに向けて課題を優先順位の高い順から何個できるかを見積もって計画を立ててもらい、期限のマイルストーンに向けて進捗管理をしていくという流れを取り入れました。

あとは教科書通りにデイリースクラムにあたる朝会を行い、開発を進めていく上での行き詰まりや課題を素早くキャッチして、お互いにフォローができるようにしました。

こうすることによって、スピード勝負のスタートアップサービスとして、スピーディーに成果を最大化するための開発フローを整えました。

ただ、このスクラム開発は差し込みにめっぽう弱いです。本当は機能改善や追加開発のような計画の立てられる開発と、障害対応するチームは分けられるのがベターではあるのですが、人的リソース的に全く余裕のないスタートアップの初期ではそのような体制も取ることはできず、全部同じ開発メンバーで対処をすることになります。そのため、障害が発生するたびにリスケが発生するため、なかなか計画どおりにスプリントを終えられることが少ないのが現状です。