「テストプロセス、プロダクト品質評価のための実用的なODC分析とCATによる管理方法」
株式会社 SHIFT
山腰 直樹
石井 優

セッションの内容「製品の品質が落ちているが、どこから手をつければ？」「新しい分析手法を試したいけどあきらめがち」。
こんなお悩みはありませんか？
欠陥分析手法「ODC分析」を用いてテストプロセスやプロダクト品質を評価するための、具体的なメトリクスとその分析事例を紹介。
「テスト活動は妥当か？」「製品に致命的な欠陥はない？」
よくあるお悩みを定量的に評価し、対策につなげていきます。
弊社のテスト管理ツール「CAT」での情報収集と分析例も実演。
デモ、対談、QAタイムにてよりODC分析の利用方法について深めていただけるセッションです。

2

アジェンダ
••••登壇者紹介（5分）
ODC分析で始める、品質分析（25分）
CATを使った品質分析 実践方法（25分）
Q&A（5分）3

スピーカー紹介4プロフィール ～山腰 直樹～

大手ITベンダーにて、約38年の製品開発（SWエンジニア）
およびITシステム開発（ソフトウェアテスト事業）を経験後、2022年2月SHIFTに参画。
金融サービス部門にてお客様支援の傍ら、ライフワークのソフトウェアテスト事業の拡大の一環として「欠陥分析サービス」 を立ち上げる。
また、我々自身すべてのメンバーに、SHIFTのもつテストオファリングをよく知ってもらい、お客様のニーズに応じたご支援ができるよう活動中。

Executive Test Specialist

山腰 直樹（やまこし なおき）
5プロフィール ～石井 優～
株式会社SHIFT
サービス&テクノロジー本部 技術統括部
開発支援プロダクト推進部 CAT開発室
セールスサポート CATエヴァンジェリスト
石井優 (Suguru ISHII)

経歴
2009／4 – 2014／11 倉庫系システム部門
2014／12 – 2015／7 東中野のPCサポート屋さん・石井屋
2015／8 SHIFT・CATサポート

好きなもの・ビール・酒・うまいもの
http://blog.livedoor.jp/sugubon-otsumami/
・Crazy Ken Band／日本の合唱／アレサ・フランクリン／チャラン・ポ・ランタン・東中野

6

ODC分析で始める、品質分析

7

アジェンダ
1. 品質評価における共通のお悩み ～ 品質の定量評価

2. 欠陥分析による品質の定量評価手法のODC分析とは？
3. 品質の定量評価、さらに踏み込んで 「採点」 をできないかを考えてみる
4. 今後の可能性と展望について

8

1. 品質評価における共通のお悩み ～ 品質の定量評価

品質の定量分析って難しいですよね

よくテスト完了報告書における品質評価のページで、以下のように評価されていますよね？

例） バグ密度：5.0／KLOC , 前回と比較して向上しており適切なテスト活動と評価するでもこれってよく考えると、、、

9

1. 品質評価における共通のお悩み ～ 品質の定量評価でもこれってよく考えると、、、
例） バグ密度：5.0／KLOC , 前回と比較して向上しており適切なテスト活動と評価する

ここの部分は定量的に測定されていますが、ここの部分は定性的な評価ですよね？

できれば、適切であるとした部分も定量的、かつ客観的に評価したいですよね。
たとえば上の例で言うならば、今回の測定値の品質評価は80点です。前回は60点でしたので、20点向上しました。
みたいな。。。。

10

1. 品質評価における共通のお悩み ～ 品質の定量評価
テスト工程の完了報告書における品質評価で、最重要な要素の1つである障害分析では検出されたバグの結果から、• どのような傾向があり、• 品質的には何点なのか、• もっと良くするためには、（次は）何をすればいいのかを述べたいですよね。。。

本日は、ODC分析という技術を使ってそのようなことを実現するアプローチについてご紹介いたします。

11

2. 欠陥分析による品質の定量評価手法のODC分析とは？
ODC分析とは…
・ODCとは、1992年に米IBM社 ワトソン研究所で確立された「欠陥分類手法」
・ODC分析とは過去のODC分類データとの比較により品質を定量的に評価する手法で、RCA（なぜなぜ分析）とは異なる「欠陥の統計分析」
統計的分析

原因分析（RCA、なぜなぜ分析）• 履歴データとの比較• 成長曲線モデル• 限定・特定不具合の調査是正措置につながらない

ODC
分析手法

多大な労力・コストがかかる個々の不具合の意味論を定量的に捉え、プロセスの進歩と品質成熟への橋渡し

効率よく原因・傾向が分析できる
ODC: Orthogonal Defect Classification（直交欠陥分類）「ソフトウェア不具合改善手法 ODC分析」
日科技連ODC分析研究会編より抜粋
参考文献：https://www.ipa.go.jp/files/000040829.pdf

12

ODC分類の考え方：Orthogonal Defect Classification （直交欠陥分類）
検出された欠陥を２つの軸（直交）で分類する手法です。
1. バグ報告者の観点（どんなテストで見つかったか）
2. バグ修正者の観点（どんな問題があったか）

代表的な分類属性

2. バグ修正者情報
欠陥タイプ（どのような修正をしたか）• 値の代入・初期化• 値のチェック
• アルゴリズム• 機能／クラス• インターフェース／メッセージ• 処理の順番• データやオブジェクトの関連付け

1. バグ報告者情報
トリガー（どのようなテストでバグを発見したか）• 単一機能の基本操作• 単一機能の特定条件• 操作手順に依存• 複数機能の相互作用• 負荷・ストレスなど

実装タイプ（実装のパターン）
• 修正
• 欠落

インパクト（ユーザーに与える影響）

13

ODC分類の考え方
基本的に分類の粒度は大きいです。これによりある程度のデータが集まれば、統計分析が可能になります。
（あまり粒度が細かいと、統計分析を行うためには大量のバグデータが必要になる）

粒度の例１（バグ報告者）
1. バグ報告者情報

トリガー（どのようなテストでバグを発見したか）• 単一機能の基本操作• 単一機能の特定条件• 操作手順に依存• 複数機能の相互作用• 負荷・ストレスなど
インパクト（ユーザーに与える影響）• 単一機能の基本操作（カバレージ）
特定な条件に依存せずバグが発生する
例：十分な預金がある口座からATMを使って引き出したが預金不足のエラーとなった。

• 単一機能の特定条件（バリエーション）
ある特定な条件でバグが発生する
例：普通預金と定期預金の合計が１００万円、普通預金口座に５０万円、の条件で、普通預金口座からATMを使って５５万円を引き出す操作をしたら、エラーとなった。

14

ODC分類の考え方
基本的に分類の粒度は大きいです。これによりある程度のデータが集まれば、統計分析が可能になります。
（あまり粒度が細かいと、統計分析を行うためには大量のバグデータが必要になる）

粒度の例２（バグ修正者）
2. バグ修正者情報

欠陥タイプ（どのような修正をしたか）• 値の代入・初期化• 値のチェック
• アルゴリズム• 機能／クラス• インターフェース／メッセージ• 処理の順番• データやオブジェクトの関連付け
実装タイプ（実装のパターン）
• 修正
• 欠落

• 実装タイプ：修正
ソースコードの一部を修正した
例：仕様書には20歳未満と記載されていたのに、20歳以下として実装してしまった。
• 実装タイプ：欠落
ソースコードを一部追加した
例：仕様書には20歳未満で、性別が男性の場合と記載されていたのに、性別の判定ロジックが抜けており、その部分を追加した。
15

ODC分析の考え方
ODCの分類された欠陥情報を集計し、その結果について考察することがODC分析です。
たとえば以下のように、ODCの分類で、開発プロセスの改善点を見える化できます。
たとえば以下のように、ODCの分類で、開発・プロセスの改善点を見える化できます。

例：バグ修正者情報と欠陥混入過程の関係
2. バグ修正者情報

欠落
プログラム

欠陥タイプ（どのような修正をしたか）• 値の代入・初期化• 値のチェック
• アルゴリズム• 機能／クラス• インターフェース／メッセージ• 処理の順番• データやオブジェクトの関連付け
実装タイプ（実装のパターン）
• 修正
• 欠落

値・フラグの誤り
データチェックの誤り
値・フラグの欠落
データチェックの欠落
アルゴリズムの誤り

詳細設計

アルゴリズムの欠落

基本設計

要件

機能の誤り

機能の欠落

（出典）Orthogonal Defect Classification – A concept for In-process Measurement（日本語訳・加筆：SHIFT）

16

修正

ODC分析の考え方
それでは前ページの分析手法を使い、あるプロジェクトにおける分類結果を分析してみます。
欠落
プログラム

修正

値・フラグの誤り
データチェックの誤り

値・フラグの欠落
データチェックの欠落
アルゴリズムの誤り

詳細設計

アルゴリズムの欠落

基本設計要件機能の誤り【分析結果サマリ】
機能の欠落（出典）Orthogonal Defect Classification – A concept for In-process Measurement（日本語訳・加筆：SHIFT）

17

一般的には欠陥混入工程が上流であるほど、課題は大きいとされています。
今回のケースでは詳細設計・プログラム工程における欠陥混入が多くなっていましたので、担当チームへの連携あるいは教育が重要であると考えられます。

3. 品質の定量評価、さらに踏み込んで 「採点」 をできないかを考えてみる

前ページの例では「バグ修正者情報と欠陥混入過程の関係」から、欠陥混入過程で改善の余地があると考えられる工程に対する対策を講じています。
これは定量的な評価と言えますが、いわゆる「絶対的」な評価であり、これをより「相対的」な評価、すなわちどのくらいの悪さ加減なのか、を述べることはできないでしょうか？

【分析結果サマリ】
一般的には欠陥混入工程が上流であるほど、課題は大きいとされています。
今回のケースでは詳細設計・プログラム工程における欠陥混入が多くなっていましたので、担当チームへの連携あるいは教育が重要であると考えられます。

詳細設計・プログラム工程に課題があることはわかったが、それはどのくらい悪いの？
どうなればいいの？

18

3. 品質の定量評価、さらに踏み込んで 「採点」 をできないかを考えてみる
ここである事例における、結合テスト工程でのODC分類「トリガー（どのようなテストでバグを発見したか）」の分類結果を見てみます。
一般的にトリガーの分布は、どのテスト工程でどのようなテストを実施してバグを発見したかの分析になりますので、すべてのテスト工程を俯瞰して、それぞれの工程で適切なテストを実施できているかを分析するのに有効です。
つまり「全体テスト方針の有効性」についての評価になります。

左のグラフは前ページの事例プロジェクトにおける結合テスト工程でのトリガーの分布です。
実はこのプロジェクトは2フェーズに分け実施しており、フェーズ1で様々な課題が浮き彫りになったため、フェーズ2ではその反省をもとに各種対策を打ち、様々な品質改善活動を取り入れ、実施しました。

その結果、フェーズ1での左の分布がフェーズ2でどのように変わったか見てみましょう。
⇒ 次のページ
19

3. 品質の定量評価、さらに踏み込んで 「採点」 をできないかを考えてみる
適切な品質改善活動を取り入れた結果、フェーズ2での分布はこのようになりました。

このように適切な品質改善活動を取り入れたフェーズ2では、トリガーの分布が大きく変わりました。
実はこの傾向はProject-Aだけではなく、すべての案件においてこのような傾向を示すということが経験上わかっています。
つまり、類似の特性を持つプロジェクトでは、結合テストにおけるトリガーの分布はこうあるべきである、というベストプラクティス指標値を設定できるということです。
それでは上記の仮説に従い、実際にフェーズ1のトリガー分布の状態を「採点」してみましょう。
20

3. 品質の定量評価、さらに踏み込んで 「採点」 をできないかを考えてみる
今回の場合、適切な品質改善活動を取り入れたフェーズ2での分布結果をベストプラクティス指標値と考えます。
それでは「全体テスト方針の有効性」について、0~5の6段階で「採点」してみます。

カバレージは基本操作で検出されたものであり、フェーズ2では46%に抑えられていますが、フェーズ1では66％もあります。
これまで多くのデータを分析してきた経験上、この数値は5%刻みに段階を評価するのが適切と考えます。
ベストプラクティス値が46%であるのに対し、フェーズ1では20％の開きがあるので、4段階減点されます。
トリガー

フェーズ1

フェーズ2

カバレージ

66%

46%

バリエーション

28%

47%

6%

8%

シーケンス・インタラクション
・パフォーマンス・負荷

すなわちフェーズ1における「全体テスト方針の有効性」の評価は、”1” (0~5の6段階のうち）であるということになります。

21

4.今後の可能性と展望について
ODCの分類結果には、開発・テストプロセスの傾向が現れます。
では開発・テストプロセスにおける品質管理の観点からどのようなメトリクスを設定すればよいでしょうか？
上流工程では、、、通常欠陥が混入されるのは上流工程（要件定義～基本・詳細設計～製造）です。
欠陥混入の工程別分布を分析すれば、特にどの工程で課題があるか、が見えてくるはずです。
そして前述の通り、ODCのバグ修正者情報から欠陥混入工程を紐づけることが可能なので、このメトリクスは測定可能です。

欠落プログラム下流工程では、、、値・フラグの欠落
データチェックの欠落
アルゴリズムの誤り

詳細
設計
基本設計
要件

値・フラグの誤り
データチェックの誤り

アルゴリズムの欠落
機能の誤り

機能の欠落

（出典）Orthogonal Defect Classification – A concept for In-process Measurement（日本語訳・加筆：SHIFT）

通常V字モデルの下流工程（単体テスト～内部・外部結合テスト～総合テスト）においては、それぞれの工程の目的に即したテストが行われます。
（例：単体テストで画面単機能テストを重点的に実施する、など）
たとえば前述の通り、結合テストにおいて検出されたバグのトリガー分布を分析すれば、その工程およびその工程に至るまでに実施すべきテストがしっかりされていたかどうかを評価することが可能です。
22

修正

上流工程の品質活動の分析のイメージ
欠陥混入の工程別分布を分析すれば、特にどの工程で課題があるか、が見えてくるはずで、課題解決のための有効な対策を講ずることができます。
たとえば欠陥混入の工程別分布がベストプラクティスに比較して以下であったとします。

※ ベストプラクティス値は仮のものです。

プロジェクトAでの欠陥混入は平均的に分布されており、一見すると問題ないように見えますが、ベストプラクティス値と比較することにより、とくに要件定義工程での品質活動に課題があることがわかります。
プロジェクトBでは、明らかに製造（プログラミング）工程に課題があることがわかります。
したがってプロジェクトAとプロジェクトBでは、取るべき対策は異なるものになるはずです。
23

4. ODC+アルファの品質評価の可能性について
SHIFTのテスト管理ツール：CATに蓄積された莫大な欠陥データの情報を活用すれば、今後さらに踏み込んだ品質評価ができるようになるはずです。
CATにはテスターが検出したバグについて、たとえば次のような分類情報が紐づいています。
1. テスト観点

例：画面I/Fのカテゴリー

SHIFTでは工程別で多く検出される（すべき）標準テスト観点が定義されています。
⇒ 標準テスト観点の分布のベストプラクティス値を使えば、「本来検出すべき工程で検出できたのか」 が見えるはずです。

画面 I/F表示

画面 I/Fレイアウト

画面 I/F遷移

画面 I/F

入力

画面 I/F

操作

例：カテゴリー:表示のテスト観点•••••

2. プログラムのバグではなかった場合の原因の分類

階層の確認
推奨画面サイズでの表示
推奨外画面サイズでの表示
推奨解像度での表示
推奨外解像度での表示

テストの本来の目的はソフトウェア（プログラム）のバグを検出することです。
しかしテスターがバグとして報告したものが、ソフトウェアのバグと認識されなかった場合は、別の原因があるはずです。
たとえば・・・・• テスターの誤操作• テストケースの不備（期待値の誤りなど）• 与えられたテストデータの不備• 与えられたテスト環境の不備などです。
もしこれらの分布がベストプラクティス値からかけ離れている場合は、対策が必要となります。
24

参考文献
• 書籍：ソフトウェア不具合改善手法 ODC分析
杉崎 眞弘 (著), 佐々木 方規 (著), 日科技連ODC分析研究会 (編集)
• IPA公開資料：SEC高信頼化技術適用事例
ODC分析による欠陥除去と品質成熟度の可視化 ～医療機器の安全性・高品質を担保するために～
オリンパスソフトウェアテクノロジー株式会社 山崎 隆
https://www.ipa.go.jp/files/000040829.pdf• Web資料：Backlog 管理図分析
https://backlog.com/ja/blog/what-is-a-control-chart/25

CATを使った品質分析 実践方法

26

統合型ソフトウェアテスト管理ツール「CAT」とはテスト・欠陥情報を一元的に管理し、テストフェーズをリアルタイムに可視化！
プロジェクトの品質・進捗を一元管理できるダッシュボード

大規模開発でもサブシステムごとに進捗・パフォーマンスを把握

27

導入メリット
中規模～大規模プロジェクト管理におけるブラックボックス化を防止、次のような課題を解決し、品質の高いプロジェクトを実現します。
• 正確な進捗や障害の発生・対応状況が見えない
テスト全体のボリューム、進捗、障害発生状況、などがチームからの報告を元にぼんやりとしか把握できない。

• 課題の発見が遅くなる
手作業で情報を収集しているため、報告に上がってこない課題・リスクなどが発生する。

• 対応コストの上昇、品質の低下を招く
テストの遅延や、数日のテスト実施不可期間などの発見が遅れ、それに影響した後続のテスト実施や障害対応も遅れ、結果即時での対応に比べ、対応コストが高くなる。
影響範囲も大きくなるため、品質の低下に繋がる。

CAT導入時の定量的効果例
プロジェクト内で発生する作業に対するコスト削減例
チーム体制、マネージャ2名、テスト実行者13名、週2回集計するチームの例

ロール

マネー
ジャ人
数

2名

単価(時間)

1.25万円／時

作業

現状の作業時間(週)CAT利用時の作業時間(週)削減可能な時間(週)Excelファイルの回収・確認

0.5時間／日×2人×2日＝2時間／週

0時間／日

2時間／週

テストと障害の情報を集計
状況の分析、課題の抽出

テスト実行者

13
名0.625万円／時

1時間 ／日×2人×2日＝4時間／週

0時間／日

2時間×5人×2日＝8時間/週4時間／週

削減可能なコスト(週)(2時間／週＋4時間／週)
×1.25万円＝7.5万円／週

0時間

結果・エビデンス登録

5時間／日×13人×5日＝325時間／週

4時間／日×13人
×5日＝260時間／週

65時間／週進捗状況のまとめ、報告

0.5時間／日×13人×2日＝13時間／週

0時間／日

13時間／週削減可能なコスト合計(65時間／週＋13時間／週)
×0.625万円＝約48.8万円

約56.25万円／週
約225.00万円／月

CAT DL版ライセンス費用(買い切り・25ユーザー÷12ヶ月)：7.5万円/月・25ユーザー
CAT クラウド版サブスクリプション(15ユーザー・月額)：5.2万円/月・15ユーザー求められる進捗管理の細かさに応じて、削減効果が大きくなります
貴社での効果についてもお確かめください29プロジェクトで頻繁に発生する課題事例と、対応例①
大規模プロジェクトにおいては、数百万単位の損失を防止
プロジェクトで頻繁に発生する課題
課題

事例

チーム単位でテ状況
スト中断が発生、 • 1サブシステムのチーム（20人）でテスト発見と解決が遅が中断。
れ、稼働工数の• 進捗の可視化・エスカレーションが遅く、3ロスが発生
日後に課題を本件を把握、その後対応
影響(大規模プロジェ • 当該チームの稼働が対応開始まで4日程
クト・600人／度停止、工数の400時間のロス
月）（20人×4日×5時間）• 後続テストの別チーム（10人）のテストも2日停止、稼働時間損失が雪だるま式に増え、工数100時間のロス（10人×2日×5時間）

CATを導入した場合の効果
改善例• テストの中断を、半日で検知。
ロスを50時間で抑え、350時間のロスを阻止（20人×0.5日×5時間）•

後続のテストチームへの影響は防げたため、100時間のロスを阻止•

合計225万円の損失を阻止（0.5万円/時 ×（350+100）時間）

CATコスト例

課題に関するお客様からの声

104万／月（600L）

大手エネルギー小売企業• 正確な状況把握がいつでも、だれでも（経営層、PM、P他）できる• 進捗の異常にいち早く対応し、明日以降の計画の反映できる• 600人規模のプロジェクトでもスムーズに導入できる

大規模プロジェクトでは、この様な事例は何度も発生します。
積み重なると、大きな損失だけでなく、プロジェクトの大幅な遅延・信用失墜に繋がります。
ブラックボックス化を阻止、いつでも課題をキャッチできる状況にすることは、テスト管理の基礎となります。
30

プロジェクトで頻繁に発生する課題事例と、対応例②
短期、中規模プロジェクトにおいても効果を発揮
プロジェクトで頻繁に発生する課題
課題

事例

CATを導入した場合の効果

1メンバーのテス
ト中断が発生、発見が遅れ稼働工数のロスと納期遅延が発生

状況• 5営業日の短期プロジェクト• テスター1人の稼働が、スキル不足により止まっており、翌日発覚。
• リカバリに上位者も一緒にテストを実施
影響• テスター8時間（1日分）のロス• 上位者のテスト実施4時間が発生• 納期が1日遅れる

改善例• テスターの課題を3時間で検知、5時間分のロスを阻止• 上位者のテスト実施4時間分のロスを阻止（短期プロジェク
ト・10人／月）••

メンバーの集計コストがかさむ（中規模プロジェ
クト・50人／月）CATコスト例

課題に関するお客様からの声

2.65万円／月（10L）

スタートアッププロジェクト• 時間単位で進捗を確認し、短期プロジェクトにでも安心できる• 開発チームからの進捗問い合わせにすぐに対応できる• 再テスト対象なども把握でき、テストの効率もあがる

12.7万円／月（50L）

流通系開発企業• 無駄な集計コストをなくせる• 人による報告粒度のばらつきや誤りをなくせる

合計約5万円の損失を阻止（0.5万円／時 × 5時間、0.62万円／時 × 4時間）
納期通りに納品完了

状況• 外部ベンダーのPMOチーム6人のうち、1名は進捗集計係として稼働改善例• PMOチームを5人に削減、月80万のロスを阻止

影響• 1名分の作業費用が発生、月80万のコスト• その上、集計が遅く不正確なため、正確な情報が把握できない•

正確な情報をリアルタイムに把握できるように中規模、小規模なプロジェクトおいても、モニタリングが重要であり、コストの削減にも効果があります。
31

品質分析という文脈でツールを使う意義

品質分析に必要な複数の項目を、適切なタイミングで、適切なメンバーに、ヌケモレなく入力してもらう

品質管理メンバーがタグ付け••

タグ付けに時間と労力を要する
このメンバーだけではわからない情報もある

Excelで各メンバーに欠陥情報を入力してもらう••

ステータスごとに入力してほしい項目がもれる
起票日付や、担当者などもいちいち手入力が発生し、正確かつ大量の情報を集めづらいツールを使って欠陥情報を入力してもらう••

ステータスごとに必要な項目を適切なメンバーに入力強制できヌケモレを防ぐ
修正完了→開発担当者・ソース属性・タイプ属性
起票日付や発生環境などはほぼ自動的に設定でき、入力の負担を軽減

32

運用を実装する上でのポイント(起票時・テスター目線)
起票時に必要な項目だけ必須可する
設定する項目の意味については、事前にメンバーに説明を行う

1回に入力させる項目は10項目程度に抑える

必須項目はなるべく1画面で見渡せる範囲に配置する

自動で入力される項目も活用する

33

運用を実装する上でのポイント(修正完了時・開発者目線)

ステータスに応じた必須項目を設定する

34

運用を実装する上でのポイント(レポート)

ダッシュボードでつねに確認できるようにする
気になる項目でピボッ
トしてみる

35

CAT フリープラン リリース！
小規模なチーム向けの永続的に無償でご利用いただけるプランをご用意しました！
製品HPイメージ特徴•••••

主要機能（テスト管理、課題管理、進捗管理、分析）を制限なく無償で利用可能
最大ユーザー数10ユーザーまで申込みから利用まで最短3分で環境構築、稟議もカードも不要！
マニュアル、サポート（ベストエフォート）が利用可能
サンプルデータが入っているので、機能の利用イメージがしやすい

こんなお客様へおすすめ•••

小規模なチーム・プロジェクトでテスト管理・課題管理を利用したい
ノーマルプランは少し予算が合わないという方も大歓迎
ノーマルプランの利用検討のために長期で利用したい
大規模プロジェクトなどを念頭に数ヶ月の利用検討にも活用可能
CATに興味があるのでとりあえず触ってみたい
テストのフォーマットや進捗情報などサンプルデータの登録もありサンプルデータを触って各種機能をお試しいただけます

ノーマルプラン（有償）との主な差異•••••

同時プロジェクト管理数：5個まで最大ユーザー数10ユーザーまで
一部機能の制限あり（外部BTS連携、ガントチャート（スケジュール管理）など）
90日利用しない場合、環境を自動でクローズ
ノーマルプランへの移行はできません（エクスポートしたデータの利用は可）
その他の差異は価格ページをご確認ください

利用開始はこちら （クレジットカード情報不要、最短5分で利用開始）
https://www.catcloud.net/

CAT テスト管理ツール

とことん使い倒す技•••••

1組織内でもメールアドレスが異なる場合は複数の環境も構築可能
設計支援ツール「TD」から出力したテスト仕様書（CSV）をそのままアップロード可能
課題管理のカスタマイズも無制限
カスタムフィールドやフローで課題管理・分析基盤を構築
テスト仕様書や課題の登録は無制限
高度な進捗管理、分析機能でプロジェクトを見える化

で検索！
36

サポート
CATをご利用際のサポートはこちらをご利用いただけます。
マニュアル
すべての機能マニュアルをWebで公開しています。
サポートサイト・FAQ
メンテナンス及びよくあるお問い合わせなどを掲載しています。

ご利用頂いているお客様の声を掲載しています。
TD製品HPTDの概要、機能について掲載しています。

問い合わせ（メール）
いつでもお気軽にご連絡ください。
cat_tech_support@shiftinc.jp※通常、2営業日以内に返信致します。
※フリープランの場合はベストエフォートとなります

CAT note 公式ブログ
細かい活用方法、TIPSやCATが開発されてきた歴史などをブログで紹介しております。
お役立ちメール
もっと効率的に利用するためのTIPS・活用事例を月1で配信。
興味をお持ちのお客様にもぜひご購読いただきたい内容です。
購読フォームから登録

CAT製品HP製品の最新情報などを掲載しています。
CAT導入事例37

お問い合わせはこちら

CAT テスト管理ツール

で検索！

今すぐ無料で試すからお試しください！

38

ご質問コーナー

いかがでしたでしょうか39