こんにちは！品質改善推進ユニットの藤澤です。 この記事はLIFULLアドベントカレンダー3の15日目です。
今年のアドベントカレンダーは何を書こうかと考えていたところ、CTOからお題が飛んできました。
ゼロから立ち上げてきたというのは正しくなく、最初に立ち上げた方は他にいまして、取り組みの一つひとつもみんなの積み重ねですが、現在この組織で歴史を一番長く知っている人間として、代表してLIFULLの品質組織の歴史や取り組みをご紹介したいと思います。
誰に何を伝えたいか
- 品質管理・品質保証の仕事は正解がありません。ビジネスドメインや会社の文化、構造によって、やるべきことは変わってきます。
- しかし事業会社における品質担当者が実際どんな仕事をしているかについての情報は、勉強会が盛んな現在においても、見かける機会が多くありません。
- そこで、この記事では当社の品質組織に関して、これまでの歴史や取り組みをまるっとお伝えして、どこかで悩んでいるどなたかの、何かのご参考になることがあれば嬉しいなと思います。
LIFULLの品質組織の現在
現在のLIFULLの品質組織は、一つのユニットの中で、5つのグループに分かれて活動しています。
品質改善推進ユニット
QAグループ
いわゆるソフトウェアテストの専門部署。「テスト計画コンシェルジュ」と呼んでいる社内向けサービスや探索的テストなどのテストに関する技術でものづくりチームを支援。
SETグループ
Software Engineer in Test。テストを自動化する技術を駆使しして不具合流出を阻止。デプロイフローの改善も担当し開発者体験の向上を目指している。
ユーザーファースト推進グループ
人間中心設計やユーザーテストに関する技術と知見を提供。ユーザーの本当の声を集めて事業部に提供している。
セキュリティ グループ
ソフトウェアセキュリティの専門化チーム。脆弱性診断、各種ガイドライン整備、セキュリティを可視化する仕組みを作り、プロダクトセキュリティをものづくりチームと一緒に守りつつ、緊急時には対応支援も行う。
品質管理グループ
品質組織が立ち上がった時からある老舗のグループ。社内障害情報の把握や社内横断的なルールの調整、開発に関するツールの整備などをはじめ、品質良くするために必要なことであれば、分野を問わずサポートからヒップキックまで何でもやる。
現在はこれらの5つのグループが開発チームと一緒になってサービス開発を行っていますが、LIFULLの品質組織の始まりは9年前、「品質管理グループ」という名前の、たった2名の一つのグループとして始まりました。
以下、3年づつ初期、中期、後期に分けてどんな取り組みを行ってきたかご紹介します。
LIFULLの品質組織の歴史
初期(2011年~2013年頃)
2010年10月頃からグループ立ち上げ準備がはじまり、2011年4月に「品質管理グループ」という部署が正式に発足しました。
記憶に残っている最初の仕事は、当時サービス品質において一番インパクトが大きい問題であったインフラ故障に起因するサービス停止の問題でした。この当時はまだオンプレ環境でサービスが稼働していたのですが、夜間や休日の障害対応体制が整備されておらず、障害発生時には社員ではなく役員がデータセンターに駆けつけて対応し、復旧するまでに4時間もかかるケースがある時代でした。
インフラエンジニアにデータセンターの近くに引っ越してもらう
この課題について、以下のようなアプローチで検討を行いました。
- インフラ障害によるサービス停止のインパクトを1時間あたりの売上損害金額として算出
- 障害発生からリカバリーまでの対応を時系列で可視化(例: 認知から状況把握まで15分、データセンター移動まで60分...など)
- 可視化されたリードタイムと損失金額から目標復旧時間を定め、解決策を検討
結果、障害対応を行う可能性のある部署の方にデータセンターの近くに引っ越していただいたり、そのための手当を会社として導入したりしました(現在はクラウド化によってこの取り組みは今はありません)。
実はこれは私の中途入社後の初仕事だったのですが、必要ならば社員の住居や会社の賃金体系にまで影響するような提案をしても、嫌がられるどころかどんどん話が進んでいきました。この体験が後々、LIFULLの品質組織として取組みを検討していく際に役割を超えて何かをやっちゃだめ、なんてないと考えられるようになる原体験となりました。
この2011年から始まる3年間では次のような取り組みを行いました。
障害対応
至急の対応が必要な障害が発生したら、全社共有されるチケット管理システムに必ず起票してもらうようにしました。障害チケットが起票されると、障害対応を行っているチームのところにいって、できるだけ邪魔にならないようにしつつ様子を伺い、影響や対応状況を把握して、必要な情報展開を社内に行うようにしました。
これを繰り返すことで以下のような効果がありました
- どのシステムとどのシステムがつながっているのかが分かってくる
- 誰がどのシステムに詳しいのかが分かってくる
- 結果として事後分析や改善のための取り組みの際に社内で動きやすくなる
テスト自動化
当時のLIFULL HOME'Sはすでにたくさんの開発者がおり、日々アップデートされるため、サービス全体の仕様を完全に把握するということが不可能な状況でした。また複数のチームが同時に開発を行っているため、影響範囲の考慮漏れによる障害も少なくありませんでした。
対策として回帰テストの自動化を開始。最初はSeleniumIDEというブラウザ操作を記録・再生可能な仕組みを使って回帰テストの自動化を行いましたが、メンテナンス性の低さによりプロジェクトを途中で断念。Page Object Patternを採用したフレームワークをPythonで構築し、第一世代の回帰テストとして運用し始めました。
Pythonによるテスト自動化はある程度うまくいきましたが、LIFULL HOME'Sが掲載する物件情報の表示確認テストにおいては、確認項目の多さとHTMLレイアウトが変更される頻度の高さから、テストスクリプトのメンテナンスコストの増加が懸念となっていき、これを解決する方法として画像の差分比較によるテスト方法がグループ内で提案され、検証活動がこのころに始まっています。
よくある考慮もれチェックリストとRFP
現在も当社で使われている「開発チェックシート」というチェックリストは、このころ導入されました。 障害分析や、開発者アンケート、インタビューの結果をまとめた、設計・実装・テストにおいて確認しておきたい項目をまとめたチェックリストです。 すべてのリポジトリではありませんが、頻繁に開発されているリポジトリでは、このチェックリストの確認が開発の必須工程になっています。
また外注開発におけるRFP(Request For Proposal)の必須化もこのころに行いました。LIFULLは内製開発の経験は多いのですが、外部のパートナー企業と開発を行う経験が少なかったため、外部パートナー企業との開発を内製と同じような感覚で進めてしまって、プロジェクトの途中で問題が生じることがありました。 現在は、一定予算以上の開発ではRFPが必須になっており、テンプレートの提供だけでなく、RFP作成自体も支援する社内向けサービスを品質管理グループから提供しています。
中期(2014年~2016年頃)
初期を「1. 障害対応を起点とする情報収集」、「2. RFP/開発チェックシートによる予防」、「3. 自動テストによる水際阻止」を特徴とすると、中期の特徴は「テスト技術の強化」と「自動テストの進化」です。
「品質管理グループ」と「QAグループ」の2グループ体制へ
開発チェックシートや自動回帰テストの実施によって、組織を横断して年に複数回出現するような類似の障害は減っていったのですが、そういった全体的なアプローチだけでは個別のプロジェクトへの支援は十分ではありませんでした。「このプロジェクトでは絶対にバグを出したくない」と開発者が思うようなプロジェクトで障害を出さないようにするには、テストの技術そのものを高める必要がありました。
組織を分離してスコープを狭めることで、そのスコープの能力を高めるスピードを上げることができると考えました。 そこでグループを2つに分離し、新設された「QAグループ」ではテスト技術を中心とした活動を高めることにしました。
LIFULLでのQAのあり方
会社肝いりの施策や、リスクが高いプロジェクトについてはQAグループが参加し、テストの計画や設計を行います。 また、QAメンバーが直接的に関与しなくても、開発チームがテストの質を高められるようにする取り組みとして「テスト計画コンシェルジュ」という社内向けサービスを行っています。これはプロジェクトにとってちょうどよい品質を作れるように、開発チームとQAが会話をしながら、60分でテスト計画を作成する活動です。また直接支援依頼を受けていない施策も含めてリスク評価を行っており、QA側から声をかけることもあります。このあたりは以下のスライドにまとめられていますので、よろしければこちらもご覧ください。
www.slideshare.net
テスト自動化の進化
初期フェーズで運用が始まっていたPythonで構築したフレームワークですが、数年が経過し、テスト実行時間の増加、大量のメンテナンス、テストシナリオの可読性の低下などの課題が顕在化してきました。
またLIFULL HOME'Sでは週2回(火曜・木曜)をリリース日としていましたが、より高頻度かつ柔軟なリリース調整を可能にするために月~木であれば毎日リリースできる体制に変更することを目指して、自動テストも改善する必要がありました。それまでに構築していた自動テストでは、毎日リリースするにはメンテナンスのコストが高すぎたのです。そこで「運用コストを半減させること」を目指して、LIFULL第三世代の自動テストフレームワークの構築をこのころに開始しました。
このフレームワークでは以下のような機能を盛り込みました。
- テスト実行だけでなく、レポートティング機能によって結果を確認しやすくする
- 自動リトライによってFlakyなテストの結果確認の負担をへらす
- テスト自動化処理の詳細と、テストシナリオの記述を分離し、かつ成約を設けることで可読性、メンテナンス性を向上させる
このフレームワークはその後、OSSとして公開しています。
また、初期の頃に検証が始まっていた画像差分テストの仕組みが、このころには2世代目に進化し、JaSSTで発表したりしていました。 この仕組みはその後も改善が続けられ、先日OSSとしても公開しました。 www.lifull.blog
中期のその他の取り組み
長くなってきたので短めに書きますが、この時期に行ったその他活動は以下のようなものがあります。
- 主要リポジトリのGithub移行とブランチ戦略導入
- 全社標準のプロジェクト、ナレッジ管理システムとしてJira/Confluenceの導入
- サイトレスポンスタイムの継続的監視環境の構築
- セキュリティ開発ガイドライン整備とセキュリティ勉強会の実施
- ユーザビリティテストの開始
- RFPだけでは予防できなかった問題への解決としてのプロジェクトマネジメント支援への進出
後期(2017年~2019年頃)
このころ、品質組織内でよく利用していた品質モデルは以下の図です。
このモデルから、Webサービスにとって重要なのは次の4属性であるとしていました。
- 有用性 (機能性、正確性): 利用者の「成果を挙げられる」または「制約を取り除ける」機能を提供できているか
- 可用性 (信頼性): 使いたいときに、ストレスなく利用できるかどうか
- 使用性 (ユーザビリティ、アクセシビリティ): 簡単に、誰でもどんな状況でも使えるか
- 安全性 (セキュリティ): 安全は守られているか
この品質モデルを推進すべく新たに「ユーザーファースト推進グループ」「セキュリティグループ」、そして週4リリースの実現や自動化技術の社内展開で頼もしさを増していた「SETグループ」の3つを加えて、現在の5グループ体制の形が出来たのがこの時期です。
この時期に開始した活動は以下のものがあります。
ユーザーテスト
サービスの質を数字だけで判断するのではなく、本当のユーザーの声を聞くことを推進する活動を開始しました。
下図は開発工程におけるユーザーテストの種類とタイミングを説明したものです。
脆弱性診断と脆弱性可視化
Webの脆弱性診断だけでなくスマホアプリケーションの静的解析環境および脆弱性診断を開始しました。 以下のツールやドキュメントに大変お世話になりました。 github.com mobile-security.gitbook.io
失敗DB
開発における失敗情報を蓄積、振り返りを促進する仕組みをConfluence上で構築しました。
品質ダッシュボード
品質モデルに基づく数値をダッシュボード化。収集した情報をDataDogで可視化しています。現在取得している情報には以下があります。
- 稼働率
- HTTPステータス
- レスポンスタイム
- アクセシビリティ
- SEO適合度
- SSL証明書有効期限:残日数
- 変更影響度 (年) (障害報告件数 / リリース件数)
まとめ
非常に簡単にですが、私達の品質組織の歴史と取り組みをご紹介させていただきました。
失敗や反省も山程あります。本来は失敗したことのほうが情報として価値があるのかもしれませんが、書き始めると本当に書ききれないので今回は割愛させていただきました。もしそのあたりも含めてご質問やもっと聞いてみたいという方が、もしもいらっしゃいましたら遠慮なくこちらまでご連絡ください。いっしょにディスカッションして世の中の品質組織の仕事をみんなでより良くしていきましょう。
また現在、LIFULLでは仲間を募集しております！ カジュアル面談も受付していますのでご興味ある方は是非ご参加ください！
