ユーザーの価値を突き詰めたからこそ誕生した内部品質を向上させる Quality Control Squad | Wantedly Engineer Blog
こんにちは、Quality Control Squad の鴛海です。Quality Control Squad という内部品質を向上させるチームを立ち上げた話から、プロダクトを作る上で内部品質と...
https://www.wantedly.com/companies/wantedly/post_articles/459966
Photo by XAVIER PHOTOGRAPHY on Unsplash
このストーリーは、Wantedly Advent Calendar 2023の1日目の記事です。
Wantedlyは、創業から10年を経て、多くのユーザーに使っていただけるプロダクトへと成長しました。創業期から成長期にかけて、ユーザーに価値を届けることを最優先し、迅速なリリースを心掛けてきました。しかしながら、この成長の過程で、バグやインシデントの対応が増え、割り込みタスクが増加してしまいました。これは、プロダクト開発の遅延を引き起こし、最終的には生産性への影響を及ぼすようになりました。本記事では、この問題への対応と、私たちがどのようにして開発体制を見直し、生産性を最適化してきたかをご紹介します。
私たち開発組織は、ユーザーに価値あるプロダクトを提供することを目指しています。単なる「nice to have」ではなく、「must have」を提供し、使いやすく、シンプルで洗練されたプロダクトを目指しています。また、開発の時間軸の重要性を認識しており、開発が遅れるとユーザーのニーズが変わってしまう可能性があるため、迅速な市場投入を目指しています。これらの目標を達成するためには、高い生産性が不可欠です。
生産性は、特定の期間内に効率的かつ効果的に成果やサービスを生み出す能力の指標です。高い生産性とは、限られたリソースや努力で大きな成果を達成する状態を指します。生産性を最適化するためには、以下のような様々なInput(入力)とOutput(出力)の項目を考慮することが重要です。
目標は「Input < Output」となるように、つまり投入されたリソースに比べてより大きな成果を出すことに集中することです。ここに記載した項目は生産性を考える上での基本的な要素に過ぎませんが、実際にはこれらを超える多くの要因が生産性に影響を与えます。
生産性は多くの要因に影響されるため、その計算は複雑です。企業によって異なる事業モデルや組織構成があるため、「開発生産性」の定義や改善方法も異なります。企業の成長段階に応じて重視すべき点が変わります。重要なのは、状況に応じて課題を正確に特定し、効果的に解決策を進める能力です。
ウォンテッドリーの組織体制は、Tribe / Squad 体制を採用しています。この体制は、縦軸に事業部ごとの Tribe、横軸に機能部門ごとの Branch が配置される特徴があります。
各 Tribe は事業戦略に基づいてプロダクト開発とビジネス開発に取り組んでいます。事業計画からプロジェクトラインを構築し、市場へのリリースを目指してプロダクト開発を進めています。プロダクトの利用と有料プラン・オプションの契約により、事業収益が生まれます。
開発組織は Squad を頻繁に結成し、短期間で解散させる運用モデルを採用していました。このモデルは短期間で成果を生み出すメリットがある一方で、リリース後の問題解決を複雑化するデメリットもありました。リリース後にユーザーからの問い合わせやバグ報告があると、関連する開発メンバーが別のSquadに移動していたことが多く、適切な対応者が不在になるケースが頻発していました。問題に対応するためには、進行中の開発を中断し、迅速な対応が必要でした。
また、QA Squad は主にモバイル開発に集中し、リリース前の重大な不具合の特定と解決に力を注いでいました。一方、Web開発ではチーム内でテストを行い、必要に応じて修正版を迅速にリリースしていました。
しかし、この運用モデルにより、品質が十分に確保されていない状態でのプロダクトやサービスのリリースが発生し、これがプロセス効率の低下やプロダクト開発の停滞に繋がっていました。結果として、スケジュール遅延やリリースまでのリードタイムの延長が発生し、計画通りの施策リリースが困難となり、数値改善が進まない状況に陥っていました。また、新しい技術や事業への投資、メンバーのスキル育成やチャレンジの機会の時間が削られることも問題となっていました。組織的な生産性低下に繋がっていました。
プロダクト開発における課題に対処するため、以下のアプローチを採用しました。これらのアプローチは完全な解決策ではありませんが、以前の状況に比べて既存開発のリードタイムへは改善傾向にあります。
品質保証(QA)の範囲拡大
QA Squadによる専門的な品質保証(QA)期間を設け、リリース前のプロダクトの品質を高めています。これまではモバイル開発に限定していたQA期間をWebアプリケーションにも拡大し、全般的な品質向上を図っています。その結果、新規開発に関する問い合わせや不具合報告の件数は減少しています。
内部品質向上チームの設立 (Quality Control Squad)
従来の短期集中型チームの問題点であった対応者不在の問題への対処と、技術的に古くなったプロダクト機能の更新を担当しています。チームの解散や再編成による問題を最小限に抑え、継続的なサポートと品質向上を実現しています。チーム設立のブログ記事を参照ください。
担当者不在時の問い合わせ対応
Quality Control Squadは、ユーザーやカスタマーサポートからの問い合わせにも対応しています。問い合わせの内容を現行開発と過去の開発に分類し、状況に応じて適切な対応を行うためのタスクボードに追加しています。
これらのアプローチを通じて、プロダクト開発プロセスの効率と効果を高め、リードタイムの遅延を最小限に抑える取り組みを行っています。
今回紹介したプロダクト開発における課題は、私たちが直面する課題の一つに過ぎません。この課題は唐突に発生したわけではなく、長い時間をかけて徐々に蓄積されたものです。創業期には「プロダクトマーケットフィットと収益化」に注力し、成長期には「事業の拡大」を目指す戦略と開発体制が採用されました。これらのアプローチは成功し、今日の成果につながっています。しかし、根本的な問題は、時間の経過と共に企業ステージが変化し、かつての正解だった開発体制が現在のニーズに合わなくなり、新たなリスクを生じさせていたことにあります。
企業はステージの変化に気付き、時代の流れに適応するための変革を行う必要があります。この変革の能力は、組織全体の生産性および開発生産性に大きな影響を及ぼします。
ソフトウェアを主軸とする事業においては、開発責任者だけでなく、経営者からメンバーまで、この変化に対する理解が重要です。
本記事で紹介したケースは、企業成長における課題のほんの一例に過ぎません。実際には、大きなものから小さなものまで、数多くの課題が存在します。みなさんの企業が同じ問題に直面するとは限りませんが、成長する企業が遭遇する可能性のある多様なパターンの中の一つです。もしもこの記事が、あなたやあなたの企業にとって何らかのヒントや示唆を提供できれば幸いです。
私たちの経験から学べることはあるかも知れません。
成長過程で直面する課題は、企業にとって重要な学びの機会であり、それを乗り越えることで、より強固な組織が築かれます。