「良いシステム像」を求めて泊まり込みのテストワークショップに参加した話 ~Day1~
前置き
ひぐちと言います。社会人6年目になります。
こちらの記事は三本だての二個目の記事です。
内容はワークショップ一日目のレポート。前回の記事はこちらです。
以下、各セッションについての振り返りです。
セッション① 「ポジションペーパー紹介」
朝指定された班で、まずは事前に作ったポジションペーパーを発表し合いました。
ここで感動したのは、運営の方々のイベント運営技術です。
名札の色合いで「初参加」「経験者」「常連」の3段階で参加者を分けて、
「経験者の方は初参加の方をフォローしてあげてください」
「初参加の人は積極的に自ら色々な人に話に行ってみてください」と
それぞれの立場に求められる姿勢をわかりやすくと定義し、
お願いベースで全体に伝えておられました。
「自分は何をすればいい。あの人は何をしてくれる」という具合に
初対面の人たちでも名札を見ながら視覚的に理解して行動を起こすことができ、
「初参加」勢として、とても快適に議論ができました。
これも「期待値の制御」の一種なのかなと思ったり。
セッション② 「前回ポジションペーパー賞受賞者の発表」
気付きは以下の通り。多少自分の解釈も含みます。
- 人は「劇的なもの」にしか目がいかず、それ以外の対象を見落としがち
- 劇的でないものにフォーカスを当てるのが演劇の一つの役割
- 大切なのは「観察」と「表現」の繰り返し
- 面白がって観察すると自分に「変化」が生じやすい
- 観察で生じた「変化」を「表現」し、フィードバックも観察することで「変化」が回る
- つまり持続的に変わっていくためには、「表現する」ことでループを回していく必要がある
- 「表現する」ことで「 外乱による 変化」が発生する。それはとても怖いこと
「書いた記事を公開せねば」と思ったのはこのセッションがあったからです。
閉じた世界で自分の体験だけに留めていても、大きな「変化」に繋がらない。
アプリ開発にせよ、品質管理にせよ、日々の生活にせよ、
コミュニケーションの中で回る世界という意味では一緒なので、色々応用できると感じました。
思いもよらないフィードバックがあるかもしれなくて怖いけど、
より良くなるためには、今の現状を正しく「表現する」のが大事。
そしてこの後のワークショップは全て
「今より良い状態に至るループを作るために、どんな「表現」ができるのか?」
を学ぶ場なのだろうなと。
そういう意味で、最初に聞いておいて良かったと感じました。
ボディーブローのように後からじわじわ効いてくる内容でした。
セッション③ 「再入門!同値分割法・境界値分析」
気付きは以下の通り。講演者の言葉ではなく、班ワークでの議論で生まれた気付きも含みます。
こういうのが出てくるのも楽しいことですね。
- 同値分割とは対象を「同じとみなせる塊」(同値パーティション)に分け代表値を抽出する手法
- 境界値分析とは「代表値」を境界に定めること
- 何を同値とするか?のグルーピングの方法は、分割する目的に依存する
- 自然言語に順序をつけることで境界値分析を適応し、仕様の曖昧さを浮き彫りにできる
- その曖昧さを許容できるか?厳密にすべきか?はドメインによって異なる
以下、ワークの内容をもとに少し深堀します。
同値分割と「分割する目的」との関係
ワークのお題
「以下の項目を同値パーティションごとに整理してください」
カラス ハエ カモメ ハト ハチ ペンギン アリ コウモリ
回答は例えば以下の通り。
- 生物学的な分類
- 哺乳類:コウモリ
- 鳥類:カラス、カモメ、ハト、ペンギン
- 昆虫:ハエ、ハチ、アリ
- 飛べるかどうか
- 飛べる:コウモリ、カラス、カモメ、ハト、ペンギン、ハエ、ハチ
- 飛べない:アリ
- 文字数
- 二文字:ハエ、ハト、ハチ、アリ
- 三文字:カラス、カモメ
- 四文字:ペンギン、コウモリ
これだけみても「何を基準に分類するか?」という観点が異なれば、
さまざまな同値パーティションが存在することがわかります。
そして、その基準は「分類した結果何がしたいか?」に依存します。
上記の分割例から考えるなら例えば以下のような感じでしょうか。
- →「生物事典に載せる項目別に分けたい」
- →「飼うときに屋根が必要か判断したい」
- →「テキストボックスへの入力時の挙動をテストしたい」
連続値でない対象への境界値分析の適応
また、これらの各項目に順序をつけることで境界値分析を適応できます。
ぱっと思い浮かぶ例としては「あいうえお順」ですかね。並べ替えるとこうなります。
アリ カモメ カラス コウモリ ハエ ハチ ハト ペンギン
例えば、「コウモリ」の前後でシステムの挙動が異なるとしたら、
「コウモリ」近辺の値を代表値として選択し、テストするのが良い。
これが境界値分析になります。
では例えば「ハ行の前後で挙動が違う」という仕様であればどれを選択したら良いでしょう?
ハエ?ハチ?ハト?列挙されていない単語である「ハ」?
そもそもハ行の単語はどちらに含まれる?どちらにも含まれない??
こういった「日本語の曖昧さ」を炙り出すことに境界値分析が使えるかも知れない。
といった話がされていました[1]。
境界に対しての厳密さ
「上記の問いにどこまで厳密に回答するか?」は対象ドメインによって大きく異なります。
例えば「施設への入場料判断」であれば厳密さは求められないでしょうが、
「特定の薬の処方判断」の場合、その厳密さはユーザの生死に関わります。
「法律への適応判断」の場合も、厳密さにかけた場合、社会問題に繋がりかねません。
境界値の厳密さには一般的な正解がなく、チームでコミュニケーションを取って、
「どこを境界とするか?」の合意形成をしていく必要があります。
その議論の補助線として、「自然言語に拡張した境界値分析」を使うのは
かなり目から鱗で、かつ有益な方法かもと感じました。
セッション④ 「レビュー活動をやってみよう」
気付きは以下の通り。個人的に自分の経験不足を最も感じ、悔しさの残るセッションでした。
- レビューにもお作法があり、多くのステップが存在する
- レビューにおいて大切なのは、「重要な問題を指摘する」こと。
- そのためには「どんな観点でレビューするか?」などを事前に決める必要がある
- (この日一番苦戦したワークだった、、)
- ステップバイステップでレビューを進めていくのが大事
そもそも1の存在を知れたことが大きな財産だったと思います。以下詳細。
レビューにおける手順
ワークのお題
お題のプロジェクトの背景と要件資料をみて、「検出すべき問題種別の設定」、「指針となるシナリオ作成」の実施
お題資料は「ある飲食系企業の出前システムの要件定義書」。
以下のレビュープロセスの最初の2つを実際に実施しました。
レビューの「お作法」はたくさんあり、どれが正解というものではなく、
今回のワークは以下の書籍におけるフレームワークを参考にしていたようでした。
いざ手順を進めてみると、、
いざ「問題種別の設定」をやってみると、早速手が止まりました、、
何から手をつけていいのか、さっぱりわからなかったのです。
しばらく頭が空転していた時に「以下画像(I-1)のような観点で」
というアドバイスをいただき、それでやっとペンを進めることができました。
また、「シナリオ作成では確認する手順までしか言及してはいけない」
という指摘があるまで、「ここにこれが足りないので追加してもらう」と
一足飛びに指摘込みのシナリオを書いていた自分に気づきませんでした、、
レビュー経験は何度かあったはずなのに、一日目で一番苦戦しました、、
いかに自分が経験や感覚に任せて「レビューみたいな何か」
をこなしていたのかが身に染みて、正直キツかったです、、
「一つずつ狙いを定める」ことが大切
、、ともあれ、セッション全体を通して気づいたことは
「ステップバイステップ」で着実にレビューすることが大事 ということでした。
問題種別設定時にシナリオを作成してはいけないし、
シナリオ作成時に「こう直したらいい」と提案まで一足飛びに飛んでもいけない。
複数人でレビューをする際、ステップを飛び越えてなされた個人の指摘は
他のレビュアーの不要なノイズになりかねないし、レビュアーが一人でも、
後から根拠や理由を遡る際に困る。
「今回見る観点」を定め「その観点において「どこ」を「どのように」みる」かを定め、
そのシナリオに従ってレビューを実施する。という手順に沿ったレビューの浸透により、
俗人化を防いだり、再現性を高めたり、さまざまな良いことがありそうです。
生成AIに上記各項目の手続きや、プロジェクトが重要と定める問題種別を学習させれば、
レビュー担当AIに手伝ってもらう未来もありそう!と思ったりもしました。
(以下、記事執筆において参考にした記事)
セッション⑤ 「ユーザビリティを作り込め!」
最もそれが顕著なセッションだったように思います。
- ユーザビリティは認知科学などの理論の積み重ね。センスに逃げるな
- 特定の利用状況、ユーザ、環境、などに影響を受けるので、ユーザ利用の分析が必須
- システムではなく、ユーザの体験に焦点を当てたのが「UX」
- 思考発話法は身近な人とできそうな良い方法だと感じた
「センスがない」のではなく語彙力不足
これがこのセッションにおける1番の収穫だったように思います。
ユーザビリティには、以下のようにさまざまな要素があるようです。
一番導入しやすそうだと感じたのは「ヤコブの法則」。
「一般的なユーザは、アプリやプロダクト、Webサイトなどに、
既存のものと同じような動作体験を望む」 という法則です。
ということは「ターゲットとなるユーザが普段どんなUIに慣れ親しんでいるか?」
をきちんと理解することが大切になりますね。
上記スライドの要素をザーッと説明していただいた上で「ここまでが前提知識」と言われた時は
「議論のスタート地点にも立っていなかったのか」と未熟さを実感すると同時に
「ここから伸び代しかないな」とも感じて、今は少しワクワクしています。
万人に刺さるユーザビリティなど夢物語
「良いユーザビリティ」は利用環境やユーザなど、以下のような要素に影響を受けます。
考えてみれば当たり前のことですが「誰もが使いやすい」システムは存在しません。
これもやはり「対象の分析」をすることが大切なのだと感じました。
(この部分は少しモヤモヤが残ったのですが、その解決は後でされることになります)
常にターゲットを分析せよ
ここまではユーザビリティにおける「一般論」で、
より「作り込む」際にはどうするか?と言えば、徹底的な「分析」です。
その中でも理にかなっていると感じたのは「思考発話法」でした。方法は以下の通り。
- 検体となるユーザに「システムでやって欲しいこと」だけを伝える
- ユーザは実際に手を動かす。その際に「感じたこと」はなるべく口に出してもらう
- その様子(それぞれの動作にかかった時間、その時の感情など)を記録する
どんな部分で戸惑うのか?その際どんな気持ちか?などを記録し、分析を行う方法のようです。
今後UI改修する際は、同僚を捕まえてやってみたいと感じました。
セッションを通して 「使うのは現場の人なのだから、より現場と人を知れ」
という二日目に出てくる「三現主義」に通じる内容だったと感じました。
直感的には「当たり前」なことも多かったのですが、
それを体系的な言語に落とし込んで議論を進めることが大切なのかなと。
もっと深掘りして知りたいと思ったので、書籍を購入し改めて勉強中です。
セッション外 「夜の分科会とかお昼休憩とか」
ここまででセッションとしての枠は終了したのですが、
夜約二時間ほど、分科会という自由に議論するための時間が設けられました。
お酒やお菓子をつまみながらアツい話や今日の復習をできる場で、
そこでの学びも載せておきます。
他にもいろんなイベントがあるみたい
昼食だったり、夜だったりに、参加者の皆様に
ここ以外のさまざまなイベントについて、教えてもらえました。
前の記事で「日常に技術の文脈を入れ込む」という話がありましたが、
「こんなに沢山文脈を知ってる人にはそりゃ置いていかれるよな」と感じました。
これから吸収し、勉強していきます。
セッション⑤延長戦 「ターゲットが広すぎる場合はどうしたら、、?」
セッション⑤で「対象となるユーザを分析せよ」という話があった時に、
自分の業務に当てはめた時、少しモヤモヤが湧きました。
「多様なユーザに提供したい場合はどうしたらいいんだろう?」というものです。
そこで実際に講演されていた山口さんにお話を聞いてみました。学びは以下の通りです。
- ユーザと大きく一括りにせず、分類していく
- それをもとに「まずはこの層にアプローチ」など戦略を持って進める
- UIの作り込みだけが選択肢ではない。政治的な対策があってもいい
対象の大きさや広さをそのまま扱うのではなく、分けて優先順位をつける。
という手法は学びになりました。「困難は分割せよ」 という言葉を思い出しました。
また、3については、システムや技術を浸透させる方法の参考として、
以下の書籍を紹介していただけました。イベント後に買って読んでみたら、
自分の仕事にマッチしまくりの内容で感動でした!
この書籍に出会えただけでも分科会に参加して良かったと思えました。
親身になって回答してくださいました山口さん。本当にありがとうございました。
まとめ
この記事のボリュームを見返してみてもわかるくらい、盛り沢山な一日でした。
これでも「書きたいけど冗長になるな」と省いた部分があるのだから驚きです。
- 何かについて学ぶとその対象への解像度が上がる
- 解像度を上げた状態で議論することで、より高度なコミュニケーションができる
- その先により良いものを目指すことができる
というのがなんとなく体感できたように思います。
これは品質というトピックに限らずそうだろうなと。
引き続きいろんな語彙を吸収していきたいなと思いました。
(二日目のレポートは年明けになってしまいそうです、、)
-
ワークでは「1歳半」「横浜駅まで」はどう区切る?と例が出されていました。 ↩︎
Discussion