Visionalグループ、株式会社M&Aサクシードは法人・審査制M&Aマッチングサイト「M&Aサクシード」を提供しています。この業界はDX化の大きな可能性を秘めており、弊社のエンジニアも日々新規プロダクトの開発に勤しんでいます。

現在は立ち上げフェーズということもあり、スピード感が求められる中で開発を進めていますが、今後の事業成長を見据え、QAチームとしてデリバリーの増大に追いつくためにプロダクトの品質を高める必要があると考えました。そしてプロダクトの品質レベルを高めるための1つとして、プロダクト外の「組織品質」を改善する取り組みを行いました。
この記事では、

「M&Aサクシード」の開発組織構成について

「M&Aサクシード」には複数チームから成るサービス開発グループがあり、QAチームもそのグループ内にあります。2023年現在、サービス開発グループの構成はこのようになっています。

開発とQAだけでなく、PdMやデザイナー、マーケティングも同じグループ内にいるのが特徴です。横断型のプロジェクトでも早期リリースを実現できる強みがあります。

プロダクト内の品質：プロダクト品質、プロセス品質

本記事の主旨ではありませんが、まずはプロダクト内の品質として、プロダクト品質とプロセス品質について簡単に書いておきたいと思います。弊社では開発手法にアジャイル開発を採用しており、プロダクト品質とプロセス品質の両面から品質を保証しています。

プロダクト外の品質：組織品質とは

本題のプロダクト外の品質、組織品質についてです。

私たちはプロダクト品質、プロセス品質以外で、プロダクト開発に大きく影響を与えているであろうという組織内のコミュニケーション品質のことを「組織品質」という概念で捉えることにしました。プロダクトに関わる人たちのコミュニケーションの状態やチーム内外の連携状況などを総合的に評価したものです。

なぜプロダクト外の品質も気にするようになったのか？　はじめは些細な報告からでした。QAエンジニアから「PdMと開発が仕様変更について直接話していて、共有されずに困っている」というもので、じゃあログを残すようお願いしておくよという話で収めましたが、ちょっとした違和感がありました。この話以外にも似たような些細な共有漏れレベルの話が続いたのもあり、違和感が少しずつ形になっていきました。 立ち上げフェーズのプロダクトゆえにスピード感が求められる環境であるとはいえ、コミュニケーションロスがあちこちで発生している、という状態です。

弊社開発チームは互いのチームにリスペクトを持って接していますが、リスペクトが過ぎる場面も多く、お互いの領域に踏み込めなくなっている様子が伺えました。その時たまたまプロセス改善の仕事で各チーム間を行ったり来たりしていた私に「これってプロセスに問題があるんじゃないか」という相談が集まったわけです。プロセスの問題として扱うことも出来ましたが、”不要な”コミュニケーションコストを増やしてリリースできる量を減らすのは本末転倒なので、これらをまとめて解決するための「組織品質」という考え方を導入しよう、という話に至ったわけです。

組織品質が高い状態とは「プロダクトに関わる人たちのコミュニケーションロスを防ぎ、事業期待に応えられるプロダクト開発がスピード感を持って進められる状態」と定義しました。

プロダクト品質 プロセス品質 組織品質
品質を測る基準 要求を満たしているかどうか プロセスに沿っているかどうか 共通認識が取れているかどうか
品質が悪いとどうなるか お客様に価値を届けられない プロダクト品質が不安定になる コミュニケーションロスが発生し、
プロセスの実施に時間がかかりプロダクトのアウトプットのリードタイムが長くなる
同じ方向を向いていないのでアウトプットの優先順位に齟齬が発生したり、価値のない
アウトプットを作り出したりしてしまう

このようにして、ベロシティや一般的な品質指標のようにある程度決まった数値を計測するものから、そういった指標が使えない定性的な概念まで、多くのエンジニアを巻き込んでの取り組みがはじまりました。

組織品質を向上するために取り組んだこと

いくつかの取り組みを進めましたが、今回は社内で中心的な取り組みとなったものを３つご紹介したいと思います。

1. 開発投資の見える化

▼当初の問題点
一部のプロダクトにおいてベロシティが安定しない傾向が見られた

▼隠れていた組織品質上の問題点
プロダクトへの投資（リソース配分）が管理されておらず、事業が期待するものとの認識のすり合わせが出来ていなかった

これは、プロセス品質をチェックしている際に検出したもので、特定のプロダクトだけベロシティが安定しない、という状態が続いていました。当時、開発チームはベロシティを上げるという大目標を掲げており、そのためにベロシティを安定化させることを初期目標として設定していました。 しかし何スプリントを回しても安定化には程遠く、開発プロセスやテストプロセスへの様々な施策も取り入れたもののそれらの効果は残念ながら微量でありました。そこで、そもそもプロジェクトが正しく管理されているかまで遡って確認を行いました。

結果的にこれが当たりで、リソース配分やプロジェクトの着手順などがすべて整理されておらず混沌とした状態になっていました。組織品質において、事業と開発のコミュニケーションロスがあり、プロダクトのアウトプットの優先順位が事業と開発で齟齬がある、という状態です。

そこで、最初にプロダクトとリソース上限値を整理しました。次に中長期で取り組むものなのか短期で取り組むものなのかを分け、投入するリソースの分配をやり直しました。このとき、プロダクトへの投資だけでなく技術的な負債解消も同じフォーマットに落とし込み、そもそもやるかやらないかまで考慮に入れました。以下はイメージです。実際には、この頃ちょうど社内にNotionが導入されたこともあって、全てNotion上で管理できるようにしました。

もともと開発工程に大きな問題はなかったので、その入り口であるリソース管理を導入しただけで「ベロシティの不安定さ」はすぐに解消していきました。さらに副次的な効果として開発チームの1リーダー体制を4ユニットリーダー体制に広げることができました。リソースの適切な分配によってチーム細分化の必要性が見え、次世代リーダーの育成にも繋げることができました。

2. コミュニケーション活性化を目的としたシフトレフト

▼当初の問題点
PdMによるオーナーチェックで指摘が多かった

▼隠れていた組織品質上の問題点
上流でのコミュニケーションが少なかった

「M&Aサクシード」のテストプロセスでは、最終プロセスとして受け入れテストを設定しています。ここでの指摘数が想定よりも多い状態が続いていたことがあり、その原因を調査したところ、PdMとデザイナー、開発・QA間で「作りたいもの」に対する認識齟齬が部分的に生まれていたことが分かりました。企画段階でのコミュニケーションが少ない、という組織品質の問題があったのです。その結果として、時に、そのままではユーザーに届けられない、価値のないアウトプットになることもありました。

解決方法はシンプルでした。開発がどういった方針で開発し、QAがどういった方針でQAするのか。設計プロセスを要件定義・デザイン工程へと被せる（工程を左にシフトさせる = シフトレフト）ことで、開発から要件定義・デザインへの一方通行レビューではなく、開発と要件定義・デザインの双方向レビューへと変化させました。早期からコミュニケーションを発生させるのが目的です。

はじめはオーバーヘッドがかかり若干のコスト増が見られたものの、開発が進むとチームにも慣れが出てきて、コストは落ち着いていきました。劇的に改善したのは受け入れテストでの指摘数です。早期にチーム全員で「どういった開発をするのか」「どういったQAをするのか」の認識を合わせておく。たったこれだけのコミュニケーション改善で、以前は1スプリントあたり10件もあった指摘数が、1～2件ほどに激減しました。1件あたりに発生していたコミュニケーションや修正のコストが数時間だったので、1スプリントあたり1～2人日分のコスト削減になりました。

3. コミュニケーションコストが重くなっていたプロセスの改善

▼当初の問題点
UIの軽微バグの修正に想定以上のコストを投じていた

▼隠れていた組織品質上の問題点
どんなバグでも同じコミュニケーションフォーマットを用いることを「仕方ない」とチームメンバーが受け取っていた

とあるUI改善のプロジェクトにおいてアウトプットに時間がかかっており、その原因分析をしていたときに検出したのが、バグに関するコミュニケーションコストの問題でした。どんなバグでも同じ報告フォーマットを用い、同じようにコミュニケーションを取り、同じようなバグ改修プロセスを踏んでいました。例えば10ピクセルが15ピクセルになっているというバグも、複雑な再現手順やテスト条件が必要なバグも、どちらもまったく同じプロセスを通過していたのです。そして、これをチームメンバーが「ルールなので仕方ない」と当たり前として受け取っていた、という組織品質の問題がありました。

まずは組織品質の改善として、振り返り方を変えました。それまで職能別とリーダー以上の横断的な振り返りの2点だったものにプロジェクト別の概念を取り入れ、プロジェクトに参加する全員でチーム間のコミュニケーションが生まれる場をつくりました。

次にプロセスの改善です。些細な指摘はNotionを利用し、1指摘あたりの起票・確認・修正コストを大きく下げました。具体的には1時間以上かかっていたものを10分や20分程度にまで下げることに成功しています。さらにテストケースではなく簡易的なチェックリストを用いて序盤に一気に確認するようなテスト改善も取り入れ、なるべく後工程で問題が頻出しないようにしました。どちらもベースは私のアイデアではなく、上述したプロジェクト別の振り返りによるコミュニケーションで生まれたアイデアです。組織品質が上がることでその他の品質も上がった、と言えるでしょう。

現在は新たな課題も出ています。「どこからが ”些細な” に該当するのか」というのが新しく組成したチームでは浸透するのに時間がかかるというものです。これも無闇に新規プロセスを追加するのではなく、まずは開発工程でのコミュニケーションにて改善を試みています。

最後に

開発エンジニアやQAエンジニアがプロダクト外の品質を考えるシーンは少ないと思いますが、その多くがコミュニケーションの問題であり、結局はプロダクトの成長に寄与するものであると考えています。今回ご紹介したものが何らかのプロセス改善のヒントになれば幸いです。

Yuki Nonaka (野中 雄貴)
Yuki Nonaka (野中 雄貴)

M&Aサクシード サービス開発グループ所属。QAとPMを兼任。最近のトレンドは「個とチームの力」を引き出すことによって「組織力」を高めること。