Plane

Work Itemsを中心に、短期サイクルから機能単位・長期計画まで同じデータで追う

Planeでは日々の作業をWork Itemsとして管理し、一定期間の実行計画をCycles、複雑な取り組みを分割する単位をModulesとして扱います。Work Itemsはrich text、ファイル添付、関連Issueなどを持てるため、単純なチェックリストよりも開発・製品チームの実務を意識した構造です。Cyclesではburn-down chartなどで進捗を確認でき、個別Issueだけでなくチーム全体の流れを同じシステム内で追跡できます。

出典：[1]

Views・Pages・Analyticsを分離せず、プロジェクト管理の周辺情報も同じ場所へ置く

Viewsでは条件に応じてWork Itemsを絞り込み、チームごとの表示を保存・共有できます。Pagesはrich text editorとAI機能を備えたドキュメント面で、アイデアや仕様を残し、その内容を実行項目へつなげられます。AnalyticsではPlane内のデータを横断して傾向やボトルネックを確認できます。Issue tracker、簡易Docs、進捗分析を別SaaSへ分散させず、一つのプロジェクトモデルへ寄せたい場合に強みが出ます。

出典：[1]

LinearやJira相当の管理を、自社インフラで持ちたい開発・プロダクトチームへ

開発タスク、スプリント相当の期間管理、機能単位の進捗、ロードマップ、仕様メモを一つの環境へまとめたいプロダクトチームに向きます。Plane Cloudですぐ試せる一方、データや運用基盤を自社で管理したい場合はDockerやKubernetesでセルフホストできます。Community向けself-host guideではDocker ComposeやDocker Swarmのセットアップ、バックアップ、アップグレードまで案内されており、クラウドサーバーの開始目安として2 vCPU・4 GB RAMも示されています。

出典：[1][2]

セルフホストの運用負荷と、AGPL・Commercialコードが混在するライセンス境界を確認する

セルフホストではアプリの更新だけでなく、公開URL、CORS、メール設定、バックアップなどを運用者が管理します。チーム招待にはメール設定が関係し、外部公開する場合はTLSや認証を含めたインフラ設計も別途必要です。Cloud版の運用負荷と引き換えに、自社管理版ではデータ・アップグレード・可用性を自分で持つ構成になります。

トップレベルREADMEとLICENSE.txtはGNU AGPLv3を掲げていますが、現行リポジトリにはSPDX-License-Identifier: LicenseRef-Plane-Commercialと明記されたファイルも存在します。したがって、Planeのコードを改変・再配布・組み込みする場合は『リポジトリ全体が一律AGPLv3』と判断せず、利用するファイルやCommunity / Commercialのedition境界を確認する必要があります。

出典：[2][3][4]