2018年のふりかえり
はじめに
2018年も終わりになりましたので、ふりかえりエントリを書きます。
よく「社会人になってからの1年は短い」と言われますが、
個人的には、学生時代にも匹敵するかのような、長く濃密な1年でした。
やったこと
1月
会社の先輩に教えていただいて、リリカルの質問全部答えますに参加しました。
思えば、これがすべてのきっかけでした。当時はブロッコリーさんのブログやリリカルさんのブログをよく拝見しており、右も左もわからないままとりあえず参加したのでした。当日のtogetterはこちら。日本企業において、品質保証がどのような歴史を辿ってきたのかを学ぶことができました。
その後、テスト酒場に参加し、まなべさんのオンラインもくもく会に参加させていただき、徐々に知り合いが増えていきました。
語る夕べにも参加してみましたが、全く単語が理解できず、議論についていけない状態でした。ただ、「わからないものがある」ことがわかるということだけでも非常に楽しかったので、その後も継続して参加しました。
テスターちゃんを頑張って読みました。2月
テスト設計コンテストなるものがあることを知り、決勝戦を見学しました。
また、デブサミに参加したり、カイゼン・ジャーニーに出会って強く共感したりもしました。3〜4月
3月はまず、JaSST'18 Tokyoに参加したことが大きかったです。正直、いまだに当日のふりかえりが終わっていないのですが、Googleにおけるテストの話や探索的テストの話など、印象深いセッションが多かったです。
また、伊藤由貴さんが、テストエンジニアのためのSlackワークスペースを作ってくださいました。
テストもぐもぐ会にも参加しました。みなさん真剣なテーマを持ち寄られていたのが印象的でした。
4月末には、休日出勤からのはしごという形で“Issueの書き方と伝え方”勉強会に参加しました。リナさんの発表がすごすぎて「すごい」以外に言葉が出なかったことを覚えています。あとセフィロス。 探索的テストっぽいことは前職を含めて結構長くやってきたつもりでしたが、自身の至らなさを痛感しました。
また、この頃からscrapboxに移行しました。5月
5月には、NaITEに参加しました。「テストの勉強会もいろいろあるんだなー」と思うようになります。
また、頑張って上司を説得してJaSST'18 Tohokuに参加しました。6時間かけてのワークショップは正直疲れましたが、ラルフチャートの考え方を早速現場に持ち込むことができました。(入力と出力を付箋で整理し、開発チームやプロダクトオーナーとテストの優先度を相談しました)。6月
6月はJaSST'18 Kansaiに参加し、続けてWACATEに初参加しました。
JaSST'18 Kansaiのテーマは「納得」でした。tawdaさんのライブコーディングに、ただただ感動しました。「納得」というキーワードは、この日から自分の中に引っかかりつづけています(ポジティブな意味で)。
WACATEは、とにかく演習についていくのに必死で、当日はモヤモヤが沢山残った状態で帰宅しましたが、悩みが深かった分、その後大きな糧になりました。 ファシリテーションやチームビルディングといった方面への興味が強まったのもこの頃です。 (ひとりSaPIDをやろう！と思ってまだやれていません...)7月
7月は、にしさんの資料をずっと読んでいました。
また、WACATE2018夏 復習会をはじめ、さまざまなイベントに参加しました。8月
ワニさんといそべさんの勉強会で、ABDを学びました。これは結構強い読書法だなと感じましたので、以後ちょくちょく使っています。
また、JSTQB AL テストマネージャを受験しました。こちらは幸い、合格することができました。9月
XP祭りに参加しました。twadaさんの基調講演だけでお腹いっぱいになりました。英語のセッションはほぼ雰囲気でついていけましたが(ついていけたと勝手に思いこんでいましたが)、ちゃんと理解できたわけではないので、英語スキルも伸ばす必要があると感じました。また、Scratch本をいただいたので、全部やりました。Scratchはビジュアルにわかりやすくコーディングできるので、通常のIDEでコーディングするのが辛い方におすすめです。10月
テスト設計コンテストのチュートリアルに参加しました。(※U-30はこちら)。終わってから早速有志で集まって、いろいろ取り組んでいます。正直まだ1㍉も理解できている気がしません。
技術書典に行きました。
VSTePの勉強会に参加しました。
秋のもぐもぐ会にも参加しました。
あと、会社の部署が変わって、地味に忙しくなりました。11月
JaSST'18 Kyushuに参加しました(部署が変わったことで、社外イベントに参加しやすくなりました)。同値分割はやっぱり深い！と感じたJaSSTでした。長崎の地形(※)とごはんも満喫しました。ペンギン水族館には行けず...。
※ながさき坂道めぐりというサイトが素晴らしいです12月
JaSST'18 Reviewに参加し、続けてWACATEに参加しました(夏に続いて2回目)。 JaSST'18 Reviewは、パネルディスカッションが特に印象に残りました。正解がないのが正解、なのだと理解しました。
WACATEは、夏に比べると気持ちの余裕をもって参加できました。～C’mon baby ジドウカ～の元ネタがDA PUMPだと気付いたのは初日の夜くらいでした。
夜の分科会も含め、充実した2日間になりました。一方で、夏と同様に消化不良感もあり、近いうちに復習会を企画できればと思っています。
語る夕べで、ゆもつよメソッドを学びました。湯本さんに初めてお会いしました。
テストアナリスト試験対策勉強会に参加しました。
Qiitaのソフトウェアテスト #2 アドベントカレンダーに参加しました。
(アドベントカレンダー#1はこちら)
(小ネタカレンダーはこちら)その他、1年を通じて
上記以外にも、様々なイベントに参加しました。
わかったこと
この1年を通じて、わかったことを書いてみます。
テストの世界は広大だと実感した
今年の収穫はこれに尽きます。小手先の方法論で何とかなるような世界だけ見ていては勿体無い、という気持ちが日を追うごとに強くなりました。インプットに偏った結果、復習(アウトプット)が満足にできなかった
こうなることがわかって突き進んだので、後悔はしていません。
特に、内部構造方面の学習＆実践がほとんどできませんでした。TDD、BDD、ATDD、コーディング(もう何年もやってない)、自動化の実装、etc
テスト開発の方法論についても、満足に手を動かすところまで行けませんでした。
積ん読もたくさん。。。健康など色々なものを疎かにした
これも反省材料です。反省はしていますが、後悔はしていません(^^;)。
つぎ(来年)にやること
最後に、来年にやること＆やらないことを書いてみます。
英語で文献を読めるようになる
ISTQBのシラバスをはじめ、欲しい情報が英語でしか手に入らないことが増えてきました。英語スキルは優先的に鍛えたいです。 iPhoneの言語設定を英語にして数ヶ月過ごした結果、ISTQBシラバスを読む程度なら違和感がなくなってきました。
他に、格ゲーの実況動画などを流し聞きしています。基礎を学び直す
ここ最近、Foundationシラバスなどを読んでいると、新たな発見＆気付きがあったりします。 丸暗記していたものがハラオチする、のパターンが多いように思います。社内外で、イベントの主催側にまわることをメインに据える
2018年は、ほぼインプットで終わりました。少しイベントを主催したりもしましたが、このバランスを主催寄りに変えていきたいと思います。 コミュニティに貢献したい、という気持ちも含めています。健康など、生活まわりを改善する
いろいろ犠牲にしました。さすがに時間リソースを振らなさすぎたので、見直します。Twitterを控えるべきなのか...！？技術書典などに向けて、書く
書きたいです(書けるとは言ってない)。
つぎ(来年)にやらないこと
- インプット目的の勉強会参加(減らす)
何を削るか考えましたが、、、このくらいしか思いつきませんでした。
やりたいことがまだ多すぎる感じがするので、やらないことをもう少し増やしたいですね。
まとめ
好奇心にまかせて、ただひたすらイベントに参加し続けた1年だったと思います。
来年は、コミュニティへの貢献を増やしていきたいと思いますので、引き続きよろしくお願いいたします！
テストアナリストのシラバスに載っているテスト技法
この記事は、ソフトウェアテスト #2 Advent Calendar 2018 14日目の記事です。
はじめに
JSTQB テストアナリストの学習を通じて、ソフトウェアテストの技法をいくつか学びました。 本記事では、日本語版シラバスの各技法に対するコメントを書いてみます。 見出しの番号は、シラバスの目次と対応しています。 あくまで私個人の経験に基づいて書いていますので、一般論ではありません。ご注意ください。
3.2 仕様ベースの技法
3.2.1 同値分割法
おなじみの同値分割です。私も実務で当たり前のように使っています。 シラバスにも書かれているとおり、同値クラス内の値が正確に同じ方法で処理されないと欠陥を見逃します。 あまり過信はせず、他の技法と組み合わせて使うことが多いです。同値分割の結果だけを使うのであれば、スモークテストで使う程度にとどめています。 また、無効同値を狙うための前処理としてよく使います。
3.2.2 境界値分析
こちらもおなじみの技法です。2値の値を用いる方法はよく使っていますが、3つの値を用いる方法は使ったことがありませんでした。3つの値を用いる方法は、JaSST'18 Kyushuでも紹介されていました。今後、取り入れてみたいと思います。 この技法は、ループや時間に関係する境界にも適用できます。例えば「同じ操作をn回繰り返す」や「日跨ぎで操作する」はよくやります。ただ、こういった欠陥は、境界値分析のテストではなく、探索的テストと意識していたことが多かったです。
3.2.3 デシジョンテーブル
実務では一番使っている技法かもしれません。表形式にまとめると、お客様への説明がラクですね。条件の組み合わせが増えると表が肥大化し見づらくなるので、情報をどう切り出すかをよく悩みます。また、デシジョンテーブルを作ると、期待結果の抜けが見つかることが多いです。そのため、ソフトウェアの設計/実装をしていた時にもよく使っていました。
3.2.4 原因結果グラフ法
座学のみに留まっている技法です。WACATEなどで記法は習いましたので、今後習得していきたいと思います。 シラバスによると、テストベースの品質向上が期待できるそうです！
3.2.5 状態遷移テスト
状態遷移図/表は、テストの実務で使ったことはほぼありません。ソフトウェアの設計/実装をしていた時にはそこそこ使っていました。 たとえば、申請/承認機能の挙動をデシジョンテーブルで整理したことがありますが、いま思えば状態遷移図/表を使った方が良かったのかもしれません。 WACATEでモデリングを学んだ際、「状態遷移中」もひとつの状態として捉えるかどうかは非常に悩みました。
3.2.6 組み合わせテスト技法
直交表、ペアワイズ、クラシフィケーションツリーについて触れられています。組み合わせ爆発を防ぐ目的で、ペアワイズを用いることはあります。直交表は、実務では使ったことがありません。クラシフィケーションツリーも、実務では使ったことがありません。今後習得していきたいと思います。
3.2.7 ユースケーステスト
実務ではそこそこ使う技法です。ユーザーストーリーを書く前の前処理的に使うことが多いです。他の技法を使うときと比べて大きく違うのが、ユースケースを書くために、有識者のお時間をいただく必要があるということです。知識を豊富にお持ちの方は概ね多忙ですので、普段から関係性を築いていくこともとても大事だったりします。
3.2.8 ユーザーストーリーテスト
実務ではかなりよく使う技法です。非機能テストを含めることができるので、使い勝手が良いです。私が関わった実務の範囲では、BDDやATDDを使うことはあまりありません。ユーザーストーリーをもとに記述した受け入れテストをデモしてDONEにしています。ユーザーストーリーテストを使う現場では、細かな組み合わせのテストなどが軽視されがちな印象を受けますので、意識して他の技法で補強しています。
3.2.9 ドメイン分析
座学のみに留まっている技法です。ソフトウェアテスト技法ドリルで学びました。私の場合は恐らく、ドメイン分析を適用できる状況でもデシジョンテーブルを使っていました。技法が分かれているということは何かしらの意味があると思いますので、学び直します。
3.3 欠陥ベースの技法
3.3.2 欠陥分類法
欠陥分類法という名前そのものには馴染みがありませんでしたが、実務ではそこそこ使っている技法だと思います。異常系のテストを設計するときに使います。 シラバスでは、テキスト欄と日付欄をサンプルに例示がされています。実務では、これらのリストがすでに手元にあることは少なく、都度考えて作っていることが多いです。ちょっと勿体無いですね。
3.4 経験ベースの技法
3.4.1 エラー推測
テスト好きであれば、大体の方が得意な技法だと思います。自分自身にスイッチが入ってしまうと、枝葉ばかり狙って幹が疎かになることがあります。使いどころには気をつけましょう。また、結果を言語化して伝えるのが難しいことも多いように思います。 例：「よくこんなの見つかりましたね！どうしてこれを思いついたんですか？」「さあ。。。？？(このあと頑張って言語化する)」
3.4.2 チェックリストベースドテスト
シラバスの定義と合っていないかもしれませんが、スモークテストなどの用途で、簡易的なチェックリストを使うことがあります。データを作って→取引の記録をつけて→月の処理を締めて→帳票に出力して、というイメージです。簡易的なチェックリストなので、細かい操作は人によってブレますが、手順抜けの防止に使えます。新規参入メンバーの教育目的で、同チェックリストを使うこともあります。
3.4.3 探索的テスト
実務では、ときどき使う技法です。JaSST'18 Tokyoで、チャーターを使った探索的テストを学びましたが、私の場合はチャーターを使ってかっちりとテストをした経験はなく、刺激に対する反応を拾って、次の刺激を与えるというサイクルを繰り返すことが多いです(刺激→反応モデルと呼ばれるそうです)。欠陥を見つけるだけでなく、「こう動かしたらどうなるの？」という情報を得るために行うことも多いです。
(番外)構造ベースの技法
構造ベースの技法は、テクニカルテストアナリストのシラバスに記載されています。 (前職の)実務では、複合条件カバレッジを用いることが多かったです。シラバスだとどこに該当するか、ちょっと理解できていません。判定条件テスト？
まとめ
シラバスを読むことで、新しい技法との出会いがありました。 自分の引き出しが増えるのは楽しいですね。既に知っていた技法についても、学びなおす良い機会となりました。 皆様もシラバスを読んで、楽しいテストエンジニアライフを送ってください。
JSTQB テストアナリストの勉強会
この記事は、ソフトウェアテスト #2 Advent Calendar 2018 3日目の記事です。
そうだ、JSTQB テストアナリストを取ろう
ソフトウェアテスト技術者の認定資格に、JSTQB テストアナリストがあります。
JSTQBは「Foundation」「Advanced」「Expert」の3段階に区分されていて、 テストアナリストはAdvancedレベルに該当します。
過去問も模試もない
JSTQB テストアナリスト試験は、2016年から毎年1回のペースで実施されており、 次回は、2019年2月です(※受験申込みは既に終了しています)。
実施自体がまだ4回目ということもあり(？)、模試などの情報がほぼ存在せず、手探りで受験対策をする必要があります。 JSTQBでは試験問題を持ち帰ることができないため、過去問を使った学習もできません。
ということで、勉強会が始まりました
そんな経緯で、有志の方が勉強会を立ち上げてくださいました。
第2回JSTQB Advanced Level テストアナリスト試験対策勉強会 - connpass
JSTQB の試験問題は、同シラバスの内容から出題されます。 勉強会では、班ごとに分かれて、シラバスを参考に問題を作成し、解きあうということを行いました。 問題を作るためにはシラバスを細かく読み込む必要がありますので、大変ですが良いトレーニングになります。
↓の一覧を使いながら、シラバスに沿ってK2(理解)、K3(適用)、K4(分析)レベル相当の問題を作成していきます。
実際に参加してみた感想ですが、 シラバスに記載されている学習の目的に沿って進めることがとても大事で、 闇雲に丸暗記を頑張るのはよろしくないということを実感しました。
今後も、2週間ペースで開催予定になりますので、ご興味のある方は是非参加してみてください！
ソフトウェアテストにまつわる英語文献2018
ソフトウェアテストにまつわる英語文献を自分なりにまとめてみました。
JaSST'18 Kyushuの行き帰りに「Advanced Software Testing- Vol. 1」を読んでみたのですが、
図解や事例が豊富で非常に理解しやすかったです。
たぶん買う。
※2018/11/24現在で、和訳が流通していなさそうなものを列挙しています。
「これ和訳あるやろがボケ！」ってものがあったら優しく教えてくださると嬉しいです。
※Advancedレベルは、最新の2012年版が和訳されているため対象外としました。
アジャイルテスターも同様です。
- ISTQBシラバス
各シラバスのダウンロードはこちらのリンクから。
https://www.istqb.org/downloads.html
以下に直リンクも作りましたが、「Downloads」からアクセスしないと怒られる模様です。
Foundation 2018
Certified Tester Foundation Level Syllabus Version 2018 Version
モデルベースドテスター
Foundation Level Certified Model-Based Tester Syllabus Version 2015
セキュリティテスター
Certified Tester Advanced Level Syllabus Security Tester Version 2016
テストオートメーションエンジニア
Certified Tester Advanced Level Syllabus Test Automation Engineer Version 2016
テストプロセス改善
テストマネジメント
- 書籍
Advanced Software Testing - Vol. 1
Advanced Software Testing - Vol. 2
Advanced Software Testing - Vol. 3
ISO/IEC/IEEE 29119 SOFTWARE TESTING STANDARDS (English Edition)
More Agile Testing
Developer Testing
xUnit Test Patterns
Explore It!
Bug Advocacy
バグレポートは伝え方が9割(※個人の感想です)
こんにちは。カルバートです。
GW前に参加してきた、「"Issueの書き方と伝え方"勉強会」の内容と、当日感じたことを書きます。
当日のツイートまとめ
エラーと欠陥と故障と不具合/バグの違い
JSTQB用語を学ぶときの最初の障壁(※個人の感想です)、エラーや欠陥などの用語の違いについて、秋山さんのスライドがとてもわかりやすかったです。
エラー：てへぺろ→人間だもの間違うことはあるよね
欠陥：家のヒビ→てへぺろの結果埋め込まれてしまったもの(ディフェクト)。経年劣化などで表面化してきたものはフォールトと呼んで区別する場合もある
故障：期待と違う結果→ヒビのところから家が壊れた、ディスプレイの画面が乱れた
不具合/バグ：故障が表出した(人間が観測できた)もの→レポートの対象になるのはこれ
私のまわり(おもにWEB系ドメイン)では、これらの概念を特別に区別して扱っていることはないのですが、厳密な分析を行ったりする場合には、区別して整理する必要がありそうですね。
「報告する人」と「報告を受ける人」は対立構造になりがち
今回は4名の方が発表されましたが、バックグラウンドが皆様それぞれに異なっており、注意すべきと考えているポイントも異なっていると感じられたのが印象的でした。
本来、不具合/バグを報告するレポートは、「サービスが期待する振る舞いをしていない」という事実を伝え、サービスを改善するために書かれるべきだと思います。実際、レポートそのものは事実を伝えるべく書かれるのですが、内容がネガティブなものにならざるを得ないため、「報告する人」から「報告を受ける人」への攻撃と受け止められがちなのかなと感じます。
「報告する人」の視座
秋山さんやリナさんの発表では、「報告する人」の立場から、テスト担当者と開発担当者が明確に別れている前提で、どのように感情を損なわず、お互いの納得感をもって、事実を記録し、情報の同期を適切に行うかという趣旨のお話をしていただきました。
リナさんのケースは個人的にとても衝撃的で、自分なりに表現すると、映画の中の理想の世界でした。黒い白鳥なんてお話の中の世界なんだから、現実を見なさい。白鳥は白いのよと教わってきた人が黒い白鳥を見たときの衝撃という感じでしょうか(伝われ)。
関係性ががっちり構築されていると、こんなにも理想的な立ち回りができるのだなあ。。。と感じた発表でした。普通の人にはマネできないと思います。
「報告を受ける人」の視座
一方、渋谷さんの発表では、「報告を受ける人」の立場で、様々な考え方を伺うことができました。僕自身の経験でいうと、とある案件の本番導入に「報告を受ける人」の立場で立ち会ったことがあるのですが、それはもう地獄でしたね。「おまえらの作ったサービスがちゃんと動かないから大変なことになっている！どうしてくれる！」という感情が篭ったレポートを毎日何十件も読んでいました。ただ、その感情の先に、「サービス提供者として気づけていなかった、隠れていた要件」が存在していたりするので、二度と思い出したくない反面、自分の原点のひとつになっている経験でもあると感じています。
みっきーさんの発表は時間の関係で深く議論できませんでしたが、また別の機会があると嬉しいです。
結局は人が相手なんだし、思いやりが大事
バグレポートに限らないのですが、結局人間である以上、耳の痛い情報を受け取るときにネガティブな感情が発生してしまうことは避けられないのかなと思います(人間というものがそういう風に実装されてしまっている)。
その特性(仕様)を理解して、「報告する人」と「報告を受ける人」がお互いに気持ちよく仕事をするために、まず「伝え方」を工夫することが大事なのかなと感じた1日でした。
発表資料
Issueの書き方と伝え方 from Rina Fukuda
参考書籍
- 作者: Cem Kaner,James Bach,Bret Pettichord,テスト技術者交流会
- 出版社/メーカー: 日経BP社
- 発売日: 2003/04/22
- メディア: 単行本
- 購入: 15人 クリック: 246回
- この商品を含むブログ (49件) を見る
余談
秋山さんから、デザートをいただきました。ありがとうございます！とても美味しかったです！
信頼度成長曲線は信頼できるのか。
こんにちは。カルバートです。
先日、信頼度成長曲線を語る夕べに参加してきました。
信頼度成長曲線とは
信頼度成長曲線とは何なのか。自分の理解の範囲で言い換えると、
いつまでテストすればいいの？を数学的に予測するやり方です。
そもそも未来を予測することはできるのか？という難しい問題提起に対して、偉大な先人たちは様々な数学的モデルを考案してきました。ロジスティック曲線やゴンペルツ曲線など、様々なモデルが存在します。いずれも、自然界の事象を数式でモデル化することで、未来の予測に活用しようとしたものだと理解しています。
ソフトウェアの不具合検出に、その技法は応用できるのか
「語る夕べ」に参加したうえでの個人的な感想は、「理論上不可能ではないが、実務に応用するためには前提条件を整えるコストがかかりすぎて、難しいのではないか」でした。ざっと調べた限りなので間違いがあるかもしれませんが、たとえば生物の発生にロジスティック曲線を適用する場合、外部の環境(気候や食糧など)が一定しているという前提が満たされている必要があります。ソフトウェアテストにあてはめた場合、「不具合は偏在しない」「不具合の発見されやすさは常に一定」といった前提が必要になってきます。テストレベルが低ければ部分的には応用できるかもしれませんが、それらだけ切り出して分析することでテストの収束が予測できるかというと、また別の話なのかなと思いました。
綺麗なグラフを見たら建設的に疑おう
当日は、みっきーさんの(つらい)経験をベースに、信頼度成長曲線をそれっぽく見せるための様々なテクニックをお話しいただきました。いくつかは自分自身も経験したことがあるものでした。
未来を数学的に予測するための道具が本来の使われ方をせず、綺麗な数字をステークホルダーに報告するためだけの存在になってしまっている(ことが多いらしい)という話は、なんとも悲しいものです。そんな作業をするために、人生の貴重な時間を使いたくはないものですね。
信頼度成長曲線に限らず、グラフを見たら根拠を建設的に疑う。自分がグラフを書くときは、根拠が誤解なく伝わるよう務める。そんなことが大事なのかなと感じたイベントでした。
参考にした書籍
当日のツイートまとめ
第4回 テスト観点を語る夕べに参加しました
こんにちは。まつやま改め、カルバートです。
第4回 テスト観点を語る夕べに参加してきました。
当日のtogetterはこちら。
はじめに
まずは登壇者のなそさんが作成されたマインドマップがどーん！
めちゃくちゃ文字が綺麗で、美しいマップです。
何を食べたらこんな綺麗な文字が書けるのでしょうか…羨ましいです。
参加型ワークショップ
当日はまず前回のおさらいから始まり、その後はにしさんのファシリテートを受けて、なそさんのマインドマップに加筆修正が行われていきました。
そのサービスのコアバリューは何か
今回のワークショップでは、connpassというサービスを題材に、サービスのコアバリューを列挙し、それを親要素としてテスト観点をブレイクダウンする手法が取られました。ここで重要なことは、機能や操作(※)といった、ソフトウェアの構造上の「わかりやすいポイント」に最初に飛びつかないことです。
(※ connpassの例でいえば、「検索」や「申込」などが該当すると思います)
僕はこれまで、要求や要件を親とするアプローチや、機能や操作を親とするアプローチを多く経験してきましたので、これは個人的に新鮮でした。
いつでもどこでも
コアバリューの例としてなそさんが挙げられたキーワードに「いつでもどこでも」がありました。connpassは勉強会ポータルですから、いつでもどこでも好きなときにイベントを登録できること、参加申し込みができること、キャンセルができること、あるいはサイトに繋がるといったことが重要なバリューになります(と、この勉強会では解釈しました)。
コアバリューを分解する
次に、コアバリューを分解していきます。ここでひとつ、注意点があります。それは、いきなり具体的なキーワードを書かないということです。子ノードを作成するときに、「いつでもどこでも」から連想する具体的なワード(例：ログイン機能)を書きたくなってしまいますが、一歩立ち止まって我慢が必要になります。子ノードを作成する目的は、今すぐにわかりやすいテストケースを作成することではなく、親ノードの持つ「意図」を分解することです。
「いつでもどこでも」を親とするならば、次の子ノードの例は「いつ」と「どこ」になります。これ以上いきなり細かくしてしまうと、MECEや継承関係が後から確認しづらくなってしまいます。
思考がアンカリングされていることを意識する
子ノードを出すときのもうひとつの注意点として、思考のアンカリングがあります。今回は、「いつ」というキーワードの意図を紐解いていくと、「トラフィックが増えたとしても、それに耐えられること」という意図が浮かび上がってきました。このとき、参加者は全員「トラフィックの増加って、つまりどういうことだろう？」と、具体的なユースケースや、システムのアーキテクトを想像しはじめます。
僕の場合は、「某人気イベントに人が殺到したけど、あの重たさは許容範囲内だったんだろうか」とか「トラフィックと一口に言ってもいろいろあるし、内部構造を知っているか知らないかでも気にするポイントは変わるな」といったことが頭に浮かびました。
こういった状態では、脳は「トラフィックが増えたとき」のことをどんどん深く考えてしまいます。それは決して悪いことではないのですが、この状態で他の「意図」について考えようとしても、「トラフィック」思考にどうしても囚われてしまいます。これが「思考がアンカリングされている」状態です。
この対処としては、アンカリングされている間は頭が空っぽになるまでアウトプットを続け、空っぽになったと思われるタイミングで次に移ることが有効だそうです。このメソッドは、ブログを書いたりするのにも使えそうですね。
ここまでのまとめ
・コアバリューを起点に、子要素をブレイクダウンする
・子要素をブレイクダウンするときは、いきなり具体例に飛びつきたくなる誘惑と戦う
・思考がアンカリングされていることを意識する
当日はこのほかにも色々お話があったのですが、一旦ここまででまとめとさせていただきます٩( 'ω' )و
