2017/8/20(日)：オンライン人狼を開催しました。

テストクラスタの有志を集めてオンライン人狼をやりました。人狼は正式名称「汝は人狼なりや？」というTRPG(テーブルトークRPG)です。本来は対面で行うゲームなんですが、グループ会話ツールを用いることでオンラインでも遊ぶことができます。個人的には夜時間における役職実行のやりやすさから、対面人狼よりオンライン人狼の方が好みです。

汝は人狼なりや? - Wikipedia

はじまり

発端はこの発言。

Skype人狼なんかは実況動画が好きでよく観てます！オンラインでも良ければ私もやりたいです！

— Toshiyuki Manabe (@ToshiManaPlus1) 2017年7月26日

オンライン人狼は動画で見て興味があったので名乗り上げました。スケジュール調整の末、この発言から約一月後に開催となってます。最初は人が集まらずにどうなることかと思いましたが、最終的には10人集まりました。

GM(ゲームマスター)

人狼を遊ぶにはGMが必要です。参加者とは別に、GMはゲームに参加せず運営を行う役割になります。私は今回GMをやりました。オンライン人狼はツールの準備も必要なのですが、そのツールに興味があったのもGMをやった理由の一つです。

ツール

オンライン人狼をやるために以下のようなツールを用意しています。

オンライン人狼ツール

• 中島人狼(チャットベースのブラウザアプリ)

www.nakajima-jinro.com

• JinroSE(中島人狼と連携できるGM用アプリ)

Jinro! Second Edition - 月夜丘

オンライン会議ツール

• Zoom

オンライン人狼ツールは今回初めて利用しましたが、とても便利でした。オンライン人狼のGMは以下のような仕事があるのですが、オンライン人狼ツールが大部分を引き受けてくれます。流石、長い間使われて改良しているツールだと感じました。

• 配役を自動で振ることができる
• 各参加者に必要なチャットを自動で展開する
• 誤操作が多い全体チャットへの書き込みを制限する
• 残り議論時間の通知を定期的に行う
• 投票の集計を自動で行う
• 夜時間での役職者への役職実行の要求、受付を自動で行う

運営

運営としては優秀なツールがサポートしてくれるので、GMの負担はかなり減りました。参加者は人狼初心者が多く、ツールやルールについて補足したりすることが多かったです。皆さんが推理しながら議論しているのを神様視点で眺められるので、議論に直接参加していなくても面白かったです。

ツールのテストで予定の1時間前から何名かにご協力いただいていたのですが、結局予定時間から45分くらいツールの説明に時間がかかってしまいました。ツールの説明をより効率的にするとともに、予めツール説明の時間がかかることを含めたスケジュールをしておくことを反省点として、次回以降の改善点としたいと思います。

おわりに

過去に何度かオンライン勉強会を開催して同様の利点を感じていますが、「遠方の人と(西は福岡、北は仙台まで)」「遅い時間に(22:00開始)」開催できるのはオンライン実行の大きな魅力と感じています。

集まっていただいた参加者の皆さんには楽しんでいただいたみたいで、運営冥利に尽きる、といった感じです。人狼は好きなゲームなので、また人を集めてやりたいなと思いました。

2017/7/22(土)、【＜ゆるっとファシリテーター＞体験会】と【ゆるっとお茶会ワークショップ】に参加してきました。

@caori_tさん主催のファシリテーションイベントに参加してきました。
ファシリテーションをやっている様子を見学できる数少ない機会なので、ファシリテーションを体験するのと合わせて、ファシリテーターの考えを学ぶ目的で参加しています。

caorit.hatenadiary.com

イベントは2部に分かれて実施されました。

• 午前：＜ゆるっとファシリテーター＞体験会
• 午後：ゆるっとお茶会ワークショップ

午前：＜ゆるっとファシリテーター＞体験会

今回は＜ふりかえりをゆるファシってみるよ レベル1*1＞ということで、参加者の一人を対象者として、対象者が「過去に実施したふりかえり」をふりかえる、という内容でした。他の参加者は見学者という形で参加しています。私は見学者の立場でした。

今回の体験会で特に面白いと感じたのは、見学者に対する注意事項でした。過去にやったときに、周りの発言によって対象者の問題が分かりにくくなることが理由です。そもそも、発言できる見学者が多くいる環境ってなかなか無いように思うので、注意事項が出てきたことにびっくりしました。

出てきた注意事項は以下のようなものです。

• 手を出さない
• 誘導しない
• さえぎらない

対して、見学者がやってもいいのは以下のようなものでした。

• 問いかけ(質問)
• 確認

内容はふりかえりをKPT形式で行い、ファシリテーションによって対象者の理解を掘り下げる形式でした。Keep,Problem,Tryごとに使う付箋の色を変えるなどの工夫により、整理された情報の一覧性が向上していました。これが問題の理解／整理に一役買っていた思いました。対象者が本質的な問題に到達しやすいような配慮が窺えて、大変参考になりました。
私は見学者でありながら、結構口を出してしまったこと(質問／確認に留めたつもり…)が反省点です。

成果物の画像です。内容は個人情報に関わるため、ぼかしています。

午後：ゆるっとお茶会ワークショップ

お茶を飲みながら個人が抱える問題と前向きに向き合える、午前の部に比べると気軽に体験できるワークショップになっていました

内容は2部に分かれていました。

• 前半：二人一組になって問題に向き合うワーク
• 後半：お茶を飲みながら、前半を振り返るフリートーク(お茶会)

問題分析は「SaPID/SaPID+」に基づいて、@caori_tさんがお茶会用にアレンジした形式になっています。

SaPID＋ - software-quasol ページ！

私も過去にSaPID+ BootCampに参加したことがあるので問題分析の全体像は把握しています。

toshimana.hatenablog.com

ですが、今回はお茶会というテーマに見合うくらい、範囲を絞って気軽に体験できるようにアレンジされていました。本格的な問題分析は十分な時間が必要なので初めての人には敷居が高くなってしまいます。対して、今回のお茶会ワークショップは短い時間で問題分析の入り口を体験できるので、とても面白い(価値のある)取り組みだと思いました。

私のペアは問題分析に時間がかかってしまい、前半の内容を後半も引き続き議論する形になりました。前半でもう少し時間が欲しかったですが、何とか個人の問題は明確になり、次のアクションが見えるところまでは検討することができました。

お茶とお菓子は美味しかったです。

他の参加者レポート

@mhlyc さんがレポートを挙げてくださってます。

mhlyc.hatenablog.com

おわりに

私の知っている問題分析(ファシリテーション)は、重たいプロセスになりがちで気軽に体験するのは難しいものでした。今回のお茶会ワークショップは、工夫しながら、できる限り軽くなるように、問題解決の手法に容易に触れられるようになっているのは素晴らしいと感じました。気軽に問題分析手法に触れられることで、問題に対して向き合い、前進する人がもっと増えるようになると思います。

お茶会ワークショップはまだまだ始まったばかりなので、この先どのような進化をしていくかは凄く楽しみにしています。

*1:レベル1＝初の試み

7/1(土)、オンライン勉強会「ドキュメントインスペクション」を開催しました。

開催しましたって書くと大げさですが、顔の見知ったメンバー数人でクローズドなオンライン飲み会勉強会を行いました。

前回はコチラ
toshimana.hatenablog.com

今回は「ドキュメントインスペクション」をテーマに議論しています。その時の学びをまとめておきます。

大きく2部構成で行いました。

• @Unity1004 による「伝わりやすい文章」についての講義
• ドキュメントレビュー大会

その１：「伝わりやすい文章」についての講義

@Unity1004 に良い文章を書くための色々な観点を教えていただきました。特に、レビューする側としてどういうところを見るか、という視点で色々まとめてくださいました。

勉強になることがたくさんあったのですが、特に興味深かったのは以下の2点です。

これまで作成した文章で困っていた項目をまとめておこう

• 「伝わりやすいか」とか「情報の過不足がないか」などといった読み手の負担になるような項目を整理しておくと、どういう観点でレビューする側がドキュメントを見るのかが明確になり、良い指摘が出しやすくなる。
• 上記項目を「明確性」や「妥当性」のように～性としてまとめておくと良い。また、その中で優先度をつけることで、今何をレビューするかをチームで認識合わせしやすくなる。
• どのような項目が必要かは文章の種類や位置付けなど、状況によって異なる。自分たちが何に困っているかをチームで議論して、自分たちの項目を出そう。

書く前に文書設計をしよう

• 文章を書くときは、いきなり書き出すのではなくて事前に情報を整理することが重要。
• 「誰が」「何の為に」読む文章なのかを明確にする。
• それを満たすために必要な情報を洗い出して、伝えるべき内容とそのレベルを検討する。
• 特に「誰が」「何の為に」が定まらないと内容が収束せずに手戻りが発生しやすくなる。

その２：ドキュメントレビュー大会

あるドキュメントをベースに、みんなはどんなレビューをするか、っていうのをやりました。レビュー方針として「パラグラフ(段落)レベルの指摘を重視」することが挙げられました。全体構成の問題を先に洗い出すことで手戻りを減らすことが目的です、

出てきた観点は以下のようなものがありました。

誰の視点の言葉か

• 人が話した内容を引用したりするときに、主語が書き手なのか話し手なのかが分かりにくくなる場合がある。主語が誰かを明確にしよう。人の話を長文で引用するときは、段落で分けるなど区切りを明確にするといい。

情報の過不足がないか

• 文章を見る相手に過不足ない情報を与えて、内容を整理しやすくする。情報不足は情報の前後関係を適切に理解することができなくなる。情報過多は本筋以外の情報の関係が出てくるので整理が難しくなる。今回は特に読み手に関係のない情報がいくつか挙がっていた。

暗黙知が抜けていないか

• 前提条件を明記しないで(暗黙知として)文章を書いてしまい、内容が相手に伝わらない場合がある。読み手がその知識を持っていないことを考慮して、説明をしてから本題に移ろう。暗黙知は書き手だと気付きにくいので、他の人にレビューをしてもらうと良い。

運営：準備不足

オンラインで勉強会をするのは2回目ですが、前回に比べて準備が不足していました。1回目が上手く行ったという油断があったのでしょう。貴重な時間を割いて参加してくれる人たちに余計な負担は掛けたくないので、しっかりしないといけない所です。

事前の連絡手段が複数存在していたため、情報が適切に伝わらなかった

• 対策：全体への連絡手段は一本化する。

タイムスケジュールがグダグダだったので、脇道に逸れやすかった

• 対策：簡単でいいので、やることを洗い出して事前にタイムスケジュールを用意する。

まとめ

伝えたいことが正しく伝わるドキュメントは誰もが求めるものです。しかし、それを作るためにはみんなで知恵を集めて、各々の感性を技術に昇華して、どうすれば良い文章が書けるかを切磋琢磨して考える必要があります。文章作成は未だにいろんな人が苦労します。また、読みやすい文章を書くための様々なアイディアをいろんな人が持っています。良い文章を作るためにどんなアイディアがあるのか、いろんな人ともっと話し合いたいですね。

オンライン勉強会をやってみた

テストクラスタの仲間うちだけのクローズドですが、オンラインで勉強会をやってみました。
適当にはじめた割には、北は北海道、西は福岡までいろんな方が集まってくれました。
最初は勉強会を行い、そのあとはグタグタお酒を飲む感じでした。

既に講演者の @____rina____ さんがブログにまとめてくれています。
underscore42rina.hatenablog.com

オンライン勉強会の環境

オンラインで参加者間をつなぐツールとして、以下の条件を満たすものを検討しました。

• 最大8人接続可能
• ビデオチャットが可能
• 画面共有が可能

ビデオチャットツール

以下の候補が上がりましたが、今回はGoogleハングアウトを使用しました。

• Googleハングアウト

安心と信頼のGoogle製ビデオチャットツール。無料だと最大10人まで同時接続可能。参加者はGoogleアカウントが必要。知名度が高いので情報を探すのには困らない。

• appear.in

アカウント不要なビデオチャットツール。無料だと最大8人まで同時接続可能。自分環境でGoogle Chromeの環境が古いと接続できない場合があった。

• Zoom

会議用ビデオチャットツール。ホワイトボード機能など、多彩な情報共有ツールがある。最大50人まで同時接続可能。参加者は専用ツールをインストールする必要がある。ビデオチャットを開始する人はアカウントが必要だが、開始されたビデオチャットに参加するにはアカウント不要。無料だと1会議40分制限あり？

あとは、Skypeが使えるかもという案も出ていたけど未検証。

ちなみに、ビデオチャットを前提に環境を用意しました。そして、参加者8人の参加方法として、ビデオ1人、音声3人、チャットのみ4人という内訳でした。ビデオいらねぇ！

講演(@____rina____ さん)

以下の本の一部を抜粋し、良い文章を作るための技法に考え方についてお話いただきました。
「伝わる日本語」練習帳 | 阿部 圭一, 冨永 敦子 | 言語学 | Kindleストア | Amazon

元々、オフライン用に用意した資料を使って講演いただきました。
資料はMicrosoftのOffice Swayで作成されており、画面共有を使って参加者が講演者のスライドを見ながら話を聞くスタイルになりました。
参加者のほとんどが「Office Swayってなんだ？」って感じだったので、それについても講演いただきました。
sway.com

オフラインと違って参加者の反応が講演者に見えないから「講演が難しいのでは？」と危惧していました。しかし、実際にやってみると参加者がチャットを使って反応しており、講演者にフィードバックしながら講演をすすめることができました。話しているのが講演者一人ですが、チャットのテキストに反応しながら講演する様は、まるで「ニコニコ生放送」を見ているような感覚になりました。

講演内容は良い文章を書くために気を付けるポイントがまとめられており、「用語は一意になるようにする」や「難しい漢字を使わないようにする」などを例を含んで説明してくれており、実感とともに理解することができました。今回の資料には、参加者に解いてもらう問題も用意されていたのですが、いわゆる「もんたメソッド」に近い、回答を少しずつ見せていくやり方をしていました。それがオンラインにもマッチしていたため、楽しく学ぶことができました。

ふりかえり

今回の良かった／次に直したいポイントをまとめておきます。

良かったポイント

• 講演者を決めて、最低限の音声担当枠を確保しておくのは良かった。ほかの人がチャットでも成り立っていた。

• 画面共有が使用者のマウスカーソルなども反映してくれて便利だった。講演者のリズムでスライドが切り替わることでオフラインに近い感覚が得られる。ワークなどで参加者の画面を共有しても面白そう。

• 夜中(22:00-)開催。遅い時間だが、自宅でできるので「あとは寝るだけ」の状態で参加できるのも嬉しい。「終わったら10秒で布団に入れる」というのは講演者の談。

次に直したいポイント

• サドンデス(寝落ちするまでやる)飲み会。やりたい人がやっているのはいいのだが、次の日もあったりなので途中で抜けやすい空気を作りたい。

• 次やる場合は人をどうやって集めるか。多すぎると無料枠でのオンラインチャットツールの人数上限を超えてしまう。有料にするとやりにくい。

• 勉強会のログ保存方法の確認。いろいろチャットしたけど、Googleハングアウトの見返し方が分からなかった。

まとめ

SNSでは良く見るけど実際に会うには物理的に難しい人たちとも交流が取れるので地方勢としてはとても楽しい時間を過ごすことができたと思う。勉強会もとても参考になったので、定期的にやりたいと思えるイベントでした。

2017/2/25,26, 【SaPID＋bootcamp】に参加しました。

プロセス改善の手法であるSaPIDを集中して学べるSaPID+bootcampに参加してきました。

安達さんが講師のもと、自分が仕事で抱えている問題を実際にSaPIDを用いて整理して、体験するができた二日間でした。

ワーク概要

自分が業務で抱えている問題をもとに、問題構造図を作成し、改善目標を検討するところまでを行いました。特に、洗い出した問題の精査が難しく、半日以上の時間がかけられていました。問題の精査の際には二人ペアでの作業となり、一方の問題に対してもう一方が質問をすることで問題を深掘りする手法で行われました。問題構造図を作成する技術だけでなく、相手の理解を深める助けをするSaPIDファシリテータの技術を学べるという、時間をかけられる合宿形式ならではの内容になっていました。

振り返り

二日間で振り返るポイントは山のようにありますが、特に問題構造の整理とファシリテーションに着目して振り返ります。

問題構造の整理

keep

• 一通り、合宿をやりきれた。一日目の予定分が終わったときは中途半端に終わらないか不安だったが、ペアの人の協力などもあり最終的には一通り形にすることができた。まだまだ上手く整理できたものではないかもしれないけど、中途半端で終わらない、よりは未熟でも完了するほうが次に進めるため、個人的にはこのbootcampの最低限の目的を達成できた。

• 洗い出しの最初の際に実務で感じた「良くない感覚」を頼りに問題を出せた。SaPIDの問題としてはとても浅いものではあるが、あとで深掘りするからこそ、「良くない感覚」を自覚するつもりでだせたため、広い範囲で問題を洗い出せたと感じた。

• 問題がロジックツリーのように整理された形にならない、ということに気付けた。問題は人それぞれなので、必ずしも整理できる形で出てくるとは限らないことを理解できた。

• 付箋に書き出した問題をまとめることができた。洗い出した問題の数が多くすぎて、全体の俯瞰が難しくなったが、まとめることで全体像の整理に注力することができた。SaPIDとしては問題は抽象的よりも具体的であることを推奨しているが、ある抽象的な問題に着目する必要が出てきたときに、まとめていた問題を分解すれば良い、という考えでやってみた。

• 問題のグルーピング、構造化を早期に行った。カリキュラム的に先走った感があるので、ワーク的に妥当だったかは不安が残るが、グルーピングや構造化を行うことで、全体像を把握しやすくなり、問題をまとめることなどに貢献した。

problem

• なかなか心の奥につっかえている問題を出すのが難しかった。こればかりは自分の心の壁を取っ払うしかないので、自分の問題に直面できる強さが必要があるかと感じた。表面に出てくる問題を解決できれば、根っこの問題が見えてくるかも。

• 問題をまとめたこともあって、最終的な問題が抽象的になった。SaPIDでは具体的な問題整理を行うため、十分に学びきれたかに不安が残る。問題のスコープが広いこともあったため、どうしても問題が発散してしまったことが原因だと思われる。もう少しスコープを限定してやってみたい。

• 問題の分類について理解が疎かになってしまった。問題ではなく手段も多く残ってしまった。問題と思って出したものが何なのかを吟味する必要がある。

• 口頭でたくさん説明したが、その説明を問題として場に出すことが上手く行かない場合があった。口にだしたら即書き落とすことをもっと徹底すべきだった。

try

• 問題が抽象的になってしまったため、より小さいスコープでやってみたい。

• 問題をより具体的にしたい。NGワード(抽象的な言葉として良く出てくるもの)をいくつか教わったので、NGワードを分解するようにしたい。

• 問題じゃないものを多く出してしまったため、出した項目が問題か、手段かを吟味したい。

ファシリテート

keep

• ほかの人の問題をうまく深掘りできる質問ができたと思う。特にうまく行ったと思っているものとして、「相手が出した問題があったとして上手く行くケース」を例示することが挙げられる。それを例示することで、「いや、そうじゃないよな」と考えを深めてもらうことができたと思う。

• 相手に教わる姿勢の重要性を学んだ。「おそらく相手はこういう問題を持っている」と予想していても、相手の捉え方が異なる場合が多々あった。事前に講師の安達さんから「相手に教わる姿勢が重要」と聞いていたが、その意味を体感することができた。

• ペアの人がいてくれることで、感性的な問題を出しても深掘りしてくれる、という安心感があった。

problem

• 相手が深掘りで詰まっているときに、例を出してしまい誘導をしてしまったことが何度かあった。例を出す場合は少なくとも2つ以上を出して、相手の思考停止を防ぐようにする必要があった。

• ペアをしてくれる人に問題を話し過ぎて、自分がスルーしてしまう部分に対してペアの人もスルーしてしまうことがあった。話したことは書き落とすことを徹底すべきだった。

try

• もっと相手のことを理解したい、という気持ちでどんどん教わりにいく。

まとめ

SaPID尽くしでしたが、学ぶことが多くてとても勉強になる二日間でした。SaPIDはもっと色々試して、自分のものになるように練習したいと思います。とても楽しい時間をありがとうございました！

2017/2/24(金)、「未来予想型チーム運営ワークショップ」に参加しました。

仕事をしていると、未経験の領域の作業をしなければならないことが多々あります。不確実性が高いため、正確な見積もりなどほぼ不可能な場合がほとんどですが、そんな中でも作業を見積もって、分からないなりに仕事をこなさないといけません。

今回はそんな不確実性の高い状況でも、自分たちのどのようになりそうかを予想しながら、問題を着実に解決し、理想的な未来のために前進するためのアイディアを学べる「未来予想型チーム運営ワークショップ」に参加してきました。
www.kokuchpro.com

問題解決のための手法である「SaPID」と「TOC」の融合という、これまでにない新しいアイディアであり、とても楽しみにしていたワークショップです。とても楽しく、非常に考えさせられる密度の濃い時間を過ごすことができました。

ワーク概要

TOCのワークショップである「CCPM×折り紙ワークショップ」がベースになっており、チームになって時間内に指定された折り紙を折る、という内容でした。折り紙のお題は最初の段階では到底達成できないと思えるような厳しい条件です。それをSaPIDをベースに起こりうることを予想して、起こりうる未来にはどんな問題があって、どのような要因から引き起こされるのかを整理します。得られた要因に対する対策を検討し、実際に折り紙を折ってみて、検討した対策について振り返りを行い、徐々に改善していきました。できないと思われた問題も、改善を繰り返していくことで効率良く進めることができ、結果的に当初の作業見積もりから大幅に短い時間で折り紙を折り切ることができました。

感想

語りたいことはいっぱいありますが、その中でも特に心に残ったことを書き留めておきます。

予想した通りの結果になる

課題が厳しい条件だったため、起こりうることを予想した時も、失敗する予想が多く挙がりました。講師の安達さんから、「予想した通りの結果になる」とアドバイスをいただき、現実味があるかはともかく完成するためのストーリーも予想してみました。そういった予想が糸口となって、厳しい課題を達成できる改善案が見つけることができたため、どんなに厳しい条件でも成功するストーリーを想定することが実際に成功を手繰りよせるカギとなることを学びました。

流石にお花の折り紙が多いからと、ある参加者が「お花畑ができあがる」と予想したのが叶うとは思いませんでした。別の参加者が知らずにお花畑作ってました。

言葉はできる限り具体的に

起こりうることを予想するとき、抽象度の高い言葉を使ってしまうと、問題やその要因がぼやけてしまい、具体的な改善策の検討が困難になります。予想を洗い出したあと、出てきた言葉を整理する作業がありましたが、自分では意識していなくても抽象度の高い言葉を使っていることに気づかされました。自分が予想した内容の文脈を明確にすることで、自分の頭の中も整理され、本質的な問題が見えるようになるんだということが分かりました。

SaPIDもTOCもやりたいことは同じ

SaPIDとTOCの2つの手法が上手く融合されていて、SaPIDの手法／TOCの手法が使い分けられていることを全く意識することなくワークをやり遂げることができました。お互いの強みを生かした構成になっていることもさることながら、異なる２つの手法がこんなに自然に繋がることに驚きを隠せませんでした。SaPIDもTOCもやりたいことは同じだからことできることでもあり、その２つをこんなに上手く融合させた講師の安達さん、水野さんは本当に凄いと思いました。

まとめ

折り紙のワークでは高度な改善を行ったにも関わらず、チームとして収支良い雰囲気でワークに取り組めました。実際の仕事では殺伐とすることも多かれ少なかれ存在しますが、良い雰囲気でも(むしろ良い雰囲気の方が)高度な改善が可能であることが本ワークで実感できました。
このように、成果が上がって皆が楽しめる場づくりをしていきたい、と強く感じた一日でした。

2016/11/19(土)「第二回盛岡ソフトウェア勉強会」に参加しました。

2016/11/19(土)の第二回盛岡ソフトウェアテスト勉強会の参加レポートです。

kokucheese.com

岩手では勉強会活動があまり盛んではない、というところから岩手出身の藤沢さんが岩手に縁のある方々を集めて開催しています。登壇者の浦山さつきさんは同じく岩手県出身、吉田さんは滝沢市にある株式会社ヴェスに勤務されています。私は岩手と直接の縁はありませんが、岩手出身の会社の人などと一緒に参加しました。

はじめに

ソフトウェアテストの勉強会だと、テスト技法についての話が多いです。しかし、今回は「ソフトウェアテストの第一歩」というテーマで、上流よりのテストの考え方について学ぶ勉強会となっています。講演者3者がテストプロセス、テストレベル、テストタイプについてそれぞれ語る形式となっています。

ソフトウェアテストことはじめ2016年ver

藤沢さんによるテストプロセスの要素である(テスト計画、テスト分析、テスト設計、テスト実装、テスト実行、テスト報告)についての説明と、藤沢さん自身の経験から考案したソフトウェアテスト活動簡易評価チェックリスト10か条の各項目の説明、という構成でした。

10か条は時間の都合で詳細な説明がされたのは5項目でしたが、機会があれば全部聞きたかったです。藤沢さんの経験に基づいているため、私含め参加者の皆様からしたらドキリとくる内容だったかと思います。いくつかピックアップしてみます。

テストに関する成果物のレビューを計画していること。また、計画通り実施していること。

テストに関する成果物に対して、必ず関係各位にレビューをしてもらおう。セキュリティ部門の方とか、開発の方とかにレビューをしてもらうことで、自分では気付かなかった成果物の問題点に気付くことができる。レビューを計画しても関係者とのスケジュール調整が困難な場合がある。しかし、レビューを実施しないことは危険であり、重要な人をピックアップして行うなどしてレビューは必ず実施する。

テストケースは、具体的なテスト実行手順を読み手に理解できるように記述していること。

検討したテストケースがテスト実行のフェーズになって実行できない問題が起きる場合がある。そのため、手順で使うツールや環境などの不明点は明確にした上で手順を検討する。細かい環境が分かっていないとテスト実行ができずに手戻りが発生する。

手戻り撲滅！テストからできる手戻り防止策

浦山さんからは開発のコストを下げるためのテスト側からのアプローチと受け入れテストについての考え方の話をお聞きしました。ワークが多く、ほかの参加者の方々と意見交換をすることができて楽しくみることができました。

開発コストとテスト

開発のコストとして、「製造コスト、予防コスト、評価コスト、内部失敗コスト、外部失敗コスト」に分けられる。製造コストを除いたものを品質コストと呼び、予防／評価コストを管理可能な品質コスト、内部失敗／外部失敗コストを管理ミスの品質コストとする。長期的な品質戦略としては管理ミスの品質コストを減らすことで、「機会損失」を減らすことが重要。そのために、要求分析や設計の段階からレビューにより不具合を検出して、手戻りを少なくすることが有効であるとされる。今回紹介された開発コストの分類は以下の書籍が出典となる。

クオリティ・マネジメント―よい品質をタダで手に入れる法

受け入れテストの考え方

機能という言葉の２通りの解釈ができる。FunctionとFeatureの解釈があり、Functionはソフトウェア開発で使われる製品操作を指す言葉。対して、Featureはもとはマーケティング用語でユーザに「役に立つ」ことを指す言葉となる。テストの観点を抽出する目的としては、ユーザ視点側であるFeature側の機能を出すようにすると良い。テスト項目を洗い出した後に「これはユーザにとってどんな価値を与えるのだろう」という切り口を持つことで、新しい項目が出てきたり、その機能がどうあるべきかを見つめなおす切っ掛けとなる。

ユーザビリティの重要性

吉田さんからは様々テストの中から、テストケースでは表しにくいユーザビリティテストについての話を聞きました。エラー時の言葉の使い方や画面タップ時の挙動についての事例を紹介しながら、テストケースの手順や期待値では表せない「ユーザがどのように受け取るか」を検討することの重要性について解説いただきました。

おわりに

岩手の勉強会活動が盛んではない、という話でしたが土曜日にも関わらずたくさんの方が参加されていました。仙台からだと比較的参加しやすいので、次がありましたらまた参加したいと思います。