「価値を届ける」ことについて改めて向き合わされた -ジャネット・グレゴリーのAgile Testing for the Whole Team研修-
Wingarc1st DataOps部の小野﨑です。
普段はBI製品(Dr.Sum,MotionBoardなど)を利用したBIシステムの構築を行ってます。3月から組織が変わりDataOps部の所属となりました。
DataOps部のミッションの一つに「DataOpsのノウハウを溜める」ことがありますが、それにあたって重要となるキーワードがあります。「自動化」です。確かにテストも含め、運用を自動化できればもっと楽できるよなぁという生来のズボラな思惑もあり、「いかに普段の業務を自動化するか」を考えることが多くなってきました。そんな折、上長から「ジャネット・グレゴリーのAgile Testing for the Whole Team研修」の案内がありました。もともとテストの自動化やアジャイルの文化については前から興味がありましたので、渡りに船と思い、手を上げました。
というわけで(「会社がお金を出してくれたから」という身もふたもない理由も含めて)、4月8日～4月10日の3日間、「ジャネット・グレゴリーのAgile Testing for the Whole Team研修」に参加しました。
実際の研修の内容については既に詳しい内容が書かれているブログがあるので、そちらをご参照ください。
ここでは、研修を受けての自分なりの感想を書いていきます。
BI・データ分析と相性の良いアジャイル開発プロセス
私の従事している仕事は、主にBI(Business Intelligence)、データ分析を行うシステムを構築することなのですが、「小さく始める」「(顧客から)フィードバックを早く受ける」ことが大変重要です。なぜなら、BIの要件は特に変わりやすいものだからです。そもそも、最初から明瞭でないケースすらあります。そういった状況では、ウォーターフォール的な開発を適用すると必要以上に要件定義の工数がかかってしまいます。それであれば、小さくて構わないのでまずシステムを作り、ユーザーに利用してもらい検証をしてもらいます。その検証結果を元に顧客からフィードバックを受けて、明らかになった要件を元に追加でシステムを作っていく、という進め方をのほうが、お互いにスムーズに進められます。
そういった意味で、BIはアジャイルと相性は良いと言えるでしょう。ではアジャイルにおけるテストとは何か。研修を受けて、テストこそがアジャイルの肝ではないかと思い至りました。
「アジャイル」の肝はテスト
アジャイル開発のテスト工程で行われる事は何か。一言で言えば「このソフトウェアが顧客に価値を届けることができているかどうか」という検証です。研修を受けるまでは、テストと聞いたら「テストケースを網羅して、バクがないかどうかをしらみ潰しに探す」という作業を連想していました。これまでやってきたテストが、そういった類のものばかりでしたし、テスターへの適性として「単純作業に耐えられる」というのもよく言われていました。
実際、金融や医療などの1つのバグが業務にクリティカルな影響を与えてしまいかねないシステムであれば、しらみ潰し的なテストにも一定の価値はあると言わざるを得ません。しかし、すべてのソフトウェアテストについて、しらみ潰し的なテストをすべきかといえば、そうではありません。
そもそもバグを全て潰す事は不可能です。
上記を踏まえて、「バグがあって怒られるのがダメだから網羅的にテストをする」という発想ではなく、発注側も巻き込んで「このソフトウェアで良いという合意を得る」ことが、アジャイルテストだと理解しました。
それを特に感じたのは研修中の演習でした。演習の内容は、グループ内で発注側と受注側に分かれ、発注側は受注側の作ったものに対して「受入」「却下」を判定するというものです。私は発注側のロールでしたが、受注側の作品を「受入」するか「却下」するかという判断は、思った以上に複雑でした。なぜ却下しないといけないか、なぜ受入しないといけないか、きちんと説明する必要があるためです、「〇〇が違うから却下」という理由だけでは通りませんでした。違っていることがなぜまずいのか、あるいは「該当箇所が違っていても受入OKとしたのはなぜか」を説明する必要があります。
アジャイルの肝がテストにある理由は何か。それは、この発注側と受注側の合意プロセス、フィードバックを内包しているからです。それにより、ソフトウェアの「品質」が上がります。品質が良いとは「バグが出ない」というだけの話ではありませんでした。
確実にお客様に価値を届けることができる。これこそがソフトウェアの品質なのだと、今は思います。
UXの伴走者としてのアジャイルテスト
以前に読んだ「アフターデジタル2 UXと自由」で例示として出された話は、アジャイルのテストを考える上でもヒントになるかもしれません。
本書では、アリババとテンセントの送金機能サービスを例として取り上げ、UXの観点から、同じような機能を実装しても同じようなサービスにならないことを説明していました。改めて読むと、アジャイルテストにおいても大事な内容が含まれていると感じました。以下、引用します。
アリペイではもともとECプレイヤーであると言う強みを生かし、ユーザーがペイメントサービスを使う際のハードルを一つひとつ丁寧に乗り越え、「アプリをダウンロードし、いつものアカウントでログインすればすぐに使える」と言う状況を作り出したことで、時間をかけて広まっていったのです。(P.57)
これに対して、テンセントは別のアプローチを取ります。
一方のテンセントは、ペイメントに関しては出遅れましたが、かなり特殊というか、ビジネス脳ではなかなか思い付かないアイデアで広めました。テンセントが用いたのは「紅包(ホンパオ、またはレッドポケット)」です。
日本でいうお年玉のことです。
(中略)その時点で、家族には会社の忘年会でWeChatの紅包機能を経験した人がいるので、今度はその人が火付け役として使い方を説明するようになります。ITギークから企業に広まり、企業で働く人から家庭に広まっていく、というアリババとはまったく異なる形で展開されていきました。(P.60)
アリババとテンセントは会社としてのミッションが異なります。
- アリババ：デジタルによって商取引を円滑にし、中小企業を支援する
- テンセント：すべてをコミュニーケーション化する
「アフターデジタル」では、このミッションによってUXがユニークになると述べています。これは想像ですが、これらの機能はアジャイル的なテストを経て作られたと考えています。機能を作りテストを行い、「このソフトウェアは正しく顧客に価値を届けているか」という検証を繰り返すことによって、アリババとテンセントはそれぞれのソフトウェア・サービスを築いた、と。アジャイルテストではユーザーのペルソナを作りテストケースを作成します。そのテストケースを作るにあたってはUXの概念を外すことはできません。UXが要件からリリースまでを横串で指す概念だとしたら、テストはプロセスの一部でありながらUXという概念の伴走者にすらなりうる概念です。
エンタープライズ系における「ソフトウェアの価値を届ける」ことについて
この研修の途中からエンタープライズ系の「ソフトウェアの価値」を考えるようになりました。アジャイルテストが「ソフトウェアの価値を顧客に届ける」のであれば、受託開発・エンタープライズ系のシステム開発とは相性がそんなに良くないのでは？と考えてしまったからです。
そう考えた主な理由は以下二点です。
・エンタープライズ系のシステム開発では「ソフトウェアの価値」について、顧客の要件定義に従った以上のものはなかなか出せない (特に汎用的でない、個別業務のシステム開発においては)
・顧客のスケールが限定的で「ソフトウェアの価値」を向上させる商売上のメリットが少ない (汎用的なサービスならスケールするが、個別なら規模がデカくなるのは限定的)
もっとも、(書いてて気付いたのですが)いずれもベンダー側の都合です。ですので、発注側が舵取りをしてベンダーを巻き込むような体制であれば、また話は違ってくるのかなとも思い直しています。いずれにせよ、エンタープライズ系のシステムからは逃れられない状況なので、真剣に「ソフトウェアの価値を届ける」ことは考えなくてはなりません。
最初の壁：テストの自動化をどう取り入れる？
先ほど自分の仕事を説明しましたが、「テストの自動化」という点では、まだまだ課題は多いです。平たく言えば技術的な課題とテストケース作成についての課題です。
まず技術的な課題ですが、主に2つの課題があります。
・画面のテストをどうやって自動化するか
・DBへの読み出し・書き込みテストをどうやって自動化するか
どちらも、純粋に技術的なことについて知見が無いことに起因する課題です。ここは社内の有識者(本研修の大きな収穫の一つは、他部署の開発者との繋がりができたことだと思います。意外と部署が違うと何をどうやっているのか、わからないので。)と相談しながら進めたい分野です。しっかり努力して怠けられるようにします。
もう一つのテストケース作成ですが、こちらの課題も主に2つです。
- どうやって「お客様に価値を届けるテストケース」を作成するか
- お客様にどうやってテストの妥当性を説明するか
これはお客様の業務にいかに入り込むかにかかっています((ここはエンタープライズ系のシステムを作る上での醍醐味でもありますが))。こちらはチーム内でしっかり意識をすり合わせして、お客様と話をする準備を進めるという、王道的な話でした。
終わりに
「Agile Testing」とタイトルにあったので技術的な知見等が得られると期待したのですが、実際には技術的な知見を得ることのみならず、ソフトウェアを作ること、自分の置かれている状況への向き合い方まで考えることになりました。大変良い研修でした。一方で、Agile Testingに関する本やサイトをもっと読み込んで事前に理解をした方が、より研修の効果が高かったのかなと、少し後悔もしました(研修では、事前に見るべき動画のリンクを案内されましたが、1回の視聴だけでは全てを理解することは困難でした)。研修費用は高かったですが、それだけの価値はあったと思いますし、「いかにチームに還元するか」を真剣に考えざるを得ない研修でした。
IMPACT MAPPING インパクトのあるソフトウェアを作る
研修中に案内された参考記事および本。
疑問が出た都度、ひたすら書き込みをして質問していたのだけど、その都度資料を紹介してくれたのがとてもありがたかったです。フィードバックが速いという意味では、アジャイル的な研修と言えなくもありませんね。
