はじめに
本記事は A Tester's Journey: A Time of Transition - Eight Months on a New Team を日本語訳したものです。
この記事は、著者のLisi Hockeが、新しいチームにJoinして8ヶ月間で起きたことを赤裸々に語っています。その中で、どのようにチームにフィードバックを促し、どのようにチームを変化させていったのかが詳細に語られており、大変良い記事だと感じたため、今回翻訳することにしました。
なお、元記事が長文なため、翻訳記事は計5回に分けてお届けします。
本記事は第1回です。
このチームに関する詳しい内容や、記事執筆後に起こった変化はJaSST Review'23にて講演予定です！（同時通訳付き）
興味を持たれた方は以下のページから参加申し込みをお願いします！
目次
序文
新しい会社、新しいチームに配属されてから8ヶ月が経ちました。年初に、最初の数ヶ月間で起きた新人研修の経験と観察内容について別記事で紹介しました。そこから半年以上が経ち、これまでのことをふりかえることにしました。共有したいことが沢山あるので、びっくりしないでくださいね。
以下では、私のチームの背景と変遷をふりかえります。私のチームは通常、複数のチームを跨いだ活動拠点となっています。私が新しい会社で最初に焦点を意図的に当てた部分でもあります。私たちは既に数多くの課題を一緒に乗り越えてきました。私たちは大きく成長し、これからのさらなる変化が待っています。そんな中で私はまだこの会社に留まり、一緒により良い方向に進んでいくための理由があります。
今、私のチーム以外にも、会社での私の第一印象や経験について話したいことがたくさんあります。一方で、品質エンジニアリングのギルドには知識豊富な人がたくさんいて、今でも同僚でいられることを光栄に思っています。これまでのところ、素晴らしい交流をしてきましたが、まだ私が望んでいるほど多くの交流を行えていません。つまり、まだまだ可能性があるということです！一方で、社内にはあらゆる分野の素晴らしい専門家が多数います。インフラ担当、医師、セキュリティの専門家、その他多くの専門家です。私たちが既に交わって事業を進めているのは嬉しいことですが、まだ私が望んでいる状態までには至っていません。それでも、自分のチームに焦点を当てるのは意図的な選択であり、それが私の注意を最も必要としているところだと、今でも感じています。そこで、私たちがチーム内で一緒に経験することになった変遷についてこの記事にまとめました。どこから始めたのか、何が起こったのか、現在はどうなっているのか、途中で必要となった助けが何か、そして将来はどうなるのかをふりかえってみましょう
どこから始めたのでしょうか？
ふりかえって、私たちがどこから始まったのか見てみるのは良いことでしょう。意図的に取り繕わずに、私が経験したことを伝えます。後になって考えると、私が最初に観察した内容のうちのいくつかは追加の証拠によって強化されましたが、時間が経って初めて得られた認識もありました。ここでは、人物についての話であることに注意してください。状況を考慮して良い仕事をしたいと思った人たちや、私が尊敬している人たちがいます。状況が変化したことによって、どのような影響があったのかについてはあとで説明しますが、最初に私が観察した状況を示してみます。
デフォルトはソロワークだった
私が以前に経験したものとは全く対照的なものでした。現チームに参加した時、私が「ペアリング」や「アンサンブル」について話しても、あまり共感してもらえませんでした。自分のやるべきことをやったら、それが終わったと考えて他の人に引き渡すような動きを誰もがしていました。チームに名前上参加しただけであり、精神的にもチームに参加したようにはなっていませんでした。
チーム内のコミュニケーションが限られていた
1日の中で1回、数行だけ共有している人を見ました。チームチャンネル内かダイレクトメッセージで私に直接送ってきた投稿はほんのわずかしかありませんでした。チームの半数は、プルリクエストのコメントの数が少しだけしかありませんでした。チームコールがあるときは、多くの人が完全に沈黙していました。ほとんどの人が常にビデオをオフにしていました。これは難しい問題でした。カメラをオンにしないのには正当な利用があるため、私は強制したくありません。それでも、私にとってコミュニケーションと人間関係の構築を困難にしている要素となります。
知識のサイロ化が発生し、ゲートキーパーとなり、透明性がありませんでした
ええ、これは解決が難しい問題でした。間違いなく共有すべき情報を人々がお互いに共有していない光景を見てきました。私は知識やあらゆる種類の学習でも同じことを見てきました。ツールであれミーティングやチャンネルへの招待であれ、許可とアクセスを得て閲覧できる状態になっていました。時には、人々が関与していないだけでなく、積極的に会話から遠ざけられていることもありました。通常、どこに行くのも頼れる人は1人だけいますが、その人を最初に見つけなければなりません。自分たちが取り組んでいるシステム全体を知らないと想像できると思います。人々がチームを離れた時に知識が失われることは想像に難くありません。また、チームレベルで共通の理解を持っていなかったため、お互いに多くの誤解や非現実的な期待があったことも想像できるでしょう。さらに、人々が進捗中の作業を「完了した」とみなす前に共有することを好まなかったということも想像できるでしょう。
専門家の役割で考える
自分の役割に基づいてお互いを全く異なる扱いをするのを私は見てきました。彼らが自分の枠に完全に収まらなくなると、自分の枠に引きこもり、仕事や責任を他の人に受け渡すのを見てきました。「それは私の仕事ではない」という態度や似たような防御パターンを見てきました。このグループは「バックエンド担当者」や「フロントエンドチーム」など、専門知識やアイデンティティに基づいた個人のサブグループの集合体のように感じられることがあります。
何もしない、決断を下す勇気がない
私はこれに何度も遭遇しました。以前までの現場で、ほとんどの場合で正式な許可なしで（影響を常に事前に考慮しながら）作業を進め、後で許しを求めることが問題ではないことを学びました。今のチームで私は、行動を起こす前に（たとえ行動を起こすとしても）何度も実行に躊躇してしまう人々に出会いました。「他の人に決定をしてもらったり、許可を与えましょう。他の人が最初の行動を起こすのを待ちましょう。チームの範囲内のほんの小さなことであっても、全てについてね！」実験は行われておらず、目に見える改善も得られなかったことは想像に難くありません。
色々な方向に振り回される
チームや製品の明確なビジョンが無さそうでした。少なくとも、ビジョンについて私が学んだものはありませんでした。むしろ、製品開発の複雑さを理解していない様々なステークホルダーによって、チームが様々な方向に振り回されている光景を見ました。期待は管理されずに放置され、明確なコミュニケーションが行われていないように見えました。チームが最後まで物事を提供できなかったのを見て、外部の人々はフラストレーションが蓄積していました。結果、チームは何か完了する前に次の大きなことに引き込まれてしまうことに不満を感じていました。
限界を踏み越えていきました
境界線に非常に気を配る人もいました（私は賞賛したいです！）。しかし、他の人たちと全く逆の振る舞いをしている人も見てきました。そして、そのような振る舞いは大きな損害をもたらしました。チームが金曜夜遅くに、月曜朝早くまでに結果を求めているのを見たことがあります。私は1日中電話を受けるたびに、何かをするように求められました。「えっと、いつですか？」もちろん、超緊急の「何でもいいから」は全く必要とされていない、もしくはフォローされていないものでした。期待しているものは非現実的であり、明らかに健全でも持続可能なものでもありませんでした。我々には息を吐く余地がありませんでした。確かにそうです。我々は人を喜ばせるという個人的なパターンに戻らないようにしながら、時には強く反発し、自分の境界線を過度に明確にする必要があると感じました。
責任転嫁
これは最も残念なことですが、これまで見てきた多くの防御的振る舞いを説明するものでした。誰でも間違いを犯し、何らかの失敗をします。そんな中で、責任の所在を問う時間が始まりました。チーム内の役割間であっても、チーム間であっても、それは常に他の役割です。なぜ人々が対処のメカニズムを思いつき、安全な場所に退却し、非難されるかもしれないことをあえて行わなかったのか不思議ではありません。
社内でのチームの評判が悪い
私が参加する前から様々な人から聞いた非常に悲しいことでした。チームの歴史（というよりも、外部から認識されているチームの歴史）は、明るい印象を持っていませんでした。チーム間のコミュニケーションの問題が多く発生していたようです。チームが他のチームの状況を壊すような変更を導入することに人々は不満を抱いていました。製品に関して認識されている全ての問題について苦情を言われました。チームに参加した時、これを裏付ける証拠があまり見つかりませんでした。チームがある程度の評判を得たら、この認識を変えるには労力が必要になります。
私はこの状況下で最善を尽くして働いた人たちのグループに出会いました。この事実だけで十分でしょう。彼らは知識と経験に基づいて互いに助け合い、サポートしようとしました。私も含めて、彼らはもっと良いものに値すると考えていた、という言葉だけで十分だと思います。それでは、この物語に変えて、独自の物語を作り上げてみましょう。その前に、全体像にさらに詳細を追加し、チーム内でテストと品質がどのように考慮されるようになったか見ていきましょう。
チームや役割を超えて渡す
自動テストは開発者の領域にありましたが、それ以外のものはすべて、チーム専任の品質エンジニアに「壁を越えて」渡されていました。 これはワークフローの 1 つのフェーズであるとさえ考えられていました。 この時点で、変更はすでにメインラインにマージされており、開発者は次のトピックに移り、フィードバック ループに非常に長い時間がかかりました。 役割を越えたコラボレーションはほとんど、あるいはまったく観察されませんでした。 その後、テストが何を意味するのか理解していないことや、開発者が重要なことを見落とすのではないかと恐れて自らテストしようとしないことまで、さまざまな理由がわかりました。
バックエンドのテストをスキップする
バックエンド側の変更はしばしば綻びを見逃して「完了」に移行されるだけでした。 まあ、同僚が変化した行動に驚いたことは想像できます。 回避可能なバグが本番環境に逃げ込んだことも想像できるでしょう。
基礎的な知識が不足している
知識のサイロ化と共有の欠如により、以前なら私がその仕事そのものに不可欠であると考えていた事柄が同僚に知られていませんでした。 彼らは単にそれを知る機会がなかったか、あるいはその機会を利用しなかっただけであり、そうするインセンティブもありませんでした。 ここで話しているのは、サービスをローカルで実行する方法、またはデプロイされたサービスの API を呼び出す方法を知ることです。 そして、彼らは善良な人々です - 彼らは自分たちの選択肢に気づいていないか、何が可能なのかを探ろうとしていませんでした。 多くの人はそれは不可能だと言われ、そこで止まってしまっていました。
統合された状態のみをテストしている
テストの実施が遅かったため、同僚は統合システムのみをテストしていました。場合によっては、これはすでに多くの変更が組み合わされていることを意味しており、私の経験では、問題を検出し、問題を特定し、根本原因に関連付けることが困難になります。小さなステップで進めて、各部分を組み合わせてどのように振る舞うかを確認する前に、最初に単一部分の小さな変更が個別にどのように動作するかを確認する方がはるかに簡単です。
テスト容易性が低い
どこを見ても大変でした。必要以上に難しかったです。それをより簡単にする方法を見つける時期が来ているので、知識を広めることも容易になってきています。しかし、当初は誰もテストを容易にすることなど検討していませんでした。テストを容易にすることは不可能であるか、価値がないと考えたか、それに投資する能力や必要な報酬がなかったかのいずれかです(はい、今まで書いていた内容と同様です)。代わりに、今のところ最も抵抗感の少ない方法を選択し、自動化以外のテストをまったく行わないか、統合された状態をテストしましょう。しかし、そこでさえ、実際に何が起こっているのかについては十分な見通しがありませんでした。
終わらせるよりも始めることを優先する
同僚は自分の仕事に集中しており、一度それが完了すると、全体としても完了したと考えていました。これはどうなると思いますか？同僚は新しいトピックを始めるということを続けました。ずっとです。これらは害を与えませんでしたね？しかし、無数の物事を始めて最後までやり通さないと、最終的には巨大なキューとなって自分自身を妨げることになります。開発者は、開発中に自分自身でやりくりしなければならないトピックが 3 つあり、レビューするトピックが 1 つか 2 つあるかもしれません。これはすでに大量ですが、1 人ではまだ大丈夫かもしれません。しかし、熱心なテスターの観点からすると、これは悪夢です。5人の開発者がそれぞれ 3 つのトピックを実行しているということは、15のトピックについてコンテキストを切り替えることになります。そしてやり取りの行ったり来たりもたくさん発生します。高速フィードバックは言うまでもなく、スループットやフローのことは忘れましょう。
可観測性と監視性が低い
プロダクションについて知っている、というよりむしろ知らないことが、私が最初に気づいたことの一つでした。問題が発生した場合、それを簡単かつ迅速に発見できませんでした。問題の調査は単純ではなく複雑でした。責任も明確ではありませんでした。問題の報告に対して私たちの自覚を促そうとする人々に誰が反応するのでしょうか？
共有すべきことは常にあると思いますが、ここまでの話によって我々のチームが行った移行を理解するための出発点となるコンテキストが得られたでしょう。
