NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST Review'21

S0) オープニング
　風間 裕也 氏（JaSST Review'21 実行委員会）

概要

全国で開催されている JaSST シンポジウムの中で、JaSST Review はレビューを取り上げている。JSTQBでは、レビューは静的テストに含まれており、シラバスが改版されて、記載分量が約2倍になっている。レビューに対する関心が高まっていることがわかる。

今回のテーマは「価値を実現するためにレビューができること」である。有名なイラスト「顧客が本当に必要だったもの」に象徴されている。この話題に対して、うまくいっている事例を聞き、レビューの役割を掘り下げたい。

今年の講演者・事例発表者への依頼背景は以下の通り。

【講演者に依頼したポイント】

1件目：

要件を「うまく」整理して、「どのように」調整したのか。

2件目：

POと開発者が実装前から「本当に必要な機能なのか？」をどのような思考で進めたのか。

【事例投稿の採用理由】

1件目：

開発とQAが一緒に作業し、認識や情報が共有されている。

2件目：

レビューの症状を分類し、その打開のための施策を実践し、分析している。

S1) 講演1
「三越伊勢丹におけるデジタルサービスのつくりかた」
　河村 明彦 氏、鈴木 祥子 氏（三越伊勢丹ホールディングス／IM Digital Lab）

概要

1. はじめに

本日紹介するリモートショッピングサービスは、地方に住む人、隙間時間で百貨店の接客を受けたい人、リモートで選んでから買いたい人などを対象としている。

昨年4月にプロジェクトが立ち上がり、初期開発期間3ヶ月を経て、昨年11月に発表した。サービス開始後は毎週リリースしている。社内からは「なんだかわからないけど、ものすごいスピード感で改善されていく」という感想をもらった。

2. 三越伊勢丹におけるPOの役割

百貨店の特徴は、多様な商品と対面接客であり、三越伊勢丹は店頭接客の元祖である。よって、三越伊勢丹におけるDXは、接客のDXである。接客するのは人間であり、ECサイトでの販売とは異なる。販売員がデジタルツールを使って接客するという新しい常識をつくる。

既存の先頭接客の仕組みと異なり、リモート接客はこれから業務を整理する必要がある。現場と一緒に試行錯誤しながら作り上げる必要がある。

プロダクトオーナー（以降PO）は4方向の仕事をする。上下が「意志決定者」と「関連部門」、左右が「お客様」と「開発チーム」とする。一般的には横方向が重要で、大企業では縦方向も重要。4方向に調整しつつ、アジャイルに進めることが求められる。

3. デジタルサービスの作り方

関係者が多いので、完全に調整するのは困難である。そこで、以下のアプローチを取る。

• 意思決定を軽くする：キーワードは「とりあえずこれで」
  考えすぎず、小さく作り改善する。新しい挑戦なので事前に定義できないから。意志決定者には、週次でのリリースを見てもらい、後から改善できると思ってもらう。
• 意思決定を俊敏にする：キーワードは「先週と状況が変わったので」
  3ヶ月分の案件リストを毎週調整する。見積は大中小程度に留める。様々な立場の役員が決定しやすいよう、ミーティングを毎週開催し、優先順位の判断基準を「売上」で揃える。
• 適切な粒度で合意する：キーワードは「あとはこっちで決めます」
  合意粒度は4方向で違う。意志決定者は大きい粒度(※1)、現場はサービスの姿(※2)、開発は機能(※3)にする。それぞれで、合意の手段とデザイン手法を使い分ける。

上記の３つの項目(※1～3)について、表現方法と注意すべきポイントを示す。

※1→エピック：案件の目的および価値を表す。具体的な実現手段に落とし込まない。

※2→サービスブループリント：お客様の行動、業務、システムの挙動をセットで表す。開発した場合の費用対効果を示す。これがないと価値が著しく下がるか？

※3→受入条件：ユーザー視点でどうなっていてほしいのか。シナリオテストができるレベルの情報を示す。

主なQ&A

Q：

「とりあえずこれで」で進めた場合、技術的負債は蓄積されなかったか？

A：

破壊的変更は起きていないので、負債は蓄積されていないと思う。使われなかった機能はあった。小さく躓く感覚。開発側が困らないようにしている。

筆者感想

筆者はアジャイル開発の推進をしており、この事例は非常に参考になった。企業の背景に合わせて、進め方を細部に至るまで工夫しており、納得感があった。また、ケーススタディも具体的でわかりやすく、アジャイル開発を実践している多くの現場が参考にできるので、社内など様々なところで紹介したい。

S3) 事例発表-1
「ドキュメントが無いプロジェクトでどうレビューする？関係者全員でモブワークして成果物を作った実例」
　伊藤 潤平 氏（ウイングアーク１ｓｔ）

概要

背景

要件定義書も仕様書もないアプリの開発現場に対して、QAの立場で関わり、関係者全員でテスト設計をしてリリースした。

まず、1時間程度全員で会話した。開発者からはアプリの操作や機能の細かい仕様に関する説明ばかり、QAからは製品の品質やリリース後のリスクの質問ばかりで、このアプリにどんな価値があり、どういった⽬的でリリースを計画しているのか、共通認識を持つことができなかった。

対策

私は「できるだけチーム全員が気持ちよくリリースしたい」という思いの元、関係者全員が持っている知識を共有して製品に対する理解を揃える必要があった。そこで全員でモブワークをして、下記の成果物を作成し、リリースができる状態にするための改善をすることにした。リーンキャンバスは、私が一度やってみたいと思っていたので作ることにした。

• リーンキャンバス（要件定義）
• ユーザーストーリーマッピング（仕様書）
• テスト観点表（テスト設計書）

このプロジェクトにかかわる関係者全員は本業以外の業務として取り組んでいたため、毎週1時間のミーティングを設定し、以下のような⽇程で全員がモブワークをする時間を確保した。成果物はMiro+Excelで共同作成した。QAが質問をしながらドライバーとして成果物を作成し、開発者が質問に回答した。レビューという観点では、お互いがレビューアやレビューイになった。

• 1週⽬：リーンキャンバス作成、ユーザーストーリーマッピング作成
• 2週⽬：ユーザーストーリーマッピング作成（続き）
• 3週⽬：テスト観点表作成
• 4週⽬：リリースに対して必要なものの整理

効果

１． 多種多様な意⾒の取り込み（認識共有）と共通理解が得られた

リーンキャンバスの作成では、これまでの会話が1つに集約された。また、目標も「街中で隣の人がこのアプリを使用している」に決めることができた。ユーザーストーリーマッピングでは、アプリの利⽤ユーザーとアプリ操作の観点からストーリーを作成するため、ユーザー視点とシステム視点の両⾯から、関係者が持つ認識が共有できた。また、関係者同⼠が使う⽤語がそれぞれ異なることが分かったため、⽤語集を作ることによって会話での齟齬が減り、バグの発⾒や、次期エンハンスの内容の決定ができた。

２． ワークの中（その場）でスピーディーに全員が合意できた

ユーザーストーリーマッピングにより、アプリの全体像の把握と、リリースまでのストーリーの優先順位を合意できた。また、ストーリーの受け⼊れ条件からテスト観点表を作成したことで、製品をリリースする際に確保すべき品質と、リリース後でも確保可能な品質（リスク）が優先順位付きで表現でき、関係者全員がリリースの判断に対する合意ができた。

３． ⼀体感が高まり、同時に学びになった

関係者全員で何もない中から成果物を⼀緒に作成することにより、⼀体感が高まった。例えば、質疑応答の結果が成果物に反映されるため、懸念事項や次期エンハンスについて皆で決定している感覚になった。また普段テスト設計書を書くことのない開発者が、モブワークの時間内にできなかったテスト設計を「やっておきまーす」と発言し、宿題として持ち帰る場⾯はステキな光景だった。

今後の展開・課題

今後は毎週1時間のモブワークを継続し、テスト実⾏のタスク管理、テストの⾃動化戦略、リリース後のリスク管理、次期エンハンスのタスク管理をバックログで⼀元的に管理する。

主なQ&A

Q:

苦労および工夫したところは？

A:

Miroに慣れていない人への説明は苦労したが、Miro上では文章ではなく単語で示すことが浸透してくると、皆がうまく使えるようになった。

筆者感想

プロダクトをリリースしなければいけないという状況を全員で乗り切ろうという皆の思いが、モブワークという場でひとつになり、結実してリリースを達成したと感じた。ペアワークやモブワークは、分業制を基本としてきた現場では導入のハードルが高いが、この事例を参考にして、試してみて欲しいと思った。

S3) 事例発表-2
「安心、安全で効果があるレビューを目指して」
　松永 光輝 氏（ソニーグループ）

概要

背景

レビューは、参加者が理想的に行動するという性善説を前提としているため、人の意志に左右される不安定な技法である。レビューに参加している人達は、レビューに期待しているものが２種類ある。純粋な成果物の品質と、レビューによって発生する副次的な効果である。副次的な効果の例としては、技術担当者の場合は承認欲求（技術者としてのリスペスト）を期待する。その期待が達成されないとレビューが不調に終わる。レビューを正しく機能させるためには、参加者の大事なものをケアして、いかにうまく人を稼働させるかが一番大事である。

分析と対策

レビュー停滞にありがちな症状を列挙する。

• 技術論の衝突、理想論、偏った指摘、沈黙、No win-win、蒸し返し、希望しない賛同、リサイタル

特に最初の３つは頻繁に発生する症状である。最初の症状に対する解説は以下の通り。

「技術論の衝突」では、ナレッジワーカーが自己の技術や考え方の正当性を示すため、win-loseで対応を行う。その結果、誰も本音を語らないレビューになる。ナレッジワーカーに悪気はなく、周りの沈黙は肯定、途中の反論は否定行為だと考えている。以後のレビューに対して担当者がレビュー実施を拒んだり、ナレッジワーカーに聞いてから設計などを始めるようになってしまう。そこで書面レビューを導入してみた。レビュー摘録を用意した形でのパスアラウンドで、必要な場合は簡易ウォークスルーも実施する。非対面、時間利用、議論の最適化のいい所をとるスタイルである。レビュー期間が伸びるなどのデメリットはあるが、特定の指摘項目に対しての対策をしっかり練ることができ、ナレッジワーカーの意見を聞く場を設けてリスペクトも表現できる。その結果、指摘密度の向上が見られた。

まとめ

レビューを正しく機能させるためには、その環境も大事である。参加者の役割やその中にある価値観を意識する、心理的安全を考慮した人選や手法を選択する、人・環境・手法を正しくマッチさせる、などを整えることができれば、大きな効果が期待できる。また、レビュー技法だけでなく、ファシリテート術や、傾聴、交渉スキル、エンジニアリング手段も重要だと再確認できた。

効果的な安心・安全があるレビューをするために、日々参加する人を意識して各環境に適した手段を日々模索していきたい。

筆者感想

レビュー停滞にありがちな様々な症状を、レビューに関わるそれぞれの立場の気持ちまで踏み込んで分析していたので、理解しやすかった。レビューは性善説だからこそ、安心安全な場作りが大切ということを改めて心がけたい。

S5) 講演2
「ビジネスの成長に合わせてソフトウェアを進化させ続ける秘訣」
　遠藤 大介 氏（ソニックガーデン）
　松木 晋祐 氏（ベリサーブ）

概要

最近のソフトウェア開発の潮流

テスト管理ツールを作っている。遠藤氏が開発役、松木氏がPO役である。ビジネスの成長に合わせて進化・改善したい。変わる市場環境やユーザーの反応を元に、柔軟に対応したい。

そのためには、保守性の高いコードを維持することが大切である。徹底的に無駄や矛盾を削らなければならない。プロダクトの本質を追求してシンプルな作りを維持することは、保守性の高いコードを維持することにつながる。

ソフトウェアを進化させ続けるためのコツ

機能を増やすのは簡単だが、削るのが大変である。「いるそれ？」と問いかけるなど、機能が増えないようにしている。

機能について、POと開発者の両方の視点から、適切さと複雑さのギリギリを見極める。徹底的に対話を繰り返すことが大切である。QAの立場としても、ここの議論が不足するとバグや脆弱性が入り込むと感じる。

本当に必要な機能を見極めるには、プロトタイピングを繰り返したり、本質的な機能は何かを徹底的に議論して仮説を立てる。正解は誰もわからない。

バックログに上がるものは、以下の観点だが、(3)を最優先にしている。

1. お客様が欲しいこと
2. 自分たちがやりたいこと
3. 長期的にやらなければならないこと

(1)に関して、お客様は本当に必要なものを脇に置いて、機能名を言う傾向が強い。欲しい要件の後ろに真の要件が隠れている。それを見つけ、削って磨く。例えば、特定ユーザーにしか配信されないベータ版を作り、フィードバックをもらうと、意外な使われ方をする、などの発見がある。内部使用ではデータ量やバリエーションが足りない。

POもエンジニアも遠慮しない。遠慮して作った機能は後で酷いことになり、後悔する。機能を盛るよりも削るほうが遥かに難しい。どこまで削れば使い物にならなくなるのか、が難しい。「あったら便利かも」は、やらないほうが良い。

これとこれを組み合わせるとこれができる、という発想は危ない。「連携」は要注意なキーワードである。多くの場合、複雑さが増す。大切なのはPOの視点と開発者の視点の両方で違和感のない形を探し続けることである。「本当に必要？」「他の形ない？」と常に問いかける。

最後に、POの回想シーンを付ける。

渋谷にあるソニックガーデンを訪問し、クラウドで使えるちょうどいい感じのテスト管理ツールを作りたいと伝えた。「Excelでいいじゃないですか。」と返され、なぜExcelではダメなのかを説明するのに6週間かかった。最初の半年は１行もコードを書いていない。今作っているものも3～4ヶ月かかっているが、その期間の大半を議論に費やし、MVPは２週間程度で開発した。また「仕様書を作ったほうがいいですか？」と聞いたが、「それより、なにをやりたいのかを教えてほしい」と返された。最初は機能を言ってしまっていた。そこから、誰の役に立つのか、どういう時に役立つのか、を考えるようになった。ユーザーのペインポイントは何か、ツールユーザーであるテスト技術者にとってどうなったら嬉しいのか、などを考え続けた。最初は噛み合わず、知恵熱が出た。二人三脚で、壁を作らずに進めてきたと思う。

主なQ&A

Q.

松木氏へ。QAとPOの両方を経験してみて、QAが果たせる役割は？

A:

必殺技はテスタビリティ。POと開発者が「いける！」となった時、QAが「このままではテストモデルが複雑になる」ことを示すことで、対等な立場になる。最初からQAが入っているのがベスト。

Q.

遠藤氏へ。攻める姿勢になった経緯は？

A:

過去にソフトウェアの開発で大変な経験をした。品質が高くないソフトウェアの保守作業で、触るのが怖いし、触るとバグが出る。これでは楽しくない、と思い、ここまで突き抜けなければいけないと思った。

筆者感想

ソニックガーデンの取り組みには前から興味があったが、具体例を通して知ることができて良かった。プロダクトオーナーと開発者が密度濃く会話し、決して妥協しない姿勢を貫くことが、良いプロダクトにつながるのだと実感した。

S6) パネルディスカッション
パネリスト：
　河村 明彦 氏（三越伊勢丹ホールディングス／IM Digital Lab）
　鈴木 祥子 氏（三越伊勢丹ホールディングス／IM Digital Lab）
　遠藤 大介 氏（ソニックガーデン）
　松木 晋祐 氏（ベリサーブ）
モデレータ：
　奥村 哲郎 氏（ベリサーブ）

内容

前半はモデレータからの質問に回答、後半は参加者からの質問に回答する形式で進められた。
以下、発言者は名前の先頭一文字を表記する。

Q.　お互いの講演を聞いてどう思ったか？

松：

概念や価値観は同じだが、進め方は違って面白かった。

遠：

「いい感じの調整」には同意。よく使っている。信頼関係構築に凄いシンパシーを感じる。

河：

語りに慣れていてラジオを聞いている感じ（笑）。ユーザーの言ったものをそのまま信じないには共感した。

鈴：

規模は違うが、考え方は近い。問題が起きてもリカバリできそうな先行現場から試している。

Q.　様々な観点から価値を見極めて説得されている。観点は？

河：

小売業なので「売上にヒットするか」は大切である。IMのミッションは「仕組みを変えてはたらく仲間を楽にする」。

松：

説得していない。周りから理解してもらいやすいチームにすることを考えている。頻繁にリリースして触ってもらう。

遠：

チーム内では説得することはない。納得するまで話す。

Q.　POとして役割を果たしていると思える要素は？

遠：

いかにして持続可能な製品にするか、を考えている。負債が溜まらないように、POの要望を実現した時は役割を果たせたと思う。

松：

何をどの順番でやるのかを開発者に合理的に説明できた時や、プロダクトの価値観をユーザーに話して「いいね」と言われた時。

鈴：

４方向に対して仕事をする。私は開発経験があるので開発者と話す。開発者に任せるところは任せる。

河：

毎週ミーティングをがっつりやっている。ユーザー部門から「いい機能だね！」と言われると嬉しい。

奥：

（質問）POが２人いると揉めるのでは？ → （回答）４方向をうまく分担しているので納得しながら進められている。

Q.　常に心がけていることは？

遠：

ソフトウェア開発を楽しくやりたい。毎週のミーティングに前向きに参加できるようにしたい。

松：

「誰がうれしいのか？」は、テストをしている時も思う。合理的に言語化して説明する。「とにかく作れ」は「はぁ？」と言われる（笑）。

河：

いいかげんではなくいい感じにやっていると思ってもらえるように、意志決定者にどういう説明をするか。売上と開発費用を常に比較している。

鈴：

現場の人達はITには詳しくないが、使ってもらえないと売上につながらない。現場が本当にやりたいことを一緒に考える。

後半は参加者からの質問に回答した。

Q.　レビューで感情的になった時の工夫は？

遠：

これは人格否定ではないと前置きする。心理的安全性を確保する、そういう場を作ることが大切。

鈴：

その場でわーっとなることもあるが、ちょっと時間を置くと冷静になる。

河：

ちょっとした言葉尻でヒートアップした時などは、「検討します（持ち帰る）」というキーワードも使う。

Q.　POとして、取捨選択の判断は？

鈴：

開発チームは様々なアイデアを出してくれるが、なくても業務が回る（目的が達成できる）ものは取捨選択の対象とする。

河：

従業員の作業を変える（業務フローを変える）ことで解決できれば作らないが、そうでない場合は作る、など。

Q.　MVPと優先順位の案件を決める際、どういう視点で見ていますか？

松：

MVPを決める時は、一番シンプルなものを思い浮かべる。ボタンを押すだけ、のようなものを考えて、足していく。

遠：

線が通っているか。例えばCRUD。最低限でもできているか。最初は更新画面がないことが多い。

鈴：

MVPでは、売上・購買のサイクルを見て、集客・売上を見る。また、様々な売り場で使えそうか、を考える。

河：

全体で使えるものか。キラーコンテンツ（勝ちきれる）か。売上に貢献するか。従業員が楽になるか。

Q.　POとしてレビューに期待することは？相手方に期待することは？

松：

遠藤氏には、要求がソフトウェアのアーキテクチャ上で筋が悪くないか、を期待する。

遠：

松木氏には、ビジネスの視点を期待する。めちゃくちゃ複雑になる機能があったら、ビジネス的にジャッジしてもらう。

鈴：

どのフェーズのレビューかによるが、レビュー時点で「全然違っていた」は、避けないといけない。そのために今日話したことをやっている。

パネリスト・モデレータから一言ずつ感想

鈴：

レビューのシンポジウムなので、みなさんにどう受け止められたか不安だったが、たくさんコメントをいただいたので良かった。他の方々の話も良かった、勉強になった。

河：

事例が勉強になった。松木氏と遠藤氏の事例は共感を持てた。

遠：

POの立場やレビューアの立場の人達に共感を得られて良かった。ソフトウェア開発はこういう方向に進むのだろう。ソフトウェア開発は楽しいと改めて思った。

松：

同じことを考えている人がいることを知ることができたのでうれしい。静的テストには「なにを作るか考える」ことも含まれるので、学べた。

奥：

色の違いが出るかなと思ったが、合意形成のしかたなどが似ていて、同じところに立っていると思った。

S7) クロージング
　風間 裕也（JaSST Review'21 実行委員会）

概要

レビューは "Re-view" であり、もう一度見るということである。それはレビューミーティングに限ったことではない。本日の発表を通して、価値に向き合っているのか、を改めて考えることができた。来週から、今日の内容を役立てていただきたい。

筆者感想（全体）

JaSST Review は毎年新鮮なテーマを掲げて開催されており、気づきが多い会である。近年、正解がわからない状態で試行錯誤しながらプロダクトを作っていく状況が増しており、２つの講演はおおいに参考になった。環境も規模も異なるが核心は同じなので、その核心を外さずに、これらを組み合わせれば幅広い現場で応用できそうだと感じた。