LASSIC Media らしくメディア

2026.07.22 らしくコラム

Fiderで要望管理をセルフホスト構築・外注

LASSIC IT事業部|元請(プライムベンダー)としてシステム保守・運用を受託

要望管理のイメージ

この記事のポイント

  • Fiderは、要望投稿・投票・6種類のステータス管理によって対応状況を可視化できる、無料のセルフホスト型フィードバック管理システムです。
  • タグ・OAuthログイン・マルチテナント構成を使うと、複数プロダクトの要望を1つの基盤に整理できます。
  • AGPL-3.0ライセンスの理解や環境変数・メール配信の設計には専門知識が必要になるため、内製と外注のどちらで進めるかを費用構造とリスクの両面から判断する必要があります。

Fiderとは?OSSの要望・フィードバック管理セルフホストツール

セルフホストサーバーのイメージ

Fiderとは、企業がユーザーからの要望・フィードバックを収集し、投票によって優先度を可視化できる無料のオープンソース製品フィードバック管理ツールです。公式サイトは自社を「顧客フィードバックのためのプラットフォーム」と位置づけ、顧客の声を製品開発の意思決定に活かす仕組みとして紹介しています*1。GitHub公式リポジトリでは2026年7月時点で4,400件を超えるスターと826件のフォークを獲得しており、AGPL-3.0ライセンスの下、Go言語のバックエンドとTypeScript製フロントエンドという構成で開発が続いています*2

図
図:Fiderの要望管理フロー(要望投稿→投票・コメント→ステータス更新→ロードマップ公開)

顧客や社内利用者からの要望をメールやチャットで受け取るだけの体制では、似た要望が重複して寄せられたり、対応の優先順位を決める根拠が担当者の感覚に偏ったりしがちです。Fiderは、こうした要望・フィードバックを1か所に集約し、投票数という定量的な指標で優先順位を可視化するために開発されたオープンソースプロジェクトです*1

セルフホストする場合、要望データは自社で用意したサーバーに保存され、外部のクラウドサービスへ送信されません。SaaS型のフィードバック管理サービスを利用する場合と比べ、ライセンス費用が発生しない点はコスト最適化を検討するうえで見逃せない要素でしょう。一方で、構築・運用を自社で担うか外部に委託するかという別のコスト判断が新たに発生します。

投稿・投票・ステータスで要望を可視化しロードマップとして公開する仕組み

要望投稿は「post」という単位で管理する

Fiderでは、ユーザーが投稿する要望・バグ報告・意見を「post」と呼ばれる単位で扱います。1件のpostには、タイトルと説明に加え、投稿者情報・作成日時・投票数(votesCount)・コメント数(commentsCount)・タグが記録される仕組みです*5。投稿の作成には認証とタイトルの入力のみが必要で、説明文は任意項目とされています*5

6種類のステータスで対応状況をロードマップとして公開する

運営側は各postに対し、open・planned・started・completed・declined・duplicateという6種類のステータスを設定できます*5。duplicateステータスを付与する場合は、原本となる別のpostの番号(originalNumber)にリンクする仕様です*5。このステータス変更を通じて要望への対応状況を利用者へ開示できる点が、いわば「ロードマップの公開」に相当する機能でしょう。ステータス変更時には担当者名や返信テキストを含む「response」を添えることもでき、対応状況の理由を利用者に伝えられます*5

ただし、ステータス変更や投稿の編集・削除には管理者またはコラボレーターの権限が必要です*5。誰がどの権限でロードマップを更新できるのか、運用開始前に社内で役割分担を決めておく必要があります。

タグ・OAuthログイン・マルチテナントで運用を整える機能

タグと表示切り替えで要望を横断的に絞り込む

投稿一覧は、「most-wanted」「trending」といった表示切り替えのほか、タグによる絞り込みや検索キーワードでの一覧取得に対応しています*5。複数タグを1件のpostに付与できるため、分野・部署・プロダクトラインといった複数の観点で要望を横断的に整理する運用が可能です。

OAuthログインとマルチテナント構成で複数プロダクトの声を集める

公式ドキュメントのガイドには、OAuth認証の設定方法や、1つのFiderインスタンスで複数のフィードバックボードを運用する「マルチテナント」構成の解説が用意されています*6。複数プロダクトや複数ブランドを展開する企業が、ボードを使い分けながら1つの基盤に要望を集約する構成を組む余地があるでしょう。TLS/SSLの有効化やWebhook連携についても個別のガイドが公開されています*6

Docker Composeで構築する標準的な導入手順

PostgreSQLコンテナとFiderコンテナの2つで構成する

公式ドキュメントは、Dockerでのホスティングを「もっとも一般的なアプローチ」と位置づけ、推奨する導入経路として案内しています*3。docker-compose.ymlには、PostgreSQL(ドキュメント例ではバージョン17)を動かす「db」サービスと、Fider本体を動かす「app」サービスの2つを定義します*4。BASE_URL・DATABASE_URL・JWT_SECRET・EMAIL_NOREPLY等の環境変数を設定したうえで、docker compose pullでイメージを取得し、docker compose up -dで起動する流れです*4。稼働後は設定したBASE_URLでアクセスできます*4

PostgreSQL 12以上が前提、HTTPS化は別ガイドを参照

動作にはPostgreSQL 12以上が必要とされています*4。インターネットに公開する場合はHTTPS化が推奨されており、公式ドキュメントは「SSL/TLSを有効にする方法」を別途ガイドとして用意しています*6。社内向け・限定公開のフィードバックボードであっても、要望内容に顧客情報が含まれる可能性を踏まえると、通信の暗号化は運用開始前に確認しておきたい項目でしょう。

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

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

比較項目 セルフホスト内製 外注委託
ライセンス費用 AGPL-3.0の無料ソフトウェアのため発生しません*2 ソフトウェア自体は無料ですが、構築・保守を委託する分の費用が発生します
必要な専門知識 Docker運用・PostgreSQL管理・JWT_SECRET等の環境変数設計・メール配信設定が必要です*4 専門パートナーが構築・調整を担うため、社内での知識習得は最小限で済みます
ステータス運用・ロードマップ公開設計 6種類のステータス運用ルールやタグ設計を自社で整備します*5 運用ルールの設計から支援を受けられます
ライセンス遵守・アップグレード対応 バージョン更新やAGPL-3.0の遵守状況を自社で確認します*2*7 動作検証とライセンス確認を含めて委託先が対応します

JWT_SECRET・メール送信・マルチテナント設定の要点

Fiderの環境変数には、認証トークンの署名に使うJWT_SECRET、PostgreSQLへの接続文字列であるDATABASE_URL、公開URLを指定するBASE_URLなどがあります*8*4。公式ドキュメントはJWT_SECRETについて、外部の生成ツールを使って十分な強度の値を設定するよう案内しています*4。この値を推測されやすい文字列のまま運用すると、認証まわりのセキュリティリスクにつながる恐れがあります。

通知メールの送信元にはEMAIL_NOREPLYを設定するほか、Mailgun・SMTP・AWS SESのいずれかの方式を選んで送信設定を行う仕組みです*4*8。SMTPを使う場合はEMAIL_SMTP_HOST、EMAIL_SMTP_PORT、EMAIL_SMTP_USERNAME、EMAIL_SMTP_PASSWORDといった項目を設定します*8。この設定を誤ると、要望投稿時の確認メールやステータス変更通知が利用者に届かなくなるため、導入時のテスト送信は欠かせない工程でしょう。

複数プロダクトの要望を1つの基盤に集約したい場合は、マルチテナント構成のガイドに沿って設定します*6。OAuthログインを併用すれば、既存の認証基盤と連携させながら利用者の登録ハードルを下げることも検討できます*6

AGPL-3.0ライセンスが外部提供時に及ぼす影響を確認する視点

Fiderは、GNU Affero General Public License version 3(AGPL-3.0)の下で公開されています*7。ライセンス本文は、ネットワーク経由でサービスを提供するソフトウェアにおいてもコミュニティとの協調を確保する目的で設計されたライセンスであると説明しています*7

一般にAGPL-3.0は、改変したソフトウェアをネットワーク経由で外部ユーザーに提供する場合、そのソースコードを利用者に開示する義務が生じる点で、GPLよりも強い制約を持つライセンスとして知られています。Fiderをそのまま自社の要望収集ボードとして使う分にはこの点を強く意識する必要は薄いものの、Fiderを改変したうえで自社サービスの一部として顧客へ提供するような使い方を検討する場合は、AGPL-3.0の条件を満たせるかどうかを、法務部門や専門家を交えて個別に確認することが望ましいでしょう*7

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

Docker運用・環境変数設計・メール配信整備に求められる専門知識

Fiderを内製で構築・運用する場合、求められる専門知識は複数分野にまたがります。Dockerコンテナの運用とPostgreSQLデータベース管理、JWT_SECRET・DATABASE_URL等の環境変数設計、Mailgun・SMTP・AWS SESいずれかによるメール配信整備、OAuthログインやマルチテナント構成の設定がその内容です*4*6*8。自社の情報システム部門だけでこれらを完結させるには、複数の担当者が連携する体制を整える必要があるでしょう。

判断を先延ばしにしたまま自己流で構築を進めると、JWT_SECRETの強度不足やメール送信未設定といった問題に後から気づくケースが生じます。特にAGPL-3.0の遵守状況を把握しないまま自社サービスへ組み込むと、想定していなかったソースコード開示義務が生じる場面につながりかねません*7

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

専門パートナーに依頼すると、Docker環境の構築からメール配信設定、ステータス運用ルールの整備、AGPL-3.0を含むライセンス条件の確認まで一連の工程を任せられます。自社では構成検討や動作検証だけで時間がかかる場面でも、複数のフィードバック管理基盤を扱ってきた知見を活用すれば、稼働までの期間を圧縮しやすくなります。内製と外注のどちらを選ぶ場合でも、まずは自社の要望収集フローとステータス運用ルールの整理が出発点と言えるでしょう。

まとめ:Fiderセルフホスト活用の3つの判断軸

本稿ではFiderの機能とセルフホスト構築の要点を、公式ドキュメントとGitHubリポジトリの情報に基づいて整理しました。要点は次の3つに集約されるでしょう。第一に、要望投稿・投票・6種類のステータスによる進捗公開はAGPL-3.0の無料OSSで実現でき、ライセンス費用は発生しません*2*5。第二に、Docker運用・環境変数設計・メール配信整備には専門知識が必要であり、JWT_SECRETの強度確保など運用面の注意点もあります*4*8。第三に、Fiderを改変して自社サービスへ組み込む場合はAGPL-3.0のソースコード開示義務を個別に確認する必要があり、構築・運用の判断と実行は外部委託によってリスクを抑えやすくなります*7

LASSICに相談するメリット

LASSIC IT事業部は、OSSを含む要望管理・フィードバック管理基盤の構築・運用を元請(プライムベンダー)として受託しています。FiderのDocker構築からJWT_SECRET等の環境変数設計、メール配信・OAuthログインの調整、AGPL-3.0をはじめとするライセンス条件との整合確認まで一貫して対応する体制を整えています。自社での構築に不安がある企業様は、まずは現状の要望収集フローの棚卸しからご相談ください。

よくある質問

Fiderは無料で商用利用できますか。

はい、AGPL-3.0ライセンスのOSSであり、ソースコードは無料で利用・改変できます*2*7。商用環境で使う場合も、改変したソフトウェアをネットワーク経由で外部提供する際のソース開示義務等、AGPL-3.0の条件を確認したうえで運用することが大切です。

Fiderの構築にはどのくらいの専門知識が必要ですか。

Docker Composeでのコンテナ管理、PostgreSQLとの接続設定(DATABASE_URL)、JWT_SECRETの生成、メール配信設定など複数分野の知識が求められます*4*8。稼働にはPostgreSQL 12以上が前提です*4

要望への対応状況はどのように公開しますか。

各投稿(post)にopen・planned・started・completed・declined・duplicateという6種類のステータスを設定でき、運営からの返信テキストを添えて公開することも可能です*5。この仕組みを通じて対応状況をロードマップのように利用者へ開示できます。

複数のプロダクトで要望を管理できますか。

1つのFiderインスタンスで複数のフィードバックボードを運用する「マルチテナント」構成のガイドが公式ドキュメントに用意されています*6。複数プロダクトや複数ブランドの要望を使い分けて集約したい企業に向いた構成です。

セキュリティ面で注意すべき点はありますか。

認証トークンの署名に使うJWT_SECRETは十分な強度の値を設定する必要があり、公式ドキュメントは専用の生成ツールの利用を案内しています*4。インターネットに公開する場合はHTTPS化も別途ガイドに沿って設定することが推奨されます*6

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


ITアウトソーシング・システム開発のご相談はLASSICへ

元請(プライムベンダー)として、貴社の課題に合わせた体制構築・開発支援をご提案します。まずはお気軽にご相談ください。

無料相談はこちら

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

  1. *1 出典:Fider公式サイト「Fider」(https://fider.io/
  2. *2 出典:Fider公式GitHubリポジトリ「getfider/fider」(https://github.com/getfider/fider
  3. *3 出典:Fider公式ドキュメント「Self-Hosted」(https://docs.fider.io/self-hosted/
  4. *4 出典:Fider公式ドキュメント「Hosting on Docker」(https://docs.fider.io/hosting-instance/
  5. *5 出典:Fider公式ドキュメント「Posts API」(https://docs.fider.io/api/posts/
  6. *6 出典:Fider公式ドキュメント「Guides」(https://docs.fider.io/guides/
  7. *7 出典:Fider公式GitHubリポジトリ「LICENSE」(https://github.com/getfider/fider/blob/main/LICENSE
  8. *8 出典:Fider公式GitHubリポジトリ「.example.env」(https://github.com/getfider/fider/blob/main/.example.env


View