はじめに
はじめまして、食べログシステム本部のDeveloper Productivityチームでテックリードをしている荻野です。2022年9月29(木)に緊急Ques ~食べログの品質ダッシュボード~という勉強会に食べログのエンジニア達が登壇しました。そこで今回は食べログの品質について紹介したり、アジャイルメトリクスについて議論した勉強会についてブログエントリを書きます[1]。勉強会には200名近くの方がご参加され、TwitterやZoomのQ&Aでもたくさんのコメントや質問をいただきました。このブログ記事では、勉強会の開催背景や各講演の概要についてレポートします。
勉強会開催の背景
今回「食べログの品質ダッシュボード」と題して、ソフトウェア開発に関する品質を可視化し改善する取り組みについての勉強会を開催しました。このテーマで開催した理由は、近年、アジャイル開発が普及したりDevOpsへと発展してきた経緯の中で、開発から品質保証、運用までのソフトウェア開発ライフサイクル全体のプロセスを改善する取り組みが盛んになってきているからです[2][3][4][5]。
スクラムからDevOpsへ
アジャイル開発初期のスクラムやXPからDevOpsへの発展の歴史は、繰り返し開発プロセスの改善範囲拡大の歴史と言ってもいいかもしれません[6]。アジャイル開発では短い開発サイクルを繰り返し、少しずつ動くソフトウェアを開発することが大きな特徴です。繰り返し開発が特徴のアジャイル開発ですが、スクラムなどの初期のアジャイルでは要求分析〜実装工程のみを繰り返しプロセスの対象としていました。テストやデプロイなどの手作業が多く何度も繰り返すことが難しかったため、QA工程や運用工程は繰り返しプロセスの中に含まれていませんでした。
その後アジャイル開発では、「パイプラインの自動化」「受け入れテストの自動化」「クラウド」「Infrastructure as Code (IaC)」などの技術により、テストやデプロイといった手作業も自動化できるようになりました。これにより、QA工程や運用工程もアジャイル開発が繰り返し開発として対象とする範囲に含まれるようになりました。これらの自動化技術によるプロセス改善の取り組みは「継続的デリバリー」「DevOps」として知られています。
DevOpsで繰り返しプロセスの改善活動が重要な理由
DevOpsでは開発から運用までの開発ライフサイクル全体を対象としたプロセスを繰り返し、開発します。DevOpsではその繰り返しプロセスの改善活動が非常に重要であり、その理由は３つあります[7]。
理由① 繰り返しプロセスは改善のインセンティブが高い
DevOpsでは開発から運用までの開発サイクルを繰り返して開発します。何十回、何百回とプロセスを繰り返すため、課題やボトルネックを抱えたまま繰り返す場合と、それらを解決して繰り返す場合では結果的に生産性に大きな差が出ます。そのため、繰り返しプロセスではプロセス改善のインセンティブが高いです。
理由② 複数役割・チームのコラボレーションの方法
DevOpsでは、開発エンジニア、デザイナー、QAエンジニア、インフラエンジニアなどの様々な役割、チームのメンバーが一つのプロセスの中でコラボレーションします。これらの役割のメンバーのうまいコラボレーションの方法はまだまだ手探りの状態であり、プロセスを分析しながら少しずつ改善する必要があります。
理由③ QC七つ道具などの分析手法が適用可能
ソフトウェア開発の文脈では繰り返しプロセスの分析や改善は新しい考え方ですが、製造業では「QC七つ道具」などの確立された品質分析のための手法があります。製造業の分析手法は繰り返しプロセスを前提としており、ウォーターフォールが主流のソフトウェア開発では適用が難しい歴史がありました。しかし、ソフトウェア開発でも繰り返し開発が主流となりQC七つ道具などを適用する土台ができてきました。
３つの講演とパネルディスカッション
こういった背景の中で、プロセス品質の可視化や品質改善がトピックとして盛り上がってきています。そこでこのトピックについてさらに深く議論するため、食べログでの開発から品質保証、運用までのソフトウェア開発ライフサイクル全体の品質を可視化し改善する取り組みを紹介し議論する勉強会を開催しました。
勉強会は3つの講演とパネルディスカッションで構成されました。３つの講演では、それぞれ食べログでの、プロセス品質の改善活動、内部品質の改善活動と、それらの品質を可視化するためのデータ分析基盤についてお話ししました。
- 講演①：開発プロセスを改善するために食べログの組織体制をマトリクス型組織へと変更した結果を定量的に分析したお話
- 講演②：プロセス品質が依存するコード品質について、食べログ17年分の歴史のあるコードのリファクタリング戦略のお話
- 講演③：品質を可視化するための食べログのデータ分析基盤のお話
また、パネルディスカッションでは、講演者とDeveloper Productivityチームのテックリードの荻野（このブログ記事の筆者）と電気通信大学の西先生を交え、品質分析の目的や手法について議論しました。
講演
これらの発表につきましては、詳細なブログ記事をそれぞれ近日中に投稿予定です。
講演１:マトリクス型組織の導入後の変化を定量的に捉える
講演2: コードのメトリクスに基づくリファクタリング戦略
講演3: 「品質ダッシュボード」と「データによる意思決定」
パネルディスカッション
パネルディスカッションでは、講演で紹介された食べログでの品質分析や改善の事例をベースとし下記の3つのポイントについて議論しました。
- A. 品質分析の始め方
- B. 品質分析の目的と達成度
- C. 品質分析手法
A. 品質分析の始め方
今回食べログでは事業会社の立場で品質分析と改善活動にあらためて本格的に取り組み始めました。食べログでの取り組みについて議論することで、品質分析を取り入れたことのない組織での始め方のポイントがいくつか見えてきました。
1つ目のポイントは、特性要因図やKGI/KPIツリーなどを通し、品質分析の目的と、分析対象のプロセスと計測対象のメトリクスの関係性を明らかにすることです。メトリクスを計測する目的は、そこからインサイトを取得し自分たちの開発スタイルへの理解を深くしていくことです。特性要因図やKGI/KPIツリーを通して、分析対象である自分たちの開発スタイルを洗い出し、インサイトを得るために必要となるメトリクスを取捨選択することが重要です。
2つ目のポイントは、業界標準などの「Elite」などの基準を目標として目指すということをしないことです。今回の講演では「改善にいろいろ取り組んだ結果Eliteになりました」という趣旨の発表がありましたが、品質分析のありがちな始め方として逆に数値基準を最初に目標として定めてしまうことがあります。数値目標達成が目的化してしまうとメトリクスハイになってしまい、本質的な問題解決とは別のところで数値目標を達成しようとズルをするといった問題が起きてしまいます。
3つ目のポイントはメトリクスを普段の業務でアクションにつなげる企業文化です。もともと食べログには利用時品質などのメトリクスについてはサービス品質改善のために活用する文化があり、今回の取り組みはそういった改善の文化をプロセス品質や内部品質に横展開するものでした。品質ダッシュボードはただ作るだけでなく、それを活用して改善活動のアクションにつなげるような文化を作ることも重要です。
4つ目のポイントは、分析手法やスキルです。品質分析ではメトリクスを取得し、そこからそのデータの特徴や傾向を明らかにします。そのためにはQC七つ道具などの統計的な分析手法や、それらを使いこなすためのスキルが重要です。特にSoftware Engineer in Test (SET)にはテスト自動化のスキルだけでなく、今後プロセス改善や品質分析のスキルが必要になりそうです。
B. 品質分析の目的や文化
品質分析には目的や文化が重要ですので、講演での品質分析の取り組みについて目的と文化について整理し、議論しました。
講演1の目的は、マトリクス型組織の導入やテスト自動化などのその他の改善効果を測定することでした。2022年5月から具体的に取り組み始め、KGI/KPIツリーを作成し、実際にメトリクスを品質ダッシュボード上に表示し改善効果を確認することができました。
今後の取り組みとして、テスト自動化や単体テストコードを書く文化を作ることを考えています。単体テストの自動化を開発チームに文化として根付かせることは、今でも開発組織で大きく話題になるトピックです[8]。食べログでは単体テスト自動化の文化を根付かせるため、勉強会やペアプロを実施して単体テストコードを書くハードルを下げる取り組みをしています。単体テストコードを書いていない人もコードレビューなどで単体テストコードを目にする機会が増えることで、文化として根付いていくことを期待しています。
講演2の目的は「リファクタリング前にコードをお掃除すること」でした。食べログのように10年以上自社開発でサービス提供している組織では、単純に機能追加を繰り返すだけでなく、継続的にソースコードをリファクタリングし保守性や拡張性を保つことも重要です。そこで更新回数やデッドコード行数などのソースコードメトリクスをもとに評価することで、お掃除の優先順位をサブシステムごとに検討することができました。メトリクスがないと闇雲にリファクタリングする必要がありましたが、メトリクスにもとづいて評価することでリファクタリングの影響力、信頼度と容易性にもとづいて定量的に戦略を立てることができています。
コード品質改善の次のステップとして、お掃除の文化を組織に根付かせることが挙げられてました。お掃除の文化を根付かせるために、お掃除の進捗がわかるダッシュボードを用意しています。ダイエット時に毎日体重計で体重が減っていることを確認できると嬉しいように、ソースコードのお掃除が進むとその変化がすぐにダッシュボードに反映されるようにすることで、お掃除の文化を根付かせることを狙っています。
C. 品質分析手法
品質分析の手法については、西先生からQC七つ道具をご紹介いただきました。QC七つ道具はハードウェアの工場で品質管理をするためのツールですが、近年ソフトウェア開発にも適用されるようになってきました。QC七つ道具には以下のものが含まれます。
- グラフ
- パレート図
- ヒストグラム
- 散布図
- 管理図
- 特性要因図
- チェックシート
今回の発表でも、講演1ではグラフを使ってマトリクス型組織導入前後でのプロセスメトリクスを比較したり、ヒストグラムを使って分布の全体像を把握したりしています。また、講演２では、散布図を使ってソースコードの更新回数とデッドコード行数の相関関係を調べたりしています。
今回の講演では使われてないQC七つ道具からは、特性要因図もご紹介いただきました。特性要因図は、プロセスの問題の原因となりえるものをツリー上に分解し表現したものです。「A.品質分析の始め方」でもご紹介したように、品質分析の目的やプロセスの問題点や原因とメトリクスを整理するのに活用できます。また、特性要因図を見ながらデータを分析し、分類することを層別と呼びます。特性要因図や層別を使うことで、複数のチームで起きている共通の問題を抽出したり、同じデータ上の別の問題をうまく区別できるようになります。
例えば、Four Keysの「変更のリードタイム」では、すべてのテストが自動化されておりコード変更後1時間以内にリリースできる「Elite」と、ウォーターフォールで開発し手動でQAを実行しているためコード変更後リリースまで６ヶ月以上かかる「Low」を同じデータ上で比較しますが、組織のプロセスがまったく異なるため層別して分析した方がよさそうです。
まとめ
アジャイル開発が発展し、DevOpsが普及した現在のソフトウェア開発では、開発から運用までの開発ライフサイクル全体を対象とした繰り返しプロセスの、品質分析と改善活動をおこなっていくことが重要です。「緊急Ques 食べログの品質ダッシュボード」では食べログでの、プロセス品質の改善活動、内部品質の改善活動と、それらの品質を可視化するためのデータ分析基盤についてお話ししました。また、パネルディスカッションでは、品質分析の始め方や手法について議論しました。
今回の勉強会では、自分たちの品質分析の取り組みの講演やパネルディスカッションを通し、自分たちの進んでいる方向性の正しさを実感できました。この勉強会で得た西先生や参加者のフィードバックをもとにさらに食べログのプロセス品質やサービス品質を改善していきます。また、西先生を中心に結成される「アジャイルメトリクスの研究会」に参加し、食べログのエンジニアリング組織として積極的に日本のアジャイルコミュニティ、品質コミュニティに貢献していきたいと考えています。
＊緊急Quesについてご興味を持っていただけましたら、下記のYouTube動画やTogetterもぜひご確認ください。
緊急Ques「食べログの品質ダッシュボード」 - YouTube
参考文献
[1] 緊急Ques ~食べログの品質ダッシュボード~ イベントページ
[3] QC七つ道具を利用したDevOpsプラクティスの導入による開発とテストの生産性改善
[4] 品質ダッシュボードを含むアジャイル品質保証の技術とパターン：SQuBok Guide最新版およびパターン集 QA to AQを通して
[5] LeanとDevOpsの科学
[6] アジャイル・DevOpsからDeveloper Productivityへ ~食べログのDeveloper Productivityチームが目指す姿~
[8] 組織に自動テストを根付かせる戦略
