KPTで振り返った後のTryには、周りの理解と協力が不可欠!

こんにちは。

他のQuesブログを書いている方々は、【テストを段取る!】や【テストにまつわるエトセトラ】など、いい感じのタイトルが付いていることに対し
ちょっとうらやましいと感じている HumanCrest の 津久井 ですw

私は今回も”振り返り”のお話です(タイトルもいつも通りな感じでいきますw)。
前回はKPT法について軽く触れて、あとは実際にどうするかなど、”振り返りをする”ことについて
フォーカスしてお話しました。

今回は”振り返り”をした後のお話を、私なりの経験の中から良さそうな昔話を交えながら、お話したいと思います。

※もしよろしければ前回の記事も合わせてお読みください
“手軽、簡単、安い” KPT法で振り返りをしよう

■はじめに
物事を良くしていこうという活動は、悪くしていこうという活動に比べて比較にならないくらい大変で時間もかかります。
効果が感じられない活動はすぐにやめて、新たなことを試したくなりますが、
“なぜ”効果が出ないのかがある程度考察出来るまでは続けるべきであると僕は考えます。

また、立ち向かう問題が大きければ大きいほど、一人では解決できないものです。
どんなに素晴らしい”Try”すべきことを掲げても、一緒に仕事をする仲間の理解と協力が無ければ、
何か成し遂げるのは難しいと思います。

そんなことを実感できた話を一つさせて頂きます。

■過去に出たProblemとTry
とある組込製品のProjectで、PLをしていた時代の話です。

テストを実施する際、どんな些細な事でもいいので、TestCaseにメモを残そう!!
っということをメンバー全員でTryしたことがあります。

背景としては、Problemで上がったこととして、TestCaseは実施する人によって、
実施完了までの工数に大きな違いがあるというものでした。
経験者と新人ではもちろん違うのはわかるのですが、どうやらそういった事だけでは無いようです。

実際に実施した事のあるメンバーにも聞いて回りましたが、”これだ!!”
っと思えるような問題点は見当たらず
・見積もりの仕方の問題なのか?
・進捗の出し方の問題なのか?
・TestCaseの問題なのか?
・実施側の問題なのか?
どれもこれも問題点としては考えられそうなのですが、確信をついたものはありませんでした。
そこで、以下のことをTryに掲げることとなったわけです。

テストを実施する際、どんな些細な事でもいいので、TestCaseにメモを残そう!!

今まではTestCaseを後から見返しても、テストの判定結果以外の情報があまり残っておらず、
実際に実施している時の些細な問題や、調べたことなどの情報をのこせていなかったのです。

まずは残すべき情報を整理し、履歴を残すことから始めることで現状を今よりも理解し、
改善したい問題に対する具体的なアクションを見出せるようになろうというものでした。

■はやくもぶつかる壁
Tryに掲げたのはいいのですが、なかなか思ったとおりに事は運びません。

なぜなら”TestCaseにメモを残す”という文化がそもそも無いからです。

Bugを検出すれば再現手順の確認をし、仕様に疑問があれば問い合わせを行う。
更に、消化率を意識して進捗も気にしなければならない。

そうです、テストを実際に実施しているメンバーは全員忙しいのです。
意識的にメモを”TestCase”に残そうとしないといけないのです。

全員が同じ意識になり、文化が定着するのには時間が必要でした。

■やっとめぐってきたチャンス
Tryに掲げてから2つのProjectが終わった頃だったと思います(ちょっと記憶が曖昧ですみません)。
※1つのProjectで大体3ヶ月くらいでしたので、約半年経過ってところですね。

全員がTryの内容を理解し、根気よく続けてくれたおかげでTestCaseにいろいろな情報が残るようになり、
分析に役立ちそうなネタもそろってきていました。
メンバーからも、情報を残すようにして良かったというような声も上がってくるようになり、
“成果が何も出ていないわけではない”ということは実感出来ました。

Projectが終わり、次のProjectまで少し時間が空いた時に、今までメンバーが溜めてくれたTestCaseの情報を
じっくりと見直す機会を作り、一つ一つを見直しました。

TestCaseは各機能ごとに作成されており、前提条件/手順/期待結果も記載されていて、項目の抜け/漏れもなさそう。
機能ごとに確認すると、一つ一つでは特に問題は見当たりませんでした。
しかし、機能ごとのTestCaseを見比べてみると違いがあることに気付けました。

・テスト実施時、一定のリズムでテスト結果を入力できるような作りになっていない
・テストを実施する人のことを考えた構成になっていない

上記の問題がある箇所に関してはTestCaseのメモが多く存在しており、もともとProblemに掲げていた問題
“TestCaseによっては実施する人によって、実施完了までの工数に大きな違いがある”
に対しての問題点であるのではないかという仮説も立てることが出来ました。

上記のことから、次のアクションの内容が明確になり、新たなTryを生み出すことが出来たのです。
そして、それらはTestCaseに実施のメモやちょっとした情報を、メンバー全員が残し続けてくれたおかげでした。
※当時一緒に同じ経験を積むことが出来た、個性豊かなチームのメンバーに心から感謝しています。

■最後に
何かに”Try”するには、周りの理解と協力は不可欠です。

一人ががんばってもなかなか難しいことがありますし、時間もかかりすぎてしまいます。

振り返った内容は、必ず関わったメンバー全員に共有し、何かを始めるのであればしっかりと理解してもらう。
そして、理解したうえで協力をしてもらう(ここ大事!!)。

チーム全員が同じ意識で”Try”することが出来れば、結論が出るまでの時間も短縮されますし、
何より、予想を上回る結果が生み出されるはずです。

”振り返り”は終わりではなく、むしろ始まりですので、僕は毎回ワクワクさせられています。
これからも、更に良い経験を積めるよう、更に面白い事例を生み出せるよう、今よりも物事が良くなっていくように
“Try”し続けていきたいとも思います。

また、機会があれば別のお話をしたいと思いますので、その時はまたよろしくお願いします。

このエントリーをはてなブックマークに追加