探索的テストの質を上げる取り組みをしました
はじめに
こんにちは！だいみょーです！
探索的テストという比較的耳馴染みが良い言葉のせいか、アドホックなテストが探索的テストと呼ばれているケースが散見されます（自分調べ）
弊チームでも探索的テストという名目で取り組んでいますが、持ち回りにしていることもあり、担当によってはアドホックになっていたり、テストの質があまり高くないという課題感があったりしました。
そこでやり方を改めて考えて、運用の見直しを図ったのでメモを残しておきます。
そもそも探索的テストとは
JaSSTのセッションのとても良い資料から拝借しましたが、 エリザベス・ヘンドリクソンさんの定義だと
直近の実験から得た”気づき”を次の実験へ活用し、テスト設計と実行を同時に行い、システムについて学習していくこと
とされています。
また、同じ資料に記載されている探索的テストに必要な3要素として、製品知識、テスト技術、バグの知識が必要とされています。 そりゃなんとなくやったところで質は上がらず、きちんと戦略立ててやる必要があるなという感じです。
引用： https://www.jasst.jp/symposium/jasst18tokyo/pdf/E2.pdf
やったこと：チャーターに広がりを持たせるセッションベースドテスト
今日はこれが気になるからやってみて探索していこうというスタイルでも良いのですが、 結構ハードルが高かったりしたので、チャーターに深みが出るように工夫（後述）して行う方針でやることにしました。
また、ふりかえりの場を設けるという意味でも区切りを設けるセッションベースドの方がやりやすいのでそうしています。 では実際の流れについて説明していきます。
全体の流れ
- チャーターを考える
- セッション①開始
- フィードバックタイム
- チャーターの見直し
- セッション②
- フィードバックタイム
- バグレポートの起票
チャーターについて
探索的テストでチャーターを作成するケースはあるんじゃないかと思いますが、 「さあ作ってみましょう」だとどうしても観点が偏ったり、結局闇雲に網を振っているだけになるので、 作り方を少し工夫することにしました。
チャーターの作り方その①：ペルソナの帽子をかぶって考えてみる
プロダクトの利用者によって求められる品質が異なることもあるので、 成り切ってそのユーザーだったらこんな風に使うかもしれないという前提でチャーターを作成することにしました。
チャーターの作り方その②：品質特性を念頭に置いて考えてみる
弊プロダクトでは、機能性と信頼性が重視されるので、例えば品質特性のこの副特性だったらこんなことを気にした方がいいなとか、品質特性を念頭に置いたチャーター作りをすることにしました。
チャーターの作り方その③：今回のスプリントで発見されたバグを中心に考えてみる
これはわかりやすいですね。バグからこんなこともあり得るかもなという形でそこから仮説を立ててチャーターを作ってみるパターンです。
やってみてどうだったか
1時間弱くらいの時間でやっているので、1セッション1人1チャーターくらいの感覚でやっていますが、 チャーターを修正するというタイミングを作っていることもあり、経験のサイクルがちゃんと回っていい感じになりました。 また、きちんと探索することで、新しいドメイン知識を獲得できたり、学習の観点でも効果があってとても良かったです。
その他
先ほどのJaSSTの資料にもありましたが、QAEの勘所というか、境界値だったりCRUDに注目したりとか、ポイント的なところを羅列しておいても良いかなとか。今のチームはSWEがテストしているので、手助けする何かがあると効率的だなあと。
ポモドーロスプリントプランニング
はじめに
ポモドーロテクニックでスプリントプランニングをしたので、経緯とどんなことをしたのか思い出を残そうと思いました。
ポモドーロテクニックとは
ポモドーロテクニックについては今更感があるので、下記リンクをご参照ください。
経緯
私のいるスクラムチームではリアーキプロジェクトを進めており、結構大掛かりに新しい技術の検証と導入を進めています。 技術的に不確実な要素が大きく、以前より時間が長引いたり体力がかかって、プランニングへの集中力や質がイマイチになってきたなという状況でした。
そんななかふりかえりのTryとして、集中力高く取組むためにポモドーロテクニックでやってみることにしました。
やり方
- プランニングで取組むべきタスクのリストをホワイトボードに書く
- 25分のタイマーを設定する
- プランニングする
- 5分休憩
- 繰り返す（4セット以上やる場合は4セット目で15分休憩する）
感想とポイント
- 今までダラダラやっていたなあ、、と実感、気分変えたりするのにもオススメ
- 45分サイクルとかもあるけど25分サイクルがちょうど良さそうな感じ
- タイマーがなったらキッチリやめる
- タイマーはキッチンタイマーがいいねえ
おわりに
タイマーはRSGT2023でもらったアカツキさんのやつを使いました〜
チームをもっと良くしたいと思った今だからこそ、DX Criteriaをやる
はじめに
極端に問題が見えるチームより、「そこそこ」上手く回っているチームの方が変化が少なく、 改善のレバレッジポイントが見え辛くなっているケースがあるかと思います。
チームをもっと良くしたいと思い、ブログ等で見つけたプラクティスを色々試してみるのですが、 小手先でやっている感じがあり、多面的に見れてない感じがする今日この頃。
そんななか、アセスメントツールとして DX Criteriaを提案してもらい、早速効果がありそうなのでまとめることにしました。
DX Criteriaとは
知っている方は読み飛ばしていただいて良いですが、HPに下記のように定義されています。
DX Criteria( DX基準 )は、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインです。
策定されたのは数年前で、当時良さそうだな〜くらいに眺めていてそのままだったのですが、 改めてチェックリストを見ると、チームからシステム、デザイン思考の観点等、幅広くチェックできるではありませんか！
具体的にどんなことが書かれているか
例えばチームの観点では
ある特定の人物に属人化した仕事を洗い出し、減らしていく仕組みがチームにあるか。
アイデアレベルの要望や構想から、要件に落ちるまでのリードタイムは計測されているか。
ふりかえりのテーマごとに数字を集めたり計測するなどして、ファクトベースで議論できるようにしているか。
システムの観点では
コードレビューガイドラインは１年以上メンテナンスされておらず、形骸化している。
一部の人だけがテストを書き、一部の人はテストを書かないといったように自動テストを個々人の努力目標などになっている。
デザイン思考の観点では
B2Bなど顧客における関係者が複数人いる場合、購買プロセスの各担当者など、意思決定に関わる人物の数だけ必要なペルソナを作っているか。
幹部人材に対して、プロダクトマネジメントのスキルについての継続的な学習機会を提供できているか。
プロダクトマネージャがソフトウェアプロダクト開発やデザインに関する知見や関心が薄く、チームの関係性が悪化している。
DXって言いながらプロダクト開発で取り組むべきもののチェックリストとしても活用できそうな感じですね。
組織をより良くしたいという人が俯瞰的に見るために使いたい
こうやって見ると、結構具体的にアレができてないから開発効率下がってるんじゃないか？とか多面的にみることができます。
上記では紹介しなかったですが、コーポレートの観点だと、チームだけでなく組織に対してどういう施策を打っていけば良さそうか、 スクラムマスターのレベル3的な活動の手助けをしてくれるかもしれません。
先人の知恵を借りつつ、組織を機敏により良くアップデートしていけたらなと思います。
社内スクラムガイド輪読会 第1回（イントロダクション、スクラムの定義〜スクラムの理論まで）
はじめに
スクラムガイド、抽象と具体のバランスが絶妙で読み直すたびに毎回違う発見がありますよね。
社内のアジャイルコミュニティでは、年1回くらいのペースでスクラムガイドの輪読会をしており、今回も継続して良い学びができそうなので、忘れないうちにまとめメモとしてまとめます。
注意ですが、潤沢に時間を取っているわけじゃないので、結論という結論がないことや、ただのリンクまとめになる可能性高なので読む方はご容赦ください。
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
輪読会全体について
グランドルールは下記の通りです。
- 重箱の隅を突くこと
- 良さそうな記事があればリンクをシェアすること
- 些細なことでも良いので発言すること（会話orチャット）
進め方については一般的な輪読会という感じで
- 読む場所を決める（1~2ページ分くらい）
- 各自黙読、気になる点をふせんに貼る
- ふせんをグルーピング
- 担当分けして各自テーマごとに調べる
- 調べた内容をシェアする
の流れで進めていきました。
第1回目の内容：スクラムの定義〜スクラムの理論
今回は上記の範囲を読み進めていきました。
気付いたことや疑問点
- 柱と言いながら透明性 -> 検査 -> 適応の順なんだ（柱以外の表現でも良いのでは？）
- スクラムが不要にするプロセスってなんだろう
- 1歩踏み出してやるってのが難しい、軽量級なの？
- 軽量級と言いつつライト級はそこそこ重い（うまい）
- 相対的な有効性とは？英文を直訳している感じではなさそう
各自調べたこと
リーン思考
- 単純にリーンをベースとした考え方でいいのか？本とかまさにの論文とか出てきた。
Amazon | Lean Thinking, 1st ed. | Womack, James P., Jones, Daniel T. | Management & Leadership
- あんまりリーンを深掘りできていないことに気付くのでもうちょっと記事とか論文を漁りたい
透明性について
- 定義：プロセスや作業を作業をする人と受け取る人の双方に見えるようにする
- 透明化すべきこと：プロダクトに関するビジョン、顧客の要件、作業進捗、困難、障害
- 透明性を持たせられるもの
- 自分たちがどこまで透明性を求めるのか考えても良さそう
- 様々な定義（Doneの定義とかも改めて）も透明化してみる
集合知について
- SECIモデルのはなし
- 現象学で言う相互主観
- 我々の主観をつくる
さいごに
できたら記事を読みつつ追記しよ、、何か気になる点があればコメントいただけますと幸いです。
ワーク・ルールズ！を読んで面接のやり方を工夫するメモ
はじめに
業務の隙間で人事関係の業務を細々やっていたりするのですが、手が回っていなかったり、そもそも今の現場にフィットする人を見つけられる手法が取れているのか？と疑問に思ったので改善を進めようと思いました。
今回はワーク・ルールズ！の主に第5章を読んでぼやっとやってみようかなということをまとめていきます。
面接における確証バイアス
面接でよくあるアンコンシャス・バイアスの1つとして、確証バイアスがあります。
これは面接や面談をしてきた人ならイメージ湧くと思いますが、第一印象や最初に感じたイメージの答え合わせをするような質問をして、矛盾することは無視してしまうといった内容です。
本書では『直感を信じてはいけない』と書かれていましたが、確証バイアスによる問題点だけでなく、面接官が固定されてしまえば特定の人に負荷が集中したり、採用もスケールしなくなるので、読み進めるなかでも構造化面接を取り入れてみようというモチベーションになりました。
活躍している人の人物像を考える
本題に入る前に、今の現場で活躍している人のスキル（や一緒に働きたい人）を考えてみます。
学習意欲の高さ、新しいことに積極的な姿勢、様々なステークホルダーを巻き込んで物事を前に進めるリーダーシップあたりがパッと思いつきましたので、もう少し言語化したうえで、それを確認するための質問を考えるのが良さそう。
Googleでは4つの要件について定義しているようです。
構造化面接について知る
Googleでは行動面接と状況面接の組み合わせで構造化面接を作っています。
フレームワークとしては、STAR面接というものがあり、状況、課題、行動、成果を順に掘り下げていきます。
行動面接では、過去の行動をSTAR面接を使って掘り下げていき、状況面接では、架空の状況ときにどういった行動を取るのか質問していくイメージ。
https://media.bizreach.biz/7697/(構造化面接とは？ Googleも採用している採用ミスマッチを防ぐ3つの重要ポイント | BizReach withHR]
公平に判断するための評価尺度
評価するための尺度が必要ですが、各面接官が求めるレベルの高さがバラバラだと意味がありません。
例えば、とても良いからとても悪いの5段階で評価するグラフィックレーティング尺度といったものがありますが、これだと暗黙的すぎて基準を揃えるのが大変そうです。
目線の合わせやすさ的にも、行動基準評定尺度（BARS）が良さそう。
さいごに
まずは人材の要件をもう少し明確化するところからですが、今回学んだことを活かして採用活動頑張りたいと思います。
システム思考の研修（基礎編）を受けたのでメモ
はじめに
アジャイル的な文脈の勉強をしているとシステム思考というワードをよく見かけており、ちょろっと本読んだり、前々から興味がありました。
最近開発チームの人数も増えてきて、結構複雑な問題を扱うケースが増えてきたので、役立ちそう！というモチベーションで受講したという経緯。
システム思考とは
システム思考は、複雑な状況下で変化にもっとも影響を与える構造を見極め、さまざまな要因のつながりと相互作用を理解することで、真の変化を創り出すためのアプローチです。
オレオレ三行くらいでまとめると、相互作用のある要素や構造をシステムとして捉え、ループ図といったツールを駆使しながら、大局的な視点でものごとを見たり、思考するアプローチです。
細かい話はワークショップベースでかなり理解しやすいように研修で説明していただけるので、 チェンジエージェントさんのサイトへGO！という感じですが、忘れないうちに気付きをまとめておこうと思います。
大局的に見たときに巻き込むべき人を巻き込めているのかということ
仮に作れば作るだけ車が売れる世界線があったときに、一応各企業環境を気にして生産していたところ、そのうち1社が無尽蔵に車を作り続けて環境汚染が進みました。
結果的に外に出れない世界になり、誰も車を買わなくなってしまっては、そもそも事業の継続ができなくなってしまいます。（まあ普通は規制とか業界から圧力とかあるでしょうけど）
1人が生み出している構造によって全体が破壊される懸念もあるということを念頭に、問題解決にあたって巻き込まないといけない人は誰なのか、その人に働きかけができているのか、改めて考えるきっかけになりました。
手段色が強い
システム思考では、全体を見渡したときのパターンを捉える「時系列変化パターングラフ」や構造を捉える「ループ図」など、問題の解決策を考えるうえでのツールを提供してくれます。
しかし、問題を解決する銀の弾丸ではないので、問題を引き起こしている要素がそもそも何なのかを考える力が必要であり、フレームワークを用いた思考法や「これだ」というポイントを見つけるための知識は広範に必要だと感じました。
ただ、使えば視覚としてイメージできた状態から考えられるので、「これ何から手付ければいいんだ...」というところからは一歩進んだ状態で始められると思います。
さいごに
業務都合で基礎編しか受けることができなかったのですが、自分でループ図描いてみてそのうち実践編にもチャレンジしたいなと思いました。
あくまでも基礎編ベースの知識なので、何か気になることがあればコメントいただけると幸いです。
モチベーション理論の系譜についてざっとまとめ
はじめに
下記記事で人的資源管理論について触れたので、流れでモチベーション理論についてまとめていきたいと思います。
人的資源管理論の捉え方
以前の記事でも触れましたが、人的資源管理論は個人を分析しており、そのことからモチベーション理論の範疇と言われています。
モチベーション理論は「動機づけの要因」そのものを研究する実体理論、モチベーションが生まれる心理的メカニズムやプロセスを研究するプロセス理論に分かれます。 （人的資源管理論は前者の実体理論の範疇）
それぞれの有名な研究を見ていくことにします。
実体理論
マレーの欲求理論
人間は欲求を持っており、それを満たそうとするプロセスとして説明する理論です。 マレーは人間の欲をリスト化した、欲求リストをまとめました。
マクリーランド（マクレランド）の欲求理論
従業員には、達成・権力・親和の3つの動機ないし欲求が存在するという理論を発表しました。
さいごに
眠くなってきたので明日以降に追記します、、
