情報量が多すぎて管理ができていなかった
伊藤潤平氏（以下、伊藤）：Living Document。“生きたドキュメント”という意味ですが、このアイデアはすごくジャネット先生も提唱していて。ゴイコさんとダンノースさんという人が提唱したものらしいんですが、すごくいいアイデアだと言っていました。
これはアプリ開発のチームの話ですが、アプリ開発のチームはプロダクトマネージャーからパワーポイントで要求仕様書がきます。1スライド1機能くらいに絵でまとめられています。それをバックログに1機能1チケットくらいで情報管理して、そのバックログをもとに、開発やテストをしていました。
しかし、情報量が多すぎて、私が見てもぜんぜんわからない。情報を追っていけない状態でした。「仕様が間違っていたので直しました」とか、「このチャットのここの会話で仕様が変わりました」とリンクがペッて貼ってあったりとか。なにが正しい情報なのか、イチから追っていかないとわからない状態になっていて、すごく苦労しました。
プラス、テストの計画書を作ったことがないチームだったので。であれば、もうテスト計画書を作って、その中で情報を整理しましょうという話をしました。
作ったことがない人が多いので、なるべくシンプルなテスト設計書を作りました。シンプルなものにこだわったのは、実はウイングアーク１ｓｔでは、ISO/IEC/IEEE29119-3に準拠したテスト計画書を作っています。
ただ、これはすごく複雑で、たぶん作ったことがない人が見たらわからないだろうなというものがあったので、本当にシンプルさを重視することにしました。テストの目的とか、何をいつまでにという情報をこの中に入れました。
ちょっと見にくいかもしれませんが、我々は100パーセントのうち60パーセントの品質を目指しますよと。この中にはこんなテストタイプを定義していて、優先順位はこうですと。これをスケジュールに落とし込むと、こんな感じになって、テストベースは成果物とマッピングする必要があるという、テスト計画書です。
“生きたドキュメント”でレビューが入れやすくなった
“生きたドキュメント”と言ったのは、トレーサビリティ。つまりテストベースに対するテスト成果物のトレーサビリティのマッピングです。ちょっと小さくて見にくいんですが、テストベースとテスト成果物というのがあって、テストベースは、要求と設計と実装みたいな感じです。
要求だったらパワーポイントのこのページに書いてあって、設計だったらバックログのこのチケットに書いてあります。テスト計画書はこのドキュメントで、テスト設計はマインドマップのこのノードに書かれていますとか。
テスト実装とテスト実行はGoogleスプレッドシートのこのシートに書かれてあって。テスト分析に関してはバグトラッキングシステムに記入しましょう、という情報を入れていきました。
バックログしかない状態のチームだったので、これだけきれいに見えるのであれば、プロダクトマネージャーはレビューのタイミングを入れやすくなる、という話をしてくれました。
プロダクトマネージャーからすると、チケットを見てもよくわからない状態だったので、できあがったら見るみたいな。プロジェクトの後半でプロダクトマネージャーのレビューのタイミングがあり、よくちゃぶ台返ししていたらしいんですね。
彼も彼ですごく反省していると言っていたんですけれど、よくちゃぶ台返しがあったと言っていました。なので、このテスト計画書を見て、「この機能ができたのならもうそろそろ見ようかな」みたいな。そんなタイミングが入れやすくなるという話。
現場のプログラマーは「割り込み対応やちゃぶ台返しがよくあったので、プロジェクト後半になると、リスクがだいぶ出てきた」と。「ただ、この生きたドキュメントの中で、リスクが発生したら、すぐにチームみんなに共有しやすくなった」と、そんな話がありました。なので、「早いフィードバックプロセスは本当に大事なことですね」という話をしました。
現在は、お客さまから「最近トラブルがなくなってきましたね」と言ってもらっています。私の中ではすごくうれしい言葉だな、と思っています。
BI開発チーム、アプリ開発チーム、プロダクトマネージャーで起きた変化
おもしろかったのが、BIの開発チームでは、新年になった時に「私は2021年は心を入れ替えて単体テストを完璧な状態にします」と言った実装者がいたことです。
それはなぜかと言うと、やはりいろいろ罪悪感を覚えていたらしくて。単体テストを完璧な状態にすれば、みんなに迷惑をかけなかったんだという意思があって、画面のスクリーンショットをしっかりと残すみたいな。「それはもう単体テストじゃないよね」くらいのレベルのテストを実装者がやっていました。
あと、ユースケースを作ったので、「ユースケースを考えながらテストや開発ができれば、たぶんもっといいものができるね」みたいな話もしてくれました。
これもちょっとうれしかったことなんですけど、「リグレッションテストをけっこういっぱい作って、みんなにやらせたら、これは自動化しないと保たないね」みたいな話があって。やっとこれで、自動化の話ができるなという瞬間でした。
次にアプリの開発チームです。“生きたドキュメント”ということで、テスト計画書を作ったら、これがすごく大事だということがわかった、という声がありました。
あと開発者は、自分のローカル上では単体テストをやっている話で、「この単体テストのプロセスもドキュメントの中で見える化できたらいいな」みたいなことを言っていたので、「ATDDとかBDDとかプラクティスはたくさんあるので、ぜひ一緒に考えていきましょう」みたいな話をしました。
プロダクトマネージャーは「安心で安全な今の品質状態を継続したい」。つまり、「伊藤さんずっといてやってくださいね」みたいな話をしてもらいました（笑）。
Whole-Teamのアプローチは、今私の頭の中ではこんな感じです。お客さまを中心にして、BIチームとアプリチームがありますが、そこには壁はなく、みんな一緒のチームになっているようなイメージ。まだ課題はたくさんあるとは思いますが、解決しやすくなっている雰囲気を感じます。
これからはQAプロモーターとして組織全体にQA推進を
未来です。最初に失敗談をしました。テストの自動化とQA監査ですね。テストの自動化は、あるメンバーからリグレッションテストは絶対自動化したいという話だったので、そういう人を集めれば、自動化は実現するんだろうなという思いでいっぱいです。
QA監査はやめました。今は、QAとテストエンジニアとSETとSREの三角錐の図。その前はQAファンネルといって、漏斗の絵ですね。QAのロールを可視化したようなものを、QAファンネルと言っています。
（スライドを示し）上からフェーズゲートQAとかQAサービス、インプロセスQA、QAコーチ、QAコンサルタント、QAプロモーター。私は最初、QA監査という言葉をやめてQAコーチとして入りますと言っていました。今はなんとなく、QAコンサルタントの位置くらいにいると思っています。将来は、QAプロモーターとして組織全体にQAを推進していくような役割をしたいと思っています。
QAプロモーターはスクラムマスターに似ている
QAはスクラムマスターではないとは思います。思うんですけれども、プラクティスはすごく真似できると思っています。QAプロモーターはその名のごとく、QAをプロモートしていく、組織に対してQAを推進していく人です。
それに対してはティーチングやメンタリング、コーチング、障害物の除去、ファシリテーションという、そういったプラクティスを継続しながら、チームを自己組織化していきたいです。
自己組織化というのは、Whole-Teamで品質にフォーカスした開発をする。そういった活動をずっと観察して、自分の手が離れたら、その時は離れ時なんだなと。すごくスクラムマスターに似ている感じがしています。
ということで、ここまでが私の事例発表でした。ご清聴ありがとうございました。
