2016/10/29(土)に行われた「ソフトウェアテスト勉強会～テスターと創る開発現場～」の参加レポートです。
東北デベロッパーズコミュニティ - イベント案内 | 2016-10-29 (土) ソフトウェアテスト勉強会～テスターと創る開発現場～
"テストの妖精"こと@miwa719さんと、"プロの無職"こと@m_sekiさんに彼らの開発現場について語っていただきました。
私たちの開発現場：@miwa719
speakerdeck.com
プロの前座(tohoku again)：@m_seki
speakerdeck.com
JaSST東北2014で初めて彼らにお会いして以来、何度か話を伺っています。彼らの話はいつも刺激的で、彼らのような開発現場をいつも羨ましく思って聞いています。彼らのチームは、私が知る限りにおいて"最高のチーム"を実現したようなチームだと感じています。
ふと、自分は彼らのチームの何を羨ましく思っているのだろうかと考えました。そこで今回は彼らのチームの何が凄いのか、何が羨ましいのかを整理してみました。
彼らのチームの何が凄いのか
2時間という時間がアッという間に過ぎるほど、今回も素晴らしい活動をたくさん話していただきました。
開発とテストが分かれていない
ソフトウェア開発はV字モデルに従って行われることが多いです。そのため、テストは"開発物が仕様通りに動くかどうか"を確認することになりがちです。しかし、彼らのチームは開発時にテストの設計も行います。テストの観点から開発設計に対して指摘をすることもよくあるそうです。また、テスターがあらかじめどのようなことを重点的にテストしたいかを伝えておくことで、開発者がその部分を意識するためバグを減らすことができているそうです。
忍者式テスト
過去のチケットを含めて毎日少量ずつテストを実施するという@m_sekiさん考案のテスト技法。テストを実施するチケットは一定期間ですべてのチケットが回るように工夫してあるとか。忍者式テスト自体は何度かお話伺ったことがありますが、てっきり"若いシステム"に対して有効な手段だと思ってました。今回、対象のシステムが15年以上のシステムだとの話を聞いて、軽く戦慄しています。
テストケースのメンテナンス
仕様が変更になった時、対象となるテストケースは同時期に修正されるのが一般的です。しかし、彼らのチームでは、テストケースの修正は気付いた時に実施するそうです。膨大なテストケースに対して、必要な変更をすべて洗い出すことに膨大な時間がかかることを理解しているからこその対応です。また忍者式テストによって、彼らのチームはすべてのチケットが一定期間で回り続けます。そのため、チケットが仕様変更の対象かどうか気付く機会が多いため、テストケースを適宜修正しても問題が起きないのだと思います。
彼らのチームの何が羨ましいのか
彼らの話を聞くたびに、「彼らは最高のチームである」と感じますし、「彼らのようなチームで働きたい」と感じます。そんな羨望の理由を自分なりに整理してみます。
何が"最高"なのか
彼らのチームは理想的な働き方を体現しています。彼ら以上に理想的な働き方ができているチームは知らないため、"最高のチーム"だと思っていますが、その漠然とした"最高"が何なのかをもう少し明確にしてみます。
- 技術が"最高"なのか
@m_sekiさんは一流の開発者ですし、@miwa719さんは一流のテスターであることは疑いようがありません。彼らがとても高い技術を持っていることは間違いがありませんが、彼らの技術に対して羨ましいと思っているわけではなさそうです。ことソフトウェアテストの分野で彼らに接する限り、技術を前面に押している印象はありません。もちろん彼らの活動が高い技術によって支えられている部分があるのですが、技術に関して言えばもっと技術を前面に押し出している人がいると考えています。そのため、自分が感じている"最高"は技術ではないのでしょう。
- 品質が"最高"なのか
彼らの活動から"品質が低いものができるはずがない"と確信しています。全員が良いものを作るために同じ方向を向いている彼らのチームは"最高"の品質を作りこめるレベルだと思います。しかし、彼らの製品は一般消費者向けではないので、自分が彼らの品質を体感できる機会はほぼありません。そのため、自分が感じている"最高"は品質ではないのでしょう。
最高のチームワーク
彼らのチームは、誰かの問題を自分の問題として真剣に向き合ってくれるメンバーで構成されています。トラブルが起きた時でもを全員の問題として捉え、知恵を出し合い、そのチームの中での最善手を選び続けているのだと思います。そんなところを羨ましいと感じています。
彼らのチームは、完璧なものなどないことを理解した上で、それでも理想に向かうために改善策を出し続けています。人はミスをしますし、完璧な成果物を作成することは不可能です。そのうえで、ミスを減らすにはどうすればいいのか、ミスが起きたことにどうやって早く気付くか、に注力しているように思います。そんなところが羨ましいと感じています。
そんな彼らのチームの「誰かの問題を全員の問題として捉え、知恵を出し合える」「人はミスをするという当たり前のことを当たり前のように受け入れ、その上で理想に向かうために変化し続ける」チームが羨ましいです。彼らのチームは私にとって"最高"に理想的な、最高のチームワークを持っているのだと思います。
どうすれば彼らのチームを超えられるのか
彼らのチームのどのようなところが羨ましいかが分かれば、それに対して自分たちにどのような改善が必要かが見えてきます。千里の道も一歩から。彼らのチームと自分のチームの差が千里あるとして、その一歩先を行くために、今の一歩を踏み出さないといけません。
- チームで問題を出し合える環境を作る
「言うは易し、行うは難し」の最たる例です。チーム内で問題を言い合おうとしても中々出てきません。出てきた問題を他人事に捉えられたり、問題を出したことで責められたり、そもそも自分の時間が惜しくて他人の話を聞くことに消極的になったり。話す側も聞く側も問題を出し合うことにメリットを感じにくいです。実際は良いものを作るうえでは必要でメリットが多いのだけど。
具体策はまだありませんが、ポイントは「心理的安全性」と「チームがどこを向いているか」あたりでしょうか。
- 現実に対して素直になる
完璧な環境で仕事をする。理想的かもしれませんが、現実にはそんな環境はありません。問題は「自分がうまくいかないのは、理想的な環境ではないから」だと責任を転嫁してしまい動けなくなってしまうことです。自分も他人も含め誰だってミスはしますし、出てきた成果に完璧なものなんてありません。それらから目を逸らさずに、その現実を踏まえた上で改善する方法を考え続けないといけません。
- アンチパターン？：個人の問題を技術で解決する
今回の考えを整理していて、最高のチームを作るうえで(IT的)技術そのものが重要ではないように感じました。求めるべきはチーム全員が一つの問題に向き合える環境であって、技術の高さではないかなと思います。では、技術が不要なのかというとそうではなく、チームの問題を解決するために技術が必要になる場面は必ず出てきます。チームの問題に昇華できていない個人の問題を技術で解決しようとすると、認識違いが起きてしまい、チームに良くない影響があるかもしれません。程度によると思いますが。
解決したい問題があったら、まずチームの問題として昇華してから解決する。その方針が良さそうかな、と思います。
まとめ
@miwa719さんと@m_sekiさんの開発現場は本当に魅力的で、話を聞くたび一緒に働かせてもらいたいと思います。そんな理想的な彼らのチームが何を大事にしているのかを理解して、自分でも同じところを大事にできると彼らのような理想的な開発現場が築けるのかな、と思います。
