セッション７ パネルディスカッション「チームワークで品質向上をめざして」
パネリスト
茨木 紀明（シーイーシー）
岸田 昌巳（てふかん）
木下 義直（松下電器）
東 秀和 （データプロセス）

シンポジウム申込時のアンケートより
テ ストチー ム ははう ま くいっ ている か？
1 . う ま くいっ ている
2 . 特に意識していない
3 . チー ム は必
要な い
4 . う ま くいっ ていない1

シンポジウム申込時のアンケートより
う ま くいっ ていな い原因は何か？

1 . 自分が何を する べきか 分 か ら ない
2 . チ ー ム ワ ー ク が ない
3 . 指 示 系 統 が 混 乱 している
4 . 役 割 分 担 が でき て いない
5 . ひ とり で 仕 事 でききる ので周 り は 関 係 な い
6 . 周 り が 見 え てい ない
人がい る
7 . その 他

パートナー会社

シンポジウム申込時のアンケートより自社で開発テスト実施担当者（パートナー会社として参画)

チームリーダ（パートナー会社として参画)

管理者（パートナー会社として参画)

テスト実施担当者（自社で開発)チームリーダ（自社で開発)管理者（自社で開発)

テスト実施担当者

チームリーダ

管理者

その他

1. うまくいっている
2. 特に意識していない
3. チームは必要ない
4. うまくいっていない2アンケートの結果より
チ ム運営がうまくい ていない原因
チーム運営がうまくいっていない原因

チームワークがない
周りが見えていない
指揮系統が混乱している
役割分担ができていない◎コミュニケーション面◎プロセス・仕組み・ツール面
ツ面

具体的な事例で考えてみましょう

事例）とある開発の現場の様子

エンドユーザからの不具合連絡と仕様変更にやっとこさで対応し、ユーザリリースを翌週の月曜日に控えた、金曜日夕方の職場の風景。。。

3

プロジェクトリーダー※今朝の進捗報告会でも特に問題点もなかったし、何とか予定通り、来週月曜日にはお客様にリリースできそか予定通り、来週月曜日にはお客様にリリできそうだ。
※直前の仕様変更やけど、うまいこと対応できたみたやし、これでお客様に顔たったわぁ。やれやれやなぁ。
後はテストチームに頼むとして、これで週末休めるなぁ。
※今回の商品は、仕様変更が多いけど、不具合クレームも多いなぁ。何で、テストチームバグがみつからないのか？何をテストしてるのかなぁ？

テストチームメンバー※今回の対応バグって、前に僕らが見つけたのとよく似てるやん？
その時は直さんようになったけど、お客さんからクレームが来るとすぐにソフト修正するのに、何でボクたちの見つけたバグは直さないの？お客さんから言われたら直すくせに。
※何で、テストの実施がいつも週末なんや？しかも時間が決まるのがいつも金曜日の夕方や。これじゃ、休みの予定もたたんわ。。
※そやけど、デグレが多いなぁ。前回動いたところがどこか動かないので、こわぁていつも基本動作から確認し直さなあかんし、ええ加減にしてほしいゎ。ホンマに非効率やなぁ。
※こんな直前に仕様変更やて 大丈夫かいなぁ？開発チームちゃん※こんな直前に仕様変更やて、大丈夫かいなぁ？開発チムちゃんと単体テスト/結合テストやっとんねやろな？ また、電源ONしたら動かんでことないやろなぁ？
※明日、開発チームだれでてくるんやろか？なんかあったら誰に連絡するんや？

4開発チームメンバー※何でリリース直前に仕様変更なの？レビューしてたら間に合わないから、先にビルドしとこ。
※結局、今回もドキュメント書いてる時間なかったわ。来週のリリース終わってから書かかなあかんな。
※よしよし、定時までに修正終わったぞ。後はテストチーム頼むで、さっさと帰ったろ。
※何で、テストチームって、表示文言誤りみたいな重箱の隅をつついたような細かいバグばかり報告するの？ユーザから指摘されるような不具合をよう検出せーへんのかなぁ？
※やたら スケジュールと費用の調整が多くて※やたら、スケジュ
ルと費用の調整が多くて、設計やレビュ
設計やレビューにかにかける時間がなかなかとれへんなぁ。

問題点１
コミュニケ ション面における課題
コミュニケーション面における課題5コミュニケーション面
現場の姿課題解決策

仕様変更が多い

ＰＬは欠陥発見をテストＴだけの責任にしている

直前に仕様変更が入る

開発ＴとテストＴ間にミゾができていてミゾができていて、信頼関係がない

顧客～営業～ＰＬ間のコミュニケーションや調整が不十分であるＰＬ～開発Ｔ～テストＴ間のコミュニケーションが不十分である

テストＴは欠陥の修正に対して要請が弱い

関係者間で「できる・できない」の要件を合意する

プロジェクトＭＴＧなどにテストＴが参加し、情報共有するソフトの欠陥ＤＢを活用し情報共有し、重要度を明確にする

開発Ｔは欠陥を修正しない・連携されてない組織は問題であることを認識すること

ＰＬは開発チームとテストチームのＰＬは開発チムとテストチ ムの問題点が把握できていない、開発チームとテストチームは、連携が上手くできていないなど”隙間がある状態の組織”となっている。

a.バグの重大性について、テストチーム
から開発チームに伝わっていない
b.仕様変更の箇所・影響について、開発チームからテストチームに伝わってない

・情報は提供する側・される側で、十分チェックすること・ＰＬ、開発、テストの主要担当者が参加する定例会議を開催すること。 （問題重視の会議にすること）
・気になったことは、即相手に確認して解決すること（情報共有の為、メールで全員にも送付しておく）

a.テストチームは、バグの重大性が伝わる不具合票を作成すること（ランク付け＋ユーザインパクトなど記述）
開発チームは、バグの重大性に耳を傾けること。
改修可否は開発視点でなくユーザ視点で考えること
b.テストチームは、仕様変更の際、変更箇所・影響箇所について、不足してるところあれば、ヒヤリングすること
また、他に影響しそうな箇所あれば指摘すること
開発チームは、仕様変更の際、変更箇所・影響箇所をテストチームに 明確に伝えること6コミュニケーション面における課題••

相手の求めているもの，確認内容
相手の求めているもの
確認内容
両方とも理解していない––•

相手を理解しよう
相手も人だよ開発チ ムと検査チ ム
開発チームと検査チーム––

両方とも重要検査が終わるまで開発は終わっていない

コミュニケーション面における課題•

いろいろなことが相手に伝わっていない。
– あなたが内容を認識する行為：認識とは、 わたし」の伝えたい 内容」を あなた」が受領したことを知らせることであり、認識とは、「わたし」の伝えたい「内容」を「あなた」が受領したことを知らせることであり、必ずしも伝えた「内容」に同意したことを意味するわけではない。
– 内容への応答：
これは「わたし」の伝えた「内容」を、 「あなた」が解読・理解して、伝わった「内容」を返信すること。

コード化

わたし

内容ノイズ

解 読
媒体

ノイズ

解 読

あなた
コード化

内容のﾌｨｰﾄﾞﾊﾞｯｸ






コード化
内容媒体
ノイズ
解読

：考えやアイデアを他者が理解できる言語（文書）に翻訳すること。
：コード化の出力。
：内容のメッセージの伝達に使用される手段。
：内容の伝達や理解を妨げる要素（例：距離や文化）。
：内容を意味のある考えやアイデアに戻すこと。

14

7

問題点２
プロセス・仕組み・ツール面における課題

プロセス・仕組み・ツール面
現場の姿
課題
解決策

ＰＬ～開発Ｔ～テスト
Ｔ間で計画合意ない

進捗報告会は形式化しているドキュメントを作成していない

テストＴにすべてのしわ寄せがくる

開発Ｔは十分なテストができていない

仕様書やコードをレビューしていない

開発体制が不明確である

要件・課題・リスクを管理していない

監査せず、ソフトをリリースしている

ソフト開発計画書を作成していない

ＰＬの管理活動が不十分であるプロセスを監査するＳＱＡ機能がない

段取りや役割を明確にするため、ソフト開発計画書を作成する

要件・進捗・課題・リスク管理は最低実施する製品だけでなく、プロセス監査する
ＳＱＡ機能をつくる

8

プロセス・仕組み・ツール面における課題• 仕事をする上、必要な情報や目的が共有できてない。

–目的
目的(情報)を共有するためには？
す
どうやって？

言う

紙に書く

客観的にわかりにくい

わかりやすいでもてっとり早い

少し面倒

内容は最新の知恵

過去の知恵

ひとことで一子相伝

標準化した資料または匠の技テクニック集

これを・・・
暗黙知(XP,PF)
形式知(CMMI)z チーム（組織）力を向上する為の情報共有を行う仕組みは、暗黙知と形式知のバランスや繰り返しが大事。

プロセス・仕組み・ツール面における課題• 使える道具は何でも導入しよう• 手間が省けるなら何でも– やってみての失敗は得られるものがある• 怖がらずにやれ– より良くより旨く作る為に導入する– チーム間の問題• 問題を解く為の導入もあり– やらないよりマシ

9・スケジュールが明確に引かれておらず、・スケジュールが明確に引かれておらず進捗管理ができていない
・テスト開始判断基準が明確でない

・スケジュール、進捗管理の実施
・スケジュール
進捗管理の実施
・テスト開始判断基準を作成する（結合テスト完了など）不具合対応など体制に不備体制の設定（担当の設定など）

バグ、仕様変更などを管理するツールが無い、或いはあるとしても活かされていない印象

バグや仕様変更などの情報がすぐ参照できるツールを導入する

各々が常に問題意識（個人レベル、チームレベル、プロジェクトレベル）を持ち、問題提起→解決していく雰囲気を作ること、また「問題＝悪いこと」ではなく「問題＝改善に繋がる良いこと」と認識することが重要

10

ご参加のみなさんのご意見は？

11

JaSST’08関西 パネルディスカッション 「チームワークで品質向上をめざして」
パネルPOSITIONシート
項番
1
2

3

項目
お名前

ご意見１
茨木 紀明（いばらき のりあき）

ご意見２

所属

株式会社シーイーシー PROVEQサービス本部 西日本サービス部てふかん

2000年 株式会社シーイーシーに入社
開発、営業を経験し、現在は携帯電話の第3者検証業務でプロジェクトリーダーとして従事

組み込みシステムのエンジニア
テスト関連の業務からキャリアをスタート
有象無象の何もない所からの開発がおおい
検査側，開発側両方ともやったことある
色々廻って，現在はとりまとめの様な仕事をしている

きしだ まさみ

プロフィール
／ご経歴

問題点１

4

5

①相手の求めているもの，確認内容を両方とも理解していないので平行①ＰＬ、開発チーム、テストチームのコミュニケーションが密でない。
→ＰＬは開発チームとテストチームの問題点が把握できていない、開発 線をたどっているチームとテストチームは、連携が上手くできていないなど ”隙間がある状態の組織”となっている。
→”隙間がある状態の組織”では、各々自分達の仕事はこなすが、今回別シートの「とある開発の現場より」より、コ の仕様変更対応のように、連携が不十分で協力しないと解決できない問
ミュニケーション面に 題がなおざりにされたり、お互いが相手の仕事だと思うことによって問題おける課題があれば が解決されずに残されてしまったりする。
②バグの重大性について、テストチームから開発チームに伝わっていな
記述してください。
い③仕様変更の箇所・影響について、開発チームからテストチームに伝わっていない①メンバーの交流と言うか，相手の理解とか①・連携されていない組織は問題であるということを各々認識すること・連携する上での情報は、提供する側・される側双方において、十分か ②最初は飲み会からでもいいけど③机が横にあるとかどうかチェックすること・PL、開発チーム、テストチームの主要担当者全員が参加する定例会 ④話し合いの場を持つとか議を開催すること。 （単なる報告会にせず問題重視の会議にし、各々の ⑤日に何度も話するとか⑥検査予定の内容を相互に確認するとか問題点を共有→解決していくこと）⑦作業を相互レビューするとか・気になったことは、即相手に確認して解決すること（情報共有の為、メールで全員にも送付しておく）②テストチーム：バグの重大性について十分に伝わる不具合票を作成す
その問題に対してどの ること。
（ABCなどの重大度のランク付け＋どれだけ簡単な手順ように解決していけば良いと思いますか？解 か、ユーザに見つかるとどれだけインパクトがあるかも記述。1回「改修しない」となっても、ユーザにとって影響大なら改修させること）
決していっています
開発チーム ：バグの重大性に耳を傾けること。改修可否は開発側のか？
視点で考えるのではなくユーザ視点で考えること。
③テストチーム：仕様変更の際、変更箇所・影響箇所について不足していると思われるところあれば開発チームからヒヤリングすること。また、他に影響しそうな箇所あれば指摘すること。
開発チーム ：仕様変更の際、変更箇所・影響箇所をテストチームに明確に伝えること。

問題点２①なにも導入されてなさそう①スケジュールが明確に引かれておらず、進捗管理ができていない②バグ、仕様変更などを管理するツールが無い、或いはあるとしても活か ②サポートしている感じがない③手順，その後の作業が判りずらい
されていない印象(現場から管理向きにツールを入れていくと担当者には判りやすいので③テスト開始判断基準が明確でないは？)④不具合対応など体制に不備

6

7

別シートの「とある開発の現場より」より、プ
ロセス・仕組み・ツール面における課題があれば記述してください。

①スケジュール、進捗管理の実施②バグや仕様変更などの情報がすぐ参照できるツールを導入する③テスト開始判断基準を作成する（結合テスト完了など）④体制の設定（担当の設定など）①問題点の管理②プロセスの管理ツール③工程管理のツール④プロジェクト全体の管理ツール（期間，費用，成果）⑤報告書，ドキュメントの管理⑥知見，ノウハウの管理⑦場所が離れているなら，TV会議とかミーティングツール⑧問題が大きくなりそうなら集結用の会議室（WAR ROOM）①問題点に対する解決案の提案・行動ができていない（問題を放置したまま作業してしまっている）①各チーム全体の工程というか，作業予定が無いようなその問題に対してどのように解決していけば良いと思いますか？解決していっていますか？

問題点３
89

その他、問題点があれ ②モチベーションが低い。
ば記述してください。

①問題点があるなら解決案を提案する。行動する。
その問題に対してどの ②動機付けする（目標設定、褒めるなど）。
ように解決していけば良いと思いますか？解
決していっていますか？

①週末に渡せば済むわけではないのであと検査チームも人なので，月曜日に渡そうよ

その他

10

何かありましたら、何でもご記入ください。

・各々が常に問題意識（個人レベル、チームレベル、プロジェクトレベル） えらい大変なところの開発現場ですねを持ち、問題提起→解決していくという雰囲気を作ること、また「問題＝悪 疲弊したメンバーが増えそうな事が気になりますいこと」ではなく 「問題＝改善に繋がる良いこと」と認識することが重要と メンタルヘルスとか．．．．
労働基準法まもれるのかなぁ
思います。

備考

JaSST’08関西 パネルディスカッション 「チームワークで品質向上をめざして」
パネルPOSITIONシート
項番
123

項目
お名前
所属

プロフィール／ご経歴

ご意見３木下 義直（きのした よしなお）
松下電器産業株式会社 パナソニックＡＶＣネットワークス社

ご意見４
東 秀和（ひがし ひでかず）
データプロセス株式会社 第二システム部

1974年因島市生まれ。広島の専門学校を卒業後、データプロセス株式
造船会社に５年勤務後、松下電器へ転職しパソコン(Let's Noteや会社に入社。ＩＴ技術者としてパッケージソフトウェア開発、映像配信、eTough Bookなど)のソフト(BIOS,ECなど)開発に約20年関わっている。
ソフト開発 、生産技術 、ソフト開発 ソフトPLを経て、現在のソフトQA(製 Learningシステム、業務基幹システム開発を経験。2002年頃より、プロ品とプロセス）およびお客様のテクニカルな質問に対するサポート業務 ジェクトマネジメントに興味を持ち、さまざまなコミュニティー活動を通じてＰＭを学習。現在は、社内受託開発のプロジェクトリーダ、および、社のリーダーを務めている。
内標準化活動の主要メンバーとして活動中。
[資格]
米PMI認定 Project Management Professional/PMAJ認定 ProjectManagement Specialist
GSC認定 TOC/CCPM Specialist/EXIN認定 ITIL Foundation
Oracle Master 10g Gold/Microsoft MCDBA/IBM DB2 Expert

問題点１

45

（１）顧客～営業～ＰＬ間のコミニュケーションや調整が不十分である。
そのため、①仕様変更が多い ②直前の仕様変更が入る（２）ＰＬ～開発メンバー～テストＴ間のコミニュケーションが不十分であ
別シートの「とある開 る。そのため、①ＰＬは欠陥を発見するのをテストＴだけの責任にしている発の現場より」より、コ
②開発ＴとテストＴ間にミゾができていて、信頼関係がないミュニケーション面における課題があれば （３）テストＴは欠陥の修正への要請が弱い。そのため、①開発Ｔは欠陥を修正しない記述してください。

①チーム間のコミュニケーションが不十分である。
②仕様を共有できるドキュメントが、最新化されていない③変更の記録（やり取りの文書）が無い。

（１）顧客のステークホルダーとの要件開発(仕様決め)を行うときに、営 ①朝会（離れている場合はリーダだけでも）など、毎日のコミュニケー業と共にＰＬも参加し、できる・できない仕様を明確にしておき、合意を得 ションをとる。ておく。弊事業部の場合は、特定の顧客というものが特にないですが、 ②必要最低限でも記述しているドキュメント（設計書）を常に最新化しておく。
法人様などのアンケートを取り、製品に活かす様にしている。
（２）プロジェクトＭＴＧなどにテストＴが参加し、情報共有できるようにす ③最新化できないものは、変更履歴（議事録/連絡票/メール/電話記る。以前は、幣事業部でも開発ＴとテストＴ間にミゾがあったと思う。しか 録）を用意しておく。
し、テストＴが積極的にプロジェクトＭＴＧに参加することにより、そのミゾは浅くなってきたように感じている。
（３）ソフトの欠陥（障害）ＤＢを活用し情報共有すると共に、重要度を明
その問題に対してど 確にする。他社でも実施されていることだと思うが、幣事業部でも欠陥Ｄのように解決していけ Ｂに重要度をつけ、ソフト開発Ｔとそれを共有することで「絶対に修正すば良いと思いまする・しない」項目を明確にしている。
か？解決していっていますか？

問題点２

67

（１）開発の段取りなどのソフト開発計画書が作成されていない。そのた ①変更の記録（やり取りの文書）が無い。
②バグ報告のルールが確立していない。(計画書など基準となるドキュめ、①ＰＬ～開発メンバー～テストＴで日程などの合意が取れていない メントがない。)②テストＴに全てのしわ寄せがいっている③開発体制が不明確である（２）ＰＬは管理活動が不十分である。そのため、①進捗報告会はあるが形式化していて、進捗管理が不十分である
別シートの「とある開②欠陥に対する適切なエスカレーションができていない
発の現場より」より、プ
③開発Ｔは十分なテストを実施できてない
ロセス・仕組み・ツー④要件・課題・リスク管理ができていない
ル面における課題があれば記述してくださ （３）プロセスを監査するＳＱＡ機能がない。そのため①ドキュメントが未作成であるい。
②仕様書やコードなどをレビューしていない③ＰＴ／ＩＴのテスト成績を確認せずにテストＴに成果物をリリースしている（４）開発ＴとテストＴのテストに関する役割が不明確である。そのため、①テストＴが基本動作の確認から始まり、非効率になっている（１）開発期間がどの程度か不明だが、方針・段取り・成果物などを決め ①バグ報告に関する仕組みなどは、テスト計画書に記述し、内容をチーるソフト開発計画書を作成する。幣事業部では、３～４ヶ月程度で１機 ムが共有する。
種を開発するペースなので、その基本モデルについては開発計画書を ②バグトラッキングシステムの導入することも重要だが、それを全体の作成するようにしている。ただし、派生モデルについては数週間の開発 意識を統一することができるかが重要。
期間なので特に作成していない。
（２）ソフト開発計画書で決められることだが、要件管理、進捗管理、課その問題に対してど 題管理、リスク管理を最低実施すべきである。また、課題のエスカレーのように解決していけ ションの手順も明確にしておく必要がある。弊事業部では、計画書に全て盛り込んでいる。
ば良いと思いますか？解決していってい （３）プロダクトだけでなく、開発プロセスのレビューや監査を実施するＳＱＡ機能を作ったほうがよい。幣事業部は、プロダクトの評価（監査）にますか？
ＰＱＡ、プロセス監査にＳＱＡを置き役割分担している。
（４）開発ＴとテストＴ間でテストの役割を明確にする。弊社では、ソフトＰＬとテストＴの間で互いの評価計画をレビューし、どのような評価方針であるかを情報共有している。

問題点３
89

その他、問題点があれば記述してください。

（１）最後のしわ寄せが来るので、テストＴの被害者意識が高い（２）残業が多くなるパターンである（３）Ｐｊの雰囲気が悪い（４）他人任せのところがある①長い間、同じメンバーでのチームの場合、指示命令系統が確立されており新しいメンバーやリーダーがその暗黙知についていくことがむずかしい。

・いかにモチベーションをあげる/維持するようにするかが、ポイントだと ①プロジェクトマネジャは、現在のメンバーの核になる人をみつけ、リーその問題に対してど 思っている。しかし、その方法は私も模索中である。手段としては、コー ダとして任命した後は、必要以上に指示しないほうがよい。（うまくいっている場合）のように解決していけ チングやファシリテーションが使えると思っている。
②うまくいっていない場合は、早い段階から、暗黙ルールをなくす為、コば良いと思います
マンド＆コントロールによるマネジメントが必要になる場合があるのでか？解決していっていは？
ますか？

その他

10・品質を確保するのは当たり前なので、業務週報などを発行している・慣れあいになっているチームでは、誰かがやってくれる、みんな知ってが、上級管理層(経営層)に対してテストＴの業務を見える化するのに苦 いるという暗黙知で進めていると、このような状態になる場合がある。
労している。
また中の人間は気付かない。
何かありましたら、何 ･テスト、開発にかかわらずチームとしての年度始めの方針や目標を同 作業場所が離れる場合、新しい人が入った場合、テストを社外に依頼でもご記入ください。 じベクトルに具体的に持っていくかが、一番重要だと思う。
する場合は、このようなやり方では成り立たない。
・ソフト開発を基本的に３段階に区切り、ソフトのQA(PQA)主催でソフトプロダクトに関するステップ移行（監査）会議を実施し移行決済している

備考事例）とある開発の現場の様子
エンドユーザからの不具合連絡と仕様変更にやっとこさで対応し、ユーザリリースを翌週の月曜日に控えた、金曜日夕方の職場の風景。。。

プロジェクトリーダー
12
3

今朝の進捗報告会でも特に問題点もなかったし、何とか予定通り、来週月曜日にはお客様にリリースできそうだ。
直前の仕様変更やけど、うまいこと対応できたみたやし、これでお客様に顔たったわぁ。やれ
やれやなぁ。後はテストチームに頼むとして、これで週末休めるなぁ。
今回の商品は、仕様変更が多いけど、不具合クレームも多いなぁ。何で、テストチームバグがみつからないのか？何をテストしてるのかなぁ？

テストチームメンバー
12
3
4
5

今回の対応バグって、前に僕らが見つけたのとよくにてるやん？その時は直さんようになったけど、お客さんからクレームが来るとすぐにソフト修正するのに、何でボクたちの見つけたバグは直さないの？お客さんから言われたら直すくせに。
何で、テストの実施がいつも週末なんや？しかも時間が決まるのがいつも金曜日の夕方や。これじゃ、休みの予定もたたんわ。。
そやけど、デグレが多いなぁ。前回動いたところがどこか動かないので、こわぁていつも基本動作から確認し直さなあかんし、ええ加減にしてほしいゎ。ホンマに非効率やなぁ。
こんな直前に仕様変更やて、大丈夫かいなぁ？開発チームちゃんと単体テスト/結合テスト
やっとんねやろな？また、電源ONしたら動かんでことないやろなぁ？
明日、開発チームだれでてくるんやろか？なんかあったら誰に連絡するんや？

開発チームメンバー
1
2
3
4
5

何でリリース直前に仕様変更なの？レビューしてたら間に合わないから、先にビルドしとこ。
結局、今回もドキュメント書いてる時間なかったわ。来週のリリース終わってから書かかなあか
よしよし、定時までに修正終わったぞ。後はテストチーム頼むで、さっさと帰ったろ。
何で、テストチームって、表示文言誤りみたいな重箱の隅をつついたような細かいバグばかり報告するの？ユーザから指摘されるような不具合をよう検出せーへんのかなぁ？
やたら、スケジュールと費用の調整が多くて、設計やレビューにかける時間がなかなかとれへんなぁ。