はじめに
はじめまして、食べログシステム本部のプロダクトチームでメディア領域の開発マネージャーをしている関戸です。 2022年9月29(木)に緊急Ques 「食べログの品質ダッシュボード」という勉強会に私を含む食べログのエンジニアが登壇しました。
QuesとはSoftware品質保証に関わるQAエンジニアの活性化を目的としたQA専門イベントで、食べログでのQAに関わる取り組みを紹介しました。勉強会の様子については本勉強会の発起人である荻野が書いたレポートをご参照ください。
本記事は私の発表である「マトリクス型組織の導入後の変化を定量的に捉える」の前半パートを文字起こししたものです。 発表概要としては、食べログの開発プロセス品質について、実際の開発プロセスの改善事例をもとに品質の変化を定量的に分析した結果の紹介になります。 前半パートでは、食べログの開発プロセス品質の定量的な分析にあたって、事例としてマトリクス型組織導入後の開発プロセス改善の取り組みを紹介しています。
本記事は、発表に興味があったものの参加できなかった方や、テキストで読みたい方向けに作成しています。発表スライド、YouTube動画やTogetterまとめを作成していますので、実際の講演や当時の反応を見たい方はこちらも合わせてご確認いただければ幸いです。
発表概要
「マトリクス型組織の導入後の変化を定量的に捉える」というテーマについて、関戸とhagevvashiの共同発表という形でご紹介させていただきます。
改めまして、株式会社カカクコムの関戸と申します。ユーザー向け食べログメディア領域の開発担当のマネージャーをしています。日々、エンジニアが企画やデザイナーなど他職種と関わっていく中で成長し、常に変化するチーム作りをしています。よろしくお願いいたします。
食べログの開発プロセス品質を定量的に分析した話
QuesはQAエンジニアのイベントであり、今回の発表は食べログの開発プロセス品質を定量的に分析した話になります。ただ分析するだけでなく、事業の成果につなげたいという観点で、開発エンジニアも一緒に分析に取り組みましたので、QAエンジニアと共同発表することにしました。
食べログにおける品質の分析は今まさに取り組み始めたところです。本格的にダッシュボードとして運用していくのはこれからであり、その手始めとなる分析をした話になります。
今回の発表内容はQAの観点でいうと品質モデル[1]におけるプロセス品質として位置づけられます。
開発プロセスを改善して事業の成果につなげる
具体的な分析に取り組むにあたって、Why,What,Howの観点で考えてみました。
分析の目的であるWhyについては、「開発プロセスを改善して事業の成果につなげること」としました。
その目的のもとで、分析対象となるWhatについては、「今までの開発プロセス改善の取り組みとその成果」が挙げられます。具体的な事例として、マトリクス型組織導入後の開発プロセス改善の取り組みがありましたので、この記事で紹介します。
分析の方法となるHowについては、「開発プロセスの具体的な形である開発チケットやプルリクエストのデータを集計して傾向を捉えること」が考えられます。そのために用いた指標と分析結果については、引き続きQAエンジニアより紹介します。
改めて発表全体を通した問いとしてまとめると、「マトリクス型組織を導入して、開発プロセス改善に取り組んできたが、改善による変化を定量的に捉えられるか？」となります。この主題に答えていく形で発表します。
「社内受託」のような状態から職種一体型へ
分析対象とした具体的な事例として、マトリクス型組織導入後の開発プロセス改善の取り組みをご紹介します。
食べログでは長年、組織のサイロ化による部門間のコミュニケーションコストの増大という課題がありました。例えば、開発部は開発のことだけ考える、企画部やデザイン部も同じで、それぞれで考えた情報の受け渡しをするだけというサイロ化の課題です。
サイロ化した状態では情報が閉じがちであるため、情報受け渡しのコミュニケーションコストが高いという課題もありました。わかりやすく言えば、「社内受託」のような状態となっていました。
そこで食べログでは、マトリクス型組織[2]の導入を進めました。職能横断でミッションの達成に向けて開発のライフサイクル全体に責任を持つチーム体制です。
マトリクス型組織の導入によって、「社内受託」のような状態だったところから、企画・エンジニア・デザイナーが一体となって案件のアイデア出しからクローズまで取り組む職種一体型に変わりました。
組織の形だけでなく開発プロセスを改善する
ただ組織の形だけ変えても、現場で働く人からすると変化の実感は得られないと考えます。現場で働く一人一人がちゃんと実感を得られて、ひいては事業の成果につなげるためにも、開発プロセスの改善に取り組みました。
開発プロセスの改善にあたって、具体的にはリリース数とリリースサイズについて変化を目指しました。リリース数は増やしていきたい、リリース数を増やすためにはリリースサイズを小さくしたいと考えました。また、障害数については引き続き減らす取り組みを継続したいと考えました。
小さく高速にPDCAを回す
まずはリリース数を増やすための取り組みをご紹介します。
2020年10月にマトリクス型組織を導入し、まずは効率的に成果を上げる方法を模索しました。いろいろ模索する中で、各職種が一体となって開発プロセスを見直していく文化ができました。
そして、2021年10月にリリース数をチームの目標として設定し、本格的にリリース数を増やしていく取り組みをしました。従来の綿密な計画にもとづく機能改修をするといった方法を変えて、小さく高速にPDCAを回す開発プロセスの確立に取り組みました。その結果、リリース数の増加につながり始めました。
「機能改修のコンフリクト」という課題
リリース数を増やしていく上で、ボトルネックとなる課題がありました。機能改修のコンフリクトという課題です。
従来のような機能軸の組織では、機能改修はチームで完結できていました。例えば、チームとしてレストラン系機能を担当するチームやユーザー系機能を担当するチームがありました。レストランチームは、レストラン検索といったレストランが関わる機能のみ機能改修の対象としていました。そのため、レストラン系機能を担当するチームがユーザーに対するメール通知などユーザーが関わる機能を改修することはありませんでした。
一方で、ミッションを軸としたマトリクス型組織では、各チームで様々な機能について改修が発生し、コンフリクトが発生しやすい状況でした。例えば、チームとして、SEOをミッションとするチームやアプリUI/UXをミッションするチームがあります。SEOチームでレストラン検索の機能改修をすることがあり、アプリUI/UXチームでもミッションを達成するために必要に応じて同じくレストラン検索の機能改修をすることがありました。
上記のようなコンフリクトを防ぐために、改めて機能軸で主管チームを整理して、レビューの運用をしました。例えば、アプリUI/UXチームでレストラン検索の機能改修を多く実施するので、レストラン検索機能の主管チームとして、SEOチームがレストラン検索の機能改修をするときは、アプリUI/UXチームのレビューを受けるといった運用です。
この取り組みにより、ボトルネックを解消してリリース数を増やすことが可能になると考えています。実際はまだまだコンフリクトは発生している状況なので、より良い運用の形を模索して日々改善に取り組んでいます。
小さなユーザー体験の改善を繰り返す
リリース数を増やしていく上でのリリースサイズを小さくすることについてです。
リリース数を増やしていくために小さく高速にPDCAを回していくという話がありました。
取り組みとしては、大きな機能改修を実施するのではなく、小さなユーザー体験の改善をするリリースを繰り返していくことがありました。一つ一つのリリースでコスパよく効果を出していくために、すぐにできてかつ効果が見込まれることをひたすらリリースしていきました。結果として、リリースサイズとしては小さくなりました。
また、ABテストの活用も実施しました。リリースによる結果について素早くフィードバックを得て、次のアクションにつなげるために、複数のパターンを同時に比較するABテストという手段を取りました。事前の検討に時間をかけすぎず、実地で検証していく形であり、一つ一つのリリースサイズとしても小さくする必要がありました。
エンジニアと他職種、エンジニア間の関わりを変える
最後に障害数についてです。
リリース数を増やしていくに伴って、障害数が増えるようなことは避けたいと考えました。
障害数の増加を防ぐためには、従来ではエンジニアが関わっていなかった要件定義での早い段階での参画に取り組みました。開発者としては、すでに決まった要件について非機能要件上のリスクがあったとしても、そのままその実現を考えてしまうことはよくあります。要件として決まる以前の早い段階で、非機能要件上のリスクを検知することで、リスクを抱えたまま実現に進んでしまうことを少なくしようと考えました。
また、マトリクス型組織では企画・デザイナー・エンジニアといった各職種間でのつながりは密になりましたが、逆にエンジニア間のつながりが希薄となり、ノウハウの共有がされずに結果としてシステム品質にばらつきが出るといった課題が見えてきました。改めて、機能コンフリクトを防ぐためのレビュー運用だけでなく、設計方針で抑えておくべきポイントを議論してまとめるなど、エンジニア間でのつながりを作り、共通認識を構築していきました。
上記の取り組みにより障害数の増加は一定防げていると考えますが、各開発者のスキルや努力によるところも大きいと思いますので、引き続き障害数の増加を防ぐ仕組みとして取り組んでいきます。
さらなる変化の機会を見出す
まとめとして、改めて事業の成果につなげることを目指すことについて考えます。
発表の冒頭で変化の実感を得られるかどうかを課題として提示していました。
今までご紹介してきたリリース数の増加や効果を見ながらの検証などの取り組みや、職種を超えた一体感により、マトリクス型組織の導入による変化は実感できてきました。
今後、事業の成果につなげるというゴールに向かっていくためには、感覚だけではなく、開発プロセスを指標で捉えることが必要と考えています。自分たちが取り組んできたことを指標にもとづく数値として表現することで、さらなる変化の機会となる点を見出していきたいです。
指標で捉えることは、変化の機会を見出すことが目的であり、高い水準の指標を目指すだけのことはしません。指標にもとづく数値で表現することで、他社や時系列での比較が可能になり、比較を通して課題がありそうな点が見えてくることを期待しています。その点を踏まえて、課題を見つけて改善し、変化の機会を作っていくことで、事業の成果につなげていきたいです。
開発プロセスを指標で捉えた結果については、引き続き別の記事でご紹介します。
参考文献
[1]誉田 直美、他(2016) アジャイル品質保証の動向 SQuBOK Review2016, Vol.1, pp.1-10
