プロジェクト管理ツールの選び方:ITプロジェクトで必要な機能と比較軸
プロジェクト管理ツールを型と比較軸で選ぶための整理。ITプロジェクトで差がつく7つの機能、重みつき評価表の記入例、SaaSとセルフホストの判断、Excelで足りる条件、定着のルールまで。
プロジェクト管理ツールとは、タスク・担当者・期限・進み具合・課題をチームで共有し、計画と実績のずれを早く見つけるためのソフトウェアです。ボード、ガントチャート、チケットなど中心になる画面は製品ごとに違い、どの型が合うかはプロジェクトの性格で決まります。
情シスが主導する社内のITプロジェクトでは、社外のベンダーと同じ画面で課題を追えるか、期限や担当が変わった経緯を後から説明できるか、といった条件が選定を左右します。こうした条件は、機能の有無を並べた一般的な比較表には出てきません。製品の人気ではなく、ツールの型と比較軸で選ぶための評価表、SaaSとセルフホストの判断、Excelで足りる条件、定着させる最小限のルールまでを扱います。
この記事でわかること
- タスクボード型・ガント型・チケット型など、ツールの型ごとの得意と苦手
- ITプロジェクトで差がつく7つの機能と、それが必要な理由
- 重みつきの評価表の記入例と、SaaSかセルフホストかの判断基準
- Excelやスプレッドシートで足りる条件と、移行を考えるサイン
- ステータスの定義やチケットの大きさなど、定着させるためのルール
プロジェクト管理ツールの型:得意と苦手
| 型 | 中心になる画面 | 得意 | 苦手 | 製品の例(執筆時点) |
|---|---|---|---|---|
| タスクボード型 | 列にカードを並べるカンバン | 小さなチームの日々のタスクの流れ | 長期の日程、作業の依存関係 | Trello、Microsoft Planner |
| ガント型 | ガントチャート | 依存関係のある日程、マイルストーン | 日々の細かな課題のやり取り | OpenProject |
| チケット型 | チケットの一覧と詳細 | 課題・不具合・変更要求の記録と経緯 | 全体の日程を一目で見ること(製品による) | Redmine、Jira、Backlog |
| ワークマネジメント型 | リスト・ボード・タイムラインの切り替え | 部門をまたぐ業務、エンジニア以外の利用者 | 細かな権限設計(製品による) | Asana |
| 開発連携型 | リポジトリと連動したIssue | コードの変更と課題の結びつけ | 開発者以外の参加 | GitHub Projects、GitLab |
| 表計算 | シート | 小さな規模、すぐに始められる | 同時編集、履歴、通知、依存関係 | Excel、Googleスプレッドシート |
多くの製品は複数の型をまたいでいて、チケット型の製品にもボード表示やガントチャートがあります。分類は「毎日いちばん長く見る画面はどれか」で考えてください。社内ITの案件で情シスが毎日見るのは、課題と変更要求の一覧です。そのため、チケット型か、チケットを中心に据えられるワークマネジメント型が合うことが多く、ガントチャートは月次の報告で使う補助の画面と割り切るとうまくいきます。
ITプロジェクトで差がつく7つの機能
タスク管理、ガントチャート、ファイル共有、チャット連携は、ほとんどの製品が備えています。ITプロジェクトで差がつくのは、その下にある次の機能です。
| 機能 | なぜ必要か | 試用で確かめること |
|---|---|---|
| 課題・リスク・変更要求を別の種類で管理 | 種類ごとに承認の流れと見る人が違う。混ぜると変更の承認記録が埋もれる | チケットの種類を追加し、種類ごとにステータスの流れを変えられるか |
| 社外ユーザーの招待と権限の制限 | ベンダーと同じ画面で課題を追えば、メールでの転記が消える。社内の別案件は見せられない | ゲストの課金体系、プロジェクト単位の閲覧制限 |
| 変更履歴と監査ログ | 誰がいつ期限や担当を変えたかを、監査や振り返りで説明できる | チケットの変更履歴、管理操作のログ、ログの保存期間 |
| 依存関係とマイルストーン | 切替日に向けて、前提の作業の遅れが後ろの作業に伝わる | 先行・後続の関係を設定でき、遅れが後続に反映されるか |
| SSOとアカウントの自動停止 | 退職者や交代したベンダー担当のアクセスを確実に止める | SAMLやOIDCでのSSO、SCIMでの自動プロビジョニング、それが使えるプラン |
| データのエクスポートとAPI | 別のツールへの移行、報告書の自動作成、ロックインの回避 | チケット・コメント・添付を一括で出せるか、APIの利用制限 |
| 通知の細かな制御 | 通知が多すぎると、全員が通知を無視するようになる | 個人ごと・プロジェクトごとに通知の条件を変えられるか |
7つのうち、後から足すのが難しいのはSSOとエクスポートです。SSOは上位プランでしか使えない製品もあり、利用者が増えてからプランを上げると費用が一気に跳ねます。確認する項目の詳細はSaaSのSSO/SCIM対応チェックリストが使えます。エクスポートは、試用期間中に実際にデータを書き出し、コメントや添付まで含まれるかを見てください。解約の段になってから試すのでは遅すぎます。
社外ユーザーの課金体系は製品によって大きく違います。ゲストが無料の製品、ゲストにも通常の利用者と同じ料金がかかる製品、ゲストの人数に上限がある製品があります。ベンダーの担当者が案件ごとに入れ替わる情シスの案件では、この違いが年間の費用を左右するので、見積を取る前に社内・社外の人数構成を書き出してください。
比較軸と評価表:重みをつけて採点する
候補を2〜3製品に絞ったら、評価表で比べます。重みは案件の性格で変わるので、次の記入例を出発点に調整してください。採点は0〜3点で、試用環境で実際に確かめられたものだけに点を付けます。
| 比較軸(例) | 重み | 製品A | 製品B | 製品C |
|---|---|---|---|---|
| 課題・変更要求の種類分け | 3 | 3 | 2 | 1 |
| 社外ユーザーの権限と課金 | 3 | 2 | 3 | 1 |
| 変更履歴・監査ログ | 2 | 3 | 2 | 2 |
| ガントチャートと依存関係 | 2 | 2 | 1 | 3 |
| SSO・SCIM(必須) | 2 | 3 | 2 | 0 |
| エクスポート・API | 2 | 2 | 3 | 2 |
| 運用の手間の少なさ | 1 | 3 | 3 | 1 |
| 重みつき合計 | - | 38 | 34 | 21 |
採点のルールを2つ決めておきます。1つ目は、必須とした軸で0点の製品は、合計点に関係なく候補から外すことです。例の製品Cはガントチャートの点数が最も高くても、SSOが0点なので外れます。2つ目は、価格を評価表に入れず、評価表で残った候補だけを費用で比べることです。価格を点数に混ぜると、安さで必須要件の不足が見えなくなります。費用は利用者の数だけでなく、社外ユーザーの数や、SSOのような機能に上位プランが要るかどうかで大きく変わるので、見積は実際の人数構成で取ります。
SaaSかセルフホストか
| 観点 | SaaS | セルフホスト(Redmine、OpenProjectなど) |
|---|---|---|
| 始めるまでの手間 | アカウントを作ればすぐに使える | サーバー、データベース、バックアップ、TLS証明書の用意が要る |
| 運用 | 事業者が更新と障害対応を行う | バージョンアップ、脆弱性対応、プラグインの互換確認を自社で行う |
| データの置き場所 | 事業者のクラウド(リージョンは製品による) | 自社で決められる |
| 費用の形 | 利用者数に応じた月額が多い | オープンソース版ならライセンス費はかからないが、サーバーと人の時間がかかる |
| 向いている会社 | 運用の人手が少ない、社外ユーザーが多い | データを社外に置けない要件がある、サーバーを運用する体制がある |
判断の基準は1つで、「このツールのサーバーが夜中に止まったとき、自分たちで直せるか」です。直せないならSaaSを選びます。セルフホストを選ぶ場合も、インターネットに直接公開せず、VPNやSSOの背後に置いてください。プロジェクト管理ツールには、ベンダーの見積や障害の詳細、社内の人事異動に絡む作業など、外に出せない情報が集まります。解約時にデータを持ち出せるかという観点は、ベンダーロックインとの付き合い方で整理した評価項目がそのまま使えます。
Redmineをセルフホストする場合、初期状態の管理者アカウントはユーザー名・パスワードともにadminです(執筆時点のRedmine 6.1系をコンテナで起動して確認)。初回のログイン後にパスワードの変更を求められますが、それまでの間にサーバーへ到達できた第三者が先にログインすれば、その人が管理者のパスワードを決められてしまいます。起動したらすぐに自分でログインしてパスワードを変え、検証のつもりで立てたサーバーでもインターネットから到達できる場所には置かないでください。検証用のサーバーを本番に流用したくなったら、そのまま使わず、バックアップと更新の手順を決めたうえで構築し直す前提で扱います。
Excel・スプレッドシートで足りる条件
Excelやスプレッドシートは、次の条件がすべてそろっている間は十分なプロジェクト管理ツールです。専用ツールの導入と定着にかかる手間を考えると、条件を満たすうちは無理に移る必要はありません。
- 更新する人が数人で、同時に編集する場面がほとんどない
- 社外の人とは共有しない、または閲覧だけ
- 課題の件数が、1画面の一覧で見渡せる量にとどまっている
- 誰がいつ何を変えたかを、第三者に説明する必要がない
移行を考えるサインは、「最新版はどれですか」という質問が出る、課題の状況を確かめるための会議やチャットが増える、ベンダーと課題表をメールで往復させている、監査や振り返りで変更の経緯を説明できなかった、の4つです。移行するときは、今のExcelの列をそのままチケットの項目に対応させます。列の名前やステータスの呼び方まで同時に変えると、操作の変化とやり方の変化が一度に来て、定着が遅れます。
導入して定着させる最小限のルール
ツールを入れても使われない原因の多くは、機能ではなくルールがないことです。使い始める前に、ステータスの定義、チケットの大きさ、更新のタイミングの3つだけは決めて共有します。ステータスは、次のように定義と「誰が変えるか」を必ずセットにします。
| ステータス | 定義 | 変更する人 |
|---|---|---|
| 未着手 | 担当者と期限が決まっている | 起票者 |
| 進行中 | 担当者が作業を始めた | 担当者 |
| 確認待ち | 作業は終わり、依頼者やレビュー担当の確認を待っている | 担当者 |
| 完了 | 依頼者または確認者が結果を確かめた | 依頼者または確認者 |
| 保留 | 外部の理由で止まっている。理由と再開の条件をコメントに書く | 担当者 |
チケットの大きさは、1人が数日で終えられる単位にそろえます。例として「ファイルサーバー移行」は大きすぎるので、「経理部の共有フォルダの権限を新しい環境に移す」のように分けます。更新のタイミングは「週次の定例の前日までに、自分のチケットのステータスと期限を最新にする」と決めると、定例の場が状況の確認ではなく判断に使えるようになります。複数の案件を横断して報告をそろえる仕組みは、PMOとはで扱っています。
選定と導入の失敗は、部門ごとに別のツールが入って案件横断の状況が見えなくなる、機能の多さで選んで設定が複雑になり誰も使わない、退職者や交代したベンダー担当のアカウントが残り続ける、の3つに集約されます。1つ目は全社で使うツールを1つに決め、例外は理由つきで承認する。2つ目は評価表に「最初の案件で使う機能」だけを軸として入れる。3つ目はSSOと四半期ごとのアカウント棚卸しで防ぎます。
よくある質問
ガントチャートとWBSの違いは何ですか?
WBSは、プロジェクトでやるべき作業を階層に分解した一覧で、「何をやるか」を決めるものです。ガントチャートは、その作業に期間と順序を当てはめて横棒で表した日程表で、「いつやるか」を示します。先にWBSで作業を漏れなく洗い出し、その作業をガントチャートに並べる順番で作ります。
エクセルはプロジェクト管理ツールとして使えますか?
更新する人が数人で、社外と共有せず、課題の件数が一覧で見渡せる規模なら十分に使えます。同時編集で最新版がわからなくなる、ベンダーと課題表をメールで往復させる、変更の経緯を説明できない、といった状態が出てきたら、チケットと履歴を持つ専用ツールへの移行を考える時期です。
OpenProjectとRedmineの違いは何ですか?
どちらもRuby on Railsで作られたオープンソースで、OpenProjectはRedmineから派生したプロジェクトを源流に持ちます。Redmineは課題管理が中心で、足りない機能はプラグインで補います。OpenProjectはガントチャートの操作や工数・予算の管理を標準で備え、有償のエンタープライズ版もあります。機能の範囲は執筆時点の公式情報で確認してください。
Redmineは時代遅れですか?
画面の古さや、標準のガントチャートを直接操作できない点は、新しいSaaSと比べると見劣りします。一方で、チケットの種類・項目・ワークフローを細かく設計でき、自社のサーバーで無償で動かせる点は今も強みです。データを社外に置けない、課題管理が中心、サーバーを運用できる人がいる、という条件がそろうなら現役の選択肢です。
まとめ
プロジェクト管理ツールは、人気の順位ではなく、毎日見る画面の型と、ITプロジェクトに特有の機能で選びます。課題と変更要求の種類分け、社外ユーザーの権限、変更履歴、SSO、エクスポートを評価表の軸にし、必須の軸で0点の製品は外します。夜中に止まっても自分たちで直せないならSaaSを選び、ステータスの定義とチケットの大きさを決めてから使い始めてください。