Dirty Testerの私がQAエンジニアとしてふりかえりにこだわる理由
はじめに
この記事は「ふりかえりAdvent Calendar 2024」のエントリ記事です。
本記事では「ふりかえり」についてDirty Tester、バキバキQAとしての思いを記載します。
QAエンジニアとして、「ふりかえり」の技術や知見を持つことは当たり前だと思っていたのですが、一般的にそうではないと知りました。
また、「ふりかえり」というマニアックな技術領域があることも知られていない現状があるようです。
ですので、ここではふりかえりについて、QAエンジニアとして私がどのような熱い思いを持っているかを述べて、ふりかえりという習慣およびふりかえり技術の一般化に寄与しようと考えています。
ふりかえりが品質保証の技術の1つとして一般的に取り上げられ、うまく活用する事例が増えたらいいと考えています。
ふりかえりとは
振り返りではなくふりかえり
ふりかえりとはRetrospectiveです。
「振り返り」ではなく、ひらがなの「ふりかえり」なのは意図があります。これらは有識者によってさまざまな書籍や文献で紹介されています。
当時は、「KPT」ではなく、「回顧」と呼んでいたのですが、同僚から、「回顧というのは固いな、ふりかえりがいいよ。一般動詞の『振り返り』とは、区別してプロジェクトとして振り返るのは「ふりかえり」という表現にしよう」と言うアドバイスを受けて、今では「ふりかえり」もしくは「ふりかえり会」と呼ぶようにしています。
「振り返り」という言葉からは「後ろを振り向く」と言う動作を連想する人もいます。また、「振り返り」が「反省会」のような活動として認知され、定着してしまっている現場も多いのです。このイメージを払拭したい、という思いもあり、やわらかい印象を与えてくれるひらがなの表記を使っています。(略)ふりかえりは誰でもできる活動と言うことを知っていただきたいという思いから、「ふりかえり」と表記するようにしています。
「アジャイルなチームをつくるふりかえりガイドブックより」
ふりかえりと振り返りの違いについては、日本的品質管理との兼ね合いも踏まえて、私も自分なりの見解を持っています。
こちらについてはいつか別の記事で紹介したいと思っています。
ふりかえりとは
ふりかえりとは振り返りではないです。
ですので、今となっては「ふりかえり」というさまざまな拡大解釈をされた謎イベントになっていると思っています。これを私は良いことだと捉えています。
ふりかえりはさまざまな目的を持って行われ、「ふりかえり手法」と呼ばれる技術は500を超えていると言われます。
(参考:https://retrospective.connpass.com/event/321762/）
ふりかえりは主に以下の目的があるように思えます。
- プロジェクトや普段の仕事から学んで、次に活かす
- チームビルディング
- 目の前の問題に向き合う
- その他
ふりかえりの目的はさまざまであり、さまざまな文献で紹介されています。
私のふりかえりへのスタンスは「ふりかえりとは目的を持った活動である必要はなく習慣や文化として取り入れ、自由な文脈で謎イベントとして活用すればいい」です
私が考えるふりかえりの存在意義
"仕事がうまくできているか"を考える機会を強制的に与える
私がふりかえりを大事にする理由がこれです。
ふりかえりに「立ち止まって考える」という性質を持っています。
ふりかえりをしている間はスプリントバックログを片付けたり、テスト実行したり、コードを書くということはできません。
ただ、「自分やチームは今どうなんだろう」と考える機会を作ることができます。
私は強制的かつ定期的にこれらの機会を作ることを好みます。
意識して立ち止まって、意識して考えるようにするためです。
ゆとりの法則にも通じると考えます。
一方、「強制的な習慣にすると目的意識を見失ってふりかえりが形骸化する」という懸念もあります。
それは正しいです。
なので、ふりかえりを信じるふりかえりマニアの人々は、ファシリテーターであってもなくても、意味あるふりかえりを行えるように意識して行動することが求められます。
目的があるからふりかえりをするのではないのです。
ふりかえりという習慣に目的を載せるのです。
また、私の意見として、QAという専門性には「強い目的意識を持っている」があると考えています。
QAであるからこそ、ふりかえりに目的を載せ、さらなる飛躍に繋げる責務があるのです。
さまざまなふりかえり手法を使おう
ふりかえりはKPTだけだと思っている人がいます。
それでもいいと思います。
ただ、私はそのような立場を取りません。ふりかえりの時間を有効に活用するために、自由な技法や自由なテーマを取り扱い、「強制的に作られた考える機会」をより効果的に扱うことが重要だと考えます。
なので、KPTだけではなく、さまざまなふりかえり手法を用いても良いと考えます。
ふりかえり手法だけでなく、チームビルディングのために「ドラッカーのエクササイズ」や「インセプションデッキ」を使ってもいいでしょう。
ふりかえりは自由なのです。
品質とふりかえり
ソフトウェア開発におけるプロセス品質
ソフトウェア開発において、内発的動機やクリエイティブな思想はとても重要だと言われています。
「とにかく心を殺して辛い時間を8時間過ごせばいい」という性質をもっていません。
ソフトウェア開発は知的な活動です。そのため、個人の創造性を発揮しながら仕事をすることが求められます。
こういった内容を私は「プロセス品質」の1つだと捉えています。
ISO9126の品質モデルでは、プロセス品質が利用時の品質に影響されることが述べられています。
私はこの立場を取ります。
品質の高いソフトウェアを作るためには、プロセス品質が必要不可欠なのです。
チームのプロセス品質を改善するふりかえり
ふりかえり手法は、基本的に「コミュニケーションのあり方」をルール化したものだと捉えています。
「立ち止まって考える」を促し、特定のルールの中で意見交換をするフレームを提供しています。
たとえばKPTでは、「良かったこと」「問題」「次挑戦すること」といった話題の方向性を設定して、「今のこの人はどんな話をしているんだろう」という理解を促し、その人の考えや問題意識を浮き彫りにすることを助けます。
これらはチームのコミュニケーションを促進して、意図的に立ち止まり、考えを深めたり、関係性を変化させる効果を持ちます。
悪い場合に作用する場合もありますが、まじめにやっていれば基本的には良い方に作用すると思います。
「チームの関係性」はプロセス品質に寄与して、品質の高いソフトウェアを作ることに役にたつと考えます。
チームの良かったところを習慣にする
ふりかえりは問題探しと思っている人は多いです。それは間違ってはいません。
ただ、私は問題を改善するだけでなく、「良かったことを習慣化する」というところに重きを置きたいです。
ソフトウェア開発では個々の工夫や創造性を発揮しながら仕事を行います。
ソフトウェア開発は、実は、常に一貫したプロセスやルールによって作られるのではなく、ふとした工夫や気遣いによって良いプラクティスが生まれたりします。
そのため、「良いこと探し」を行なって、「意識して習慣化を目指す」ことには意味があると考えます。
「良かったところを習慣にする」は問題を解決するよりもイージーです。
なぜなら1度やっているからです。
チームの問題を認識する
良いところ探しも良いですが、もちろん問題を明らかにすることも大切です。
ふりかえりでは、その一人だけで認識していた問題をみんなで見える化して、それに共感するという行動に移りやすいです。
問題は認識するだけで価値がありますが、「問題対我々」「チームで問題に共感する」というフェーズを挟むことで、よりチームとしての一体感を生むと考えます。
これらはチームへの愛着を生み、チームビルディングの1つとして役にたつと考えます。
チームの問題を共に乗り越えるチームとして問題を認識して、共に乗り越えることは超いいプラクティスです。
一人では乗り越えられないような難しい問題をチームで乗り越えることができるのは、解決の効果も高いんじゃないでしょうか。
「チームとして乗り越えました」という事実が残ることも良いです。
これらはチームとしての練度が高まったことの証明になります。
その状況やメンバーにあったふりかえり手法が存在する
ふりかえり技法はテーマやコミュニケーションのやり方についてルールを提供します。
これらは声の大きな人や自由な人にとっては不自由に感じるかもしれませんが、「皆が公平に、主体的に考える」という点では効果的だと考えます。
テーマに一定の縛りを与えることで、新しい発想や思いもよらなかったアイデアが思いつくことがあります。
みんなのリスク感を知りたい場合は、「像、嘔吐、死んだ魚」が良いでしょう。
メンバーの思ってることを知りたい場合は、「Lean Coffee」が良いでしょう。
価値観を知りたい場合は「ありたい姿」などを考えても良いともいます。
ふりかえり手法は500個あるらしいですが、シーンやメンバーの特性に合わせて、自由にルールを決めて、自由にふりかえりをしたら良いのです。
「KPTだけうまく回してたらいい」という考えは否定しません。
しかし、私は「別のふりかえり手法を使えばもっと別の形で向き合えるかもしれない」という改善の心は常に持ち続けています。
さまざまな視点で物事を見るふりかえり手法はさまざまな切り取り方でテーマを与えてくれます。
過去、現在、未来問題、課題、対策事実、感情、学びなどですね。
これらのフレームは考えの幅を与えてくれて、アイデアや気づきを持つための手助けをしてくれます。
おわりに：QAがなぜふりかえりを学ぶのか
ふりかえりはプロセス品質を上げるためにもっとも手軽な方法の1つだと考えます。
「決められた方法を提供して、決められた方法を守ってるかを検査することがQAだよ」という主張もあります。
それは否定しません。
しかし、ソフトウェア開発において、私はあくまでチームの中の非定型的なコラボレーションの産物として、高品質なソフトウェアが生まれると信じています。
それらを促進する手段として、より効果的なふりかえりの時間にするため、私はふりかえりを学ぶのです。
ふりかえりに対する私の思いを記載してみました。これが誰かの手助けになれば幸いです。
もしこれをきっかけにふりかえりについて学びたいと思ったQAがいれば、ぜひさまざまな書籍から学んでみてください。
Discussion