こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
昨今、プロダクトの品質がビジネスに与える大きなインパクトについて語られる場面が多くなっています。そんな中、品質を測る具体的な取り組み、品質そのものについての情報は溢れる一方で、「その大切さを組織に広め、品質文化を醸成する方法」については参考にできる書籍がほとんどなく、経験と勘を頼りに手探りに進めるしかないのが現状です。
Findyでも「品質とは何か」「品質をいかに測るか」に関連するイベントは過去に実施し、多くの皆さまにご参加いただきましたが、その後のアンケートで「文化醸成のためにやったこと」についての話を聞きたいとのお声も多くいただいていました。 そこで、
本イベントでは、書籍『LEADING QUALITY』の内容を踏まえ、訳者である河原田 政典(@mkwrd)さんと、末永 昌也(@sue738)さん、風間 裕也(@nihonbuson)さんに、ご知見や実務経験をお話しいただき、ご参加者の皆さんが今後の取り組みに活かせる学びの場となることを目指していきます。
会の様子
イントロダクション：書籍『LEADING QUALITY』について
最初にMarkさんからさくっとLEADING QUALITYの紹介がありました。
本の読みやすさには原著も翻訳書もこだわっているということで、まとまりを重視しているということです。SNSでも絶賛の声が多くあるということで、中には全人類に推せるというコメントもあり、嬉しいとのことでした。
セクション/章ごとにざっくりと紹介もあり、本書のユニークネスとして品質ナラティブが挙げられるという話やビル・ゲイツの発言がXでバズっているという話などがありました。
また、この領域に馴染みがない人は、訳者まえがき→第1章→第2章→第3章→第8章→第10章で読んでみるとよいということです。
本書の価値としては、
- ソフトウェア品質はビジネスの成否を左右する経営課題であり、テックとビジネスの垣根を超えて取り組むべきと喝破している
- 品質の大切さをいかに組織に広め、品質文化を醸成するかを2年半にわたり集めた事例やインタビューをもとに解説している
- 技術書というよりも技術領域に光を当てたビジネス書
が挙げられ、
- 翻訳くさくない読みやすい文章
- かゆいことに手が届く
- さらなる調査/研究に役立つ豊富な参考資料
に翻訳としてはこだわったそうです
パネルディスカッション
次に、品質文化醸成とチームと会社の成長指標というテーマに関してパネルディスカッションがありました。以下、内容を箇条書きかつ常体で記載していきます
品質文化醸成
- 組織に品質への課題感・危機感があるのか？がそもそもあるのかは大切だと思っている。昨今はソフトウェア開発の速度は下がったため、品質の担保にボトルネックが移ったような印象がある
- 品質は大事ではないという人はいないのでどのように扱うかを重視するとよい
- 現場から乖離した「偉い人」のリードには注意したい。特に強制感があるやり方*1には注意したい。ボトムアップ・アプローチも重視していきたい(短期的にはトップダウンが有効だが中長期的には逆効果になる印象がある)
- 忖度なく言いづらいことを言えることが大切だと思っている。何か指摘をするというよりも、教えてほしいというスタンスで臨むことが多い(「コードのこと深くはわかっていないんですけど...」「入ったばかりで詳しくないんですけど...」といった枕詞をつけるなど)
- プロダクトチーム全体で顧客に徹底的に向き合うことが重要。顧客に一番近い現場から品質に向き合うことが重要だと思っている
- QAチームが開発チームと分かれずに開発することがいいのではないかと思っている
チームと会社の成長指標*2
- 自分たちの組織がどういう価値観を持って何を目指している企業なのかを外さないことが需要。ただ、エンジニアにはそういったところに興味がない人も多いのは難しい
- 組織によって品質とはぜんぜん違うと思うので、自分たちにとっての品質を問い続けるのが重要(GQMのGoalから考えることが重要)
- QAチームが会社の成長指標にどれだけ貢献しているか？は(QAチームという枠にこだわる前提だと)プロダクトチームと同じ指標で話すのは難しいと思う
- すでに知られている狩野モデルや品質特性やアジャイルテストの4象限などを穴埋め的に使うのはアンチパターン
- 具体的な取り組みとして、NPSを品質に対して取るようにしている
Q&A
最後にQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。
QAエンジニアが開発の下請けにならないための方法は？リードを取るためにはどうすればいいか？
- QAチームが開発チームのメンバーの一人として振る舞うようにしている。そのため要件定義などの段階からQAチームが入り、枠にとらわれず動くようにする
- そもそもリードを取ろうと思うことはない。リードを取ろうと思うとトップダウン的なアプローチになってしまうため、スクラムチームとして何をやっているQAなのかを示すことが重要だと思う
- 最後に検証をするような仕組みを作ると、検証が終わらないと見せられないみたいな動きになりがちなので注意したい
CTOやQAエンジニア以外をどのように仲間にするか難しい
- 一つのチームなので、開発チームメンバーをまず仲間にする
- 今はどんなゴールに向かっているのか？など途中経過の報告を含めていくことで経営層などを巻き込んでいく
QAチームもおらず必要最低限のUnitテストを書くような状態だがどのようなところからスタートするのがよいか？
- なんのためにUnitテストを書いているのか？の言語からしてみる
- そもそも品質とはなにか？から考えてみる
ビジネスや会社の成長にQAはどのように貢献できるのか？
- QAチームのビジョンを会社のビジョンやビジネスとしてやりたいことと結びつけ、自分たちのプロダクトの社会的意義を理解した上で取り組みやゴールを考える
- QAチームって最終的にいるんだっけ？というところからスタートし、今QAチームがいないと何が困るかを考えてみる。その困る部分がQAチームの目標や取り組むことになると思っている
品質を作り込む具体的な行動は何があるか？
- よくいう話ならShift Left Testing。更に具体的に言うならリファインメントに参加して、テストのインプット材料にしながら自分たちが思っていることをそこで言ってみる(「これどういうテストすればいいのかいまいちわかってないんですけど...」など)
- スクラムイベントに参加してその中で価値を出す
- Question Askerとしてふるまう
会全体を通した感想
書籍がコンパクトということもあり、書籍では補いきれない部分もあったと思いますが、そこから具体的な課題に踏み込んで話を聞くことができたので非常に面白かったです。
特に、イベントの途中でも出ていましたがそもそも論の話が多かったのがよかったなあと思いました。
