2026-04-09

ChatGPTでのアウトプット型学習

ChatGPTエンタープライズのスケジュール機能を使い、アジャイルQAの判断力を鍛える学習を試した。

単なるインプットではなく、「その場でどう動くか」を考え続ける点が特に有効だった。一方で、継続前提の学習設計ゆえの難しさも見えてきた。

想定読者と前提

アジャイル開発の現場に関わるQAエンジニア
「知識はあるが、現場判断に自信がない」と感じている人
ChatGPTエンタープライズ（スケジュール機能が使える環境）を利用可能な人

なぜこの学習をやろうと思ったか

アジャイルQAを目指す中で、

「テスト技法や考え方は知っているが、実際の現場でどう動くかを問われると迷う」

という課題を感じていた。

座学や記事のインプットだけでは、

優先度の判断
ステークホルダーとのやりとり
限られた時間での品質判断

といった部分がなかなか鍛えにくい。そこで、疑似的に現場を再現し続ける仕組みとして、ChatGPTエンタープライズのスケジュール機能を使った学習を試してみた。

結論

「どう動くか」を言語化し続ける学習として、とても相性が良い
スケジュールによる強制力が、忙しい中でも思考を止めさせない
ただし、継続前提の設計なので、間を空けるとつらくなる

やったこと（学習の仕組み）

基本の流れ ChatGPTエンタープライズに以下を依頼した。

アジャイル開発の現場で起こりうるQA視点の場面を提示する
ある程度の前提条件（チーム状況、制約、背景）も含める
私が「その場面でどう動くか」を回答する
回答内容をレビューし、次の課題につなげる

この一連をスケジュール機能で週1回実行するように設定した。

お題のイメージ（例）

スプリント終盤で仕様変更が入った開発者は「今回はテストを簡略化したい」と言っているリリース日は動かせない → QAとしてどう判断し、どう動くか？

良かったこと

インプットだけで終わらない知識を読むだけでなく、「自分ならどう動くか」を毎回考え、言語化する必要がある。これはレビューやトリアージ、相談対応など、実務にかなり近い思考訓練になった。

スケジュールによる強制力 {tip} 週1回リマインドされることで、「忙しいから今週はいいや」を防げる。強制的にQA視点で考える時間が確保されるのは、想像以上に大きかった。

難易度が徐々に上がるこちらの回答に応じて次のお題が出るため、

最初は単純な判断
徐々に前提が複雑になる

という流れが自然に作られた。お題をリセットすれば、別の文脈（別チーム・別課題）にも対応できそうだと感じている ※これはまだ試してはいない。

難しかったこと・ハマりどころ

お題自体の難しさに加え、間を空けると「前提」を忘れてしまう。

週1回とはいえ、

忙しくて1回飛ばす
前回の判断理由を忘れる

と、「この状況ってどういう前提だっけ？」となりがちだった。これはAIの問題というより、継続前提のケーススタディ学習そのものの難しさだと感じている。

実務で使うならの工夫

毎回、前提条件と自分の判断理由を簡単にメモに残す
正解を求めすぎず、「判断軸」を意識する
チーム内で同じお題を使って議論しても面白そう

まとめ

ChatGPTエンタープライズのスケジュール機能は、アジャイルQAに必要な「考え続ける力」を鍛える仕組みとして有効だった。

万能ではないが、

判断に迷うQA
実務に近い形で練習したい人

には一度試す価値があると思う。

2025-12-16

「システムを破壊するよりも、最高のシステムを構築する」をもう一度考える

注意事項：

この記事は自分の備忘録として記載しています。また生成AIを使って作成しています。
私が研修で学習したことをベースに書かせていますので、生成AIを単純に使った以上に私の理解力による問題がある可能性があります

はじめに

アジャイルテストマニフェストを扱った研修の2日目、アイスブレイクとして

「5つの価値のうち、最も大事にしたいものはどれか」

をチームで選ぶワークを行いました。

そのとき、 「システムを破壊するよりも、最高のシステムを構築する」 という価値は、ほとんど選ばれませんでした。

理由として挙がったのは、

自分たちはテスト専門でずっと仕事をしてきたので、システムを「構築する」イメージが湧きにくい

といった意見でした。

ただ、私はこの発言を聞いて、 「この言葉の本質は、本当にシステムを“作る・作らない”の話なのだろうか？」 という疑問が残りました。

この記事は、その違和感を出発点に、アジャイルテストマニフェストのこの一文を、改めて考え直してみた記録です。

「システムを破壊する」とは何を指しているのか

まず、左側の価値である

システムを破壊する

について考えてみます。

これは一般的に、

バグを見つけることそのものが目的になる
仕様の穴や想定外を突くことに価値を置く
欠陥を指摘することが成果として評価される

といった、テスト行為そのものに重心が置かれた状態を指していると解釈できます。

これは決して悪いことではありません。特に、

品質を担保する最後の砦としてのテスト
独立した視点での厳しい検証

が求められる場面では、非常に重要な役割です。

アジャイルテストマニフェストも、「破壊することは間違いだ」と言っているわけではありません。

あくまで、

それ“だけ”に価値を置いていないか？

という問いを投げかけているのだと思います。

「最高のシステムを構築する」の本質

では、

最高のシステムを構築する

とは、何を意味しているのでしょうか。

ここで重要なのは、 「コードを書くこと」「設計すること」だけを指しているわけではない という点です。

アジャイルテストの文脈で語られる「構築」とは、

ユーザーにとって価値のある状態を作り続けること
チームが安心して変更できる状態を育てること
問題が起きにくい構造や判断を支えること

といった、プロダクトの“状態”を良くしていく行為全体を指していると考えられます。

つまり、

バグを見つけること
壊れにくい考え方を広めること
リスクに早く気づけるようにすること

も、すべて「構築」に含まれます。

テスト専門の立場でも「構築」に関われる

「自分たちは作らない側だから、構築には関われない」

この感覚は、多くのテスト専門職が一度は感じるものだと思います。

しかし実際には、テストの立場だからこそできる “構築への貢献”は少なくありません。

例えば、

仕様が曖昧なまま進みそうなときに立ち止まらせる
ユーザー視点での違和感を言語化する
バグの背景にある判断や前提をフィードバックする
「次に同じ問題を起こさないためには？」を一緒に考える

これらはすべて、 システムをより良い状態に導くための働きかけです。

欠陥を報告して終わるのではなく、

なぜ起きたのか
どうすれば防げたのか
次はどこに注意すべきか

まで踏み込むことで、チームは学習し、プロダクトは強くなっていきます。

これはまさに、「壊す」ことを通じて「構築」に関わっている状態だと言えます。

なぜこの価値は選ばれにくかったのか

今回のワークでこの価値が選ばれなかった背景には、

「構築＝開発者の仕事」という固定観念
自分たちの役割を狭く定義しすぎていたこと
これまで評価されてきた成果の文脈

があったように思います。

特に第三者的な立場で長く仕事をしてきた場合、

指摘すること
見つけること
防波堤になること

が役割として強調されがちです。

その結果、 「一緒に良くしていく」という視点が言葉として結びつきにくくなっていた のかもしれません。

おわりに

アジャイルテストマニフェストの

システムを破壊するよりも、最高のシステムを構築する

という言葉は、

テスターが開発者になるべき
テストは優しくあるべき

といった意味ではありません。

むしろ、

見つけた問題をどう未来につなげるか
チームやプロダクトをどんな状態に導きたいのか

を問い続ける姿勢そのものを指しているのだと思います。

テスト専門の立場であっても、私たちは

最高のシステムを構築する一員である

と言えるはずです。

この価値が、「自分たちには関係ないもの」ではなく、 自分たちなりの言葉で語り直せる価値として受け取られるようになると、アジャイルテストマニフェストは、より実感を伴ったものになるのではないでしょうか。

2025-12-16

UIが頻繁に変わる初期フェーズとテスト自動化の現実

注意事項：

この記事は自分の備忘録として記載しています。また生成AIを使って作成しています。
私が研修で学習したことをベースに書かせていますので、生成AIを単純に使った以上に私の理解力による問題がある可能性があります

はじめに

アジャイル開発や新規サービス開発の初期段階では、UI（画面）が頻繁に変わることは珍しくありません。にもかかわらず、

「最初からE2Eテストを自動化すべき」
「UIテストが一番ユーザーに近いから価値が高い」

といった意見を目にすることがあります。

本記事では、研修で学んだ内容と広く知られている実践知（テストピラミッド、CI/CD、アジャイルテストの原則）を根拠に、

なぜUIが頻繁に変わる初期フェーズとUI自動化は相性が悪いのか
では、どこから自動化を始めるべきか
最終的にどのような状態を目指すのが現実的か

を整理します。

※特定のツールやプロダクトには依存しない、一般論としての内容です。

なぜUIが頻繁に変わる初期フェーズとUI自動化は相性が悪いのか

UI（E2E）テストの特性は、以前から整理されている

UIテスト（E2Eテスト）の特性は、近年突然言われ始めたものではありません。テストピラミッドやアジャイルテスティングの文脈では、長年次のように整理されています。

ユーザー体験に最も近い
その一方で
- 作成コストが高い
- 実行時間が長い
- 失敗時の原因特定が難しい
- 変更に弱く、メンテナンスコストが高い

研修でも、UIテストは「テストの忠実度は高いが、コストも最も高い層」として説明されていました。

初期フェーズのUIは「変わること」が前提

新規サービスや立ち上げ期のプロダクトでは、UIは次の理由で頻繁に変わります。

仮説検証（UX改善）の繰り返し
ステークホルダーからのフィードバック反映
仕様の未確定・方向転換

これは設計が甘いからではなく、価値探索を行っている健全な状態です。

この状態でUIテストを大量に自動化すると、

UI変更のたびにテスト修正が発生する
テスト修正が開発のボトルネックになる
「テストが邪魔」という認識が生まれる

という状況に陥りやすくなります。

これは多くの現場で報告されている、典型的なアンチパターンです。

では、どこから自動化するのが現実的か

① UIの裏側にある「変わりにくいもの」から始める

研修や一般的な実践で一貫して推奨されているのは、

UIではなく、UIの裏にある安定した責務から自動化する

という考え方です。

具体例：

ビジネスルール
計算ロジック
条件分岐
ステータス遷移
権限制御

これらは、画面レイアウトや文言が変わっても、比較的変更頻度が低い領域です。

事実として、

単体テスト・サービス層テストは
- 実行が速い
- 壊れにくい
- CIに組み込みやすい

という特徴があり、テストピラミッドの下層に位置付けられています。

② API・コンポーネント間の結合点

次の段階として現実的なのが、APIレベルの自動化です。

フロントエンドとバックエンドの契約（リクエスト／レスポンス）
外部API連携（モック・スタブを含む）

ここを自動化すると、

UIを手動で触りながらも
「裏側は壊れていない」ことを機械的に保証できる

状態を作れます。

これはCI/CDの文脈でも、早期フィードバックを得るための実績あるアプローチです。

③ UI自動化は「最小限」にとどめる

初期〜成長フェーズでUI自動化を行う場合も、

主要ユーザージャーニーのみ
数は極力少なく
「壊れたら致命的」なシナリオに限定

という制約付きで行うのが、現場実績として現実的です。

研修でも、

E2Eテストは魅力的だが、万能ではない

と明確に説明されていました。

最終的に目指すべき状態とは

ゴールは「UIを全部自動化すること」ではない

アジャイルテスティングの文脈での最終ゴールは、

テストケース数
UI自動化率

ではありません。

研修では、次の状態が目指す姿として示されていました。

変更するたびに
自動で品質の最低ラインが確認でき
チームが安心して変更できる

つまり、

「完成しているかどうか」を早く・頻繁に知れる状態

です。

UI変更は、人が価値を評価する

UIは、

使いやすさ
分かりやすさ
期待とのズレ

といった、人の感覚が重要な領域です。

そのため中長期的には、

UIの変化 → 探索的テスト・レビューで評価
壊れてはいけない約束事 → 自動テストで担保

という役割分担に落ち着くケースが多いことが、実践として知られています。

まとめ

UIが頻繁に変わる初期フェーズと、UI自動化は構造的に相性が悪い
これは個人の感想ではなく、
- テストピラミッド
- アジャイルテスティング
- CI/CD で長年整理されてきた事実
初期は
- ロジック
- API から自動化を始めるのが現実的
最終ゴールは
- UI自動化率ではなく
- 「安心して変更できる状態」を作ること

UI自動化は、やらない判断も含めて戦略です。初期フェーズほど、「何を自動化しないか」を意識することが重要だと、研修を通じて強く感じました。

2025-12-15

アジャイルテストマニフェストを、開発チームの外側から読み解く

注意事項：

この記事は自分の備忘録として記載しています。また生成AIを使って作成しています。
私が研修で学習したことをベースに書かせていますので、生成AIを単純に使った以上に私の理解力による問題がある可能性があります

はじめに

これからアジャイル開発に関わる人のために

近年、アジャイル開発を採用する組織やチームは増え続けています。それに伴い、これまで開発プロセスの後半で関わることが多かった立場の人にも、

スプリントの途中でレビューしてほしい
仕様が固まりきっていない段階で意見がほしい
リリース前だけでなく、継続的に品質を一緒に考えてほしい

といった依頼が届く場面が増えています。

これは、アジャイル開発では 「品質は最後にまとめて確認するものではない」 という前提が置かれているためです。

一方で、従来の

要件を固めてから
開発し
最後にテスト・確認する

というウォーターフォール型の経験が長い場合、

何をどこまで関わればよいのか分からない
自分の責任範囲が曖昧に感じる
開発チームとの認識が噛み合わない

といった戸惑いが生じやすくなります。

そこで本記事では、 アジャイル開発におけるテストと品質の考え方を整理するための共通の軸として「アジャイルテストマニフェスト」を取り上げます。

ここでの目的は、

すぐにやり方を変えること
これまでのテストや品質活動を否定すること

ではありません。

アジャイルな文脈で声をかけられたときに、どう考え、どう判断するかの拠り所を持つことです。

アジャイルテストマニフェストとは何か

アジャイルテストマニフェストは、 2001年に公開された「アジャイルソフトウェア開発宣言（アジャイルマニフェスト）」の考え方を、 テストと品質の文脈に落とし込んだ価値観の整理です。

アジャイルマニフェストが「ソフトウェア開発全体の価値観」を示したのに対し、アジャイルテストマニフェストは、

テストとは何か
品質は誰の責任か
いつ、何のためにテストするのか

といった問いに対する判断の指針を示しています。

重要なのは、アジャイルテストマニフェストが

新しいテスト手法を定義するものではない
特定のプロセスや成果物を強制するものではない
従来型のテストを否定するものではない

という点です。

マニフェストが示しているのは、

左側の考え方にも価値があることを認めたうえで、状況に応じて右側をより重視する

という価値判断の優先順位です。

これは、正解が一つに定まらないアジャイル開発の現場で、「何を基準に考えるか」を揃えるための共通言語として機能します。

コラム：よくある誤解①

「アジャイルではテスト計画書やテストケースは不要になる」

実際には「不要」になるわけではありません。 目的に対して最適な形に変わるだけです。

重要なのは文書の有無ではなく、

チームが何を品質基準としているか
どこまでできていれば安心して次に進めるのか

が共有されていることです。

コラム：よくある誤解②

「アジャイルではテスターや品質担当者は不要になる」

これも事実ではありません。

アジャイル開発ではむしろ、

品質観点やリスクを言語化する
チーム外の視点を持ち込む
判断の軸を整理し、議論を助ける

といった役割の重要性が高まります。

これらの誤解は、 「やり方（How）」だけを見て、「なぜそう考えるのか（Why）」を共有できていないことから生まれやすいものです。

アジャイルテストマニフェストが示す5つの価値（要点）

アジャイルテストマニフェストでは、次の5つの価値の対比が示されています。

従来よく重視されてきた考え方	アジャイルでより重視する考え方
バグの発見	バグの防止
最後にテストする	ずっとテストし続ける
機能をチェックする	チームが理解している価値をテストする
テスターの責任	テストに対するチームの責任
システムを壊す	最高のシステムを構築する

ここで大切なのは、 左が間違いで、右が正しいという意味ではないという点です。

ウォーターフォール型の開発では、左側の考え方が合理的で、多くの成果を上げてきました。

一方で、

変化が前提
早く学び、早く修正したい
小さく作って価値を確かめたい

といったアジャイル開発の前提条件では、右側の価値を意識したほうが、結果として品質とスピードの両立につながりやすくなります。

開発チームの外側にいる人にとっての使いどころ

アジャイルテストマニフェストは、 そのまま現場に適用するルール集ではありません。

特に、開発チームの中に常駐していない立場の人にとっては、

判断に迷ったときの思考フレーム
開発チームとの会話を整理するための共通言語

として使うのが現実的です。

例えば、

今回の依頼は「発見」を求められているのか、「防止」を求められているのか
「最終確認」なのか、「途中での気づき」が欲しいのか
自分に期待されているのは実行なのか、視点なのか、助言なのか

こうした点を整理する際に、 5つの価値が状況を翻訳するための軸になります。

おわりに

アジャイルテストマニフェストは、

何をやるべきかの正解集

ではなく、

どう考えるかを揃えるための道具

です。

すべてを理解してから動く必要はありません。まずは、

この場面では、5つの価値のうちどれを少し意識すると会話が前に進みそうか

を考えるところからで十分です。

アジャイル開発に関わる立場や距離に関わらず、 品質について建設的に関わるための共通言語として、このマニフェストを活用してもらえればと思います。

2025-12-15

ペアテストは本当にコスパが良いのか？

〜アジャイル初心者QA向け・正直な話〜

注意事項：

この記事は自分の備忘録として記載しています。また生成AIを使って作成しています。
私が研修で学習したことをベースに書かせていますので、生成AIを単純に使った以上に私の理解力による問題がある可能性があります

アジャイル開発の文脈で、

「ペアテストは効果的だ」
「2人でやるから品質が上がる」

といった話を聞いたことがある方は多いと思います。

一方で、品質保証部の立場から見ると、こう思うのも自然です。

人が2人必要＝工数が倍では？
忙しいスプリントで本当にやる余裕があるの？
いつものテストを2人でやる意味ある？

この記事では、ペアテストは本当に費用対効果があるのかを、 Webアプリケーションの文脈で、良い点も悪い点も含めて整理します。

そもそもペアテストとは？

ペアテストとは、2人で1台のPCを使ってテストするプラクティスです。

ドライバー：実際に操作する人
ナビゲーター：観察し、考え、次のテストを提案する人

役割は固定ではなく、随時入れ替わります。

重要なのは、

「2人で同じ画面を見ること」

ではなく、

考える役割と操作する役割を分け、対話しながらテストすること

です。

まず正直な話：ペアテストは常にコスパが良いわけではない

最初に結論を言っておきます。

ペアテストは万能ではありません。 使いどころを間違えると、コストが高いだけのテストになります。

よくある失敗パターン

① 単純な回帰確認をペアでやる

既存のテストケースをなぞるだけ
想定通り動くかを確認するだけ
新しい観点や仮説が生まれない

この場合、

人は2倍
得られる価値はほぼ同じ

になります。

② 役割が対等でないペア

開発者が常に操作
テスターは横で見ているだけ
「それ違うのでは？」が言いにくい

これも「一緒に座っているだけ」で、ペアテストの学習効果・発見効果はほぼ出ません。

では、いつペアテストは効果的なのか？

答えはシンプルです。

不確実性が高いとき

です。

効果が出やすい場面（Webアプリの例）

① 新機能・UI変更が入った直後

仕様はあるが、使われ方が読みにくい
ユーザー行動のパターンが多い

このような場面では、 1人では気づきにくい「違和感」や「迷いポイント」を、短時間で多く発見できます。

ドライバーが操作に集中
ナビゲーターがユーザー視点で問い続ける

この形がうまく回ると、30分でも十分な成果が出ます。

② 開発途中での開発者×テスターのペア

実は、完成前の方がペアテストは効果的です。

テスターが境界値・業務例外を口に出す
開発者がその場で修正する
バグチケットを書かずに問題が消える

結果として、

バグ管理コスト
手戻りコスト
認識ズレの調整コスト

がまとめて減ります。

短期と中長期で見る、ペアテストのコスパ

短期（1スプリント内）

作業量は大きく増えない
重要な欠陥や違和感を早く見つけやすい
単純な効率は上がらない

👉 「速くやる」ための手法ではない

中長期（数ヶ月）

ドメイン知識が共有される
テスト観点がチームに広がる
仕様の誤解が減る
QAが後工程になりにくくなる

👉 「後で困らない」ための投資

QA部門としての現実的な付き合い方

ペアテストは、

常時やるものではない
すべてのテストを置き換えるものでもない

QA部門としては、次のように考えるのが現実的です。

✔ 不確実性が高い機能だけに使う
✔ 時間を決めて短くやる（15〜30分）
✔ 探索・学習が目的だと明言する
❌ 回帰確認の代替にしない

まとめ

ペアテストは、

❌ 人を2倍使うテスト手法

ではなく、

⭕ 不確実性を早く減らすための手法

です。

アジャイル開発では、「あとでまとめて品質を作る」ことが難しくなります。

だからこそ、 品質保証部が早い段階で関わり、考えを共有する手段として、ペアテストは有効です。

まずは、

新機能1つ・30分だけ

から試すのが、一番失敗しにくい始め方です。

章末付録：最初の30分ペアテスト手順

ここでは、アジャイル初心者のQAメンバーでも迷わず進められるように、 30分ペアテストを「時系列の手順」として整理します。

ポイントは、

何をするか
特にナビゲーターは何を考え、どう振る舞うか

を明確にすることです。

手順1：テーマとゴールを決める（開始〜5分）

最初にやることは、テスト対象を減らすことです。

テスト対象を1つに絞る
- 画面1枚
- 新機能1つ
- ユーザーストーリー1本
今日のゴールを言葉にする
- 「初回ユーザーが迷いそうな点を見つける」
- 「業務ルールの抜け・勘違いを洗い出す」

ここでの注意点：

ゴールが言語化できない場合は、まだペアテストを始める準備ができていません
ゴールが曖昧なまま進めると、操作確認で終わります

手順2：役割を決めて宣言する（5分時点）

次に、役割をはっきりさせます。

ドライバー：操作に集中する人
ナビゲーター：考える・観察する・問いを投げる人

このとき、

「途中で役割を交代する」
「ナビゲーターは遠慮せず口に出す」

ことを先に合意しておきます。

手順3：操作を始める（5〜20分）

ここからが本番です。

ナビゲーターが最初に意識すること

操作が始まったら、ナビゲーターは次の問いを常に頭に置きます。

今、誰の視点で操作しているか？
その人は、この画面を見て次に何をすればよいと理解するか？

ナビゲーターの具体的な振る舞い

見たままを口に出す
- 「ここ、ちょっと情報が多く感じます」
- 「次の操作が一瞬止まりそうです」
仮説で話す
- 「初回ユーザーだと、ここ押していいか迷いそうです」
- 「業務を知らない人だと、この用語は分からないかも」
操作を急がせない
- 正解ルートを早く進ませない
- 迷い・違和感が出るまで待つ
仕様の正しさで会話を止めない
- 「仕様通り」かどうかは後回し
- まずは体験としてどう感じるかを言語化する

ドライバー側の意識

操作しながら考えを説明する
ナビゲーターの問いを遮らない
「仕様だからOK」で終わらせない

手順4：役割を交代する（必要に応じて）

15分程度経ったら、役割を交代します。

交代することで視点がリセットされる
ナビゲーターの難しさを双方が体感できる

※ 時間が足りない場合は無理に交代しなくても構いません。

手順5：振り返りをする（20〜30分）

最後の10分で、簡単に振り返ります。

今日わかったことを共有する
- バグ
- 違和感
- 改善できそうな点
次に試すとしたら何を見るかを決める
- 次回のペアテストのテーマにする

ここでのポイント：

きれいにまとめようとしない
記録より「理解が揃ったか」を重視する

この手順がうまくいっているサイン

会話が止まらない
ナビゲーターが沈黙していない
「仕様ではこうだけど…」という前置きが自然に出てくる

逆に、

2人とも黙って画面を見ている
操作確認だけで終わっている

場合は、手順1（ゴール設定）からやり直すのが一番の近道です。

2019-12-11

分かりやすく伝えるってなんだ？(小ネタ)

経緯
わかりにくい文章 3か条

経緯

ちょうど先日、仲間内で「あいつ何言ってるかわからん」という話題が上がったため、説明が分かりにくくなる原因を考えました。
今日はそこからさらに発展させて読みやすい文章について考えてみました。

※注意：本記事は私がお客様先に常駐して QAエンジニアをしている都合でその視点での記事になっています

わかりにくい文章 3か条

なぜ相手に言いたいことが伝わらないのか。
と考えたときに、以下の 3つに区分してみました。

伝える相手が何を知りたいのかわからない、知らない
純粋な語彙力(知識)不足・日本語力(文章構成力やら文法、敬語やら)不足
そもそも実は伝えようと思ってなくて、実は単なるつぶやき

おまけで、思考すっ飛び型(本人の中では連想ゲーム的につながっているけど、それが全く言葉になってないので前後のつながりが破綻する)というのもあるかなという話も。

2，3つ目に関しては、頑張れ！としか言えないし、おそらく本人は自覚がないと思います。
2つ目はもし業務で必要な人材なのであれば、周りの人間がちょっと細かいかなっていうレベルで指摘してあげる必要があります。
正直自覚がないと、違和感にも気づかないので一生成長はしないです。
いつか気づいてくれるは幻想です。

どうしたら伝わりやすい文章になるんだろう？

ちょっとかんがえてみました。

目的や読み手を明確にする
全体の構成や流れを考える
語彙力や日本語力を磨き、違和感に気付く

例えばこんな感じでしょうか。

目的や情報の受取手を明確にする

テストの各工程において、何らかの情報を伝えることはどの立場であってもついて回りますよね。

対自社のマネージャー
対メンバー
対お客様のマネージャー
対開発者
etc...

相手に何を求めているのか、相手は何を知りたいのか。
そこを意識できているでしょうか。

また、あえて立場に限った話をしましたが、同じマネージャーでも気にするポイントは違うと思います。

相手が気にするポイントを把握しようとしていますか？

例えばメール一つとっても、誤字脱字が気になって気になってしまう人と、とにかく1秒でも早く情報が欲しい人など、様々です。

... まあ、誤字脱字は無いに越したことはないのですが、それを置いてもすぐ情報が欲しい人、というのもいると思います。そういう場合、推敲に1時間もかけて情報を渡すのではナンセンスです。

受け手の意識や心情に配慮できるとよいですね

全体の構成や流れを考える

最近よく現場で「報告書を読み上げるんじゃなくて、何を伝えたいのか考えて話すように」と言われます。

自分が一番伝えたいことは何か、相手が一番知りたいことは何かを考えて予め構成を考えておきましょう。

報告内容によっても構成を変える必要があります。

時系列順
結論から経緯
etc..

例えばセキュリティインシデントの場合は、とにかく時系列順に伝える必要がありますし、時間のないマネージャー向けの説明の場合は結論から話すなどの工夫が必要です。

語彙力や日本語力を磨き、違和感に気付く

本を読め！話はそれからだ。

…だとあまりにもひどいので、長くなり過ぎない程度にポイントを。

読むほうは慣れるまでテンパる可能性があるので、経験上、まずは書く文章から気を付けるようにしたほうがよいと思います。

読み返し方

時間をおく
印刷して読む
音読する
読み手の立場で読み返す

読み返すポイント

日本語が正しいか
誤字脱字はないか
文章全体の表記ゆれはないか
スペースの使い方は適切か
違和感のあるところはないか
やたらと読点、句点が多くはないか
接続詞は多くないか、間違ってないか
逆接の接続詞から入っていないか
必要ない言葉が含まれていないか

例

蒸気は私が現場で出荷判定会の場で報告するときに気を付けるポイントです。
上記は、私が、現場で、出荷判定会の場で、報告するときに、気を付けるポイントです。
上記は、私が現場で気を付けているポイントです。

まとめ

どうです？どの文章が一番読みやすかったですか？
あるいはどれも響かなかったですか？

情報の受け手を意識して、日本語力を磨いて、素敵なエンジニアライフを過ごしましょう！

2019-12-07

開発者と作るテスト観点(小ネタ)

開発者と作るテスト観点

2019年にとあるプロジェクトで行った取り組みについて、備忘録がわりにまとめます。
そのものずばり、テストのための観点出しを開発チームと一緒になって行うことで、観点の過不足を補ったりや合意を取って進めることができました、というお話。

経緯

今回の評価対象は非常に難易度の高いものでした。
理由はいくつかあって

新サービスであること (e.g. ノウハウがまとまってない)
テストチーム内に前任者がいないこと (e.g. すぐに頼れる人がいない)
環境が多岐に渡ること (e.g. 不具合の切り分けが難しい)
ドメイン知識そのものの難易度が高いこと (e.g. 理解そのものが難しい)
ボリュームが大きい
メンバーに類似サービスの知見がない

etc....

のような感じでした。

取り組み

従来の進め方は以下の通りです

[テストチーム内] テスト対象の分析を行う
[テストチーム内] テスト計画を立てる
[テストチーム内] テスト観点出しをする
[開発チームに向けて] 概要レベルの観点レビューを行う
- 基本的には 1回こちらが観点を読みあげて、その場でチェックしてもらう
[テストチーム内] テスト詳細設計をする
[テストチーム内] テスト実装をする
[テストチーム内] テスト実施をする

今回は、まずテスト対象の分析に時間がかかったこと、開発物が出てくるのと仕様の FIX が計画時点ですでにテスト実施が始まってからでないと難しそうな予感を漂わせていたこと、その他もろもろの理由で、従来の進め方ではテストの遂行が行えないだろうと思われました。
そのため、以下の工夫を行いました。

開発チーム、運用チーム、(必須ではないが) サポートチームを招いた「仕様理解MTG」を週次で実施
仕様ができた(もしくはできる)順番にテスト観点だしをテストチームで行い、私(類似サービスの経験あり)がレビューをする
- 観点をマインドマップの形にして、かなり細かいレベルで書く(必要に応じてテストデータ、パラメータも当てはめた)
レビューが済んだもののうち、不安が残るものは週次のMTGで対面で説明し、不明点を埋める
それ以外のものについては開発チーム側の見える場所に集約し、非対面で指摘をもらう

よかったこと

上記の取り組みを行うことで、開発チームの持つノウハウの吸収が行えました。
また、テスト観点漏れをかなり防げました。

悪かったこと

開発計画時点で考えていたことではなかったため、開発側の工数をだいぶ食ってしまった。
今回が初だったので、次回からは早い段階でこういう取り組みがしたい旨を共有しておく必要がある、と思った。悪かったとは言われませんでしたが、反省点の一つです。