株式会社グロービスは、社会人教育を基本に、「経営に関するヒト・カネ・チエの生態系を創り、社会に創造と変革を行う」というビジョンを掲げる企業。MBA学位を授与できる「グロービス経営大学院」は知る人も多いだろう。
創業から25年経った現在、経営大学院の枠を超えて、企業研修や、ビジネス知識の学びを深めるコンテンツの提供なども進めている。
2016年からアプリケーション開発の内製化に踏み切り、2019年には横断的なQA組織を立ち上げ。その中心にいる、チームリーダーの池邊 啓介氏にお話を伺った。
(写真中央上、株式会社グロービス QAエンジニア チームリーダー 池邊 啓介氏)
– それでは、まずは池邊さんの自己紹介をお願いします。
池邊さん: 株式会社グロービスで、開発のQAチーム、リーダーをしています。QAエンジニア歴は3年になります。「QAなんでも知ってるぞ！」という者ではないですが、いちQAとして活動しつつ、チームリーダーも務めています。
グロービスは経営大学院としてビジネスリーダー教育を提供することはもちろんのこと、最近はオンラインでもビジネス知識を学べるようなアプリをリリースしています。
最近の状況下でも、デジタルサービスはユーザー数も伸び、売り上げも増加しています。「学びを止めるな」というメッセージを通じて、不安定な時代ですが将来を見据えた自己成長を意識いただきたく力を注いで来ましたが、このような反応をいただき、とても励みに思っています。
– ありがとうございます。早速ですが詳細をお伺いしていきたいと思います。
グロービスさんが、アジャイル開発にシフトしたのは最近だと伺ったのですが。
池邊さん: 2016年に独立事業部門としてスタートし、同年の年末から自社開発にむけて動き出しました。それまでは外部に開発をアウトソースしていましたが、スピードを上げていこうという形で方針を変え、自社開発へと開発組織を立ち上げ、今は100人を超えるまでになりました。エンジニアやデザイナーなど開発に関わるメンバーだけでも70名を超えています。
組織は大きくなりましたが、プロダクトもそれに伴ってグロースしているので暇になることはない状況です（笑）。
– 内製化ってとても難しいと思うのですが、どのように進められたのでしょうか。
池邊さん: そうですね。戦略として、今あるプロダクトを開発ベンダーから引き剥がすのではなく、全く新しいプロダクトを作るという「ゼロイチ方式」をとったというのがよかったのかもしれません。
その、最初のプロダクトが「GLOBIS 学び放題」です。
– 今はいくつぐらいのプロダクトがあるのですか？
池邊さん: 今は大きく4つのプロダクトを提供しています。グロービス学び放題（ビジネスに必要な体系的な知識をを凝縮した動画学習サービス）、それの英語バージョン（GLOBIS Unlimited）、グロービスの在校生または卒業生が起業したベンチャー企業を対象とする投資プログラム「GLOBIS Alumni Growth Investment」、グロービスの研修で利用するためのLMS、そしてそれらの認証や申込みなどを司るプラットフォームの計5つです。
– 池邊さんのチームが、それらのプロダクトのQAを横断的に行なっていると伺いました。
池邊さん: そうです。
プロダクト横断でQAをする、ということを前提に、2019年にチームをつくりました。「横断チーム」になった背景としては、元々の課題が、プロダクトを繋ぐところでのミスが多くなっていたというものがあります。そのような連携部分をカバーできる組織体制を目的として立ち上がりました。
– では、もともとはプロダクトごとに品質管理、QAをしていたのですか？
池邊さん: 2018年までは、そうでした。スクラムチーム内でリリース管理をする、ということを前提としていたので、エンジニアが品質を担保していました。プロダクト単位ではこれでも一応は品質基準を満たせていただのですが、プロダクト同士を繋ぐ部分になると問題が頻発し、大変になりました。技術面だけでなく「どちらがテストするんだ」といった役割分担の面でも課題が重なり、意識がバラバラになってしまっていました。
– まさにE2Eのテスト重要性が増してきたという状況だったのですね。
池邊さん: これまで「E2Eテスト」自体はあまり行われていませんでした。正直、嫌うというほどではないものの、自動化もしづらいですし、手動で全部見るなんてことは人手不足もあり到底やれていませんでした。そこを補完したいというのがとても大きかったです。
– Autify導入前の課題として、E2Eをカバーしたいということの他に、どのようなものがありましたか？
池邊さん: 僕が入社してから、Selenium, Headless Chromeで一部自動化を試したことはありました。ただ、全く安定しなかった。
「このメンテナンスをひたすら続けるなんで苦行でしかない」とも思いました。
また、全部自分一人でやるというのも現実的ではない上に、これを自分以外の誰かに任せる、または分担するというのも難しいです。Seleniumの環境をシェアする、テスターさんにお願いする、といったようにいくつか選択肢がありますが、いずれにしても、ずっと人的コストが必要になる。このようなマンパワーで回る組織にはしたくなかったんですよね。
– マンパワーに任せたくなかったというのはどういうことでしょうか？
池邊さん: 人手でE2Eテストを実行するというのは時間もコストもかかります。スクラムにあわせて、テストも素早くまわすためには、自動でまわる、デプロイと一緒にまわるというフローである必要がある、と考えていました。
また、「チームをつくる」という観点でも自動化は重要でした。これまで、自分自身が経験してきた中で「ひたすらテストをやり続けることって本来は人がやることではない」というのはずっと感じてきました。仕様書にあわせて上からなめて作業をするだなんて、人がやることではない。チームメンバーにもやらせたくないと強く思っていました。
加えて、テスターの人員をたくさん抱えるというのは、マネジメントコストも発生します。これでは、元々つくりたいと考えていた「エンジニアリングもできるQA組織」を全く達成できないということはわかりきっていたので、それはやらない、最初から自動化に投資することありきで考えていました。
– グロービスさんには、Autifyの正式ローンチ前から使っていただいていました。正直、まだまだ形もできていなかったところで、どのあたりに魅力を感じていただいたのでしょうか？
池邊さん: 1つは、先ほど申した通りテスターをがっつり抱える組織じゃないQA組織を作りたいというもの。2つ目は、そもそもの人材不足が挙げられます。自動化エンジニアってとてもニッチな職種（エンジニア）だと思っています。この人材を採用するのは非常に難しいと感じていました。
それであれば、ツールのようなものでエンジニアじゃなくてもメンテナンスができる、使えるものがあればなと思っていました。ただ、「そんなツールなんてあるのかな」と懐疑的だったんですが（笑）
ちょうどそのあたりについて調べ始めたときにAutifyの話があり、ベストタイミングでした。
エンジニアじゃなくても使えて、さらにメンテナンスが楽になる。
– エンジニアじゃなくても使えて、メンテナンスが楽になるツールを探していたということですか？
池邊さん: グロービスの各スクラムチームにはPOもいるので、そのPOがテストもできる、メンテナンスもできたらいいなぁという気持ちがありました。その頃はまだ、あるべき姿に近づけそうだなと想像する程度ではありましたが、それにまさにはまっていました。
– それでは、Autify導入するときの進め方についてお伺いさせてください。
池邊さん: 進め方としては各プロダクトでやっているE2Eテストのシナリオを各チームからかき集めて、Autifyでシナリオ化していくというところからはじめました。特段の難しい導入をしたわけではないかなと思います。
他の点でいうと、staging環境でテストをするということは決めていました。
既存のテストケースをシナリオ化していくときに、「これは、そもそものE2Eテストとしてできない」とか「データの後処理が必要なもの」が発生して、そのままでは自動化に向かないものがありました。そういった自動化をすることへの試行錯誤はあったかなと思います。
– テストのシナリオを見てどこから自動化していこうかって考えたということですね。
池邊さん: 当時Autifyに共有したテストケースは、QAチームでまとめたものではありませんでした。書式も揃っていませんでしたし、テスト観点といったものもありませんでした。明文化もできていないままお渡ししてしまったので、その読み替え・組み替えには苦労があったのではないかと思っています（笑）
※ 当時、Autifyではテストシナリオの作成代行も含めてご一緒していました。
– 実はあのプロジェクトのおかげで今のAutifyがあるといっても過言ではありません（笑）グロービスさんのQAチーム発足後、すぐのタイミングだったと記憶しています。
使っていただく中で、Autifyのいいなと思ったところを教えてください。
池邊さん: カスタマーサクセス、サポートの異常な充実さが素晴らしいです。
またユーザーのフィードバックを聞いて、そこから機能を追加していっている、というユーザー視点であることが素晴らしいと感じています。
その上、ロードマップが公開されているのがとても良いです。足りない機能、こういった機能がほしいなとかはもちろんあります。ただロードマップがみえればその道筋が立つので、助かっています。
例えばマウスオーバーのアクションに対してJavaScriptのステップを使う必要がありましたが、それもリリースされました。どんどん解決されていくんだというのは、すでに身をもって知っています。ロードマップに対しての信頼感も十分にありますしね。
– 現状1年ほど経って、今はどのような感じでテストの自動化を進めているのかお聞かせください。
池邊さん: まず、テストケース自体はプロダクトから集めることをやめました。
Autifyを使うことを前提に、各プロダクトのユーザーの導線の中から一番重要性の高いもの、且つ、メンテナンスにコストがかからないものから順にシナリオ化していくようにしています。
各プロダクトのドメイン知識から重要性を判断します。次にAutifyで自動化できるかを判断する、というフローです。シナリオを全部洗い出すという形ではなく、重要な部分がAutify化できるかを確認して進めていきます。
つまり最初からAutifyが前提の考え方に思考もプロセスもシフトしたのです。
幸い、チームにテスト自動化の経験者が入ってきてくれたこともあり、自動化に向いている向いていない、といったような判断はそのメンバーの知見も生かして進めていくことができました。
– フロー自体が変わったというところ、とても興味深いです。シナリオを作ってからではなく、Autifyありきで進めていくということですね。
池邊さん: そうです。”この機能”、 ”ユーザーの動き” のような、観点の整理は最初に行います。その後工程となる、テストのステップをわざわざExcelなどに書き起こすよりも、Autifyでレコーディングしてしまう方が速いというのが理由です。
ステップをExcelに書き起こすのと、Autifyでのレコーディングって結局同じことを2回することになるので、そこを一気に効率化しました。
– そんなQAチームは現在何名になったんですか？
池邊さん: 私を含めてメインで稼働しているのが6名になりました。その他にアルバイトさんが2名いるという状況です。アルバイトさんは非エンジニアでコードはかけませんが、もちろん積極的にAutifyでシナリオを作成しています。
まだまだ足りていないんですが、1人でチームと名乗っていた時からするとだいぶ変わりましたね（笑）
いろいろなことに手をつけられるようになりました。
– チームとして運用時に工夫したこととかありますか？
池邊さん: 使い方の一部になるかもしれませんが、スモークテストにもAutifyを利用しています。
pingに近いといえば近いのですが、各プロダクトのSSOが通るか、ログインできるか、といったミニマムなものも定期的に実行してます。
初期からこのスモークテストへの適用の構想はありましたが、手をつけられていなくてやっと最近手をつけはじめることができました。
– そのあたりも効果ありそうですか？
池邊さん: スモークテストはシナリオが短く、そもそも安定性が高い。Autifyの安定性と合わせた結果、サービスの安定性という点で良い効果が出ると思っています。
– Autify導入後の成果、導入前と比較して具体的にどのような効果がありましたか？
池邊さん: 内部的な課題として、まだ各プロダクトの品質を定量的に測れていないという状況ではありますが、スモークテストや各プロダクトへのリグレッションテストがまわっていることの安心感は大きいです。
– それでは定量的ではなく、定性的な効果とかあります？
池邊さん: シナリオが増えて安定性が底上げされています。
複数の、しかも中規模なプロダクト、それらを横断で見る、という組織体においては、ワークフローを定義しなければいけません。Autifyがあるとこのあたりのワークフローの定義のしやすさに繋がっています。
過去にテストの自動化に取り組んだことのある人、経験したことのある人ほど、複雑なものメンテナンスが大変なものに取り組むにはとても腰が重いものです。
「簡単に自動化っていうなよ」ってのをどこかに抱えていたりします。
Autifyはこのあたりを払拭してくれました。使い方は簡単ですし、使えば使うほど、実際にそのメンテナンスコストも非常に低いことがわかる。「頼って良いんだ」という気持ちになれます。
– 過去に自動化に取り組まれたことのある方からの信頼をいただけるというのは我々にとってもとても嬉しいですね。
一方で費用対効果は出ていますか？
池邊さん: 人件費が大きいです。例えば、もう1人、スキルの高いテストエンジニア、自動化エンジニアを抱えなければならないと考えると、Autifyの利用料金と同金額では満たせません。
年収で考えても600万円以上。これにかかる採用費用も人件費も浮いています。
そもそもテスト自動化エンジニアって、そうそう世の中に存在しませんよね（笑）。自分自身もSeleniumを使ってE2E構築してみたことがあるという程度で。ここに、言語の要件まで入ってくると更にハードルが上がります。採用するとなると、会社のカルチャーもフィットしていないといけない…ほぼ、いません。実際には人件費と比較はできないのではないかと思っています。
ただ、実は2020年3月時点でツールの見直しは行いました。
コロナ禍の影響と会社の規定であるという背景もありますが、きちんと正当に、改めて評価しようということで他の製品と比較を行いました。
その上で「現時点では、課題が解決されるロードマップが出ていることも含め、Autifyより良い製品はない」と判断し、継続して利用するに至っています。
– 正当に評価いただいた上で、継続いただけていること、とても嬉しいです。引き続き継続いただけるよう私たちも進化していきます。
池邊さん: 最初の導入時点は、アジャイルのリリース前テストフェーズで、各PO (プロダクトオーナー) に使ってもらう予定でした。
実はここを変更しました。このお話をさせてください。
グロービスでは、Autifyの利用をシフトライトに切り替えました。つまり、リリース後のものに対しても常にまわっている、リグレッションテストに適用するように変更したのです。
まず、テストのためにリリースができない、というのはアジャイル的には本質的ではないと思っています。シフトレフト、シフトライトを考えたとき、我々にはどちらも必要でした。
導入時はE2Eテストの手間が減る、というところだけがAutifyの魅力だと思っていましたが、利用していく中で、シフトライトの部分をAutifyに任せることができると判断しました。
結果として現在、グロービスではシフトレフト部分は人手で、シフトライトをAutifyに任せる、という形を取ることで、スクラムとは非同期にQAを動かすことができるようにしたのです。
– テストを理由に開発を止めないということですね。
池邊さん: staging環境と本番環境は同じものを担保する、というのがグロービスの開発ルール。その中でやっています。
ずっとAutifyが動いていて常にAutifyが見てくれている。問題が分かったら本番環境からStaging環境に差し戻すような流れです。
– シフトレフトの対応はどのように行なっているのでしょうか？
池邊さん: シフトレフトは、社内で「POサポート」という名称をつけました。スクラムのリリース速度を早めたいと考えた時、POのリリース判断が一番のネック、重要なポイントになります。
これまでは、ユーザーストーリーとして起こした仕様のチェックをリリースの判断材料として使っていました。これでは、POの視点でしかチェックされないという課題があります。
まだ検証中の段階ですが、そこをQAチームがアシストしています。POチェックで見るべき観点に、品質保証の観点を追加します。例えば過去の不具合から、「こんな観点があります。チェックしないといけませんよ」という形で伝えていきました。
そうすることで客観的、多角的な視点を入れられることになります。更にそれらを明文化することで、POのリリース判断そのものがテストとして成立するようにしたいと思っています。
– ユーザーストーリーと品質保証とをうまく組み合わせた形ですね。
池邊さん: 将来的にはユーザーストーリーを作る前に実行できるようにしたいな、とは思っています。
いわゆる俗にいわれる「シフトレフト・シフトライト」とは違うところもあるかとは思うんですが、結果的にこれがリリース速度を加速していくだろうと確信しています。
– グロービスさんの今後の展望について教えてください。
池邊さん: 繰り返しになりますが、グロービスには、中規模なプロダクトが複数あります。
1つのプロダクトに2、3のスクラムが紐づいているという状態です。「Scrum@Scale」といったフレームワークを取り入れて、小さいスクラムをいっぱいうまくまわすという方針をとろうとしています。
QAもそれにあわせて柔軟なQAのあり方を模索しています。
このやり方の正解は、QA界隈でもまだ定義されていません。ここを我々として定義していきたい、そんな思いで取り組んでいます。
小さいスクラムチームでも効果的なQAがまわって、結果的にプロダクトの品質が上がり、素早くリリースできる。
これを実現するためにも、QAチームとしては人手でカバーするという方法は絶対に取りません。
グロービスのQAとはどうあるべきか、どうアプローチしたら品質が上がるか、といったことを一緒に考えて、チームで取り組んでいきたいと思っています。
– ありがとうございます。最後に、これからテスト自動化へ取り組む方へのメッセージをお願いします。
池邊さん: メッセージをいえるほどまだまだやること、やりたいことは山積みではありますが（笑）。
前に、AutifyのSamさん (共同創業者の山下) のお話を聞いて思ったことがあります。
テスト自動化のツール市場自体は膨らんでいく。そのような中で、QA自体はもっと「どうテストを設計するか」という方向に頭を使っていくようになると思いますし、そうなるべきだと考えています。
テストを自動化すること自体は、品質を上げることではありません。どうやったら品質が上がるのか、は人が考えること。そこに取り組めるように、自動化はAutifyに任せて、人らしい活動ができるようになっていけばな、と。
この想いを多くの方にも共感いただけたらと思います。
.jpg)
.jpg)
