自己紹介
私は、現在の会社に2021年12月末に参加しました。
本日が2022年5月で、約半年なので新規参加も新規参加のエンジニアです。
なぜ私が職業エンジニアを志したのか
後の話にも大きく関わってきますので、ここで説明しておきます。
一言で言えば、『LeanとDevOpsの科学』を読み、統計的に正しいとされるプラクティスを実践することでエンジニア組織のパフォーマンスを上げ、会社のビジネスをより成長させたいという夢を持ってしまったからです。
『LeanとDevOpsの科学』との出会い
私は、日頃から様々なジャンルのPodcastをよく聴いています。
そんな折にたまたま、t_wadaさんとyasaichiさんが運営されているポッドキャストtexta.fmの「5. Accelerate」を聴く機会があり、そこで本書が紹介されていました。
お二人の話に心が踊り、そのPodcastを聴き終える頃には、すっかりエンジニアリングと経営をつなげることに使命を感じるようになっていました。
ふと聴いたPodcastが人生を変えてしまうのだから、人生何があるかわからないですね笑
そこから、texta.fmにドハマリしてしまい、テスト駆動開発・アーキテクチャ設計・組織エンジニアリングなど様々なことに興味が湧いてきました。
おかげさまでフルサイクル開発者としての道を着実に進むことができているので、お二方には大いに感謝しております。
出典：Netflixにおけるフルサイクル開発者―開発したものが運用する
本記事の執筆スタイル
基本的には、時系列に沿って書いております。
チームに新規参加したエンジニアがその時々で何を考え、どう行動し、ゴールにたどり着いたのかが少しでも伝われば幸いです。
以下本題
どんな人にこの記事を読んでほしいか
- テスト自動化の体験談について興味のあるエンジニア・QA担当のみなさま
- 『LeanとDevOpsの科学』のプラクティスを実践した過程・結果に興味のあるみなさま
本記事を読むための前提知識
本記事は『LeanとDevOpsの科学』の内容を前提として執筆しております。
以下のリンク先で背景知識を持っていただいた上で本記事をご覧いただけますとより理解も深まるかと存じます。
5. Accelerate
6. 1on1 in Public
質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition
『LeanとDevOpsの科学』まとめ - Qiita
とはいえ、何も説明しないわけにもいかないので、軽く私なりの要約をしておきます。
私なりの要約
- 現代においてはビジネスの中核にソフトウェア産業が君臨するようになりました。
- ビジネスの収益性・生産性などに影響を与える指標が膨大な統計データから3つ発見されました。
- それらは、「デプロイ頻度」「サイクルタイム」「MTTR」です。
- それら3つの指標を改善する24のケイパビリティがあるのでそれらを実践していきましょう。
ざっくり図にするとこんな感じです。
とするならば、我々がエンジニアがすべきことは以下になります。
- サイクルタイムなどのメトリクスを計測する。
- 24のケイパビリティを参考にボトルネックをひたすら解消し、メトリクスを改善し続ける
まずは結論
時系列としては以下のような流れで改善を行っていきました。
- 自チームのサイクルタイムを計測(2月初頭)
- 開発のボトルネックを特定(2月中旬)
- ローコードテスト自動化ツールmablでボトルネックを解消し始める(2月後半~3月末)
- 非エンジニアであるQAメンバーが使いこなせるようにレクチャー(4月初頭~4月末)
- 自チームのサイクルタイムを約1/7にまで短縮(4月末)
- 他プロダクトチームに展開する準備完了(今ココ)
- アジリティを獲得した結果、新規ビジネスや新規プロダクトをリードする余裕が生まれ始める(今ココ)
改善結果
サイクルタイムの計測を行い始めた2月時点から自動E2Eテストが完成するまでの2ヶ月間でサイクルタイムは以下のように改善しました。
2022年2月時点： 37.5日 2022年4月時点： 5.55日
『LeanとDevOpsの科学』の指標に従えば、ローパフォーマーからハイパフォーマーになることができました
サイクルタイム全体のより詳細な内訳
開発フェーズ
2022年2月時点： 10.5日 2022年4月時点： 3.1日
※コードをコミットし始めてからプルリクエストを出すまでの時間と定義
レビューフェーズ
2022年2月時点： 9.2日 2022年4月時点： 2.4日
※プルリクエストを出してからそれがレビュー担当者全員にapproveされるまでの時間と定義
QAフェーズ
2022年2月時点： 17.8日 2022年4月時点： 0.05日
※QA依頼を出してから本番環境にリリースされるまでにかかる時間と定義
サイクルタイム計測のきっかけ(2月初頭)
私の所属するチームでは朝会・夕会があります。
そこでお気に入りの技術書について話す機会があり、
『LeanとDevOpsの科学』がきっかけでエンジニアになったという話をチームリーダーにしました。
その際に大いに興味を持っていただき、「せっかくならメトリクスの計測を中森君の個人目標にするのはどう？やり方も全部任せるよ」 と提案していただきました。
天啓とはまさにこのこと。
自分がやりたいことに専念していいよというお墨付きをもらえるばかりか、それをチームが応援してくれるわけです。
「推測するな、計測せよ」という格言にも従い、では計測しようではないか！となったわけです。
ということで、比較的容易に計測ができるサイクルタイムを計測することにしました。
計測方法
当初は、Four Keys 〜自分たちの開発レベルを定量化してイケてる DevOps チームになろう〜
を参考にGithub Webhookを使い厳密にメトリクスの計測を行おうと考えたのですが、一人でやるにはあまりにも時間がかかりそうに感じたので他の方法を模索することにしました。
ところで、弊社ではzenhubを使いカンバンによるissue管理を行っています。
「カンバンの移動を適切に行うことで、開発サイクルの各フェーズでどれだけ時間を使っているのかを計測できるかも」とチームリーダーにアドバイスしていただきました。
そこで、厳密な計測からは少しずれてしまうものの計測の労力がかなり少ないので、zenhubを使いサイクルタイムを計測し始めることとしました。
計測から見えてきたこと(2月中旬)
計測の結果、以下の事実が判明しました。
2021年の11月時点でサイクルタイムが約9日だったのが、2022年の2月には約35日になっている。
より詳細に言えば、
- 昨年11月時点と比べてサイクルタイム全体で4倍遅くなっている。
- 開発フェーズとレビューフェーズにかかる時間は約3.3倍程度遅くなっている。
- QAフェーズにかかる時間が約6倍となっており、他フェーズよりもパフォーマンスが異常に悪化している。
そこからいくつかの仮説を導き出しました。
3つの仮説
1.開発フェーズに要する時間が間延びしたのは、新規参加したエンジニアの私に一因がある
これは、チームの暗黙知を吸収しきれていない私の生産性が他のエンジニアに比して低いというだけなので、日々のキャッチアップでいくらでも改善できるはずです。
これはあくまでも個人の問題であり、構造的な問題ではないです。
2.レビューフェーズの間延びについても、新規参加したエンジニアの私に一因がある
具体的には、私の書くコードがレビューしづらいものであること、並びにコミットの切り方・コミットメッセージの書き方に一因がありそうです。
こちらに関しても日々のキャッチアップでいくらでも改善できるはずであり構造的な問題ではないです。
補足：少人数のチームに所属しているので、私一人が足を引っ張ると、全体に大きな悪影響を与えてしまっていると理解していただければと思います。
3.その一方で、QAフェーズの悪化は何らかの外部要因が働いており構造的な問題の気配がしました
なぜなら、QAはプロダクトチームの外にあるQAチームに行っていただいていたからです。
そこでより詳細な調査の旅に出ることにしました。
構造的な問題にアプローチしよう
ここで、個人の問題、構造的な問題と場合分けしているのには理由があります。
私は、それが個人的な問題であれば業務の時間以外で解消すればいいと考えています。
プログラミングスキルが低ければ、仕事終わりに学習すればいいですし、Githubを使いこなせていないのであれば書籍を買い学習すればいいだけです。
本来、業務において取り組むべきは、構造的な問題のはずです。
一人で成し遂げられないことを成し遂げるのが会社であるのだから、構造的な問題に積極的にアプローチしたいわけです。
構造問題を解消していくことで、仕事仲間が幸せに働ける居場所が広がって欲しいという思いもあります。
ここらへんの話は、『エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング』をお読みいただけるとよりイメージしやすいかもしれません。
ヒアリング調査から明らかになったこと
弊社に創業当初から所属しているエンジニアの方数名とQAチームのリーダーにヒアリングを行いました。
そこで以下の事実が明らかになりました。
- 創業当初の意思決定として、スピード感を持って開発するためにRailsのリクエストスペック(APIテスト)のみ書くという意思決定が行われていた。結果として、ユニットテストとE2Eテストが書かれていない。
- プロダクトの急成長に伴うエンジニアの人員増に比してQAリソースは増えていない。
- プロダクト数の増加ならびに1プロダクト当たりの機能追加も加速度的に進んでおり、手動E2Eテストの項目数も加速度的に増加している。
- あるプロダクトチームが大きな機能追加を行った場合の手動E2EテストでQAリソースが専有されてしまう。
結果、別のあるチームが小さな機能追加を行った場合の手動E2Eテストでさえも長い待ち時間が発生してしまう。 - エンジニアがマインドマップツールを使ってE2Eテストの項目を記載し、それをもとにQAチームがテストを行うので、コミュニケーション齟齬が以前よりも頻繁に起きるようになっている。
これで謎が解けました。
小さな修正のQAでも多くの時間がかかっていたのは、やはり構造的な問題だったのです。
ここで誤解しないでいただきたいのは、この構造的な問題を引き起こしてしまった過去の意思決定の積み重ねを否定するつもりは全くないということです。
過去において最適だとされていた意思決定の積み重ねが牙を向き始めた。
ただそれだけのことです。牙を向き始めたのならやり方を変えていけばいいと思います。
問題を認識した、まさにこの瞬間から動き出すことで事態は好転させられます。
補足：
詳細に立ち入ることはしませんが、筆者としては創業当時のユニットテストを書かないという意思決定は非常に合理的な判断だったと考えております。
もしご興味のある方は以下の記事をお読みいただけるとイメージが湧きやすいかと存じます。
TDD is dead. Long live testing.
TDD再考 (2) – 何故、ほとんどのユニットテストは無駄なのか？
構造的問題がさらなる構造的問題を生む
ヒアリング調査を整理していた際に、突然ある考えが自身を支配し始めました。
それは、「QAフェーズが間延びしてたことが、開発・レビューフェーズにも悪影響を与えているはず」、
より詳細に言えば、「QAフェーズにかける総時間を少なくするために、各プロダクトチームは以前よりも大きな機能追加を行ってしまっているのではないか？」 というものです。
- 1回のリリースあたりのissueが増えたり、issue自体が肥大化してしまえば、開発フェーズは当然長くなります。
- 結果、レビューフェーズも長くなってしまいます。
- 並行開発の常態化は、コンフリクトのリスクを高め、サイクルタイム全体の悪化につながります。
そうした現状を証明するように私のチームでは、デプロイ頻度は3ヶ月前と比べて半減しておりました。
もし、これが正しいものだとすれば非常にまずいと言わざるを得ません。
どうやらそろそろ問題解決の旅に出る必要がありそうです。
そしてこの絶望的な状況を前に不思議と活力が湧いている私がそこにいました。
「空席」を探す
客観的にどう考えても深刻な状況にも関わらず活力が湧いてきたのは、私が組織で行動するときに意識している考え方、「空席」を探すにあります。
「空席」というのは 「組織の中でいまだ誰もそのポジションを確立できておらず、そのポジションを確立することができれば大きく組織に貢献できる場所」 を指して、私がよく使う言葉です。
弊社では、テスト自動化が大きなペインになっていることは明らかでした。
残念ながら、このペインに対して根本治療は行われていませんでした。
このテスト自動化というペインを根本治療することが「空席」を埋めることになると私は確信しました。
「空席」を探しだし、その「空席」を埋めることができれば、次第にそこが「居場所」になり、楽しく働けるようになると思いますので、皆様もご自身が所属する組織の「空席」を探してほしいと思います。
各々が「居場所」を見つけ出せる会社・組織が増えれば増えるほどより幸福な社会につながると思っております。
自動テストツールを比較(2月後半~3月初頭)
サイクルタイムを計測してわかった事実と仮説をチームリーダーが深刻に受け止めてくださったおかげで、毎週金曜日は開発を一切行わず、テストに費やす日（通称：アジャイルテストDay）として設定してくださいました。
初めてのアジャイルテストDayでは、自動E2Eテストツールを調べることになりました。
そこで挙がった論点は以下のようなものです。
- Cypressを筆頭とした開発者ツールを使うのか？
- mablを筆頭としたローコード・ノーコードのテスト自動化サービスを使うのか？
それぞれのメリット・デメリットをざっくり表にまとめたのがこちらです。
※Cypressでは、テスト作成者がエンジニアに限られるので、導入コストもメンテナンスコスト高くつくと評価
個人的には以下の理由からエンジニア以外でも使用が可能なローコード・ノーコードのSaaSサービスを使いたいと考えました。
- 弊社の歴史としてCypressを使い自動テストを行ったことがあるが、エンジニアリソースの確保に苦戦し断念している。
-
2021年12月のITエンジニア・クリエイター正社員転職/フリーランス市場動向によれば、正社員エンジニアの求人倍率は17.8倍となっており、中長期的にエンジニアリソースの確保はより難しくなる。
その結果、テスト作成者がエンジニアに限定されるCypressを使うことのリスクは日々増大している。 - SaaSサービスでどうしても自動化できないものに関してはCypressなどの開発者ツールで自動化を進めればいい。
幸い、私の見解にチームリーダーも理解を示してくださり、めぼしいSaaSサービスいくつかをトライアルで使用することになりました。
いくつかのツールを1週間ほど使用してみた結果、弊社ではmablを採用することにしました。
その理由は下記のとおりです。
- 基本的にはノーコードでテストを作成できる一方で、少しプログラミング的な発想を身につければ、非エンジニアでもメンテコストを限りなく小さくしたテストが書けると感じた。
- 料金もリーズナブルなので、決済者の説得も比較的容易に感じた。
ところで、『LeanとDevOpsの科学』の調査結果から、エンジニア組織のパフォーマンスを左右するメトリクスとしてデプロイ頻度があります。
mablはこのデプロイ頻度が他のSaaSサービスに比べて高かったです。
個人的には、これがmablを選択する決め手になりました。
いざテスト自動化へ
超えなければいけないハードル
ツール選定としては、mabl一択となったのですが、超えるべきハードルがまだあります。
mablはSaaSサービスで利用料金が発生するため、mablが費用対効果に十分見合うことを決済者に証明する必要があるのです。
ここで証明しなければいけないことは、以下の2つです。
- mabl導入以降でE2Eテストにかかる時間を大きく削減できるのか？
- 本当に非エンジニアでも使いこなすことができるのか？
そして、決済が下りなかったときのことを考えると少し怖くなってきました。
なぜなら、テスト自動化に少なくない時間を投じた結果、ツールが採用されなければ、あとに残るものは何もないと感じたからです。
機会費用で考える
私はこういう場合、常に最悪の状況を想像することにしています。
今回で言えば最悪の状況とは、mablにさんざん時間をつかったものの決済が下りないというものです。
この場合、失われてしまうものはなんでしょうか？
そう、時間です。
より正しく表現するならば、その時間を使ってできたはずであろう機能開発です
ただ大変幸福なことに、私は新規参加したばっかりのエンジニア。
技術力でもプロダクトの仕様把握という点でも他のエンジニアに劣るため、時間あたりの機能開発は、他のエンジニアに比べて少ないわけです。
つまり、機会費用は弊社エンジニアの中で最も低いわけです！！
欠点は見方を変えると強みになるとはまさにこのこと
また、mablが導入されなかったしても私には以下のメリットがあります。
- テストを作る過程でプロダクトを隅から隅まで実際に触れるので、仕様理解が進む
- 仕様理解が進めば、機能開発がスムーズになる
- テスト関係の話題が再燃した際に、リードできる立場になりうる
さぁ、心の準備もできました。
あとは、一気呵成にテストを書くだけです。
mablに全力投球した1ヶ月(3月初頭~3月末)
最高のツールを携えて、覚悟を決めた私は、チームリーダーにmablに1ヶ月ほど全力投球をさせてほしい旨を伝えました。
デプロイの独立性を失いつつあることに大きな懸念を抱いていたチームリーダーは、それを快諾してくださりました。
そして、アジャイルテストDayがアジャイルテストMonthになりました。
ここで、3月時点での私のチームの開発状況を少し整理しておきます。
- バックエンドにRailsのAPIモードを使い、フロントエンドアプリ3つという構成
- Railsのリクエストスペックはかなり手厚く書かれている
- フロントエンドの3アプリは基本的には独立している
- 3月はフロントエンドの1つのアプリに集中して機能開発する予定
最後が決定的に重要でした。
1つのアプリの機能開発しか行わないのであれば、そのフロントエンドアプリのE2Eテストだけ書けばいいということです。
これにより、サイクルタイムがどれだけ短縮できるのかも簡単に計測できます。
ということで、3月〜3月末にかけて、ひたすらmablでテストを書きまくりました。
覚悟を決めたら後は必死にやるだけです。
戦力の逐次投入のような生半可なやり方ではなく、一気呵成に攻略することが大切です。
結果、ほぼ独力でリグレッションテストのカバレッジ率を75%程度にもっていくことができました。
ちょうどこの頃、mablから嬉しいメールを頂きました。
どうやら私はmablを最も使っているユーザーの一人のようです笑
また、カバレッジ率が十分に高まったタイミングでQA方法を変更することにしました。
辛いQAフェーズ
従来までは、機能追加のたびにエンジニアがマインドマップにテストケースを追加していました。
それをプロダクトチームと独立して存在するQAチームがテストを行うという形でした。
前述の通り、これはコミュニケーションコストを増大させる一方で、プロダクトの機能が正しく動くことを保証するものでもないです。
私にとってマインドマップを書く行為はあまり意味が感じられずかなり苦痛でした。
楽しいQAフェーズへ
一方で、mablの自動テストは仕様そのものになります。
アプリが壊れれば、テストも正しく壊れてくれます。
なにより、作っていて楽しいです。
また、私のチームではQAフェーズをQAチームに丸投げするのではなく、QA・プロダクトチームの協同で行うことにしました。
自動化できていない部分は、全員で実機を触り検証します。
以前までは、QAメンバーがリグレッションテストをするので精一杯でしたが、協同により探索的テストをする余裕さえ生まれました。
結果、QAフェーズは以下のように改善されました。
2022年2月時点： 17.8日 2022年3月時点： 0.1日
1回のリリース辺りにかかる時間が2時間程になったわけです。
これで、超えなければいけないハードルの1つ目は見事クリアできました！！
mabl導入以降でE2Eにかかる時間を大きく削減できるのか？- 本当に非エンジニアでも使いこなすことができるのか？
さてお次は、非エンジニアでも使えるかの検証です。
非エンジニアでも使えるかを検証(4月〜4月中旬)
mablはローコードツールであり、非エンジニアでも使えることが魅力の一つとして宣伝されています。
実際、私が使用してみてもプログラミング的な発想さえあれば、ノーコードでも非常にメンテコストの低いテストが作れると感じました
しかし、それが本当かどうかは非エンジニアの方に触ってもらわないことには証明できません。
ということで、早速プログラミング未経験のQAメンバーに実際に使ってもらいつつフィードバックを行っていくことにしました。
私がQAメンバーに教えたことはたったこれだけです。
- 変数の使い方とそのメリット
- 関数の考え方と引数という考え方
- 条件分岐とは
- 一度に複数のことをやらせすぎない
当然、プログラミングコードは一切使っておりません。
あくまでも、プログラミング的な発想を伝授することに徹しました。
QAの皆様の理解力の高さも手伝い、早速非常に質の高いテストが量産されるようになりました。
あまりに質の高いテストを作ってくださるので、レビューをしていて私の考え方が正されることも多く、非常に刺激的です。
余談ですが、弊社のQAメンバーはGithubなど様々なエンジニア御用達ツールを使いこなしつつあり、非常に前途有望な組織だなぁと感じる今日この頃です。
ということで、2つ目のハードルも無事に超える事ができ、mablの正式採用が決定しました！！
mabl導入以降でE2Eにかかる時間を大きく削減できるのか？本当に非エンジニアでも使いこなすことができるのか？
テスト自動化完了(4月中旬〜4月末)
その後、残り2プロダクトのカバレッジ率もみるみる上昇し、4月末時点で8割ほど自動化が完了しました。
非常に素晴らしい結果ではないでしょうか？！
ただ、テスト自動化の旅はまだ終わりません。
これからは他プロダクトチームにも自動テストの文化を広める旅に出ようかと思います。
また、アイスクリームコーンからの脱却も図らなければならないので、自動テストの旅はまだまだ続きそうです。
出典：alisterbscott.com
そしてこれから
チームのパフォーマンスがハイパフォーマーになったと言えども、エリートとはまだまだ大きな差があります。
詳細は割愛しますが、今後は監視基盤を整えていくことで、より安全により迅速に価値をデリバリーできるチームにしたいと考えております。
実はすでに他チームに先駆けて、４月頭からSREチームのリーダーと協力しながら環境整備を行っています。
『LeanとDevOpsの科学』で科学的に良いとされているプラクティスの実践をし続けることで、エリートになれる未来を夢見てこれからも行動していきます。
あとがき
今振り返ってみても、私ひとりではここまで来れなかったと思います。
当時の私のわがままに付き合ってくれたチームリーダー
QAフェーズの改善に積極的に協力してくださったQAチームのリーダーとメンバーのみなさん
メトリクス計測の方法で右往左往していたときに1on1でアドバイスをくださったエンジニアリングマネージャー
テスト自動化を推進する私を褒めに褒めてくれたテックリードエンジニア
そんな、みなさんのおかげでここまで来ることができました。
改めて感謝を述べさせていただきます。
本当にありがとうございました。
そして、最後までお読みいただいた皆様にも何らかの気づきがあれば幸いです。
エンジニアが対象とする問題解決に必要なのはコーディングスキルだけではないです。
むしろ、コーディングスキルは問題解決に必要な一部の要素に過ぎないと思います。
視野をもう少し広げて観察してみると、そこに思わぬ「空席」が見つかるかもしれません。
その「空席」があなた様の「居場所」に変わることを願って本記事を終わりにしたいと思います。
さよなら、さよなら、さよなら