【読書メモ】マインドマップから始めるソフトウェアテスト

読みました。

マインドマップから始めるソフトウェアテスト

読もうと思った経緯

社内で割りとマインドマップとソフトウェアテストの話を聞くことが多く、最低限の知識を身につけておこうかなと思ったので。マインドマップとワニが出会ったのは2008年ごろと思うのですが、しばらく嫌いだったんですよ。絵を描くことが目的の１つと思っていたから。

マインドマップ

合計66のノード（気づき）がありました。マインドマップに落としていく中でちゃんと読めていないところが見えたり、疑問点をそのままにしなかったりとなんとなく読んでいるよりは大分スッキリ読めた印象。「ローリングウェーブの計画」とか単純にまったく知らない知識にも出会えました。

この本で得たもの

新しいものを使うことに抵抗はない人間なのですが、ソフトウェアテストにマインドマップを使うことに抵抗がありました。正直。それはワニの中でマインドマップというものが「知識として知っているが、業務として使うもの（正式なアウトプット）としては、認められにくいような風潮」、「周り(目の見える範囲)にマインドマップを使っている人がいない」、「個人的なアイデア出しは良いとして、定量的に効率アップを証明しにくい」、「業務中に絵を描くのは抵抗がある」といったところでしょうか。直接的に怒られることはないですが、認められにくい環境ではあったと思います。最近はそのマインドは大分薄れてきましたが。話長くなりそうなので、この話は別途。

マインドマップで新しい"気づき"を発見する

　ベテランのテスト技術者が暗黙的に出来ているテスト分析と同等のことを行う為にマインドマップが有効と書いています。テスト分析と書くと意味が広いのですが、仕様書からのコピペでテストケースに落とし込みをすると、テストケースの質が仕様書記述に左右される。ベテランのテスト技術者はそこを勘と経験で補って、テストケースを作成できるが、初心者には簡単には出来ない。簡単に教えれるものではないので、マインドマップを描くことで自然と行えるようにするものとのこと。

マインドマップは新しい技術ではないので、そこで嫌悪感を持たない

　今やマインドマップの名前を聞くことも珍しくはなくなりましたが、そもそもマインドマップは歴史の浅い技術ではないそうです。1960年代にトニー・ブザンによって考案されたもので、50年近い歴史があります。会社でもしマインドマップを誰かに推奨する時はこの情報も与えると良いかもしれませんね。良くわからない横文字の時点で嫌悪感を持つ人もいるので。

きれいなマインドマップが目的ではないので、絵や色、書き直しにとらわれない（そんなことを考えている暇があったら、1枚でも多く書く) 

 　手書きで描くと余計にですが、書き直しが難しい以上、心理的にきれいな、完全なマインドマップを描かねば・・という心理に陥りがち。本書でも要所要所でその心理的プレッシャーを和らげる解説が豊富です。例えば、メイン・ブランチ（中央のテーマから一番最初に延びるブランチ）を描くのに抵抗があれば、先にメイン・ブランチの候補リストを別紙に書き出して眺めてみるとか。

　初学者にとって、合っている、合っていないを自分で判断することが難しいものや、マインドマップのような答えが不定なものは、"正誤の確認作業が出来ない"→"不安になる"→「うーん、よくわからん。使うのをやめよう・・」となりがち。そこまでの配慮、解説が出来ているのはニクい本ですね。

　各テストプロセスに対してのマインドマップ導入例もメイン・ブランチからステップバイステップで解説されているので、それを参考にまずは同じ題材でマインドマップを描いてみる。自分の業務に置き換えてどこから導入出来そうか考えてみるのも面白そうです。知識を知っていることと使えることはまた別ですからね。

 感想

　ソフトウェアテストとマインドマップについても紹介は念入りで、50/216Pも割いてある。ソフトウェアテストの意義の解説や例もわかりやすく、知識がまだまだの人が読んでもそこまで読むことに苦労しないのかなという印象でした。網羅的なテストプロセスの理解や、各プロセスでのマインドマップの使いどころ（と勘所）が理解出来て良い。10年以上前の技術本ですが、まだ中古では手に入るものです。