はじめに
本記事は A Tester's Journey: A Time of Transition - Eight Months on a New Team を日本語訳したものです。
この記事は、著者のLisi Hockeが、新しいチームにJoinして8ヶ月間で起きたことを赤裸々に語っています。その中で、どのようにチームにフィードバックを促し、どのようにチームを変化させていったのかが詳細に語られており、大変良い記事だと感じたため、今回翻訳することにしました。
なお、元記事が長文なため、翻訳記事は計5回に分けてお届けします。
- Joinする前のチーム状況
- チームに入ってから8ヶ月間で起きたこと（本記事）
- 現在のチームの状況
- チームが変化できた要因
- 今後の展望とチームの変遷の記録
本記事は第2回です。
このチームに関する詳しい内容や、記事執筆後に起こった変化はJaSST Review'23にて講演予定です！（同時通訳付き）
興味を持たれた方は以下のページから参加申し込みをお願いします！
www.jasst.jp
目次
何が起こったのでしょうか？
この8か月間に本当にたくさんのことが起こりました。私たちの旅のハイライトをいくつかご紹介します。
チームを変えました
まず第一に、私が入社したチームは、今いるチームとはもはや同じではありません。元の従業員5名が退職し、契約社員2名がこの期間内に入社および退職し、新たに正規雇用者4名が加わりました。私が始めたときは大きすぎるチームでした。今では10名ですが、私の観点から見ると、チームの規模としてはまだギリギリまで大きい状態です。 コミュニケーション経路はすでに非常に複雑です。
親愛なるプロダクトマネージャーを見つけました
以前までは、複数の製品担当者が頻繁に交代していた状態に悩まされていました。今、私たちは本当に幸運なことに、透明性と知識の共有に尽力し、常にチームを巻き込んでくれる素晴らしいプロダクトマネージャーを見つけることができました。彼女は明確な優先順位を設定し、チームに集中力を与える人です。彼女は利害関係者に明確な期待を示し、役に立たない組織の問題からチームを守る人です。彼女は迅速に意思決定をし、即座に行動を起こし、それによって主導権を握る人です。これがどれほどの違いを生むかは、どれだけ強調しても言い過ぎにはなりません！
弊社のプロダクトマネージャーに感謝の意を表します。彼女は透明性と明瞭さを生み出すのが本当に素晴らしいのです。彼女は今日、チーム全体にわたる複雑なトピックについて次のように話しました。「私たちが考えていることや想定していることをすべて書き留めて、参考として見えるようにしましょう。たとえそれが間違っていたとしても、異議を唱えることができます。」 🌟
リリースの仕方を再発見しました
知識は失われ、リリースの方法という重要な知識さえ失われました。はい、これは痛いです。製品のコンプライアンスを考慮する必要があることを考えると、新しい製品バージョンを市場に投入するために何が必要かを把握するのに、これは少なからぬ必要な労力でした。再発見フェーズには時間がかかり、多くの変更が待ち構えていたため、大規模なリリースになりました。私たちは皆、これをもっと頻繁に実践し、リスクを減らして小規模なリリースをしたいと考えていました。次の各ステップで、より簡単に行う方法についてさらに学びました。そして、私たちはまだ学び続けています。そして今では透明性があり、チーム全体が参加してリリースを行うことができます。
チームキャンバスセッションを行いました
これは新しいプロダクト マネージャーによって始められたもので、当時チームが必要としていたものでした。 私たちにとって何が重要か、どこに成長したいか、プロダクトにどのような機会があると考えているか、個人の価値観などを共有する場所です。 チームを構築するための基盤です。 その結果、私たちはチームの価値観も明確にすることができました。 このようにして、私たちは生きていく上で、またチーム外の人たちやチームに参加する人たちにとっても大きな参考になります。
巨大なEpicがありました
今年の初めに、チームは今後のトピックについて知らされました。 それを聞いたとき、多くの期待の不一致（「2～3週間でこれを行います」なんてありえない）を観察しながら、これは膨大な労力を意味することになるとすぐにわかりました。 結局のところ、それは本当に大変な労力でした！ 現在最後の仕上げ段階ですが、これは非常に大きなことでした。 あまりにも巨大だったので、実現するために文字通り他のものをすべて捨てなければなりませんでした。 また、非常に明確に期待値を設定した我々のプロダクトマネージャーにも改めて敬意を表します。
たくさんの火を消しました
3月から6月はちょっと極端でした。 非常に緊急な議題がたくさんあり、それをすべて同時に行う必要があったため、大きなプレッシャーがかかりました。 その間に私たちはすでにその巨大なEpicに取り組んでいました。 一度に一つのことに取り組み、新しいプロダクトマネージャーが本当にステップアップしたおかげで、なんとか乗り切ることができたと思います。これはどれだけ強調しても足りません。彼女は最初の 1 か月で最悪の状況を経験しましたが、今も私たちと一緒にいます。ここでポジティブな点を考えてみます。今回の出来事は、明確な制約を設定し、期待を管理し、他のチームと状況を共有し、理解とサポートを得る機会となりました。チームを壊すか、チームを良くするかのどちらかになる瞬間だと私は本当に感じました。そして私たちは最終的に良い方に向かうことができ、チームは本当に団結を深めました。
初めてチームから離れました
最初の数カ月間、私はカンファレンスやその他の取り組みを意図的に断っていましたが、ある時点で行うことにしました。チームが自分たちでテストを引き継ぐ状態になっていました。彼らは完全なコンテキストを持っており、仕事を始めたときに私自身が陥っていた状況に外部の誰かが陥ることになるでしょう。一時的な価値はありません。そしてまた、私たちが取り組んできた文化の変化の多くを元に戻すことになるでしょう。
私が実行した取り組み
上記以外にも多くの構築中の場所があり、チームには改善の余地がありました。 最初の 1 か月間観察し、関係を構築し、知識を増やした後、私がチーム内で実行した取り組みを以下に示します。
オンボーディングとオフボーディングのガイドラインを作成しました
最初の 1 か月ですでにチームに共有知識が不足していることが明らかになり、厳しいスタートとなりました。とにかく情報を断片的に集めなければならなかったので、既存のオンボーディング ページを次の参画者を支援するガイドへと改訂しました。ドキュメント自体はページ全体の半分にすぎず、残りの半分は、新しいチームメイトにどのように出会うか、どうすれば彼らに歓迎され、大切にされていると感じてもらえるかというマインドセットについて書きました。 つい先週、新しい人が私たちのチームに加わりました。 彼らのフィードバックによると、私たちはすでに物事をかなり改善しているようです。 さて、常に新しい人が来るのと同じくらい、去っていく人もいます。 そのためには、最後に一緒に良い時間を過ごすだけでなく、許認可を処理し、自分たちの将来のときに新しいチームを立ち上げるためにもガイドラインが必要でした。
知識を共通化しました
コラボレーション中の知識の共有から、チーム チャネルで学んだことの共有、「HowTo」ドキュメントの作成まで多岐にわたりました。チームメンバーが知識の共有を非常に高く評価していることにすぐに気づきました！ 彼らも一緒に楽しみたいと思っていました。そこで、隔週の「知識とゲーム」セッションを導入し、知識のターンでは障壁を下げるためにできるだけ非公式に、学んだことを共有することにしました。ゲームのターンでは、その日私たちがどんな予定をしていても、予約されていました。最初のセッションですでに、私は「なるほど！」という瞬間をたくさん観察しました。 このEpicの上位段階では、知識の共有が減り、ゲームが増えていることが観察されましたが、これは私たちが止められなかった数少ないことの 1 つでした。今では知識共有の部分も復活しており、とても嬉しいです。
今週の課題処理のポリシーと課題調査をする人（課題調査員）の設定をしました
運用環境を知ることの 1 つは、運用環境で報告された課題に対処する方法を知ることでした。弊社には全体的なガイドラインがありましたが、チームのコンテキストに応じた形での実行は行えていませんでした。私は過去に明確なポリシーを導入することで良い経験をしたので、今回もそれを試してみました。 私は提案をし、コメントを求め、ミーティングですべてを一緒に検討し、全員に同意を貰いました。 そして私たちはそれを活用しています。このポリシーの 1 つでは、迅速な意思決定を行い、問題が未解決のまま放置され、腐敗して単なる無駄になることを認めていません。 もう1つのポリシーは、私たちが特定した問題、または私たちが指摘した問題に対する迅速な対応についてでした。現在、私たちはローテーションを導入しており、すべてのチームメイトが毎週交代で「初期対応者」（または「課題調査員」と呼んでいます）として課題を評価し、ポリシーに従って対処します。当初、「これは修正しません。十分な価値が提供されていません。」などの電話を掛けたり、チケットのステータスをクローズにすることにあまり乗り気ではありませんでした。 しかし、すぐに取り組む価値がない場合は、状況に関する知識が変わらない限り、まったく取り組まないという現実を直視しましょう。物事が最初に考えられていたよりも重要な場合、再び表面化します。 今年の初め以来、きれいな課題のバックログ ( 3 年間埃をかぶっていた古い課題もありました) だけでなく、迅速な決定、重要な課題が実際に修正され、新しく入ってくる課題への迅速な対応なども確認できます。チームの肩の重みが軽減されます。今ではさらに明確になりました。
数日前、私のチームに新しい課題処理ポリシーを提案しました。提案は素晴らしい会話のきっかけとなり、私たちは試してみることにしました。今日、私たち 3 人は現在抱えている問題のバックログをすでに 50% クリーンアップし、さらにチーム セッションでさらに 2 つを処理する方法をすぐに決定しました。 これは勝利と言えるでしょう！ 😊🎉
さらにクリーンアップを行い、より透明性を高めました
課題のバックログのクリーンアップが非常にうまく行ったため、止まらずに継続することにしました。残りのバックログもクリーンアップし、残っている古いEpicや期限切れのチケットなどを閉じました。完全に解放されたことで、さらに課題が明確になります。これは新しいプロダクトマネージャーが加わる直前という素晴らしいタイミングで行いました。また、Wiki スペース（非常に多くの古いドキュメント置き場）も整理しました。何も削除してませんが、ページを「アーカイブ」セクションに移動したため、Wikiの残りの部分は無駄がなく、最新の状態になり、再びアクセス可能で管理しやすくなりました。
全員が参加できるようにシステムを形成しました
私たちにとって、一人一人を積極的に会話に引き込むだけでなく、人々が自分自身の選択をできるように、最初から物事にアクセスでき、目に見えるものを用意することが重要でした。 たとえば、チームに関連するすべての通話記録をチーム カレンダーに登録するなどです。 ちょっとしたことをするだけで、チーム文化は大幅に改善されます。さらに、物理的なチーム部屋のように、全員が参加して一緒に、または並んで作業できる通話リンクを常に利用できるようにします。これにより、他の方法ではアクセスできなかった多くの会話も耳にしました。 そして、役割に関係なく、必要なすべてのツールに対する権限をチームメンバー全員に同様に付与するなどして、システム上のサイロを解消します。 個人を単一の連絡窓口としてボトルネックにするのではなく、チーム外の人々が共通のチームチャンネルを通じて私たちに連絡を取り、全員がそれを確認し、全員が対応できるようにする文化を醸成します。負荷を分散して回復力を高めるのに加えて、オーナーシップの共有やチームの責任感にも大きな違いをもたらします。
フローと素早いフィードバックのために協力する方法を（再）発見しました
私が仕事を始めたとき、チームの人々は何のつながりも持たず、私が「ペアリング」や「アンサンブル」について話すときに、それが何を指すのかを理解していなかったことがわかりました。彼らが非常に非同期的に動作していることも理解しました。そこで、彼らがいる場所で会って、最初は非同期的な方法で非常に密接に協力するように努めました。ボードを「右から左」に動かし、最初にプロセスの最も遠い項目についてフィードバックを提供します。次に開発チームメンバーが現在取り組んでいることに近づけるように作業を進めます。この方法では調査結果を監視できないため、チケットにコメントとして調査結果を追記しました。質問したり洞察を共有したりするために Slack を頻繁に使用しました。私は素早く作業を行い、基本的に彼らを追い越そうとしました。そうすれば、非同期の方法でも早く、「並んで」作業できるようになります。うまく機能すると、その体験を通じて、素早いフィードバックの良さが何を意味するのか理解し始めました！「ペアリング」について話すのも止め、代わりに毎日の通話でメンバーを捕まえて、「少しの間そのままでいてくれますか?見せたいものがあるのですが」と伝えるようにしました。画面を共有し、質問がある場所や発見した内容を示し、通話中にシステムとの対話を続けます。物事を一緒に見ることの利点をデモし、何が起こっているかを理解しやすくします。ある時点で、早期の理解者がこの状況を逆転させました。今までは「会話を続けてもいいか」と私が言っていましたが、今度は開発メンバーが私に同じような形で尋ねるようになりました。この開発者は現在の状態を私と共有したいと考えており、初期のイテレーションで積極的に私のフィードバックを引き出しました。彼は、これによりフィードバック ループが短縮され、より速く動けるようになることに気づきました！それ以来、彼は私にペアリングセッションを求め続けました。彼はマージを待ったほうがいいかもしれないとも言いました。おそらく将来的には「testing」列は必要なくなるでしょう。大勝利です！特に彼は他のメンバーの前でこれを行っていました。私には、すでに新しい方法を提唱していた支持者がいました。現在では全員とペアリングを行うまでに成長しました。互いにペアになることもできます。少人数のグループが集団として協力します。必要に応じてさらに多くの人を呼び込みます。ただ並列して作業することもありますが、一緒に同じことへ取り組むことが多くなってきています。
全体的なテスト（Holistic testing）を継続的に行いました
デリバリー全体を通じてフィードバックを高速化するだけでなく、アイデアからロジックユニット、モックアップから自動テスト、ドキュメントからアーキテクチャに至るまで、あらゆる種類の要素をテストします。テストはどんどん早くなり、規模も小さくなっていきます。開発メンバーが行っているところで、もしくは開発メンバーが新しいタスクを始める前に追い越そうとするうちに、私は自然に、より小さな反復とより小さな部分をテストするようになりました。私自身は過去のチームでそのようなことに慣れていましたが、チームメンバーの誰もまだこれを経験していませんでした。心の中でそれは時間の無駄、または正しいアプローチではないと感じているメンバーもいました。私はそれを（何度も）やってみて、そのメリットを体験してもらうことにしました。そして彼らは行ってくれました！最初の数か月間、私はテストのみに参加することで、すでに満足していましたが、最近では、ようやく変更やその他の活動を実装するときにも参加できるようになりました。また、スプリントで計画されている新しいタスクを開発メンバーが手にする前に、テストのアイデアをブレインストーミングするようにしました。繰り返しになりますが、チケットにコメントを残すだけで、その場で彼らに会うことになります。それにより、彼らは気づきを得て、意見を求め、会話のきっかけとして使用することができます。そして、さらに先に進むことができます。
テスト容易性の問題を解決しました
早期にテストすることで、テストしづらい課題がたくさん見つかりました。十分に優れた解決策を発見し、それを基に構築することが非常に役立ちました。たとえば、ローカルで実行する方法を理解することで、現時点では内部での可視性を得られます。Readmeファイルを改善し、Postmanコレクションを作成して、テストの開始点を早められます。Wiremock を使用して外部依存関係をスタブし、サービスの振る舞いをさらに探索できます。他のツールを使用して、テスト中にさらに多くの洞察を得られます。他の人のために参考として文書化するための「ハウツー」ガイドも作成します。はい、これらは同時に行われた大規模な取り組みです。行うにあたり、私は過去の経験から多くのものを取り入れました。正直に言うと、新しい会社に入社したことで、過去 6 年間で得た経験が大きく証明されました。最近では、自分が詐欺師であるとはあまり感じなくなりました。テスト容易性を高めるためにできることはまだたくさんあり、私にはたくさんのアイデアがあります。ただし、容量は限られているため、最も影響を与えるものを慎重に選択しています。チームが変更をフォローアップするのにあまりにも急ぎすぎないようにする必要があります。
今日、さらに 3 つのレガシー サービスを発見しました。これらは解決するのが難しい問題でした。 時にはイライラすることもありますが、とてもやりがいがあります。テストに必要な部品を実行できるようになり、内部の仕組みについてさらに多くの洞察が得られました。今回の取り組みを通じて、自分の「物事を理解する」スキルに自信がつきました。 💪🏻
始めることをやめて、終わらせることを始めるようにしました
幸いなことに、この合言葉を繰り返していたのは私だけではありませんでした。プロダクトマネージャーやエンジニアリングマネージャーも、この絶え間ない説教に参加してくれました！しかし、説教だけでは役に立ちません。 模範を示し、行動を起こし、明確な主張をしなければなりません。「終わらせる」振る舞いに報酬を与えるシステムを設定しましょう。人々は自分自身で痛みを経験して初めて、終わらせることが容易になり、何か新しいことを始める前に、お互いに助け合えるところは何かをまず考えるようになりました。まあ、他の期間よりも良かった週もありましたが、それでも私たちは皆人間です。特にプレッシャーがかかったり、ストレスを感じたりすると、古い習慣に戻ってしまいがちです。私自身もそれを何度も繰り返し見ています。現在では、流れははるかにスムーズになり、ほとんどの日で以前よりもはるかに高いスループットを実現しています。ここでも役に立ったのは、私たちが壮大で明確な優先事項に明確に焦点を当てていたこと、そしてこのアプローチがプロダクト マネージャーによって非常に明確にサポートされていることです。フォーカスは、全員が自分だけで突き進むのではなく、密接に協力できるようにするのに非常に役立ちました。
前回のレトロでは、次のようなコメントがありました。
1.「始めるのをやめて、終わりを始めなさい - チームとして」 @lisihocke
2. 「新しいタスクを始める前に『完了するために何を手助けできるだろうか』と考えてください。」
ボードの配分は始まりと終わりを重点的にし、中央にはほとんど配置しないようにする必要があります。
チームがテストできるようにしました
各チームメイトが私とのペアリングセッションを経験し、私と一緒に(ドキュメントを含む)テストの練習を経験することで、システム全体、何を探すべきか、その方法についてますます学びました。ここでも、過去のチームで役に立ったことを試しました。一般的なテストガイドラインの作成です。これは、コンテキスト内で重要な特定の事柄を忘れないように個人的に常に役立ちます。また、特にテストの練習が少ない人にとっては、他の人にも同様に役立つことを学びました。車輪を再発明する必要はありません！私が不在の場合について人々が考える良い参考になることもわかりました。たまたま、私が時間を空ける時間が増えていきました。最初は2日間しか離れていませんでした。数週間後、丸一週間離れました。その後すぐに、2週間以上離れました。開発メンバーはこれから何が起こるかを本当に理解しており、ステップアップする必要があることに気づきました。大幅に後退したくない場合は、物事をただ放置することはできません。どうしたのでしょうか？最初の 2 日間、早期に理解した開発者はテストをすべて一人でカバーするという英雄的な努力をしました。驚くべきことに、彼は私と一緒に観察したことをたくさん真似していました！しかし、それは彼にとって大きな負担でした。2 回目ではチームは苦戦し、他の変更をテストするよりも新しい変更に取り組むことを好みました。チケットはフィードバックを待って山積みになり、彼らは痛みと摩擦を自ら経験しました。戻ってきたとき、私も彼らと一緒にきれいな状態に戻るのに2週間かかりました。まあ、人々が苦労することは予想されていました、彼らはこれまでにこれをしたことがありませんでした。そしてついに、私にとって最も長いオフタイムがやって来ました。そして彼らは非常にうまくやってくれました！私は最新状態のところに戻り、プレッシャーを感じることなく落ち着いて開始することができました。今回は 3 人の開発メンバーが対応してくれました。本当に素晴らしい結果です！これまでにチームが引き継ぎに成功したのを見てきましたが、これほどうまくスピードを出したことはありませんでした。彼らをとても誇りに思っています。
昨日、同僚の品質エンジニアが、私のストーリーのテストノートにインスピレーションを受けたと共有しました。そのようなことが起こるとは思いませんでした! 😅😊 また、自分自身とチームが常に意識できるように、「X をテストするときにこれらすべてを考慮する」チェックリストを作成するアプローチを共有していることも学びました 😉
仲間の開発者をとても誇りに思っています。 😍
私はカンファレンスのため2日間お休みしてしまいました。
彼は、
1) 5 つのストーリーのテストを引き継ぎました。
2) 真剣に取り組みました
3) 素晴らしいアイデアを思いつきました
4) 貴重な情報を学びました
5) 結果をしっかりと文書化しました
6) 他の開発者に説明しました。 ❤🌟🙌🏻
2週間以上の休暇を経て仕事に復帰し、これまでで最長の期間となりました。復帰したら、何も積み重なっていない、最新の状態に戻っていて本当に良かったです。🤩 開発者 5 人中 3 人は、ドキュメントを含むテスト活動を実行し、すべての処理が行われ、素晴らしい仕事をしていました。私はもう一度参加するだけです。❤
チームとしてリリースを行うようにしました
リリースがどのように行われるかを再発見したとき、私は「ハウツー」ガイドラインに一つのステップを文書化しました。その後、この知識をチーム全体で共有し始めました。前回のリリースは、その日に参加可能なチームメイト全員が一緒にリリーステストに参加する初めての回でした。大幅な改善でした！彼ら全員が現在のリリース プロセスでの摩擦を経験しているため、退屈を軽減する、より良い方法を見つけることに触発されました。現在のリリースでは、私が主導的な立場に立つことなく完了しました。私はもちろん、必要なときに相談を受け、サポートするためにまだそこにいます。これはチームにとってまた大きな一歩です！
@TestPappy、ありがとう！ 😍
今日は、このチームがチームとして一緒にリリースをテストするのは初めてでした。挑戦的でしたが、その価値は絶対にありました。💪🏻 今日だけではなく、私たちのチームと私個人に対する皆さんの素晴らしいサポートにどれだけ感謝しているか、どれだけ強調しても足りません。 🙏🏻
チーム間のコラボレーションを促進しました
私たちが取り組んでいる巨大なEpicには、多くのチームが関わっています。一緒にテストするなど、チーム間でうまく連携する方法を確立し、学ぶ絶好の機会です！共感を獲得し、システム全体について学び、ドメインについてより深く知り、特に人間関係を築くのは本当に素晴らしいことです。もう一つのトピックがあります。チーム間の協力も必要となるインシデントの際には、私たちはチームとして現れます。チームメンバーはある日突然私たちのチームを違った視点から見るようになり、ストレスの多い状況でも私たちが緊密かつ建設的に協力していることに気づきました。それが私たちに良い評判をもたらしたか、少なくとも人々に私たちへの視点を再考させたのではないかと思います。また、インフラストラクチャサービス、顧客体験、医療知識など、他の専門分野の人々とより密接なコミュニケーションとコラボレーションを行うことができました。架け橋と絆を築き、常に可能な限り透明性があり、建設的で役に立つよう努めています。どのような依存関係があるのか、誰に何を知らせる必要があるのかを学び、それについて積極的に取り組む必要があります。私たちの働き方や知識を求めて積極的に連絡をくれる人もいます。
昨日は苦労したけど、今日は勝ち！🎉 さまざまなチームの人々とシステムテストを促進し、多くのことを学びました。💡 同僚である@TesterFromLeic と @jrosaproencaとのカンファレンスからの洞察を提示しました。🔥@janetgregoryca と @lisacrispin とペアリングについて素晴らしい話をしました! 🤩
本番環境を知るようにしました
これは私たちにとって今でも大きなテーマです。これは、私が始めた最初のプロダクトの 1 つであり、また、悲しいことに、私たちの巨大なEpicの熱い段階で中断された最初のプロダクトの 1 つです (何という矛盾だろう。私たちが最も必要としていたときだったのに)。私は、現在のインフラストラクチャの設定や何が起こっているかを確認するためのツールについてさらに学ぶことに投資し、対処する必要がある重要な部分を確認するためにクリーンアップとノイズの除去を開始しました。チーム全体で良いプラクティスを確立しようとする前に、最終的に重要な唯一のシステムである本番環境で実際に何が起こっているのかを確認するという毎日の習慣を自分自身に導入しました。この方法で問題を発見し、修正したので、幸先の良いスタートとなりました。その後、それ以上改善することなく、現状を維持するだけで停止しました。今、私たち全員が再び手に入れることができます。
Part3「現在のチームの状況」に続く…
