@kitanosirokumaさんのSaPID-TP(試作中)のおはなし

きたのしろくま @kitanosirokuma

昨日突然支援依頼があり、テスト業務を対象としたSaPID-TP(試作中)のトライアルを実施。TMMIや29119を参考に構造分析した結果、実務者が納得する現状把握と対策が導出できた〜♩

きたのしろくま @kitanosirokuma

もすこし磨けば使えそう(^o^)

弦音 @tulune

@kitanosirokuma すごい！見たいですー。

きたのしろくま @kitanosirokuma

@tulune 手法は見た目簡単になりそうですが、使いこなせる人とそうでない人に二分されると思います。(^o^)

弦音 @tulune

@kitanosirokuma 秘伝のたれｗ

きたのしろくま @kitanosirokuma

@tulune FLレベルくらいまでの実務者が主な対象になりそうです。

弦音 @tulune

@kitanosirokuma FLレベルなら十分では？

弦音 @tulune

@kitanosirokuma あ。私ダメだ（爆

きたのしろくま @kitanosirokuma

@tulune こちらこそ(爆ww

きたのしろくま @kitanosirokuma

トライアルの進め方を書いておきますね。 対象はテストを専門で請け負っているチームです。現状から一歩改善したいものの、何をすればよいかいまいちわからない。管理者さんは「これかな？」と思うところはあるものの、チームメンバーの考えはバラバラ、という状態です。

きたのしろくま @kitanosirokuma

何かよい方法はないかと相談を受けました。では、ということで、チームメンバーのうち、リーダ格の４名と管理者さんに１時間だけ集まっていただき、こちらからいろいろと質問をして状況を把握することにしました。

きたのしろくま @kitanosirokuma

以前から（私は）彼らが普段どのように作業を進めていて、どのような事象が発生しているのかは代表的な成果物でも大まかに把握していましたが、詳細はわかりません。直接話を聞くのは初めてです。

きたのしろくま @kitanosirokuma

テスト業務の中で最も重要な問題点を各自から教えてもらうところから始めました。「個人的な主観や気持ちで構わないので、これがなくなると欲しい成果になると考えられるものを出してみてね」「これめっちゃイヤだよね！ってやつでOK！」というアプローチです。

きたのしろくま @kitanosirokuma

この質問で、業務を自分のこととして捉えている人が誰で、他人事として捉えている人は誰なのか？など、各自のスタンスを把握しつつ、各自が嫌だなぁとおもっているものを抽出します。

きたのしろくま @kitanosirokuma

次に、TMMIや29910、JSTQBなどのテスト関連プロセスやタスクから私が個人的に抽出した一連のプロセス枠群（テスト業務を全体で包含するもの）に沿って、それぞれの枠ごとに「例えばこの枠でこんなことはないですか？」という感じで、問題点を抽出していきました。

きたのしろくま @kitanosirokuma

たとえば「テスト分析作業で困る・立ち止まって動かなくなること」「テスト分析のし損ないが原因で後から手戻りや嫌な事象が発生すること」って何かない？ていうような感じです。

きたのしろくま @kitanosirokuma

枠ごとの質問に対する回答に対して、具体的な事例で把握しつつ、すべてプロジェクタに投影してその場で記録し、こんな表現で言いたいことは言えてるかな？わからない人はいないかな？と一つひとつ確認・合意しながら進めます。

きたのしろくま @kitanosirokuma

プロセス枠群は大まかにテストマネジメント、テスト開発、テストインフラ関連にわかれていて、それぞれの中に個別の枠を持っています。テスト開発なら、テスト分析、テスト設計、テスト実装、テスト実行のような感じです。

きたのしろくま @kitanosirokuma

アセスメントと異なるのは、自分達にとって嫌なことを集め、それらを活用して現状を把握することです。この方法だと、自分達の嫌なことを解消するための改善方策を考えるので、自分達の課題・問題を自ら解消する図式になります。議論に参加して積極的に考え、動いてくれる可能性大です。

きたのしろくま @kitanosirokuma

次に収集した問題点（わたしたちにとって嫌なこと群）を構造分析にかけます。この問題点があるからこっちの問題点が発生している、、、というネットワーク状の図になります。

きたのしろくま @kitanosirokuma

今回はマネジメント系の問題点の流れと、テスト開発系の問題点の流れが相まって自分達と顧客も嫌な結果につながっている図になりました。 この図を前に参加メンバー全員が「これ、まさに俺たちの状態だわ」「個々にわかっていることをあらためて整理した感じの図だね」という感じて納得したのでした。

きたのしろくま @kitanosirokuma

完成した図を問題構造図と呼びます。 次に対策を打つとしたらどこを攻めるとよいかを問題構造図を前に全員で議論します。この時に大事なのは、打開したい事項に効果があることと現状の自分達でできる現実的な内容にすること、の両面を満たすことです。 よって、打開したい事項の選択を先にします。

きたのしろくま @kitanosirokuma

打開したい事項が決まったら、打開策を検討します。今回は打開したい事項が１つ、それを打開するためにマネジメント系で１つ、テスト開発系で１つの方策が必要と判断しました。テスト開発系ではすぐに効果を獲得できそうな方策とスキルを高めるなどの時間がかかる方策に分ける必要性が出てきました。

きたのしろくま @kitanosirokuma

沢山の問題事項を包含した問題構造図の中から、打開したい事項とそれを解決する方策を当てる事項を特定したので、後者については詳細に事実情報を確認することになります。どのような情報を得ると的確な方策を検討できるのか、方策の概要を意識合わせしてひとまず終了。ここまでに４時間かかりました。

きたのしろくま @kitanosirokuma

全ての問題事項を詳細に把握して分析・検討するのではなく、大まかに全体像を把握し、改善する事項を特定してからそこだけを詳細に把握するため、工数・期間を圧縮できます。とはいえ大まかに全体を把握する際には事実情報で裏を取っているので筋違いの結果が出ることもありません。