テストチーム運営方法 v1 2

© 2010 ACCESS CO., LTD. All rights reserved.

テストチーム運営方法

Ver.1.2

Shigeta IKUJI,

© 2010 ACCESS CO., LTD. All rights reserved. 2 Confidential

はじめに


この資料について

この資料は、2010/1から約１年、フィーチャーフォンのミドルウェア開発において、5~10人のテストチームを運営した際の運営メモをまとめたものです。

当時、開発のマネジメント業務もあったため、管理コストを極端に圧縮する必要があり、メンバーの自律性に頼る必要があったため、主にScrumの運営手法からナ

レッジを拝借しつつ各種マネジメントナレッジをチームメンバーと共同で「自律型チーム管理手法」としてまとめました。

1年間の運営の結果、毎朝25分のミーティング以外の管理コストほぼ全てを圧縮

することができ、他にも副次的な効果としてチームメンバーの著しいスキルアップ効果がありました。また、Retrospectiveの中で、「楽しかった」という意見が多かったのも特徴的でした。

こうした結果から、Scrumを応用したマネジメント手法は、異なる分野でのラーニング手法としても応用価値があると思い今回公開することにしました。


自律型チーム管理手法

要訓練作業集団を最小労力で戦力化する手法

チームに段階的な権限委譲を行うことで効率的に強化する

戦力化対象は5～10人程度の小集団であることを前提とする

ソフトウェアテスト開発が非定型反復作業であることを考慮する

実施の前提条件として以下の条件を満たす必要がある

修得対象スキルを管理者が完全に修得していること

管理者が被管理者の完全な作業アサイン権限をもつこと

毎日20～30分のミーティング時間を持つこと


自律型チーム管理手法の効果測定

時間単価の算出方法

市場平均価格：Tester＇30～40万円/月（、組込エンジニア＇80万円～120万円/月（

このため、Teste:Engineer = 1 : 2.7 で計算

2, 3月は導入期間だったため測定できず

時間単価の計算式はPage21を参照

月次 4月 5月 6月 7月通算

工数(h) 工数(h) 工数(h) 工数(h) 工数(h)

売上工数 1,360 1,190 1,360 1,360 5,270

稼働時間 1,253 1,051 1,169 1,032 4,505

粗利工数 138 167 222 359 886

管理工数 158 135 165 158 616

余剰工数 90 223 13 203 529

社員過去実績 34 34 34 34 136

社員今回実績 8 7 9 8 32

社員余剰時間 26 27 25 26 104

仮想利益 298 462 304 632 1,696

仮想利益率 21.91% 38.82% 22.35% 46.47% 32.18%


目次

全体を以下に分類理念

組織の最終目標

戦略理念と収益に対する長期対策方針

行動方針現場視点の戦略解釈

基準目標達成基準

組織業務遂行のためのチーム構成

経営幹部被管理側リーダー

手順具体的な作業手順

事業計画戦略に沿った長期計画

業務計画事業計画に沿った中期計画

コントロール・システム業務計画達成度の常時監視機能

モチベーターメンバーのモチベーション向上施策

行動方針手順

事業計画

基

準

戦略

理念

組織経営幹部

業務計画

コントロール・システム

モチベーター


理念


理念

「戦力的人材の短期育成により組織の利益に寄与する」

戦力的人材の定義：自律型高技能人材

自律型人材の定義：責任職に耐えうるメンタリティーがあること

高技能人材の定義：管理技能か専門技能のいずれかをもつこと

管理的技能の定義：ラインとプロジェクトの遂行能力

専門的技能の定義：対象専門分野の問題解決能力


戦略


戦略

余剰時間最大化 ⇒ 対訓練効率

作業手順効率化・自動化による訓練時間捻出

高次安定知識共有 ⇒ 対訓練効率

学習理論を応用した業務による知識共有最適化方法

業務可視公開化 ⇒ 対戦力化境界値

戦力化境界値の明確化と外部への貢献と協力の獲得


余剰時間最大化

プロセス最適化による余剰工数をメンバーに投資する

スキル向上支援と組み合わせ、高度な作業はインセンティブとして管理側と作業者の認識をあわせる

業務改善作業が更なる余剰工数を生む正のスパイラル

Widget Browser Mailer etc

一般テスト業務・プロセス最適化

・テスト自動化で圧縮

マネジメント

高度コンテンツ解析

仕様分析

ドキュメント管理

情報管理

翻訳

高度な作業に余剰工数投下


高次安定知識共有

学習理論と知識経営学に基づき知識共有フローを設計

インストラクショナルデザイン＇デールの学習円錐（

ナレッジマネジメント＇SECIモデル（


指示者と作業者を分けることにより知識共有を行う

インストラクショナルデザインによる知識共有

管理者メンバー

メンバー

作業

★

講義型知識伝達作業指示＇Teach Others（

作業実施＇Immediate Use（

リーダー

資料

リーダーを集中的に訓練し内部的な知識共有を重視する

資料化は実施確認作業を含むため準作業実施に相当する

資料化＇Practice by doing（


資料が第三者利用されることにより内部共有が加速される

ナレッジマネジメントによる知識共有

資料

管理者メンバー

メンバー

作業

★

参照

作業

リーダー

共同化

内面化

連結化

表出化


業務可視公開化

監視、参考、賞賛、警告

広義のオープンブックマネジメント

可視化による効果測定と目標確認

公開化による知識共有と外部評価

作業知識

可視化

公開


行動方針


現場のことは現場が決める ⇒ 現場主義

可能な限り権限委譲を行い、自律的な組織運営を行う

ルールは尐ない方がいい ⇒ 最尐規制

ルールは原理原則を基本とし、可能な限り単純化する

自分ができることは他人にやってもらう ⇒ 知識共有

知識は報酬であり、教えることは教育機会と効率化の両立とする

行動方針


基準


基準

現状を知るためには何を計測すればいいか

工数：知識を得るための費用対効果を計測する必要がある

知識：自分と組織の戦力レベルを計測する必要がある

これらはどのように定量化することができるか

時間＇工数（

戦力化境界値

戦力＇知識（ ⊿訓練効率


測定基準詳細

測定項目を＇個人, 組織（×＇工数, 知識（で定義

時間会計：単価を隠蔽した工数会計により組織のP/L, B/Sを表現する

EVM ：担当テスト作業の効率化測定のための時間×進捗の表記手法

CMMI ：一般的組織成熟度の評価指標

TPI ：テスト組織に最適化された組織成熟度の評価指標

知識マップ：ある作業を必要な知識に分解してTPSの星取表で表現する

工数知識

組織時間会計 CMMI, TPI

個人 EVM 知識マップ

次ページ以降、時間会計と知識マップのみ解説

EVM, CMMI, TPIの適用方法はそれぞれの基準に従う


時間会計

内部効率による余剰工数をインセンティブにできる仕組み

残業をすると手取りは増えるが、教育的投資が減る

効率化すると手取りは減るが、教育的投資が増える

会計化すると顧客＇ACCESS（に貢献する利益も明確になる

売上工数＇170h×メンバー時間単価（

原価工数＇実働時間×メンバー時間単価（粗利工数

案件工数＇案件作業時間×メンバー時間単価（間接工数

管理業務

固定工数

能力開発

投資工数

ACCESS

財務利益

テストチーム

知識的報酬

仮想利益


知識マップ

ある業務を次の4段階に分解

A：人に教えられる B：安定してできる

C：一人でできる D：教えられればできる

各段階をスキルと経験＇～をしたことがある（でマッピング

知識マップは体系的であることより業務直結であることに重点を置く

経験＇～をしたことがある（をできるだけ用いることで定量性の確保を行う

Category 作業イロハニホヘ

Work リリース前試験自動実施コンテンツの実施 B C D D D A

自動実施試験の実施 B C D D D A

リリース前自動試験の実施 C C D D D A

リリース前試験の実施 B C D D D A

Check Skill イロハニホヘ

Player コンテンツを動作させたことがある Yes Yes No No No Yes

リリース前試験で実施する試験セットをwikiを見て判定できる Yes Yes No No No Yes

SVNから試験セットをチェックアウトして試験可能な状態にセットし

たことがある Yes Yes No No No Yes


組織


組織

TM＇TestManager（：

運営担当者。管理者とのインタフェースになりプロジェクト間リソース調整、スケジュール調整等のラインマネジメントを行う。チームで1名。兼任非推奨。

Sub-TM＇Sub-TestManager（：日次進捗ミーティングに同席する。TM不在時に業務を代行する。

TL＇TestLeader（：依頼案件担当者。PGMとのインタフェースになり依頼作業を行う。

Tester

TestLeaderからの指示で作業を行う。

管理者

何も行わないことを基本とする。

TL-Tester間はスキル共有のため

別Project間の兼任が推奨される。

TMは数ヶ月単位のトロイカでスキル

共有される


組織教育方針

多能工化による業務安定化を優先度１とする

組織としての安定化を目指し、主業務1, 副業務1~2程度の共有化

マネジメント能力の修得を優先度２とする

高度専門化の前にTL業務相当のマネジメント業務修得を行う

資質と興味を重視した高度専門能力修得を優先度3とする

組織への貢献を目的とした個人能力開発を行う

Widget Browser Mailer etc

一般テスト業務

マネジメント

高度コンテンツ解析

仕様分析

ドキュメント管理

情報管理

翻訳

多能工

Build on Strength

緊急度低緊急度高

重要度低

重要度高

優先度１

優

先

度

２


経営幹部


経営幹部

チーム運営を任せられる戦力的人材を効率的に育成する戦力的人材 = 自律性 + 高技能＇管理的技能 + 専門的技能（

自律性修得機会： Tester < Sub-TM < TL < TM

TMは組織運営に責任を持ち、TLは案件完了に責任を持つ。双方とも工数会計を用いて利益を意識する機会を与えられる。

管理的技能習得機会： Tester < TL < Sub-TM < TM

TMは日次進捗MTGでマネジメント理論講義と業務を通じた理論実践の場を提供される

専門的技能習得機会： TM < Sub-TM < TL < Tester

Testerは既に対象技能を持ったTLからの直接指導機会と必要な余剰工数の割り当てを提供される

CMMI, TPI, 知識マップを参照し、メンバーを適切に配置する


手順


手順

理念・戦略・行動方針・基準

構成管理

案

件

標

準

手

順

手順の前提として、これまでの理念~基準に加え、

「TiDD」、「状態管理」、「構成管理」が定義される

具体的なフローは案件/日次/月次の各標準手順に定義される

プロジェクトマネジメント

案件手順

ラインマネジメント

日次/月次手順

状態管理 TiDD

日

次

標

準

手

順

月

次

標

準

手

順


TiDD

Ticket Driven Development：チケット駆動開発

BTSを使ってBugを含む全てのActivityを管理する

細かいTODO事項やリスク対策など全て一元管理

レビューなどもBTSの担当変更で完結する

後述の状態管理スケジュールもチケット単位で管理される

テスト依頼

リスク対策

改善活動

BTS ★


状態管理 – 進捗管理

状態管理の進捗管理は依頼作業のDeliveryに注目し、

以下の機能を提供する

端末モデルベーススケジュール管理

端末モデルのリリーススケジュールに注目し、緊急対応発生予測や優先順位付けに用いる

依頼作業ベーススケジュール管理

依頼作業ごとに予実管理をおこない、チーム内リソース調整やエスカレーションの根拠に用いる

担当者ベーススケジュール管理

テスト担当者ごとの勤怠予定とアサイン予定を管理し、実績値から工数超過有無の判断に用いる


状態管理 – 進捗管理

プロジェクト名、PGM、期間

アクティビティ名、担当、状態

マイルストーン

進捗

メンバー、担当プロジェクト、

担当アクティビティ日次単位作業予定/実績


状態管理 – 月次工数管理

状態管理の月次工数管理はチーム単位の予実に注目し、

前述の時間会計を用いることでパフォーマンス評価を行う

依頼プロジェクト管理

予算はプロジェクト単位で割り当てられるため、プロジェクト単位の実績を記録・管理する

チーム月次成績

チャージ工数に対する稼動工数、余剰工数、超過工数を算出する

担当者ベース実績管理

アクティビティ単位で稼動実績を記録・管理する。フォーマットはATOMに準ずる


状態管理 – 月次工数管理

プロジェクト、予算/実績プロジェクト、キャリア、メーカー

全体予定/実績

テスター別アクティビティ予定/実績


構成管理

案件に関わる全ての技術的な情報は、

原則として全て「製品」の単位で管理される

各モジュールの情報は、「製品」ごとに分割されて

管理される

プロジェクトの情報は、工数管理のみに用いるため

技術的情報はプロジェクト番号などで分類されない


構成管理図

主：製品モデル＆従：モジュールの関係性で情報を統一


案件手順

プロジェクトマネジメント手順

UMLアクティビティ図で作業を漏れなく記載

縦軸：PMBoKのプロセスフェーズ

立ち上げ、計画、実行、監視、終結

横軸：チーム関係者と役割

PGM, TM, TL, Tester

作業の見積もり・スケジュール化・構成管理など複雑なものについては同様のフォーマットで別表管理


日次/月次標準手順

ラインマネジメント手順

フォーマットは案件標準手順と同じ

日次作業は日次ミーティングの開催、日報送信が主な作業

月次作業は反省会の開催、

工数管理が主な作業


日次進捗ミーティング

毎朝20~30分、管理者＋TMでミーティングを行う

8人程度のチームの場合、管理者 + TM + SubTM×2の4名程度

TMからチーム状況の報告と管理者から運営事項の連絡

残りの時間でマネジメント/技術上のアドバイスを行う

管理者がチームとの積極対話を目的とする唯一の公式機会

管理者がチームに過干渉しないことで主体性が醸成される

連絡

フィードバック

状況報告 ★


日次朝会

チーム内で状況確認を行う

管理者は参加しない

進捗ミーティング連絡事項の内部展開

一日の作業内容の確認

司会進行はTMが行う

基本的には以下の資料に準拠する http://www.objectclub.jp/download/files/pf/MorningMeetingGuide.pdf

★


月次反省会

チーム内で月毎のふりかえりを行う

管理者も出席するが主体はチームなので極力干渉しない

メンバーの異動などはこの場で展開する

当月のKPTを行い、次月の目標設定を行う

基本的には以下の資料に準拠する http://www.objectclub.jp/download/files/pf/RetrospectiveMeetingGuide.pdf


事業計画


事業計画

4半期程度の期間で戦略に沿った定量目標と計画を立てる

反省会で用いる資料を事業計画書相当と位置づけて運用する

事業計画はTMと管理者で作成する

目標は1ヶ月単位で分割され計画化される

例（

CMMI Lv.X 相当達成

TL経験者X%化達成

特定スキルXXの修得率X％達成

目的は、大体の方針を立てること

それが変更されたことを明確化すること


業務計画


業務計画

バランススコアカードに基づいた業務計画書を作成する

各項目の対応は次のようにする

財務：時間会計を用いた余剰時間を適用

顧客：依頼元のPGMを顧客と定義

プロセス：CMMIの項目を元に目標を設定

学習と成長：知識マップを元に目標を設定



管理＇計画との差分把握（は次のように行う

日次管理

意識のずれの確認：日次進捗ミーティング、日次朝会

進捗のずれの確認：状態管理表＇進捗管理表（

工数のずれの管理：状態管理表＇進捗管理表（

月次管理

意識のずれの確認：月次反省会、業務計画書

進捗のずれの確認：状態管理表＇月次工数管理表（

工数のずれの確認：状態管理表＇月次工数管理表（


モチベーター


モチベーター – 二要因性理論

ハーズバーグの二要因理論を特に支持

衛生要因への対応

成果のみをルールとし、時間的制約などは可能な限り自由化する

収益の原理原則に基づき自らルールを作ることで納得性を高める

動機付け要因への対応

責任に対して達成された成果は余剰時間としてインセンティブ化する

オープンブックマネジメントを行うことで自活自律運営の意識を行う


モチベーター – 状況的学習

責任と成果の原則を重視し、管理者の干渉は限定する

管理者の干渉はTMに限定し、

TM-TL間でのラインを堅持する

制度導入初期は、教示的に

TMに接したとしても、TL側から

管理者-TM間の関係性は

隠蔽される

テストチーム運営方法 v1 2

Documents