Redmineは社内では完璧に機能していた。チケットが積み上がり、ステータスが動き、担当者が変わっても履歴が残る。エンジニア同士なら、特に説明しなくても動けた。
問題は、外注先が増えたときだった。
「このURL開いてチケット確認してください」と送ったら、相手から「ログインってどうやるんですか？」という返信が来た。そこから、話が変わった。
限界その1：アカウント発行と権限設定のコストが積み重なる
Redmineで外部メンバーを受け入れるには、管理者がアカウントを発行し、プロジェクトに追加し、ロールを設定する必要がある。
一人二人なら問題ない。でも外注先が3社を超え、そこに各社担当者が2〜3人いるようになると、このオペレーションがバカにならない。
誰かがプロジェクトを抜けるたびに権限を剥奪しなければならない。参加者が変わるたびに管理者を通さなければならない。流動性の高い外部メンバーの出入りと、Redmineの設定操作は相性が悪い。
限界その2：非エンジニアが使いこなすには概念の壁がある
Redmineのチケット・トラッカー・バージョン・ロードマップは、開発プロジェクトに最適化されたモデルだ。エンジニア同士なら自明でも、クライアントのシステム担当者や外注先のデザイナーには「ここに何を入力すればいい？」が伝わりにくい。
操作マニュアルを渡しても、日常的に使わない外部メンバーは定着しない。結局、Redmineに入力するのは社内だけになり、外部とのやりとりはメールかチャットに戻っていく。
外部メンバーが使えないツールは、外部との協業ツールにはなれない。
限界その3：スマートフォンからの確認がしづらい
Redmineはデスクトップ環境を前提に設計されており、モバイルブラウザからの操作は快適ではない。
クライアントや外注先が外出中にスマートフォンで確認したいとき、Redmineのモバイル表示では「見にくい・操作しにくい」という声が出やすい。専用のモバイルアプリもデフォルトでは存在しない（プラグインや別途対応が必要）。
スマートフォンで完結する体験が当たり前になった今、この点は外部向けに使いにくさとして表面化しやすい。
二刀流で解決するチームも多い
Redmineの内部管理の強さは本物だ。だからこそ「Redmineを捨てずに使い続けながら、外部向けに別の見せ方をする」という選択をするチームは多い。
具体的には、内部の開発管理はRedmineで動かし続ける。外注先やクライアントとの進捗共有は、別のツール（PaqutやNotionなど）でシンプルなボードを作る。そこに「今週やること」「完了したもの」「確認待ち」だけを映し出す。
二重管理になるデメリットはあるが、外部への操作説明が不要になり、Redmineの設定を変えずに済むというメリットがある。
外部共有を重視するなら最初から分けて考える
もし今から新しくプロジェクト管理の体制を作るなら、「内部開発管理ツール」と「外部共有ツール」を最初から分けて設計する方が摩擦が少ない。
外部メンバー向けに重要なのは、招待の手軽さと操作のシンプルさだ。URLを送るだけで参加できる・追加コストがかからない・スマートフォンから確認できる。この三点があると、外注先やクライアントが動いてくれやすくなる。
Paqut はゲスト招待を無料でURL1本から実現している。Redmineと並行して外部共有に使うケースにも対応できる。
外部メンバーとのやりとりを、もう少し軽くしたいと感じているなら、試してみる価値はある。