イレギュラーな事態と向き合う
- イレギュラーな事態はどう頑張っても起こる
- 誰も悪くない
- 粛々と対応しよう
私はQAE/SET（以下、QAEと一括りにする）として、これまでスタートアップから大手日系、外資系企業等、様々なソフトウェア開発チームで活動してきた。QAEに与えられるミッションは、ソフトウェアの品質保証活動、特に手動・自動テストの担当だ。日々の業務を品質保証活動に終止できれば幸せなのだろうが、往々にしてそうはいかない。（QAEに限った話ではないが）組織で活動している以上、我々は時としてイレギュラーなイベントに振り回される。例えばプロダクトのドキュメントが整っていなかったり、複数のQAEが短期間に次々と離脱したり。「これってQAEの仕事でしたっけ？？」「なんで自分がこのタスクしなきゃいけないの」「なぜ自分がこんな酷い目に」と思う瞬間はいつだって訪れる可能性がある。この記事では、よく聞くイレギュラーなイベントをいくつか書いてみようと思う。
プロダクトのドキュメントが整っていない
これは特にQAチームの立ち上げを行うときに直面する課題だが、プロダクトの仕様書やユーザーマニュアルといった公式のドキュメントが存在しない場合がある。あるいは、課題管理チケットとして存在してはいるが、ユーザーストーリやアーキテクチャが十分記述されていなかったり、関連チケットとのトレーサビリティが確保されておらず全体像が把握しにくい状態だったり。テストを実施するにあたり、プロダクトへの理解は必須である。そのため、仕様書の整理やユーザーマニュアルの作成がQAEの最初の活動となる場合がある。なお、私が最も戦々恐々としたのは、シニアメンバーがプロダクトの情報を暗黙知のままにして離脱してしまったときだ。
QAメンバーの同時多発的離脱
この課題は、チーム内のエース/リードエンジニアが離脱した場合や社内の評価制度/組織構成が変わったときに起こることが多い。例えばQAチームにコミュニティで有名な人、チームの精神的支柱の役割を果たしている人が所属している場合、彼らの離脱は他のメンバーの離脱のトリガーとなることがある。よくある理由としては「この人がいないんだったらこのチームに居続ける理由がない」「この人が抜けると業務負荷の増大が目に見えている」といったものだ。また、QAEは時としてエンジニアとみなされない場合もある。所属組織からこのような烙印を押されてしまったとき彼らのプライドがそれを許さず、離脱につながってしまう。
いずれにせよ、同時多発的な離脱が発生してしまった状況では、現場がカオスになることが確定する。業務引き継ぎはもちろんのこと、士気が下がったメンバーのフォローや採用活動強化といったチームの建て直しを行う必要がある。ときには、不足したリソースを補うため（一時的に）他部署の方に品質保証活動の一部を依頼したり品質レベルの目標を下げる必要が出てくるかもしれない。このような状況では日々の業務をテストで終止するなんて場合ではなくて、メンバーやタスクをマネジメントするほうにエネルギーを持っていかれることになるだろう。
正直に言うと、エースエンジニアが離脱したときに自分も離脱しようと考えるのはモチベーションが甘いなと思っている。すごい人の隣で色々学びたかったんだろうけど、エースの側からするとむしろ自分を引っ張ってほしいと感じていたりする場合もある。頼ってくれるのは嬉しいけどアテにはすんなよ、あなたも何か面白いとこ見せてくれよ。。と。
リードエンジニアに引きずられて離職が発生する場合については、組織の上層部がこの関係を早い段階で認識しておくと対策が打ちやすい。タフな彼が自分を盾として膨大なタスクからメンバーを守っているのか？攻撃的な振る舞いをするステークホルダーとの議論を（メンバーにストレスを与えないよう）自分が率先してやっているのか？彼が特定の重要なタスクを達成するために必要な特別なスキルを持っていて、メンバーへのスキル継承がされないのか？このパターンは、チーム内外との関係性や業務フローを見直すことで予防できる場合もある。上層部-リードエンジニア間で1on1を実施するのも効果的な方法ではあるが、各チームが保持している業務量/リソースや人間関係を常時観察できる人がいると理想的だ。
QAEがエンジニアとしてみなされなくなる状況も、しばしば発生するのが現実だ。個人的にはポジションにも所属にも拘りはなくて、品質を始めとした各種改善活動に取り組むことができればなんでもいいと思っている。が、そうでない人も当然いる。組織がQAEをエンジニアとして認識しなくなる理由は「デザインと動きをチェックする人だから」「コードの読み書きができないから」といったものが多い。しかし調べてみると、テストはソフトウェアエンジニアリングの一領域であること、コードを書けることがソフトウェアエンジニアの必須条件であるわけではないことがわかる。経営層の方にはぜひともエンジニアの定義を考えていただきたい、と思いつつ、現場の方も「あなた方の考えるエンジニアとはなんですか、QAEに何を期待していますか」くらいは聞いてみても良いんじゃないかと思う。
A software engineer applies the principles of engineering to design, develop, maintain, test and evaluate computer software. This is often a highly collaborative activity that requires teamwork skills. A software engineer uses components of a hardware system to create the tools to develop software and tends to solve issues on a large scale.
"12 Different Types of Software Engineers (With Salaries)" より抜粋
Software development is the process used to conceive, specify, design, program, document, test, and bug fix in order to create and maintain applications, frameworks, or other software components. Software development involves writing and maintaining the source code, but in a broader sense, it includes all processes from the conception of the desired software through the final manifestation, typically in a planned and structured process often overlapping with software engineering. Software development also includes research, new development, prototyping, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.
Wikipedia "Software development" より抜粋
さいごに
組織で活動していれば、想定外の事態はどう頑張っても起きる。そして、それは誰も悪くない場合が多い。ドキュメントの必要性を理解していてもリソースが足りない。リソースを確保したくても予算が足りない。時が経てば会社の方向性や評価制度が変わってメンバーの心が組織から離れてしまうかもしれない。同志とも呼べるほど分かりあえたメンバーと仲違いし、同じチームで働くことにうんざりすることだってある。全て自然なことだ。特定の個人を責めて解決することではない。この記事も、いくつかのイレギュラーな状況を取り上げてはいるが決して誰かを非難する意図で書いていない。私の主張は冒頭に書いた通り、すなわち「粛々と対応する」ことに尽きる。想定外の事態が起きることを自然なことだと認識してさえいれば、少々心が揺らぐ出来事に遭遇しても案外冷静に対処できると思う。
最後の最後にちょっと意識高いこと書いておくと、こういう想定外の事態は経験値をガン積みするチャンスなのでむしろポジティブに捉えてしまってもよい。日常的業務の外側のタスクに取り組むことで、（大変な思いはするけれども）スキルの幅は少し広がるし乗り切ったときには自信もつく。長期的にはキャリアアップの材料になるはずなので、理想的には楽しんで向き合えるようになるとよい。
神よ、変えることのできないものを静穏に受け入れる力を与えてください。
変えるべきものを変える勇気を、そして、変えられないものと変えるべきものを区別する賢さを与えてください。
一日一日を生き、この時をつねに喜びをもって受け入れ、困難は平穏への道として受け入れさせてください。
ラインホルド・ニーバー「ニーバーの祈り」より抜粋
参考資料
https://www.indeed.com/career-advice/finding-a-job/types-of-software-engineer
