自分戦略研究所 | 自分戦略研究室 | キャリア実現研究室 | スキル創造研究室 | コミュニティ活動支援室 | エンジニアライフ | ITトレメ | 転職サーチ | 派遣Plus |

ソフトウェアテストワークショップ「WACATE 2011 夏」レポート

誰がためにレポートを書く? バグレポートを改善せよ

第3バイオリン(@IT自分戦略研究所エンジニアライフ コラムニスト)
2011/8/3

前のページ1 2

ベテランの役割は見守ること、任せること

img
ワークショップの様子

 リーダーやサブリーダーは、WACATEの主役たる若手に任せます。ベテランは自らの持つ知識や経験を伝えながら若手をサポートする、しかし必要以上に口や手を出さない、というポジションをキープします。私はまだベテランという年齢ではないので、これは想像なのですが、おそらくベテランの皆さんはたびたび、もどかしい気持ちになるのではと思います。

 「だが、そこを抑えて見守る。任せることで若いリーダーが2日間で大きく成長する姿を間近で見ることができる。それがいい」と、あるベテランの参加者が言っていました。彼らのような「若手の心を持つベテラン」のお話には、本当に勇気付けられます。ロールモデルとなる先輩方に出会えるのも、WACATEの魅力です。

チーム全員で考えた「良いインシデントレポートとは?」

エンジニアライフ
コラムニスト募集中!
あなたも@ITでコラムを書いてみないか

自分のスキル・キャリアの棚卸し、勉強会のレポート、 プロとしてのアドバイス……書くことは無限にある!

コードもコラムも書けるエンジニアになりたい挑戦者からの応募、絶賛受付中

 ワークはいくつかのステップから構成され、ステップごとにタスクが振り分けられています。1日目、2日目それぞれの終了時刻は決まっていますが、各ステップの時間配分はグループで決めます。あらかじめスケジュールを立ててタスクを消化していく、ステップごとに時間の予実を確認して、場合によってはスケジュールを見直していく。その辺りはまさにプロジェクトそのものです。

img
スケジュール管理は大事

 バグが埋め込まれたプログラムを動かして確認する時間は、わずか10分間。その貴重な時間を最大限に活用するのも、プロジェクトマネジメントの腕の見せどころです。

 グループのメンバーにはテストエンジニアもいれば開発者もいます。それぞれの立場から、読みやすく、内容がパッと理解しやすいインシデントレポートの在り方を考えて「この項目は削除しよう」「この書き方はこう変えた方が分かりやすい」と全員で意見を出し合って、ああでもないこうでもないと議論を繰り返して、インシデントレポートの改善案を資料にまとめていきます。

img
ふせん紙を使ってアイデアを整理

 そして、いよいよ成果発表。

 グループごとにインシデントレポートの改善案や、ワークで工夫したポイントなどを発表します。グループによって提案内容も違えば、プレゼンテーションのやり方も異なります。真面目に発表するグループ、ところどころにネタを挟むグループ、各グループの持ち味がいかんなく発揮される成果発表は楽しくもあり、「こういう考え方、見せ方もあるんだ」と勉強になる場でもあります。

レポートが書くこと自体が目的になっていないかという指摘

 私のグループは、ワークショップのときに、モーニングセッションの講師である日本IBMの細川宣啓さんから、以下の指摘を受けました。

 「インシデントレポートは書くこと自体が目的ではない。読む人に何か訴えたい、伝えたいことがあるから書くもので、さらに、読んだ人を動かす、何かアクションを起こしてもらうために書くものなんだ」

 私のグループでは書き方をどうするか、については活発に議論していましたが、インシデントレポートは誰が読むのか、それを読む人が読んだ後で何をするのかについてはうまく考えられていませんでした。

 こういうワークショップでありがちなのですが、カイゼンに夢中になっているうちに、いつのまにかカイゼン自体が目的になってしまって「誰のために」「何のために」カイゼンするのかという議論が置き去りになってしまったのです。

 そういうわけで、細川さんの言葉はかなりズキッときました。

このレポートは誰のために書くものか?

 普段書いているインシデントレポートは何のために、誰のために書くものなのか。今の自分の書き方には本当に問題がないのか。

 これが、今回のWACATE参加で最も考えたことでした。 WACATEに参加した後は、インシデントレポートを書く際に「開発チームにとって読みやすく、インシデントの再現確認が間違いなく実施できる内容になっているかどうか」を改めて考えるようになりました。

 普段の業務でインシデントが発生した時に、私はよく検証のためにインシデント発生時とは異なるデータを使ったり、手順の一部を変えたりして再度、確認を行うことがあります。その時の結果も併せてレポートに書くのですが、その際にインシデントと同じ現象が発生する/しない条件を きちんと整理できているかどうか、ただ確認した順番に並べるのではなく、データ別、手順別にまとまっているかどうかを注意するようになりました。

 「初歩的なことなのに今までできてなかったのかい!」とお叱りを受けそうですが、実際できていなかったのです。今回、実際にワークショップで手と頭を動かすことで、体感した部分はかなり大きいです。

◇◇◇

 今回から、山崎崇さんが新しく実行委員長に就任します。山崎さんが、これからのWACATEについて、思いを語ってくれました。

 「もともとWACATEは発起人である池田暁さんの思いによって作られ、ここまで育ってきました。今回、池田さんより私にタスキが渡されたわけですが、根付いたWACATEという『場』をより良いものにし、次の世代へタスキをつなぎたいと思います」

 これからも、WACATEから目が離せません。

◎WACATE2011夏のコラムまとめ

◎過去のWACATEレポートまとめ

 

前のページ1 2


自分戦略研究所、フォーラム化のお知らせ

@IT自分戦略研究所は2014年2月、@ITのフォーラムになりました。

現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。

これからも、@IT自分戦略研究所をよろしくお願いいたします。