システム開発のプロジェクト管理ツールを選ぶ｜課題とコードをどこで結ぶか

システム開発のプロジェクト管理ツールを探し始めるとき、比較表を見ても決め手が出てこないことがあります。どれもガントチャートがあり、どれもカンバンがあり、どれもコメントが書けるからです。実際に選定を分けるのは機能の有無ではなく、課題をどの細かさで持つか、コードとどう結ぶか、そして誰にライセンスを与えるかの3点です。この記事では、公開されている情報だけで確かめられる範囲に絞って、選定の軸を順に整理します。

道具が合わなくなるのは、機能不足ではなく課題の粒度

開発チームから「いまの道具が使いにくい」という声が出たとき、その中身はたいてい機能の話ではありません。課題1件が何を指すのかが揃っていない、という話です。

同じ板の上に、「決済機能の実装」と「ボタンの色を変更」が並んでいる状態を考えてください。前者は3週間かかり、後者は10分で終わります。この2つが同じ形のカードで並んでいると、残り件数を数えても何も分かりません。進行を預かる立場から見ると、件数が減っていないのに作業は進んでいる、あるいはその逆が起きます。

粒度をどう決めるかには、実務でよく使われる基準があります。1件が3日を超えるなら分割し、1時間を切るなら他の件とまとめる、という考え方です。この範囲に収めると、朝会で1件ずつ状況を聞いても会議が長くなりません。

ここで道具の選定に効いてくるのが、階層の深さです。大きな塊を親にして、実際の作業を子にぶら下げる形を取りたい場合、階層が2段までしか持てない道具と、3段以上持てる道具では設計が変わります。国内で使われているサービスでは、Backlogが親課題と子課題の2階層を提供しており、孫課題を含む3階層はプレミアムプラン以上で使える形になっています。Jiraはエピックと課題とサブタスクという構造を標準で持っています。

粒度の話には、もう1つ側面があります。見積もりの単位と、進捗の単位を同じにするかどうかです。見積もりは機能のまとまりで出し、進捗は作業単位で追う、という形をとるチームは多くあります。この場合、道具の側で親子の関係を持てないと、見積もりの単位がどこまで進んだのかを人が暗算することになります。親に子の状況が集まる仕組みがあるかどうかは、階層の段数と同じくらい重要です。

逆に言えば、扱う案件が小さく、1件が数日で終わるものばかりなら、階層は要りません。階層の無い板のほうが、開くたびに全体が見えて速く回ります。階層が要るかどうかは、道具を選ぶ前に自分たちの案件の大きさを見て決めることです。

他の業種の進行管理と違う、5つの要件

システム開発の進行管理には、他の業種にはあまり出てこない要件があります。選定の前に、自分たちにどれが必要かを確かめてください。

・コードの変更と課題が結び付くか。 どの修正がどの課題に対するものかを後から辿れるか ・バグ票を課題と同じ場所で扱えるか。 別の管理表に分けると、優先順位の判断が2か所に割れる ・リリース単位でまとめられるか。 次のリリースに何が入るのかを、課題の集合として表せるか ・レビュー待ちが状態として見えるか。 作業は終わっているが他人の手番、という時間が長い ・社外の開発者に、必要な範囲だけ見せられるか。 委託先や副業のメンバーが加わることが多い

3つ目のリリース単位は、見落とされがちですが影響が大きい項目です。次にお客様の環境へ出すものが何なのかを、課題の集合として表せないと、リリースの直前に一覧を手で作ることになります。手で作った一覧は、その日の朝までに入った変更を取りこぼします。道具の側で「バージョン」や「マイルストーン」といった属性を課題に持たせられるか、そしてその属性で絞り込んだ表示を保存できるかを確認してください。

4つ目のレビュー待ちについては、後の節で詳しく扱います。ここでは、状態の選択肢を自分たちで増やせる道具かどうかが分かれ目になる、とだけ書いておきます。既定の3段階から動かせない道具では、この時間が測れません。

このうち、5つ全部が必要になるのは、自社でプロダクトを継続的に開発している場合です。受託で1件ずつ納品していく形なら、1つ目と3つ目の重要度は下がります。社内の業務システムを1つ育てている形なら、5つ目が最重要になります。

機能で絞らず、区切るのは人数とボードの数だけという料金の考え方をとるサービスもありますが、コードとの結びつきについては話が別です。リポジトリを内包しているかどうかは、料金の設計とは無関係に、その道具が何を目指して作られたかで決まります。

課金の単位が2種類ある。同じ人数でも費用が数倍変わる

選定でいちばん見落とされるのが、課金の単位です。大きく2種類あります。

1つ目は、組織で定額の形です。 人数が増えても金額が変わりません。Backlogがこの形をとっており、2026年9月時点の公開ページでは、スタンダードプランが月額16,000円（税抜）でユーザー数は無制限、プロジェクト数は100までとなっています。フリープランは最大10ユーザー・1プロジェクトです。

2つ目は、1人あたりの形です。 使う人数に比例して増えます。同じ時点の公開ページで、Jiraは Standard が1ユーザーあたり月額1,085円、Premium が1,987円、Free は最大10ユーザーまで無料です。Asanaは Starter が1ユーザーあたり月額1,200円（年払い）、Advanced が2,700円です。Trelloは Standard が1ユーザーあたり月額5米ドル（年払い、月払いは6米ドル）、Premium が10米ドルです。

この2つは、人数が増えたときの伸び方がまるで違います。20人の開発チームで比べると、1人あたり1,085円の道具は月額21,700円になり、定額16,000円の道具を上回ります。逆に5人なら、1人あたり課金は月額5,425円で、定額よりはるかに安くなります。

15人あたりが、両者の順位が入れ替わる目安になります。ただし、これは道具そのものの優劣ではありません。人数が読めない組織では定額のほうが計画を立てやすく、人数が確定していて少数なら1人あたりのほうが無駄がありません。

もう1つ、席の数え方も確認してください。monday.comの公開ページでは、無料プランが最大2ユーザーで最大3ボードまでとなっており、有料はベーシックが1ユーザーあたり月額1,300円（年払い）からで、購入するユーザー数を選ぶ形になっています。人数の刻みが決まっている場合、実際に必要な人数より多く買うことになります。

主要なツールの公開情報を横に並べる

2026年9月時点で、各サービスの公開ページに書かれている内容を並べます。金額はすべて公開ページの表示で、税の扱いや支払い周期は各サービスの申し込み画面で確認してください。プランは変わります。

サービス	無料でできる範囲	有料の入口	課金の単位
Backlog	最大10ユーザー・1プロジェクト	スターター月額2,700円（税抜）	組織で定額
Jira	最大10ユーザー	Standard 1ユーザー月額1,085円	1人あたり
Asana	2ユーザーまで	Starter 1ユーザー月額1,200円	1人あたり
Trello	ワークスペースあたり10ボード・10コラボレーター	Standard 1ユーザー月額5米ドル	1人あたり
Notion	フリープランあり	プラス 1メンバー月額1,650円	1人あたり
monday.com	最大2ユーザー・3ボード	ベーシック 1ユーザー月額1,300円	1人あたり

時間軸の表示がどのプランから使えるかも、開発では効いてきます。Backlogはガントチャートがスタンダードプラン以上で、表示範囲は6か月分と明記されています。Asanaはタイムラインとガントビューが Starter 以上です。Trelloはカレンダー、タイムライン、テーブル、ダッシュボードといったビューが Premium 以上です。Jiraはタイムラインビューとカレンダービューを Free プランの説明にも含めています。

無料プランで始めて、あとで時間軸が必要になったときに有料へ移る、という進め方は現実的です。ただし、その時点で人数が増えていると、1人あたり課金では想定より高くなります。無料で試す段階で、有料に移ったときの金額を人数分計算しておいてください。

コードと課題を同じ場所に置くか、分けるか

システム開発の道具選びで、最も分岐が大きいのがここです。

同じ場所に置く形。 Backlogは公開ページでGit / Subversionを機能として挙げており、フリープランを含む全プランで利用できると記載されています。リポジトリと課題が同じサービスにあると、コミットのメッセージに課題番号を書くだけで両者が結び付きます。どの修正がどの依頼に対応するのかを、後から探さずに済みます。

分ける形。 リポジトリは別のサービスに置き、進行管理の道具はそちらと連携させます。多くの開発チームはこの形です。理由は、コードのホスティングに求められる要件（レビューの仕組み、自動テストの実行、権限の細かさ）が、進行管理とは別に進化しているためです。

どちらが正しいという話ではありません。判断の軸は次の2つです。

・チームの人数と、開発が何年続く見込みか。長く続くほど、リポジトリ側の要件が独立して重くなる ・非エンジニアが課題を書くか。書くなら、リポジトリと同居していない道具のほうが、画面が単純で受け入れられやすい

正直に書いておくと、板でタスクを回すことに特化した道具には、リポジトリの機能そのものは含まれていないことが普通です。カードにリポジトリのURLを貼る、コミットの通知をチャットに流す、といった形での結び付けになります。ここが必須要件なら、リポジトリを内包しているサービスを選ぶほうが早く決まります。何がどこまでできるのかはできることで確認できます。

外部に委託する場合、誰がどこまで見えるか

受託開発でも、社内開発でも、社外の人が入ることは珍しくありません。ここで費用と権限の設計が必要になります。

Asanaは、Starter以上で無制限の無料ゲストを公開ページに挙げています。 追加料金やライセンス数への影響なしに社外のコラボレーターを招ける、という説明です。Trelloは、Standardでシングルボードゲスト、Enterpriseでマルチボードゲストという段階を設けています。 Backlogは組織で定額なので、そもそも人数で費用が変わりません。

社外の人を入れるときに確認すべきなのは、費用より先に見える範囲です。次の3つを確かめてください。

・案件ごとに区切って見せられるか。他の顧客の案件が見えてしまう構造になっていないか ・ファイルの添付が、案件の区切りを越えて検索できてしまわないか ・委託が終わったあと、アカウントを外すと過去のコメントがどう扱われるか

受託開発では、もう1つ確認しておきたいことがあります。発注元が使っている道具に、こちらが合わせるよう求められる場合があるという点です。顧客ごとに違う道具を開かされると、自社の案件全体を見渡す場所が無くなります。この場合、自社の進行は自分たちの道具で持ち、顧客の道具へは報告として転記する、という二重の運用になります。転記の手間を減らすには、自社側の粒度を顧客側の報告単位に合わせておくのが現実的です。

3つ目を忘れると、後で困ります。人を外した瞬間にその人のコメントが「不明なユーザー」になり、経緯が読めなくなる道具もあります。契約の終わりが決まっている相手を入れる場合は、試用の段階で1人を外してみて、何が残るかを確認しておいてください。

社内のデータを外部のサービスに置くこと自体への説明が必要になる場合は、安全性の考え方にまとめられている観点が、社内の承認を取るときの下敷きになります。

バグ票とタスクを、同じ板に載せるか分けるか

システム開発の進行管理で、意外と揉めるのがバグの扱いです。開発中に見つかった不具合を、機能開発のタスクと同じ場所に置くのか、別の管理表に分けるのか。どちらにも理由があります。

同じ場所に置く利点は、優先順位が1か所で決まることです。 次に何をやるかを決めるとき、機能追加とバグ修正を同じ土俵に並べないと、比べようがありません。別々の表に分けていると、バグ側の表を見ていない週にバグが積み上がります。

分ける利点は、性質の違う項目を混ぜないことです。 機能開発のタスクは自分たちで書きますが、バグ票は他人から届きます。再現手順、発生環境、期待する動作といった、機能タスクには不要な欄が要ります。この欄を全部のカードに持たせると、機能タスクを書くときの入力が重くなります。

実務でうまく回っている形は、同じ場所に置いたうえで、種別で区別するやり方です。カードに「種別」という項目を1つ持たせ、機能かバグかを選ばせます。バグを選んだときだけ再現手順の欄を埋めてもらう、という運用にすると、両方の利点が取れます。道具を選ぶときは、この項目を自分で追加できるか、そして種別で絞り込んだ表示を保存できるかを確認してください。

数の目安も持っておくと判断が速くなります。開発期間中に見つかるバグが週に10件を超えるようになったら、バグの一覧を独立させたほうが読みやすくなります。それ未満なら、混ぜたままのほうが全体が1枚で見えます。

もう1つ、リリース後に外部から届く不具合の報告は、開発の板とは分けたほうが安全です。顧客や社内の他部署から届くものは、まだ不具合かどうか分かっていない相談を含みます。それを開発の板に直接入れると、判断が済んでいない項目が並ぶことになります。受け口を別に置いて、確認した結果として開発の板へカードを作る、という2段の形が現実的です。

レビュー待ちを、状態として持つ

開発の進行で最も長く時間を食っていて、しかも表に出ないのがレビュー待ちです。書いた本人から見れば作業は終わっており、レビューする人から見ればまだ着手していない。この2つの視点の隙間に、日数が消えます。

対策は単純で、状態の選択肢に「レビュー待ち」を独立して置くことです。作業中と完了の間に1つ挟むだけで、集計したときに次のことが見えます。

・レビュー待ちのまま何日経っているか ・レビュー待ちが誰のところに何件たまっているか ・完了までの時間のうち、何割がレビュー待ちだったか

3つ目が効きます。実装に3日かかった課題が、レビュー待ちで4日止まっていたとすると、速度を上げるべきなのは実装ではありません。人を増やすかどうかの判断も、ここを見てから決めるのが正確です。

道具を選ぶときの観点としては、次の2つを確認します。1つは、状態の選択肢を自分たちで追加できるか。既定の3段階から変えられない道具では、この形が作れません。もう1つは、状態が変わった日時が記録として残るか。残っていれば、あとから滞留日数を計算できます。

レビュー待ちを可視化すると、最初は数字が悪く見えます。これまで見えていなかった時間が数字として出てくるためです。ここで「悪化した」と受け取らないよう、導入時にチーム全体へ伝えておいてください。見えるようになっただけで、実態は前から同じです。

開発以外の人が、同じ画面を見るか

選定の最後に効いてくるのが、開発チームの外にいる人です。営業、企画、サポート、経営。この人たちが同じ画面を開くかどうかで、選ぶべき道具が変わります。

開くなら、画面の単純さが最優先になります。 開発向けに作られた道具は、設定の自由度と引き換えに用語が増えます。エピック、スプリント、ワークフロー、スキーマ。これらの言葉を全社に説明するのは現実的ではありません。開発チームは開発向けの道具を使い、外向けには進捗の要約だけを別の場所に出す、という二階建てにするチームも多くあります。

開かないなら、開発チームの都合だけで選べます。 設定の自由度が高い道具を選び、社内の説明は会議で口頭とする形です。人数が少なく、開発だけを見ていればよい組織ではこれが速く回ります。

判断を分ける問いは1つです。進捗を聞かれたときに、口頭やチャットで答えているか、画面を見てくださいと言えているか。 前者なら、外の人が開ける画面を作る価値があります。後者なら、いまの構造が機能しているので変える必要はありません。

二階建てにする場合、要約を手で作らないでください。手で作る要約は、作る人が忙しい週に止まります。板の状態がそのまま集計として見える形を選び、外の人にはその集計だけを見せるのが続きます。

変わることを前提に選ぶ。プランは改定され、サービスは終わる

道具は永久ではありません。選定の段階で、この観点を必ず入れてください。

Backlogは、2026年12月31日で現在のプランの新規契約を終了し、2027年1月1日から新しいプランに移行することを公表しています。新プランはエコノミー、ビジネス、プロフェッショナルの3つで、公開されている月払い料金（税抜）はそれぞれ21,000円、36,300円、100,000円です。エコノミーはユーザー数15、プロジェクト数30、ストレージ30GBという上限が示されています。既存の契約者への影響も明記されており、スタンダードプランの利用者については次のように案内されています。

プランは自動的に切り替わりませんので、適用開始日までに、ビジネス、またはプロフェッショナルプランへの変更をお願いします。 出典: backlog.com

これはユーザーが16名以上、または31プロジェクト以上で使っている場合の案内です。開発チームは案件ごとにプロジェクトを切ることが多いため、プロジェクト数の上限は人数より先に当たることがあります。

サービスそのものが終わることもあります。Jootoは公式サイトで、2027年7月31日をもって一般提供を終了することを告知しており、2027年8月1日以降は登録されていたデータを順次すべて削除する予定であると記載しています。契約更新やライセンス追加についても、終了に向けて段階的に受付を停止すると案内されています。

この2つの例から読み取れるのは、料金や機能だけでなく、そのサービスがどれくらい先まで提供を約束しているかも選定の材料になる、ということです。終了や改定が告知されるとき、多くの場合は半年から1年以上の猶予が置かれます。逆に言えば、告知を見逃さない仕組みを持っていないと、猶予の大半を使わずに期限だけが近づきます。契約管理者のメールアドレスを個人ではなく共有の受信箱にしておくのは、地味ですが効く備えです。

選定のときにできる備えは2つです。1つは、データを持ち出せる形式が公開されているかを確認すること。もう1つは、いま入れようとしている道具に、移行できないほど深く依存する使い方をしないことです。自動化のルールを何十本も組んで、その道具の中でしか成立しない業務フローを作ると、移る判断そのものができなくなります。

いまの道具のままでよい場合

乗り換えを検討している人に向けて、先に書いておきます。次のいずれかに当てはまるなら、いまの道具を使い続けるほうが合理的です。

1つ目は、リポジトリと課題が同じ場所にあることに強く依存している場合です。 コミットと課題の紐づけを日常的に使っていて、それが無くなると経緯が追えなくなるなら、その機能を持たない道具に移る理由は薄くなります。

2つ目は、設定を作り込んだ結果として業務が回っている場合です。 ワークフローの分岐、カスタムフィールド、権限の階層。これらを組み立てるのに何十時間もかかっているなら、移行の費用はライセンス料の差額を簡単に上回ります。

3つ目は、不満の中身が道具ではなく運用にある場合です。 課題が放置される、コメントが読まれない、期日が守られない。これらは道具を変えても直りません。粒度の決め方と、更新のきっかけの設計が原因です。

不満の中身を切り分ける手順は単純です。チームに「いまの道具で、どの操作に時間がかかっているか」を1人1つずつ挙げてもらいます。挙がったものが操作の話なら道具の問題、人の話なら運用の問題です。ここを分けずに乗り換えると、新しい道具でも同じことが起きます。

2週間で決めるための選定の手順

選定が長引くのは、比べる項目を増やしすぎるからです。次の順で進めると、2週間で決まります。

1週目の前半は、要件を5つに絞ります。 先に挙げた5つの要件から、自分たちに必要なものだけを残します。全部が必要というチームは多くありません。ここで絞れないと、比較表が横に伸びて決まらなくなります。

1週目の後半は、公開されている料金と上限を人数分で計算します。 いまの人数と、1年後に想定される人数の2通りで出してください。1人あたり課金の道具は、人が増えたときの伸びが直感より速くなります。

2週目の前半は、実際の案件を1つ、候補の道具に載せます。 架空のデータで試すと、どの道具も快適に見えます。いま動いている案件の課題を30件ほど入れて、朝会を1回やってみてください。

2週目の後半は、抜けるときの手順を確認します。 データの書き出し形式、書き出せない項目、アカウントを外したときの表示。ここまで見てから決めます。

候補を横に並べるときは、比較の観点をまとめた比較の一覧が下敷きになります。板の形が近いものから見るならTrelloとの比較、一覧とタイムラインを行き来する形ならAsanaとの比較、自分でデータベースを組む形ならNotionとの比較、色分けした表で全体を眺める形ならmonday.comとの比較が参考になります。課題管理から入る国内サービスとの違いはBacklogとの比較に、無料の板から始めた場合の違いはJootoとの比較にまとまっています。

費用の考え方そのものは料金で確認でき、いま使っている板から移すときの手順はTrelloからの移行にあります。ここは正直に書いておくと、自動で取り込める形が用意されているのはTrelloからの移行で、それ以外は書き出したデータを整えて入れ直す形になります。選定の途中で出てくる細かい疑問はよくある質問に集まっています。

最後に1つ。板でタスクを回す道具は、自動化のルールや外部サービスとの連携の数では、その領域に特化したサービスに及びません。画面が日本語だけという制約が問題になる場合もあります。それらを承知したうえで、開発以外のメンバーも同じ画面を開き、案件の状態が1枚で見えることに価値があるなら、選ぶ理由が立ちます。逆に、自動化で人手を減らすことが第一の目的なら、そこを得意とする道具を選ぶべきです。

Q1. システム開発のプロジェクト管理ツールは、どこで差が付きますか？

機能の有無ではなく、課題をどの細かさで持つか、コードと課題を同じ場所に置くか、そして誰にライセンスを与えるかの3点です。特に課金の単位が組織で定額か1人あたりかで、同じ人数でも費用が数倍変わります。人数が15人あたりを超えると、定額のほうが有利になる場面が増えます。

Q2. 無料プランだけで開発チームは回せますか？

人数と案件の数によります。2026年9月時点の公開ページでは、Backlogのフリープランが最大10ユーザーで1プロジェクト、Jiraが最大10ユーザーまで無料、Trelloがワークスペースあたり10ボードと10コラボレーターまでとなっています。時間軸の表示は有料プランからというサービスが多いため、ガントが必要になった時点で有料に移ることになります。

Q3. リポジトリと課題管理は同じサービスにまとめるべきですか？

必須ではありません。まとめると、コミットのメッセージに課題番号を書くだけで修正と依頼が結び付き、後から経緯を辿りやすくなります。分ける場合は、コードのホスティング側の要件を独立して選べる利点があります。非エンジニアが課題を書くチームでは、画面が単純な道具を別に持つほうが受け入れられやすくなります。

Q4. 選定にどれくらいの期間をかけるべきですか？

2週間で決められます。前半で要件を5つ以内に絞り、公開されている料金を現在の人数と1年後の人数の2通りで計算します。後半は実際に動いている案件の課題を30件ほど載せて朝会を1回やり、最後にデータを書き出す手順と、アカウントを外したときの表示を確認してから決めます。