この記事はソフトウェアテスト Advent Calendar 2018 – Qiitaの３日めです。昨日はtononoさんによる『間違いだらけの設計レビュー』からの学び – TestonoBlogでした。
チームでソフトウェアテストやQAをするとき、情報のストックと共有はとても大切です。しかし、QAのお仕事をしていると、テストをするのに必要な情報が足りないとか、適切に連絡が来ないとか、情報がたまっていないという不満も（私は）多く耳にします。特に、テスト会社に所属して客先で働く私のようなお仕事だと、人の入れ替わりも多いため、上記のような問題が起こりやすいのでしょう。
こういった問題に対処するため、テストチーム（もしくは開発チームと合同で）Wikiのようなナレッジベース（以下、Wiki形式以外のナレッジベースも含めて、便宜上本記事中ではWikiと呼ぶことにします）を使います。が、このWikiもなかなか曲者。
私は「Wiki作って情報残すの大好き！」なタイプで、どの案件に入ってもほぼ必ずWikiを作っています。しかし、
- 情報のストックに関して個々人の経験値や熱意が異なる
- チームメンバーの役割、人数、組織内での位置づけが都度異なる
など、要するに「情報共有に絶対の正解がない」のでいつも悩みながらやっている状態です。
そんな中でも、「このやり方は部分的にはほぼ鉄板だな」とか「もっとこうすればうまくいくのでは？」というアイディアが自分の中でたまって来ているので、棚卸しの意味も込めてブログ記事にしてみました。
前提事項など
この記事のゴール
- 情報共有の基盤を持っていないテストチームが、Wikiを作って情報をためはじめる
- 現在情報共有で困っているテストチームが、改善のためのヒントを得る
対象読者
- 今現在チームでテストをしているひと
そもそも情報共有する目的は？
テストチームで情報を共有する目的はチームのパフォーマンス低下を小さく抑え、向上するためと考えます。
※パフォーマンス、というと抽象的ですが、ここでは単純な「単位時間あたりのテストケース消化率」のようなものだけを想定しているわけではありません。
例えば経験豊富なメンバーが抜けて新しいメンバーが入ってくるような場合。新人が、慣れたメンバーと同じように効果的なテストを行うためには、テスト対象の理解や、そのチームで使用しているツールの使い方の把握、どんな機能・性質が大切でどんなバグが些細なのかなどの理解などが必要になってきます。つまり、こういった情報を形式知化して共有できれば、メンバーの交代によるパフォーマンスの低下を抑え、迅速に「いままでどおり」のパフォーマンスに復帰することが出来ます。
また、テストチームのメンバーが各自持っている「俺がいつもやっている、効果的にテストを行うコツ」をチーム全体で共有することができれば、全体のパフォーマンス向上に繋がります。
どんな情報を記載すればいいのか
テストチームでWikiに記載すべき事項を、私の過去の経験からざっと整理してみました。
大きく
- チームについて
- プロジェクトについて
- テスト対象のシステム
- テスト
- その他
を共有すべきと考えます。
チームについて
例えば
- 文化・ミッション
- 「われわれはなぜここにいるのか」
- チームが大事にすること、行動指針
- ルールや決まりごと
- 勤怠や就業規則
- 定期的な会議・MTG
- 定期的なタスク
- メンバーのロール、担うべき役割
- 細かなHowTo
- 会議室の取り方
- プリンタの設定方法
などの情報を記載して共有しましょう。
われわれはなぜここにいるのか、はアジャイルの文脈で言う「インセプションデッキ」の中の質問の一つです。チームがその場で何をすべきなのか、これが共有できていないとチームでのお仕事が破綻してしまいます。Wikiに書き、定例MTGで都度確認し、全員暗唱できるレベルで浸透しているのが理想です。
また勤務時間などのチーム内の細かいルールも、お仕事を進める上で必要ですし、新しいメンバーが来るたびに必ず説明する事項なので、Wikiに書いておくと便利です。人が増えるときはチームがバタバタしていて対応できない、という状況はありがちなので「とりあえずココ読んでおいて！」と指示できる状態にしておくと、新メンバーも受け入れる側も楽です。
プロジェクトについて
例えば
- これまでの経緯
- なぜそのプロジェクトが始まったのか
- プロジェクトのゴールは何か
- 用語集
- 各種資料へのリンク
- 各種システムのURL
など。
プロジェクトに関する情報もできる限りWikiにまとめておきましょう。
特に「プロジェクトの経緯」は大事だと考えています。
そもそもそのプロジェクトが発足したのはなぜか、いままでどんな経緯があったのか。これらはテストの計画を立てる上でも必要になってきますし、あとからテストのために必要な情報を得ようを思ったときに、「以前在籍していた＊＊さんに確認しよう」といったたどり方もできます。過去在籍した人に聞かなくともWiki読めばわかる状態にしておくのが一番ですが。
ほかにも、新しくメンバーが入ってきたときに重宝する「用語集」や、Wiki以外のファイルサーバ等に置かれたドキュメントへのリンクもあると便利です。
テスト対象システムについて
例えば
- 細かい仕様
- 過去に発生したバグ
- テストデータの生成や取得の方法
- システムの使い方
など。
多くは別途ドキュメント化されているかと思いますが、「過去にこんなバグを見逃して困った」「仕様書には書かれていないがこんな動きをする」など、チーム内でみんな踏む罠になっているような情報はWikiに残しておきましょう。これらの情報はチーム内の古株が大体覚えていたりするのですが、いろんなメンバーから都度質問されていると古株の作業がストップしてしまいます。「Wiki見て」で済むようにしておきたいところです。
テストについて
- 開発プロセスにおける各種テストの位置づけ
- テストの事前準備手順
- テスト実行後のフロー
- テスト用の各種ツールの使い方
など。
用語集とも若干重複しますが、「このチームにおける”＊＊テスト”の意味」は全体像とともに明示しておかないといけないところです。
また、テストの準備や実行、テストを行うためのツールの使い方など、チームの全員が知っておくべき事項はWikiにまとめておきましょう。（Excelなどで書いておいても良いですが、Wikiから辿れるようにしておきたいところ）
その他の情報
- 職場周辺ランチ情報
- 会議・MTGの議事録
- メンバー日報
など。
ランチ情報などを載せるようにすると、Wiki自体の閲覧・編集のカジュアル感が増して、より活発にWikiが育つ効果が期待できます。また、会議などの議事録やメンバーの日報もWikiの一部としてまとめておくことで、メンバー皆がWikiを読み書きする機会を増やすことができます。
参考：JSTQBのシラバスでも情報共有ツールについて言及されている
実はJSTQBのFoundationLevelのシラバス「アジャイルテスト担当者」※PDFの3.4.2で、情報共有ツールについての言及があります。
チームは Wiki を使用して、次のようなプロジェクトのさまざまな側面に関するオンラインナレッジベースを構築して共有できる。
・プロダクトのフィーチャ図、フィーチャについての討論、プロトタイプの図表、ホワイトボードでの討論の
写真およびその他の情報
・チームのメンバにより有益であることが判明した、開発およびテスト用のツールや技法
・プロダクトステータスに関するメトリクス、チャートおよびダッシュボード。Wiki をビルドサーバやタスクマ
ネジメントシステムなどのその他のツールと統合すると、このツールはプロダクトステータスを自動的に更新できるので、これらの情報は特に有用となる
・チームメンバ間の会話。インスタントメッセージや電子メールに類似しているが、チーム内の全員で共有
される方法で行う
Wikiでの情報共有のコツ
ここまで、なぜ情報共有をすべきなのかと、Wikiに何を書けばいいのかを説明してきました。
Wikiでの情報共有がスムーズにまわるようにするには、チームの全員が「読み書きする意味がある」と感じている状態をつくることが重要です。情報共有のコツは、いかにみんなに主体的に参加してもらうか、と言い換えることができるかもしれません。
以下のような点を意識していただくと、より意味あるWiki運用ができると考えています。
「全員が書き編集するもの」と周知し雰囲気づくりをする
Wikiなどを運用していると、メンバーの中には「特定の誰かがかくもの」という意識をもつ人がいます。これは、その人がヘンにスレている場合だけでなく、たまたま過去のプロジェクトで記入権限が一部の人にしかなかったなどでそれが当たり前になってしまっているパターンもあります。
そのため、
- Wikiはみんなが書くもの
- 他人が書いたものを編集してよい
ということをみんなが認知するまで周知する必要があります。
また、誰もが書いていいということが理解できても、ハードルが高く感じてなかなか書けない、という人が出てきます。
こうしたハードルを下げるために、たとえば
- 未完成でも公開していい、情報は育てるもの、と伝える
- 誰かが書いたら「いいね！」「助かるよ！」と積極的に伝える
などの工夫をすると、より全員が気軽に書ける雰囲気が出てきて良いですね。
編集長を決める
誰もがWikiに情報を書いて共有するようになると、こんどはWikiの中が散らかってきます。
そんな散らかった状態を整理する役割として、「編集長」を任命してその人主導で普段から整理していくのがオススメです。
注意したいのは、編集長は「この情報はいらない」とか「もっとうまくかけ」といったことを言ってはいけません。権力者としての存在ではなく、みんなが自由に書いていった結果少し散らかってしまった情報や重複している情報などを整理整頓して、見やすくするための調整役です。
あえて「編集長」という呼び名にしたのは、「Wiki係」などの言い方にすると「雑務やらされ感」が出てしまうから。ナレッジ共有に関して主導するリーダーとしてやっていくぞ！と当人が思えるのであれば、好きな呼び方でかまいません。
情報を残すことを遊びやサボりだと思わないようにする
Wikiを積極的に更新していると、「お前ヒマなの？」と思われたり言われたりすることが、残念ながらあります。
同じ内容をExcel方眼紙でドキュメンテーションしていると言われないのに、Wikiだと言われたりするのが謎・・・
もちろん、目の前に緊急のタスクがあるのにそれを放置している、などであれば問題ですが、そうでない場合は「後々のために情報を残しておくこと」「既に存在する情報を最新にアップデートしておくこと」を積極的に行っている人をサボり認定しない雰囲気を作ってください。
まとめ
テストチームにおけるWiki等のナレッジベースでの情報共有のコツ、一言で言うなら、全員が積極的に読み書きするような動機付けと雰囲気づくりをしようです。
本記事ではそのための具体的な考え方や、私が過去の経験から考えた「こうすると良いでしょう」を書きました。
どこかお役にたつところがあれば嬉しいです。