LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）として受託開発・システム開発の品質保証（QA）体制構築を支援

Kiwi TCMSとは？受託開発のテスト工程を一元管理するOSS

Kiwi TCMSとは、テスト計画・テストケース・テスト実行結果を一元管理できるオープンソースのテスト管理システムです。公式サイトでは「手動テストと自動テストの両方に対応するリーディングオープンソースのテスト管理システム」と位置付けられており、ダッシュボードで保留中の作業を可視化し、複数チーム間での作業割り当てや進捗追跡を行える点が特徴として挙げられています^*1。

受託開発・システム開発の現場では、テスト項目がExcelやスプレッドシートで属人的に管理され、実行結果や不具合の紐づけが後から追いにくくなる課題が生じがちです。Kiwi TCMSは、こうした課題に対してテスト計画・テストケース・テスト実行結果を1つのシステムで管理する目的で開発されたコミュニティ主導のオープンソースプロジェクトで、2009年にRed Hat Inc.が最初のバージョンを作成したことが公式リポジトリに記載されています^*2。

ライセンスはGPL-2.0で、ソースコードは無料で利用・改変できます^*1*2。本稿執筆時点（2026年7月）のGitHub公式リポジトリでは、スター1.2k・フォーク364・ウォッチャー46を獲得し、リリース数は69件（最新はv16.1、2026年6月24日公開）、総コミット数は7,538件に達しています^*2。言語構成はPython 72.4%・HTML 14.1%・JavaScript 10.6%となっており、2023年11月時点でDockerHubからのプル回数は200万回を超えたと紹介されています^*2。

テスト計画・テストケース・テスト実行の3層構造で管理する仕組み

TestPlanでテスト計画を管理する

Kiwi TCMSは、テスト計画（TestPlan）・テストケース（TestCase）・テスト実行（TestRun）という3つの階層で情報を整理します。TestPlanには添付ファイル・クローニング・メール送信・履歴管理・タグ付け・テストケースレビューといった機能が備わっており^*4、案件やリリース単位でテスト方針をまとめる単位として機能します。

TestCaseには添付ファイル・クローニング・メール機能・履歴追跡・パラメータ機能・タグ付けが実装されています^*4。一度作成したテストケースを別のTestPlanへ複製したり、パラメータを変えて条件違いのケースを効率よく増やしたりできる点は、回帰テストを繰り返す受託開発の現場で活用しやすい仕組みと言えるでしょう。

TestRunで実行結果を記録する

TestRunには、クローニング・メール・環境（environment）・履歴・パラメータ・タグに加え、テストマトリックス生成機能が備わっています^*4。テストケースを実際に実行した結果はTestRun単位で記録され、公式サイトはテスト結果の収集・分析によって「テスト活動の即座の洞察」が得られる点を特徴として挙げています^*1。

この3層構造により、どのテスト計画のどのケースを誰がいつ実行し、結果がどうだったかを後から追跡できます。ただし、階層をまたいだ運用ルール（タグの命名規則やパラメータの使い方）を事前に決めておかないと、チームが増えるにつれて情報が整理されにくくなる点には注意が必要です。

バグトラッカー連携と自動テストフレームワーク連携

複数のバグトラッカーと1クリックで連携する

Kiwi TCMSは、Bugzilla・JIRA・GitHub Issues・GitLab Issues・Azure Boards・BitBucket Issues・Mantis BTをはじめとする複数のバグ追跡システムに対応しており、「1-click bug report」と呼ばれる機能でテスト実行画面から直接不具合を登録し、自動でバグ情報を更新できます^*4。テスト実行中に見つかった不具合をその場でトラッカーへ連携できるため、テスト結果と不具合票が分断されるリスクを抑えられます。

また、JSON・XML-RPCによる外部APIが提供されており^*1、GitHub公式リポジトリでも「充実したAPI層（rich API layer）」が特徴として紹介されています^*2。既存の社内ツールやCI/CDパイプラインと連携させる余地がある設計と言えます。

自動テストフレームワークとの連携

自動テストの実行結果を取り込む連携先としては、Django・JUnit 5・junit.xml・PHPUnit・py.test・Robot Framework・Test Anything Protocol・TestNGへの対応が挙げられています^*4。手動テストの記録と自動テストの結果を同じ管理画面に集約できるため、手動・自動が混在するテスト工程を一元管理したい場合に検討の余地がある構成です。

Docker Composeで構築するセルフホスト導入手順

前提条件と基本手順

公式ドキュメントは、Kiwi TCMSのセルフホスト導入に「Docker」と「docker-compose」またはそれに相当するツールが必要と案内しています^*3。手順としては、まずコミュニティ版の場合は公式リポジトリからdocker-compose.ymlを取得し、リポジトリのディレクトリで「docker compose up -d」を実行します^*3。このコマンドにより、最新のKiwi TCMSイメージを使うWebコンテナと、コミュニティ版ではMariaDBのDBコンテナが作成され、永続ストレージ用にkiwi_db_dataとkiwi_uploadsという2つのボリュームが用意されます^*3。

コンテナ起動後は「docker exec -it kiwi_web /Kiwi/manage.py initial_setup」を実行し、データベース構造の作成とスーパーユーザーアカウントの作成を行う必要があります^*3。この初期設定を省略すると管理画面にログインできないため、構築手順の中でも見落としやすい工程と言えるでしょう。設定完了後は、コミュニティ版では「https://localhost」でアクセスできます^*3。

環境変数・ポート・アップグレードの実務ポイント

データベース接続には環境変数KIWI_DB_PASSWORDを使い、平文で指定する方法とDocker Secrets（/run/secret/db_password）で管理する方法の両方が案内されています^*3。パスワードを平文のdocker-compose.ymlに直書きしたまま運用すると、リポジトリ管理の仕方次第で情報漏えいのリスクにつながるため、Docker Secretsを使う運用ルールを最初に決めておくことが望ましいでしょう。ポートは既定でHTTPSが443、HTTPが80であり、HTTPアクセスは自動的に443へリダイレクトされます^*3。

アップグレードは「docker compose down」でコンテナを停止し、「docker compose pull」で新しいイメージを取得したうえで「docker compose up -d」により再起動し、最後に「docker exec -it kiwi_web /Kiwi/manage.py upgrade」を実行する流れです^*3。バージョンアップのたびにこの一連のコマンドを手作業で実行する運用になるため、定期的なメンテナンス体制をあらかじめ組んでおく必要があります。

コミュニティ版とセルフサポート・クラウド版の料金体系

Kiwi TCMSはセルフホストとクラウドの両方で提供されています。公式サイトによると、セルフホストのコミュニティ版はローリングリリースで無料、セルフサポート版は月額25ドルからとなっています^*1。クラウド側では、プライベートテナント版が月額75ドルから、エンタープライズ版が月額600ドルから、マネージドホスティング版が月額2,000ドルからという料金体系が示されています^*1。

コミュニティ版を自社サーバーへセルフホストする場合はソフトウェア自体のライセンス費用は発生しませんが、構築・運用・アップグレード対応にかかる社内工数は別途見込む必要があります。クラウド版やセルフサポート版を選べば料金の中に運用サポートが含まれますが、その分の費用が継続的に発生する点を比較材料として押さえておくとよいでしょう。

セルフホスト内製と外注委託のコスト構造比較

セルフホストによる内製構築と、外部パートナーへの委託では、費用構造・必要スキル・リスク対応の重心が異なります。以下の表に主な違いを整理しました。

受託開発・システム開発のQA工程における活用場面

受託開発・システム開発のプロジェクトでは、要件定義・設計と並行してテスト計画を早期に固め、開発の進行に応じてテストケースを積み増していく進め方が一般的です。Kiwi TCMSのTestPlan・TestCase・TestRunの3層構造を使うと、案件ごとにテスト計画を分けつつ、共通するテストケースをクローニングして再利用できるため、複数案件を並行して抱えるQAチームにとって管理の手間を減らせる可能性があります^*4。

また、バグトラッカー連携によりテスト実行中に見つかった不具合をその場で開発チームへ連携できる点は、テストとバグ管理が別システムに分かれていることで生じる情報の抜け漏れを防ぐうえで有効です^*4。一方で、複数のプロジェクトや協力会社を横断してKiwi TCMSを運用する場合、アクセス制御やタグ運用ルールの設計次第で使い勝手が大きく変わるため、導入前の運用設計が重要になります。

内製構築に必要なスキルと外注との違い

Docker運用・権限設計・連携設定に求められる専門知識

Kiwi TCMSを内製で構築・運用する場合、求められる専門知識は複数分野にまたがります。Dockerコンテナの運用とデータベース接続情報の管理、Docker Secretsを使った権限設計、バグトラッカーや自動テストフレームワークとの連携設定、TestPlan・TestCase・TestRunの運用ルール整備がその内容です。自社の情報システム部門やQAチームだけでこれらを完結させるには、複数の担当者が連携する体制を整える必要があるでしょう。

判断を先延ばしにしたまま自己流で構築を進めると、パスワードの平文管理やアップグレード手順の未整備といった問題に後から気づくケースが生じます。特にバージョンアップ時の「docker compose pull」から「manage.py upgrade」までの手順を把握しないまま運用を続けると、いざ更新が必要な場面で対応に時間がかかりかねません^*3。

専門パートナーに委託した場合の違い

専門パートナーに依頼すると、Docker環境の構築からバグトラッカー・自動テストフレームワークとの連携設定、バージョンアップ時の互換性確認、テスト計画・テストケースの運用ルール設計まで一連の工程を任せられます。自社では構成検討や連携設定だけで時間がかかる場面でも、複数の受託開発プロジェクトでQA基盤を扱ってきた知見を活用すれば、稼働までの期間を圧縮しやすくなります。内製と外注のどちらでも、まずは自社のテスト工程とバグトラッカー運用の整理が出発点と言えるでしょう。

まとめ：Kiwi TCMSセルフホスト活用の3つの判断軸

本稿ではKiwi TCMSの機能とセルフホスト構築の要点を、公式サイト・公式リポジトリ・公式ドキュメントの情報に基づいて整理しました。要点は次の3つに集約されるでしょう。第一に、テスト計画・テストケース・テスト実行の3層管理とバグトラッカー連携はGPL-2.0の無料OSSであるコミュニティ版で実現でき、ソフトウェアのライセンス費用は発生しません^*1。第二に、Docker運用・環境変数の権限設計・アップグレード対応には専門知識が必要であり、手順を誤ると障害対応に時間がかかるおそれがあります^*3。第三に、複数プロジェクトを横断する運用設計やサポート体制の確保を重視するなら、セルフサポート版・クラウド版の契約や外部委託によってリスクを抑えやすくなります^*1。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Kiwi TCMS公式サイト「Kiwi TCMS」（https://kiwitcms.org/）
2. *2　出典：Kiwi TCMS公式GitHubリポジトリ「README」（https://github.com/kiwitcms/Kiwi）
3. *3　出典：Kiwi TCMS公式ドキュメント「Installing Kiwi TCMS via Docker」（https://kiwitcms.readthedocs.io/en/latest/installing_docker.html）
4. *4　出典：Kiwi TCMS公式サイト「Features」（https://kiwitcms.org/features/）

Tweet