不具合頻発から品質向上へ。SHIFTと協力して達成したSLO99%実現までの軌跡 【助太刀 × SHIFT対談】
こんにちは。株式会社助太刀の開発部のエンジニアリングマネージャーをしている赤星です。
今期のテーマとして「開発組織の生産性の向上」と「不具合の削減」がありました。開発組織の生産性向上については以下の記事を先日公開させていただきました。
今回は「不具合の削減」についてこの半年間やったことを振り返りたいと思います。弊社の不具合を削減する、という目標達成のプロセスを語る上で、SHIFTさんの存在は欠かせないものでした。2022年の5月にSHIFTさん率いるQAチームが助太刀にジョインし、協力して不具合削減に取り組んできました。そこで今回はSHIFTさんで品質PMOをしている竹林さんと私で対談形式で、これまでやってきたことを話していきたいと思います。
1. まずは自己紹介
赤星 孔太
株式会社助太刀の開発部のエンジニアリングマネージャー
事業部とのやり取りやpjm、スクラムマスター、開発効率化を担当
前職はオンライン英会話のiOS / バックエンド を担当
最近はポーカーにハマっています
竹林 大繕
株式会社SHIFTのテスト案件管理者と品質向上PMOを兼任
テスト計画立案やバグ分析、テスト設計者育成などテストの上流工程を担当
前職はインフラやサーバーサイド、テクニカルサポートなどを浅く広く歴任
趣味は異世界転生系のアニメが大好き
2. 簡単に助太刀の説明
建設業界には330万人以上の職人がいるにも関わらず工事会社では「職人不足で大きな現場が受けられない」、「閑散期に仕事が欲しい」といった課題に悩まされています。助太刀では、工事現場の発注者と受注者を繋げるマッチングプラットホームを提供しています。
業界の課題やプロダクトのポテンシャルについてはこちらに詳しく書かれているので、よろしければ御覧ください。
3. 開発規模拡大に伴いテストが追い付かなくなった
竹林：本日はよろしくお願いします。さっそく聞いていきたいのですが、QAチーム立ち上げの経緯から話しましょうか。改めてどんなところが課題だったのでしょうか。
赤星：よろしくお願いします。SHIFTさんのQAチームが発足されたのが2022年の5月だったと記憶していますが、それ以前の2021年ごろからチームのメンバーが増えてきて、開発量は増えたんですよね。内製化が進んだことはいい事ではあるのですが、開発量に比例してテストの量も増えるわけで、そのリソースが回らなくなった、っていうのが正直なところですね。
竹林：そうなのですね。僕は結構不具合が頻出してる、と事前に伺っていました。
赤星：そうですね。その頃はテストは僕と開発者数名で進めていました。リソースが回らない中でスケジュールを守ろうとしてテスト漏れてしまった、だったり1回目確認したら問題なかったが、次の改修で他の不具合を直したら別の箇所に影響が出た、というようなものが頻発していました。
竹林：開発規模拡大に伴いテストが追い付かなくなった、ということですね。
赤星：と思っています。一時期、ビシネスサイドの方にもテストを依頼していましたが、当たり前ですがビジネスサイドの方は裏側の事に関しては知りようがない。本当の意味で品質担保するには、ある程度開発側のリソースの確保が必要でした。
竹林：確かに、QAは一定の専門知識が必要ですね。QAのポジションを採用、ということは考えなかったですか？
赤星：もちろん最初は採用を検討しました。しかし会社としても、この問題を急速に解決したいとの事で、私も同意見だったので、SHIFTさんに依頼したという背景があります。
竹林：確かに、アウトソース化すると、そこのスピード感はありますね。一方で、内製化比率が下がるみたいな不安は無かったですか？
赤星：結論から言うと無かったです。もともと弊社はオフショアで開発していて、パートナーと依頼者、という関係で開発をしていました。そこから業務委託の開発者の方に社内に入ってもらい、近い距離で開発するようになりました。今もそういった感じで働いていて、現状開発チームは20名を超えていますが、7割は業務委託の方です。内製化の定義、のような話になりますが、私が重要視していたのは近い距離でチームとして課題を解決できることだったので、そこの懸念はありませんでした。
4. 着実にテスト範囲を広げ、早期に結果が出せた
竹林：実際にSHIFTのQAチームが機能し始めて、どういう感覚でしたかっていう、定性的な質問をさせてください。
赤星：確か（SHIFTさん）5月に来ましたよね？
竹林：はい。大きい機能だと、ビジター機能(会員登録せずともアプリがある程度使用できるようになる機能)が実装されるタイミングでしたね。で、実際のQAをどこから始めるか、それまでに何を行うか、のような議論からスタートしましたね。
赤星：正直半信半疑ではありました。と言うのも仕様が複雑じゃないですか。助太刀のサービスはプランや、ユーザー種別、受発注で振る舞いが変わることもあり要件が多岐であることや、そもそもこちら側で仕様がまとめられておらず、私しか理解していない部分が数多く存在してしまっているという課題もありましたし、そのあたりをうまく伝えたりすることが難しいだろな…と最初は思っていました。
竹林：じゃあ、ちゃんと仕様をキャッチしてくれないとテストもまともにならないだろうな、と
赤星：そうです。基本的にはこちら側の原因ですが、開発プロセスがちゃんと整ってない中でQAを入れてちゃんとワークするのだろうか？といった不安はありましたね。確かに。
竹林：その辺の不安はどうやって解消されていったんですか？
赤星：結果ですね。具体的にはQAチームを導入してから4ヶ月後あたりには（本番環境での）不具合の流出率や、出ている不具合の中でも例えば「メイン機能が使えない」等のクリティカルなものの割合が下がっていることが挙げられます。昔はリリース日に不具合が頻発していました。現状不具合は問い合わせなど報告ベースで上げられるものが多く、当日に不具合が出るということは、ユーザー全体が使う大通り的な機能に不備があるということです。今はリリースによる不具合というよりは、特定の条件下で発生するものが多い印象です。テストにフォーカスしているチームがいるからこそ短期間で成果を出せたと思います。
竹林：結果が出ていく中で、導入前の不安が解消されていったということですね。
赤星：そうですね。もちろんどこまで行っても問い合わせベースなので、内部で早期検知する仕組みは別途必要だと思います。現状はDataDogを導入しておりそのあたりも気付けるようになりました。
竹林：結果が良かったなら何よりです。具体的にどういった部分が結果に寄与したと思いますか？
赤星：結構早い段階で、何を最初のゴールとしていくかみたいな調整をSHIFTさん側主導でやってくれたような印象がありますね。
竹林：まぁ、そうですね。ここまでにこれをやりましょう！とか。
赤星：そうそう。
竹林：いきなり新機能のテストはできないからまずはリグレッションテストから巻き取りましょう！とか、段階的に拡大していくことを意識してました。
赤星：QAという工程にはちゃんと細分化した定義があるということも、正直私は曖昧に理解していた部分があったので、今の助太刀にどういった順番でどういったテストを行うべきか、というロードマップを早期に引いていただき、それぞれ解説していただいたのはすごく助かりました。
竹林：なるほど。それでいうと、僕としては最初は期待値調整を重要視しました。
QAチームが出来たとしても、時間もリソースも限られているので、すべてのテストが出来るわけではありません。「QAチーム入れたから不具合が0になります」という期待値だと結果的にずれてしまうので、少しずつ達成可能な範囲を広げていく、というイメージで進めていました。
赤星：そうですね。それはよかったと思います。
5. SLO計測のプロセス
竹林：先程、実際に不具合が減っているというお話をされていましたが、実際にデータを見てみましょうか。実態としてはこんな感じになっていて
これは完全に僕の主観ではありますが、最近でも不具合の報告自体はありましたが、内容としては細かいものが上がってくるようになったのかなって気はしますね。
赤星：僕もそう思います。ただそれはどこまで行っても定性なので、このプロジェクトを立ち上げた際、SLOの定義も定めましたよね。例えば細かいものでも数が多ければそれだけ品質自体は低いものとなります。不具合を差し引きして最終的に助太刀はどれくらいのサービス稼働率なのか、が出せるようになったのもSHIFTさんの協力があったからですね。
竹林：SLOを導入したプロセスも、僕らから作ったものではなく開発チーム全体で話し合いながら進めていきました。最終的には以下のようなアウトプットになりましたが、感覚値に近いものが出せているのではないかと思います。
助太刀のSLO
= 影響ユーザー数（何人のユーザーが影響を受けたか）
× 発生不具合の継続時間（数時間で収束したか、数日続いたか等）
× 影響のあったシステム範囲（影響を受けたシステムは一部か、全部か）
× 不具合の重要度係数（使いにくい程度か、被害を生むものか等）
赤星：実際にSLOを計測してみると、たしかにその計測基準で言うとQAが本格的に稼働するまではSLO 99%以上を達成できてなかったと思いますが、現状は99.9%を維持できていますよね。
竹林：SLOが99.9%を維持できている要因としては不具合の修正速度が以前より上がっているのではないかと思っています。例えば不具合が上がって3日以内に修正した場合と、次月にまとめて修正した場合だとざっくりSLOの減少率が10倍ほど違います。
赤星：それはあるかもしれません。これに関しては開発のスピードが上がったというよりは、開発の優先度の意思決定がプロダクトチーム(プロダクトをマネジメントするチーム)の発足により明確になったことが要因かなと思っています。今まではこの不具合の修正はどれくらい重要で、今やっているどのタスクであれば止めていいか、ということが曖昧になっており、そのすり合わせに労力がかかっていました。そのあたりの責任と権限の所在を明確にできた、ということもこの一年での成果ではないかと思っています。
竹林：じゃあ、プロダクト側との連携も改善してきてる、と。
赤星：そうかな、と思います。
6. 不具合の発生頻度だけではない「品質」
竹林：今ちょっと良い話が続いたと思ってますが、何か苦労した事とかもありましたか？
赤星：うーん・・・。
スケジュール面で言うと、逆に考えなきゃいけないことが増えたなと思います。具体的に言うと、今までは開発工数だけ見れば良かったんですけど、じゃあそれはテスト工数も問題ないのか、という部分です。今のスクラムで進めている性質上、テストはSprint毎に1週間程度で終わらせる必要があるのですが、まずそれが終わるのかということ。加えてテストするにはテスト設計が必要なのですが、それがテストまでに間に合うのか、ということですね。
なので開発は終わったけど、テストを考慮するとリリースは次回のSprintになる、といったケースも発生するようになりました。
竹林：なるほど。まあそうですね、ちょっと仕方なしみたいな所もありつつ。
赤星：そうですね。品質に拘るためにリソースを割くという意味だと、ある程度そういったことは発生すると思います。
竹林：逆に言うと、自分の担当の所だけでなくテスト工程も含めて気にしていただけてありがとうございます。
赤星：いえ、チーム増えたら気にすること増えましたねってだけかもしれないです。
竹林：ありがとうございます。それ以外の変化とか「思ったよりここがよかったな、悪かったな」みたいなことってありますか？
赤星：またいい話に戻ってしまうのですが、SHIFTさんだからなのか、竹林さんだからなのか分からないんですけどQAの定義が結構広いなと思っていて、なんでしょうね・・・。品質っていう定義を広く持って、色んな運用やオペレーションを見ていただいたり、他の事業部の方に「こういうことですよね？」「こうするのはどうですか？」等積極的に発信されているところは素晴らしいなと思いました。その辺りはあまり期待してなかったので、良いことだと思いました。そこまでしていただけるのか、と。
竹林：そうですね。個人的に「運用も含めて大きなシステム体系の一部」だと捉えているので、運用フローが問題ないかどうか？も含めてチェックしたいと思っていて、積極的にその辺見てるっていうのはありますね。
赤星：ありがとうございます。仕事を依頼する、となるとどうしても「ここまでは責任持ちます、（ここからは）持ちません。」みたいな話に結構なりがちで、それはそれで重要だとも思うのですが。1つのチームとしてやっていく中で、積極的にやって頂きありがたいです。
竹林：当然任されてる「本番環境にバグ流出させない」や「設定したテストケースをやりきる」とかそういうのは大前提としてありつつ、余裕があるときには迷惑にならない範囲で出来ることはやろうっていうスタンスです。これはまあSHIFTっていう会社自体が柔軟に、積極的に支援していこう！っていう社風な部分はありますね。
7. QAチームとしてのこれから
竹林：ここまでQAという文脈で今までやってきたことを話してきましたが、これからのことも話したいですね。赤星さん的に今後QAをどうしていきたい、という考えはありますか？
赤星：もう少しQAという業務を最適化したいと考えています。先程「どういったテストをどういった順番でやっていくべきか、を竹林さんに説明していただいた」と話しましたが、現状、良くも悪くもすべてQAチームにおまかせしている状態になっています。それはそれで良い形だと思うのですが、おそらく開発者がやったほうが良いテスト、開発者のほうが気づける観点、もしくは誰がやるべきでもない自動化するべきテスト、というものがあるはずです。そういったものを整理して、QAの方が本当にフォーカスすべきテストに集中できるように仕組みを整えていきたいと考えています。
竹林さんが以前「テストの定義が開発者によって曖昧なので、勉強会を行いたい」と言っていただけたと思うのですがそういうことですよね。
竹林：そうですね、合ってます。自動化の話になってくると、ちょっと自分から提案するのも不思議な気持ちなんですけど、QAでやってるリグレッションテスト自体も、どんどん自動化していく余地もあるのかななんて思ったりはしてます。
赤星：まぁ理想ではあるので、少しずつやっていくって感じですかね。
竹林：そうですね。よくある事例として、工数がかかるけど単調な値のチェックなどの自動化を進めて、そうすると全体の工数の1/5程は削減できると思います。その浮いた工数で、QAに振られている重要度が高いチケットに手を回せるようになったり、不具合が起きるのは仕組みの問題なケースも多いのでそういった整理を行えるようになったら理想ですね。
これからも頑張りましょう。ありがとうございました。
赤星：こちらこそありがとうございました。
7. 終わりに
助太刀ではエンジニアリングマネージャーを含めて、すべてのエンジニアを募集しています。詳しくはこちらをご覧ください。
助太刀が立ち向かう建設業界という市場は、規模60兆円を超える巨大市場にも関わらずICT化が進んでいない、という課題を抱えています。それを一緒にテクノロジーの力で解決するプロダクトを一緒に作っていきましょう。
この記事が気に入ったらサポートをしてみませんか？