Comments
Description
Transcript
講演資料（PDF: 390K） - JaSSTソフトウェアテストシンポジウム
ＪａＳＳＴ ‘０９ Ｔｏｋｙｏ 事例発表 ■概要 • ソフトウェア開発時のコミュニケーションを効率化するために、 双方の立場や背景（コンテキスト）を可視化するワークショッ プ（以下、ワークショップ）を企画、実施した。 ソフトウェア開発時のコミュニケーションにおける コンテキストの可視化ワークショップの実施とその考察 • ワークショップは自由連想による連想単語を記録し、その結 果から意味ネットワークの形成と、連想単語の偏りを分析し、 コンテキストの可視化を試みた。 • その結果から、ソフトウェア開発のどのような場面でワーク ショップを実施すれば、ソフトウェア品質や生産性が高まる かについて考察する。 ２００９・０１・２８ ＮＥＣネクサソリューションズ株式会社 小池輝明 （Ｓ－ｏｐｅｎ 感性ＳＩＧ） ※この事例はＳ－ｏｐｅｎのＳＩＧ活動の一環で行われました。 (C) Copyright 感性SIG（S-Open） 1 ■ワークショップ実施の目的と背景 (C) Copyright 感性SIG（S-Open） 2 ■コンテキストの見える化へのアプローチ • 目的 – ソフトウェア開発におけるコミュニケーションの効率化を 図るために、コンテキストを可視化する。 受信者 【ワークショップ概要】 【手順１】 「ＲＦＰ」から、連想する単語 を付箋紙に記入。 【手順２】 記入した単語から連想される 単語を次の付箋紙に記入。 コード 記号化 【手順３】 同様に連想された単語を次 の付箋紙に時間まで記入。 【コンテキスト分析】 目的別に集計カテゴリを２種類用意 連想単語の集計 解読 受信者 受信内容 メッセージ 経路 メッセージ 伝達内容 (C) Copyright 感性SIG（S-Open） 4 対象は「ソフトウェア開発に関する全ての事項」、プロフィールには役割を記入。 時間は１０分で実施し、ワークショップ前には自由連想のルールのみ説明。 コンテクスト コード メッセージ コンテキストの可視化へ コンテクスト 発信者 – 宣言的知識は概念をノードとする意 味ネットワークを形成していると考え られている。連想単語群をあるカテ ゴリに分類し、カテゴリ間の連想関 係の数をノードの強度とすると意味 ネットワークが見えてくるのではない かと考えた。 (C) Copyright 感性SIG（S-Open） ■ワークショップと分析の概要 – 意味ネットワークに加えて、連想 単語をカテゴリ化することで、宣 言的知識の偏りもしくは網羅性 が明確になる。 – こうして、意味ネットワークと連想 単語の偏りから、コミュニケー ションとしての背景が浮き彫りに され、これがコミュニケーション モデルにおけるコンテキストに 相当すると考えた。 宣言的知識と意味ネットワーク 解読 経路 • – 与えられた単語からの連想単語を 記録し、連想単語からの連想を繰り 返す。このとき、連想時には外部か らのヒントを一切与えられないことか ら連想単語は潜在的な意識の現れ であり、これは宣言的知識に相当す ると考えられる。 メッセージ 3 ■コンテキストの見える化へのアプローチ 自由連想と宣言的知識 伝達内容 発信者 (C) Copyright 感性SIG（S-Open） 記号化 受信内容 – 顧客の要求が正確に開発者に伝わらない、アーキテクト の意思が設計に活かされない、テスト設計に要求が反映 されていないなどの事象は、コミュニケーションのありか たにも問題があると考えた。 – コミュニケーションにかける時間を短くしつつ、正確に行う ためには、メッセージの送り手と受け手の背景（コンテキ スト）を同じにする必要がある。 – より高度な開発を求められる今日のソフトウェア開発の現 場では質の高い効率的なコミュニケーションが求められる。 • コード コード • 背景 • コンテクスト コンテクスト 5 共通フレーム２００７ ＳＱｕＢＯＫ 連想ワー ドの分類 開発プロセスと 周辺管理領域の分析 マネジメントと 知識領域の分析 分析上の 期待 プロセス別の 関心領域の明確化 知識領域別の 関心度合の明確化 (C) Copyright 感性SIG（S-Open） 6 WACATEでのワークショップ風景 記入カード (C) Copyright 感性SIG（S-Open） 7 ■ワークショップ結果のデータ概要 役割 品質担当者 開発担当者 テスト担当者 その他 コンサルタント スタッフ ＰＭＯ 生産技術・研究 総計 共通フレーム、ＳＱｕＢＯＫにおける連想単語のカテゴリの上位を集計。 プロセス （共通フレーム） キーワード数 （一人あたり） 18 16 9 7 3 3 1 1 58 8 ■連想単語カテゴリ分析（１） 上位カテゴリ 調査対象者を役割別に分類。本事例では、品質担当者、開発担当者、テスト担 当者について分析する。 調査数 (C) Copyright 感性SIG（S-Open） 572 628 247 267 112 50 105 119 2100 31.8 39.3 27.4 38.1 37.3 16.7 105.0 119.0 36.2 (C) Copyright 感性SIG（S-Open） 品質技術 開発 担当者 開発プロセス 管理プロセス 要件定義プロセス 要求分析のマネジメント アーキテクチャ設計の技法 プロジェクトマネジメント全般 実装の技法 テストのマネジメント 要求分析の技法 品質 担当者 開発プロセス 管理プロセス 要件定義プロセス 要求分析のマネジメント テストの技法 プロジェクトマネジメント全般 要求分析の技法 テストのマネジメント 品質分析・評価の技法 テスト 担当者 開発プロセス 管理プロセス 共同レビュープロセス プロジェクトマネジメント全般 アーキテクチャ設計の技法 要求分析のマネジメント 実装の技法 テストのマネジメント レビューの技法 9 ■連想単語カテゴリ分析（２） 下位カテゴリ 品質知識（SQuBOK） 品質マネジメント (C) Copyright 感性SIG（S-Open） 10 (C) Copyright 感性SIG（S-Open） 12 共通フレーム 共通フレーム、ＳＱｕＢＯＫにおける連想単語のカテゴリの下位を集計。 品質知識（SQuBOK） 品質マネジメント 品質技術 プロセス （共通フレーム） 開発 担当者 品質 担当者 再利用プログラム管理プ ロセス 監査プロセス 環境整備プロセス 運用プロセス リスクマネジメント 調達のマネジメント 意思決定のマネジメント 監査プロセス 意思決定のマネジメント 調達のマネジメント 保守プロセス 運用・保守のマネジメント 品質分析・評価の技法 品質計画の技法 レビューの技法 レビューの技法 実装の技法 品質計画の技法 契約の変更管理プロセス 運用、保守プロセス 構成管理プロセス テスト 担当者 品質保証システム 監査プロセス 問題解決プロセス 再利用プログラム管理プ ロセス プロジェクトマネジメント全般 メトリックス 要求分析のマネジメント 品質計画の技法 テストのマネジメント 品質分析・評価の技法 (C) Copyright 感性SIG（S-Open） 11 ■開発担当者のコンテキスト分析（１） 共通フレームにおける意味ネットワーク ■開発担当者のコンテキスト分析（２） ＳＱｕＢＯＫにおける連想単語の分析 連想単語が開発プロセスで 多いことから、開発プロセスを ハブとして他のプロセスとの 関係が作られていることがわ かる。 契約、要件、開発、品質、マネ ジメントが強く結びついてい る。 一方、運用・保守、文書化・構 成管理、問題解決・ユーザビ リティの連携が弱い。 以上の分析から、留意してい るプロセスに偏りがあり、それ がシステムの品質に影響する リスクがあることがわかる。 矢印の太さ：カテゴリ間の連想数を強度とし、太さで表現 カテゴリの境界線の太さ：当該カテゴリ内での連想単語数を表現 コンテキストとしては「システ ムを作るプロセスに注力」し ている立場にあると言える。 (C) Copyright 感性SIG（S-Open） ＳＱｕＢＯＫのマネジメント領域と知識領域では、アーキテクチャに関心が高い様子がわかる。 共通フレームの分析と同様、運用・保守、構成管理への関心の低さに加えて、調達のマネジメントに 対する関心の低さが見える。 13 ■品質担当者のコンテキスト分析（１） 共通フレームにおける意味ネットワーク (C) Copyright 感性SIG（S-Open） 14 ■品質担当者分析（２） ＳＱｕＢＯＫにおける連想単語の分析 開発担当者との違いで顕著 なのは、契約・品質管理・問 題解決とマネジメントプロセ スの連携が強いことである。 組織に関するライフサイクル がハブとなっている傾向が強 いため、ルール重視指向とも 言える。 運用・保守に関しては、開発 者よりもさらに少ない。 コンテキストとしては、既定の ルールを重視したアプローチ をとることが予想される。 マネジメントでは、アーキテクチャとプロジェクトマネジメントへの関心が高く、テストに関してはマネジ メント、技法ともに関心が高い。 注目すべきは、教育のマネジメントへの関心が高いことから、品質管理担当者の育成に何らかの課 題を抱えていることが予想される。 矢印の太さ：カテゴリ間の連想数を強度とし、太さで表現 カテゴリの境界線の太さ：当該カテゴリ内での連想単語数を表現 (C) Copyright 感性SIG（S-Open） 15 ■テスト担当者のコンテキスト分析（１） 共通フレームにおける意味ネットワーク (C) Copyright 感性SIG（S-Open） 16 ■テスト担当者分析（２） ＳＱｕＢＯＫにおける連想単語の分析 開発担当者と品質担当者に 比べてサンプル数が少ない ために、全体的に関連強度が 低く見える。 ハブカテゴリは、品質管理の 視点に於かれていることが興 味深い。 コンテキストとしては、品質管 理を基点とした行動になって いると言える。 マネジメントでは、テストのマネジメントへの関心が高い点が目立つ。 技法では、アーキテクチャ、実装への関心が見られるが、マネジメントと同様に偏りが大きい。 矢印の太さ：カテゴリ間の連想数を強度とし、太さで表現 カテゴリの境界線の太さ：当該カテゴリ内での連想単語数を表現 (C) Copyright 感性SIG（S-Open） 17 (C) Copyright 感性SIG（S-Open） 18 ■考察（１） ソフトウェア技術者のコンテキストとテストの課題 ■考察（２） ワークショップのテストでの活用方法 • コンテキストの分析結果 本事例のワークショップをテストフェーズ別での活用例を下表に示す。 基本的な実施方法はそのままで、フェーズに合わせた連想領域を定めると分析 が容易になると思われる。 – 全体的に開発プロセスとプロジェクトマネジメントへの関 心が高い一方、運用・保守、ユーザビリティへの関心が低 い。 – したがって、システムを「作りあげること」に関心が高く、 「どのように使われるか」への関心が低い、と言える。 フェーズ • テストの課題 – このようなコンテキストの状態において、要件ベーステス ト、リスクベーステストなどをテスト戦略として採用する場 合、関心領域が偏っている状態では十分な品質が確保 出来ない可能性がある。 – テスト戦略の立案時にこのワークショップを実施し、関係 者間でのコンテキストの偏りを早期に発見する必要があ る。 (C) Copyright 感性SIG（S-Open） 連想対象、参加者 効果 要件定義を対象 プロジェクト初期におけ テスト計画 ＰＭ、開発担当者、テス る役割分担の適正化 ト担当者、品質担当者 システム要件とテスト 要件の整合性向上 システム設計 システム設計とテスト テスト設計 ＰＭ、開発担当者、テス 設計対象の明確化 ト担当者、品質担当者 システム設計とテスト 設計の整合性向上 プログラム設計 テスト実施 開発担当者、テスト担 当者 実装技術に対するテス ト技術の対応状況の明 確化 19 実装担当者とテスト担 当者の関心対象の明 確化 (C) Copyright 感性SIG（S-Open） ■まとめ ■参考文献 • コンテキストの可視化の効果 • – コンテキストを意識したコミュニケーションにより、お互いの立場や役 割の違いについて「気づき」の機会を創出する。この「気づき」は、コ ミュニケーションの問題解決のスタートとなる。 • • • • コミュニケーションの問題の解決 – 正確なコミュニケーション • • コンテキストが見えてくると立場の違いが明確になり、立場の相互理解 が容易になりコミュニケーションが効率化すると思われる。 • – 「動く・使える」システム • システム利用者の視点（顧客視点）を持つことができれば、「動くが使え ないシステム」が作り上げられてしまうリスクを回避することができる。 • • • – コンテキストの変化の把握 • ワークショップを適時実行し、コンテキストの変化を把握すれば、良い変 化か悪い変化かの予兆を見極めるのに役立てることができる。 (C) Copyright 感性SIG（S-Open） 目的 20 ソフトウェア品質知識体系ガイド（オーム社）―ＳＱｕＢＯＫ策定部会著(２ ００７／１２) 共通フレーム２００７（情報処理推進機構ソフトウェアエンジニアリングセ ンター ２００７／１０） ＪＳＴＱＢテスト技術者資格認定-シラバス テスト担当者を悩ませる１０の難題克服（日経ＢＰ）ウィリアム・Ｅ・ベリー、 ランドール・Ｗ・ライス（２００７／９） 人月の神話新装版（ピアソンエデュケーション）フレデリック・ブルックスＪ ｒ（２００２／１１） 要求仕様の探検学（共立出版）Ｄ・Ｃ・ゴーズ、Ｇ・Ｍ・ワインバーグ（１９９３ ／８） 記号論への招待 (岩波新書) 池上 嘉彦著（１９８４／３） 脳はなにかと言い訳する（祥伝社）池谷 裕二著（２００６／０９） 新・心理学の基礎知識 (有斐閣ブックス)中島 義明、 箱田 裕司、繁桝 算男ほか（２００５／０１） 21 (C) Copyright 感性SIG（S-Open） 【資料】コンテキスト分析補足（１） 開発者の連想単語分析（共通フレーム） 22 【資料】コンテキスト分析補足（２） 品質担当者の連想単語分析（共通フレーム） 共通フレーム２００７分析（品質管理） 共通フレーム２００７分析（開発者） 350 300 1.00 160 0.90 140 0.80 250 1.00 0.90 0.80 120 0.70 0.70 0.60 200 0.50 150 0.40 0.30 100 100 0.60 80 0.50 0.40 60 0.30 40 0.20 0.20 (C) Copyright 感性SIG（S-Open） 0.10 23 １．８ 保守プロセス ２．７ 監査プロセス １．７ 運用プロセス ３．２ 環境整備プロセス ２．３ 品質保証システム ３．５ 資産管理プロセス ２．２ 構成管理プロセス ２．９ ユーザビリティプロセス (C) Copyright 感性SIG（S-Open） １．３ 契約の変更管理プロセス ３．６ 再利用プログラム管理プ ロセス １．４ 企画プロセス ２．８ 問題解決プロセス ２．１ 文書プロセス ２．５ 妥当性確認プロセス １．１ 取得プロセス ２．６ 共同レビュープロセス ３．３ 改善プロセス ２．４ 検証プロセス ３．４ 人的資源プロセス 0.00 １．２ 供給プロセス 0 １．６ 開発プロセス ２．７ 監査プロセス ３．２ 環境整備プロセス ３．５ 資産管理プロセス ３．６ 再利用プログラム管理プ ロセス ２．８ 問題解決プロセス ２．２ 構成管理プロセス １．８ 保守プロセス １．３ 契約の変更管理プロセス １．７ 運用プロセス ２．９ ユーザビリティプロセス １．４ 企画プロセス ２．３ 品質保証システム ３．３ 改善プロセス ２．５ 妥当性確認プロセス ２．１ 文書プロセス ２．６ 共同レビュープロセス １．１ 取得プロセス ２．４ 検証プロセス ３．４ 人的資源プロセス １．２ 供給プロセス ３．１ 管理プロセス １．５ 要件定義プロセス 0.00 １．６ 開発プロセス 0 ３．１ 管理プロセス 0.10 20 １．５ 要件定義プロセス 50 24 【資料】コンテキスト分析補足（３） テスト担当者の連想単語分析（共通フレーム） 【資料】コンテキスト分析補足（４） 開発担当者の連想単語分析（ＳＱｕＢＯＫ ソフトウェア品質マネジメント） 共通フレーム２００７分析（ソフトウェアテスト） SQuBOK分析（開発者） 80 1.00 70 100% 0.90 70 0.80 90% 60 80% 60 0.70 50 50 70% 0.60 40 0.50 0.40 30 60% 40 50% 30 40% 0.30 20 0.20 10 0.10 20% 10 10% ３．６ 再利用プログラム管理プ ロセス (C) Copyright 感性SIG（S-Open） 25 3.4 レビューの技法 3.2 品質計画の技法 3.6 品質分析・評価の技法 3.1 メトリックス 3.5 テストの技法 3.3 要求分析の技法 0% 3.3-*2 実装の技法 0 3.3-*1 アーキテクチャ設計 の技法 ２．７ 監査プロセス ２．８ 問題解決プロセス ２．３ 品質保証システム １．８ 保守プロセス ２．２ 構成管理プロセス １．７ 運用プロセス ３．５ 資産管理プロセス １．３ 契約の変更管理プロセス ３．３ 改善プロセス ３．２ 環境整備プロセス ２．５ 妥当性確認プロセス ２．９ ユーザビリティプロセス １．１ 取得プロセス ３．４ 人的資源プロセス ２．１ 文書プロセス １．５ 要件定義プロセス ２．４ 検証プロセス １．４ 企画プロセス １．２ 供給プロセス ３．１ 管理プロセス ２．６ 共同レビュープロセス 0.00 １．６ 開発プロセス 0 30% 20 (C) Copyright 感性SIG（S-Open） 【資料】コンテキスト分析補足（５） 品質担当者の連想単語分析（ＳＱｕＢＯＫ ソフトウェア品質マネジメント） 26 【資料】コンテキスト分析補足（６） テスト担当者の連想単語分析（ＳＱｕＢＯＫ ソフトウェア品質マネジメント） SQuBOK分析（品質管理） SQuBOK分析（ソフトウェアテスト） 40 35 100% 20 100% 90% 18 90% 80% 16 80% 70% 14 70% 60% 12 60% 50% 10 50% 40% 8 40% 30% 6 30% 20% 4 20% 10% 2 10% 0% 0 0% 30 25 20 15 (C) Copyright 感性SIG（S-Open） 27 (C) Copyright 感性SIG（S-Open） 3.6 品質分析・評価の技法 3.2 品質計画の技法 3.1 メトリックス 3.3 要求分析の技法 3.5 テストの技法 3.3-*1 アーキテクチャ設計 の技法 3.2 品質計画の技法 3.3-*2 実装の技法 3.4 レビューの技法 3.3-*1 アーキテクチャ設計 の技法 3.1 メトリックス 3.6 品質分析・評価の技法 3.3 要求分析の技法 3.5 テストの技法 0 3.4 レビューの技法 5 3.3-*2 実装の技法 10 28