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

テストチーム運営方法

Ver.1.2
Shigeta IKUJI,

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

はじめに

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

この資料について

この資料は、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%


目次

 全体を以下に分類
 理念事業計画
理念
 組織の最終目標
 戦略
業務計画
 理念と収益に対する長期対策方針
 行動方針
 現場視点の戦略解釈コントロール・システム戦略
 基準
 目標達成基準
 組織
 業務遂行のためのチーム構成基
 経営幹部準
 被管理側リーダー
 手順
 具体的な作業手順手順行動方針
 事業計画
 戦略に沿った長期計画組織経営幹部
 業務計画
 事業計画に沿った中期計画
 コントロール・システム
 業務計画達成度の常時監視機能
 モチベーターモチベーター
 メンバーのモチベーション向上施策

理念


理念

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

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

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

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

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

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


戦略


戦略

 余剰時間最大化 ⇒ 対訓練効率
 作業手順効率化・自動化による訓練時間捻出

 高次安定知識共有 ⇒ 対訓練効率
 学習理論を応用した業務による知識共有最適化方法

 業務可視公開化 ⇒ 対戦力化境界値
 戦力化境界値の明確化と外部への貢献と協力の獲得


余剰時間最大化

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

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

 業務改善作業が更なる余剰工数を生む正のスパイラル
マ高仕ド情翻
ネ度様キ報訳
ジコ分ュ管
メン析メ理
ンテン
トント
管
高度な作業に余剰工数投下
ツ
解理
析

一般テスト業務
・プロセス最適化
Browser Mailer Widget etc ・テスト自動化で圧縮

高次安定知識共有

 学習理論と知識経営学に基づき知識共有フローを設計
 インストラクショナルデザイン＇デールの学習円錐（
 ナレッジマネジメント＇SECIモデル（


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

 指示者と作業者を分けることにより知識共有を行う
講義型知識伝達作業指示
＇Teach Others（

作業実施
＇Immediate Use（

管理者リーダー★ メンバー
作業

資料化
資料
＇Practice by doing（

 リーダーを集中的に訓練し内部的な知識共有を重視する
メンバー
 資料化は実施確認作業を含むため準作業実施に相当する


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

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

表出化
管理者 ★
リーダーメンバー
作業

内面化
資料

連結化参照メンバー

作業

業務可視公開化

 広義のオープンブックマネジメント
 可視化による効果測定と目標確認
 公開化による知識共有と外部評価
可視化

公開
作業
知識

監視、参考、賞賛、警告


行動方針


行動方針

 現場のことは現場が決める ⇒ 現場主義
 可能な限り権限委譲を行い、自律的な組織運営を行う

 ルールは尐ない方がいい ⇒ 最尐規制
 ルールは原理原則を基本とし、可能な限り単純化する

 自分ができることは他人にやってもらう ⇒ 知識共有
 知識は報酬であり、教えることは教育機会と効率化の両立とする


基準


基準

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

 工数：知識を得るための費用対効果を計測する必要がある
 知識：自分と組織の戦力レベルを計測する必要がある
戦力＇知識（
⊿訓練効率

戦力化境界値

時間＇工数（

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


測定基準詳細

 測定項目を＇個人, 組織（×＇工数, 知識（で定義
 時間会計：単価を隠蔽した工数会計により組織のP/L, B/Sを表現する
 EVM ：担当テスト作業の効率化測定のための時間×進捗の表記手法
 CMMI ：一般的組織成熟度の評価指標
 TPI ：テスト組織に最適化された組織成熟度の評価指標
 知識マップ：ある作業を必要な知識に分解してTPSの星取表で表現する

工数知識
組織時間会計 CMMI, TPI
個人 EVM 知識マップ

 次ページ以降、時間会計と知識マップのみ解説
 EVM, CMMI, TPIの適用方法はそれぞれの基準に従う


時間会計

 内部効率による余剰工数をインセンティブにできる仕組み
 残業をすると手取りは増えるが、教育的投資が減る
 効率化すると手取りは減るが、教育的投資が増える
 会計化すると顧客＇ACCESS（に貢献する利益も明確になる

テストチーム ACCESS
知識的報酬財務利益

売上工数＇170h×メンバー時間単価（
原価工数＇実働時間×メンバー時間単価（粗利工数
案件工数＇案件作業時間×メンバー時間単価（間接工数
管理業務能力開発
固定工数投資工数

仮想利益


知識マップ

 ある業務を次の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とする
 組織への貢献を目的とした個人能力開発を行う
重要度高
マ高仕ド情翻
優ネ
ジ
度
コ
様
分
キ
ュ
メ
報
管
訳
メン析理
先ン
ト
テ
ン
ン
ト
ツ管
Build on Strength 度解
析
理

２
一般テスト業務
Browser Mailer Widget etc
優先度１
重要度低
緊急度高多能工緊急度低

経営幹部


経営幹部

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

 自律性修得機会：
 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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (15)

Semelhante a テストチーム運営方法 V1 2

Semelhante a テストチーム運営方法 V1 2 (20)

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