こんにちは、Quality Control Squad の鴛海です。
Quality Control Squad という内部品質を向上させるチームを立ち上げた話から、プロダクトを作る上で内部品質とどう向き合っていくべきかという話をしようと思います。

ウォンテッドリーの開発スタイルと開発体制の変遷

Wantedlyでは全てのエンジニアやデザイナーがプロダクトを通してユーザに向き合い、プロダクトに関わる全てのことにオーナーシップを持っています。

プロダクトの課題発見及び解決 - Wantedly Engineering Handbook より

ウォンテッドリーではどんなプロダクトが求められているか考え、実装し、検証するまでをエンジニア 1人1人ができるような組織を目指しています。その結果、ウォンテッドリーにはプロダクトを変更する意欲が高いエンジニアが集まり、様々なプロダクトの改善を行い、ユーザーに価値を届けてきました。

開発基盤の整備による開発生産性の向上

しかし、ユーザーに価値を届けるためにはただがむしゃらにプロダクトを作ることだけが最短経路ではないと考えています。そこで開発基盤を整えて開発を促進させるために Infra Squad というチームが開発プラットフォームの改善を続けてきました。さらに2020年には 「エンジニアがより早く/より安全にプロダクト開発ができる環境」をつくることをミッションとした Developer eXperience Squad 通称 DX Squad が誕生しました。ツールやライブラリを作ったり導入したりすることでより早く、より安全なプロダクト開発を提供しています。

具体的にはマイクロサービス開発のために必要なコンポーネントのみをコピーする疑似クラスタコピーツールである kubefork や 任意のサーバーサイド/フロントエンドのロジックをブラウザから request local に書き換える開発用ツールである Feature Flag を開発しました。

DX Squad の詳細は以下の記事をご覧ください。

見えてきた内部品質の重要性

以下の図のように Infra, DX Squad によってインフラ/開発基盤は整備され、それを利用するシステムの開発の生産性も向上しました。

これでより早く、より安全なプロダクト開発ができると思っていたら新たな問題が見えてきました。

それは既存のシステムの内部品質が悪いことによって早く、安全なプロダクト開発ができず、外部品質に影響を与えているという問題です。10年以上運営してきたサービスのコードには現状に合っていない設計や、バグを生みやすい、またはすでにバグを生んでいるコードが存在しています。例えば以下のような問題がありました。

• 当初の想定以上に責務が拡大されたモデル
• 新しい基盤を導入したが全体適用できていないことによる学習コストの増大
• コードリーディングを阻害するデッドコード
• 把握できないバグの件数
• ヒューマンエラーを起こしやすい設計、コード

ただ、これまで内部品質を高めるような動きがなかった訳ではなく「大きなドメインのマイクロサービス化」「GraphQL の導入」「gRPC の導入」など様々な施策を打ってきました。しかし、導入はしたけどその後の改善が回せていなかったり、全体に導入し切れていないことでコードの地層を生み、より学習コストがかかるようになってしまう状態になっていました。

そこで私たちはサービスの機能改善をしつつも、より継続的に内部品質を高めこれからの開発を加速させることにもリソースを投下するべきだと判断し、内部品質を上げることで外部品質を改善していくチーム Quality Control Squad を立ち上げました。
これにより、DX Squad は開発基盤の品質を向上させることに集中して、Quality Control Squad がコードベースの品質を向上させていく体制ができあがりました。

Quality Control Squad が何をやっているか

システムの内部品質向上

「品質とは誰かにとっての価値である」(Gerald Weinberg 著, 大野 徇郎 訳.ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉. p.7) という言葉がありますが、内部品質はシステムの開発者にとっての価値であると考えています。外部品質は内部品質に依存します。プロダクトを成長させる(=外部品質を上げる)ことを本当に達成したいのならば内部品質から上げないといずれ崩壊することになります。かといって今あるバグも放置できません。例えるなら、健康な身体を手に入れるためには運動をしたり、よい食事を心掛けたりすることが大切ですが、今ある怪我や病気を治さなくては健康になれません。

これらの課題観から、内部品質向上として「リファクタリング」と、外部品質を担保する「バグの修正」の 2つの種類のプロジェクトを行っています。

1. リファクタリング

「リファクタリング」を行うプロジェクトでは、コードの設計を大きく見直したり、古い基盤を使っているコードを新しい基盤に移行することで内部品質を上げることを目的としています。現在は昔からある機能でコードが古くなっている箇所を別の箇所で導入している新しい基盤に移行しています。具体的には、Rails + Haml + jQuery を、Ruby gRPC + GraphQL + Next.js に移行しています。

なぜこの基盤に移行するのかについては以下の記事をご覧ください。

2. バグの修正

QA やユーザーからのお問合せ、社内からのフィードバックなどさまざまな場所からバグは発見されます。これらのバグが正しいバックログに入るような仕組みを整備し、日々バグが報告されています。報告されたバグを全部対応していては本来行いたい内部品質の向上にとりかかれないため、優先度を付けリファクタリングのプロジェクトとのバランスを見て対応していっています。

直近3ヶ月で大規模なリファクタリングプロジェクトを進めながら 60件のバグを修正しています。また、対応する中で見つけた内部品質の悪さはリファクタリングのプロジェクトとして行われることになります。

内部品質を向上させるための文化醸成

組織でプロダクトを作っていることも忘れてはいけません。いくら Quality Control Squad が内部品質を上げても新しく追加されるコードの品質が悪くてはいつまでたっても問題は解決しません。組織全体でよい品質のコードを書く方法や、よい設計の手法を学んだり、品質が悪いことを認知できる仕組みが必要です。

現在はチーム内で設計の手法の勉強会を行い知見を貯めたり、リファクタリングやバグ修正を進めて得た知見を含めて社内に広めていこうとしています。

さいごに

サービス開発をしていると機能開発に集中するあまり内部品質は蔑ろにされがちです。なぜそのようなことが起こるのかを表わした ”Clean Architecture” の一節がありました。

「あとでクリーンにすればいいよ。先に市場に出さなければ！」開発者たちはそうやっていつもごまかす。だが、あとでクリーンにすることはない。市場からのプレッシャーは止まらないからだ。「先に市場に出さなければ」ということは、後ろに競合他社が大勢いるということである。競合他社に追い抜かれないためには、これからも走り続けるしかない。その結果、開発者はモードを切り替えることができない。次の機能、また次の機能、またまた次の機能を追加することになり、コードをクリーンにすることまで手が回らない。そして、崩壊が始まる。生産性がゼロに近づいていく。

Robert C.Martin 著, 角 征典, 高木 正弘 訳. Clean Architecture　達人に学ぶソフトウェアの構造と設計 (Japanese Edition) (Kindle の位置No.449-455). Kindle 版.

まさに数年前までのウォンテッドリーはこれと同じことが起きていたと思います。内部品質の高いコードを書く、長く使える設計をするということはソフトウェアエンジニアとしては当たり前かもしれません。しかし、それらの重要性を正しく説明し組織に適用することは意外と難しいことだと Quality Control Squad を立ち上げたときに実感しました。Quality Control Squad はこれからも内部品質を上げてユーザーの価値を高めていきます。

また、内部品質がよくない状態だけどどうしたらいいか分からない、Quality Control Squad や DX Squad についてもっと知りたい、内部品質について雑談したい、Quality Control Squad として働きたいなどあれば下の「話を聞きに行きたい」ボタンを押してカジュアル面談しましょう！