Martin Brennan
Mar 10, 2026 • 9 min read
Discourseは高度にカスタマイズ可能なコミュニティソフトウェアであり、ユーザーの権限やその他の機能に基づいて多くの設定やインターフェースのバリエーションがあります。そのため、多くのカスタマイズや独自テーマを持つサイトでは特に、プロダクトの変更がサイトオーナーやそのメンバーにとって予期せぬ影響をもたらす可能性を予測することが難しい状況です。
私たちはこれまでもDiscourseの変更ロールアウトを管理するためにフィーチャーフラグを使用してきましたが、これらは必ずしもわかりやすいものではありませんでした。つまり、管理者はフラグがすでに有効化または削除された後まで気づかないことが多く、その時点ではすでに手遅れという状況でした…
私たちは、プロダクトの改善を続けながら、すべてのDiscourseサイトにおける予期せぬ問題や不具合のリスクを軽減する方法を見つけたいと考えていました。また、意欲的な管理者が早期にオプトインできるよう、今後予定されているエキサイティングな変更を伝えることで、プロダクトの変更が恒久的になる前にテストや準備のための十分な時間を確保できるようにしたいと思っていました。これにより、私たちのプロダクト開発チームは、物事を壊すことなく、スピーディーに動き、自由に実験することができます。
そこで登場したのが「今後の変更」システムです。これは、管理者に新機能や既存機能への変更を通知する新しい方法であり、安定性を念頭に置きながら継続的にプロダクトを革新・改善することを可能にします。
どのような仕組みになっているのですか？
すべてのDiscourseサイトには、管理者UIからアクセスできる「今後の変更」ページが追加されました。以下でその外観をご確認いただけます：
各変更にはステータス、説明、影響を受ける対象者、Discourse Metaのフィードバックトピックへのリンク、そして任意でプレビュー画像が含まれています。管理者はいつでも変更へのオプトインを選択でき、信頼できる早期採用者グループをテストに活用している場合は、サイト上の特定のグループに限定することもできます。
ただし、ステータスがExperimentalからAlphaへと進み、StableそしてPermanentへと移行するにつれて、私たちは自動的にそのサイトへの変更を有効化し、その過程で管理者に通知します。このシステムの仕組みの詳細については、Discourse Metaのアナウンストピックをご覧ください。
どのように作成したのですか？
ここからは、Discourse内で大規模なプロダクト変更がどのように計画・実行されるか、特に複数のチームや役割をまたがる変更についての経緯をたどっていきます。その過程で、私たちが遭遇したいくつかの技術的な詳細や課題を説明し、2025年8月に開発が始まって以来の「今後の変更」機能の進化についても触れていきます。
着想とプライベートRFC
このプロジェクトの始まりはかなり偶然の産物でした。私は昨年のプラハミートアップの2週間前に、同僚のJoffrey Jaffeuxを訪ねてモンペリエに滞在していました。私たちは一緒に取り組むプロジェクトを探していたところ、それ以前の数ヶ月間、Discourseプロダクトへの変更を安全かつスピーディーに行うことに関する問題が繰り返し浮上していました。
そこで、いつものランニングのためにレ川へ歩いている途中、システムがどのように機能するかについてアイデアを出し合い始め、その後数日間にわたってCEOのSam Saffron、プロダクトマネージャーのLindsey Fogle、そしてdev experienceチームのテックリードであるDavid Taylorと議論しました。反応は概して好意的で、次のステップは考えを整理してより広くフィードバックを募ることでした。
その後、選ばれたグループへのプライベートメッセージから始め、システムがどのように機能するかについての詳細なRFC（コメント募集）を送りました。これは当時、考えを明確にしてシステムの詳細を説明するために書き記すことが非常に役立ちました。書くことは考えることですので、このプロセスで答えを見つけなければならない多くの疑問が生まれました。時間が経つにつれ、カスタマープロジェクトチーム、開発マネージャー、エンジニア、プロダクトマネージャーなど、会社内のさまざまな部門や役割の参加者が加わり、プライベートメッセージは大きくなっていきました。
ここでの主なフィードバックの一つは、今後の変更をどのように分類するかという点に集約されました。最初の提案では、各変更にリスク（例：高、中、低）とタイプの両方を定義していました。しかし、リスクに関する懸念は、すべてのサイトオーナーや管理者がリスクの定義や許容範囲が異なる可能性があるという点でした。私たちが低リスクと考えるものが他の人には高リスクと見なされ、期待のミスマッチを引き起こす可能性があります。また逆に、何かを高リスクと分類することで、管理者が変更を有効にすることを極端に躊躇してしまう可能性もあります。
最終的に、カスタマープロジェクトチームのMark VanLandinghamが提案した「影響（Impact）」に落ち着きました。これはタイプと、変更が誰に影響を与えるかの指標を組み合わせたもので、私たちはこれをロール（Roles）と呼んでいます。例えば、管理者にのみ影響する機能変更もあれば、すべてのメンバーに影響する変更、あるいはテーマ開発者にのみ影響する変更もあります。
これらの会話から、最初の方向性と実装へのアプローチ方法についての考えが生まれました。このシステムでは、完全に新しいものを構築する代わりに、すでに必要なツールが多く揃っている既存の堅牢なサイト設定を活用することにしました。
サイト設定の仕組み
少し立ち止まって、私たちのサイト設定システムがどのように機能するかを説明させてください。Discourseフォーラムを設定したことがある方なら、すべてのサイト設定の大きなリストや、関連する設定を直接埋め込んだ新しい設定ページを通じて、このシステムを使用したことがあるでしょう：
サイト設定には、基本的なテキストや数値入力からドロップダウン、アップロードまで、多くの種類があります。すべての設定はDiscourseコアリポジトリ内のsite_settings.ymlファイルで定義されており、プラグインも独自に設定を定義できます。各設定には非常に多くのメタデータを添付できます。非表示か表示か、特別なバリデーションがあるか、最小値と最大値、ユーザーインターフェースで使用可能かサーバーサイドのみかなどを定義できます。すべての設定にはデフォルト値があり、管理者はそれを上書きできます。
これらの設定はアプリケーションの起動時にメモリに読み込まれ、その値はサーバーで実行されているすべてのプロセス間で同期されます。管理者がインターフェースで値を変更すると、その値をデータベースに保存し、バックグラウンドで実行されているすべてのサーバープロセスのメモリ内の値を更新する必要があります。また、MessageBusというライブラリを使用して、すべてのユーザーのウェブブラウザに新しい値を送信します。これにより、UIはサイト設定に基づいてリアクティブに変更されます。
以下はプロパゲーションの仕組みを示す基本的な図です：
これらの機能をすべて組み合わせることで、管理者がニーズに合わせて上書きできる宣言的な設定を通じて、Discourseサイトのユーザーインターフェースを簡単に制御できます。これは「今後の変更」システムが活用するのに理想的なシステムでした。私たちが行ったのは、設定にいくつかのメタデータ（ステータスや詳細情報URLなど）を追加するだけで、「今後の変更」として管理者にシンプルなユーザーインターフェースで提示できる堅牢なシステムが出来上がりました。
全社的なRFC
では、開発の経緯に戻りましょう。プライベートRFCと議論の後、全社的なRFCを作成する時が来ました。これは私たちの社内DiscourseサイトのProductカテゴリでよく行うことで、プロダクト、エンジニアリング、デザインなどさまざまな部門の異なる人々が意見を出す機会となります。
最初に、旧スタッフエクスペリエンスチームが作成した管理者ユーザーインターフェースのガイドラインと再利用可能なコンポーネントを使用して、システムのデモ用の基本的なUIが素早く作成されました。これは最初のパスとしては十分でしたが、そのページは明らかにもう少し手を加える必要がありました。シニアデザイナーの一人であるKris Aubuchonが改善を加えるために参加しました。
改善前：
改善後：
Krisはバッジを独立したカラムから外してメインのNameカラムに移し、色をより見やすいものにしました。[…]メニューは廃止されました。このメニューにはPreviewとグループ選択のインターフェースが含まれており、どちらもインラインに移動されました。モーダルを開かなくても使いやすい、よりバランスの取れたページになりました。最終的に、デザインは現在の管理者インターフェースで見られる最終形に収束しました。そこでは、Enabledがオン/オフの状態と変更の特定グループ選択の両方を組み込んだドロップダウンになっています。
最終デザイン：
全社的なRFCで起きた大きな変更の一つは、「今後の変更」が管理者に対して自動的にオンになる仕組みに関するものでした。最初は、変更に対してプロモーションバージョンが設定され、ステータスはどこまで変更が進んでいるかの視覚的な指標に過ぎないという提案でした。これはBasecampのヒルチャートに似た考え方です。
ここでプロダクトディレクターのDave McClureが指摘した主な問題は、プロモーションバージョンはいかなる変更においても予測が非常に難しいということ、そしてステータスだけでも変更の準備状況を十分に示すことができるという点でした。そのため、ステータスのみに絞ることにし、Lindseyとのさらなる議論の末、プロモーションの最終的な仕組みが決まりました。それは、各サイトについてプロモーションバージョンを非表示サイト設定で定義できるというものです。
私たちのホスティングでは、一貫性を保ちつつスムーズなロールアウト経路を確保するため、サブスクリプション層ごとにこれらを設定しています。例えば、Starterプランのホステッドサイトは、Enterpriseのお客様よりもずっと早いステータスの段階で変更が適用されます。この議論の中で、最初のステータス名をPre-AlphaからExperimentalに変更することも決まりました。
このようにすることで、このシステムを実験的な試みだけでなく、Permanentまで確実に進むことが確認されている変更にも活用できます。Experimentalな変更は継続するかどうかわからない場合もありますが、希望する幅広いユーザーがオプトインできるようにすることは依然として有用です。
プロモーションと通知システム
開発が進むにつれて、「今後の変更」システムをすべてのお客様にロールアウトする前に完了しなければならない最後の重要なマイルストーンが一つ残っていました。それは、管理者に新しい変更や、ステータスに基づいて自動的にプロモートされた変更を通知するためのシステムです。私たちは、プロモーションステータスの一つ前のステータスに達した時点で、管理者に新しい今後の変更を通知します。例えばProサイトでは、Betaでプロモートされるため、変更がAlphaステータスに達した時点で管理者に通知します。
最初、私がこれにアプローチした方法は、Ruby on Railsのイニシャライザを使用して、サイト起動時に今後の変更が利用可能またはプロモートされているかを検出し、サイトのすべての管理者に通知を送るというものでした。サイト設定のyamlファイルは常に変化していたため、サイト設定の設定に基づいてサイトがこれらの今後の変更を最初に検出した時点や、その他のイベントを追跡するための新しいデータベーステーブルを導入しました。最初にこの方向で進んだのは、バックグラウンドジョブであまり多くの作業を行うことを当初は躊躇していたためです。
しかし、developer experienceチームのDavid TaylorとLoïc Guitautによるレビューの結果、いくつかの問題点が明らかになりました。イニシャライザでこれを行うことの問題点は以下の通りです：
- Railsイニシャライザ中にデータベースを呼び出すとサイトが遅くなる可能性があり、この場合は読み取り専用モードへの対処も必要になります
- 私たちはブルーグリーンデプロイメントシステムを採用しており、2つのサイトが同時に異なるバージョンを起動できるため、一部の管理者は新バージョンに当たって通知を受け取り、他の管理者は旧バージョンに当たって通知を受け取らないという状況が発生する可能性があります
- 私たちのサイトは同一サイトに対して複数のプロセスが実行されているため、同じ処理を複数回繰り返さないようにする必要があります
このフィードバックを受けて、システムに対していくつかの大規模なリファクタリングを実施しました。その際、claude code CLIを活用して処理を移動させ、自動化されたスペックを修正しました。データベース内の今後の変更のバッキング設定を更新する代わりに、変更がステータスの閾値に達した場合は有効であると報告し、管理者が機能を手動でオン/オフに切り替えた場合はデータベースの値を報告する「仮想」設定を持つことにしました。
また、今後の変更のステータス検出と関連する通知を、20分ごとに実行されるバックグラウンドジョブで処理するように移行しました。これらの通知は時間的に重要なものではないため、起動時の問題を回避するための小さな遅延は大きな問題ではありませんでした。
最終的には、起動時の技術的な課題やエッジケースに対処することなく、管理者に最新情報を提供するシンプルなシステムが出来上がりました。
今後の展開
Discourse全体の多くのチームや部門に影響を与えるシステムの内部開発ライフサイクルの一端をご覧いただけたでしょうか！「今後の変更」システムはすでにすべてのDiscourseホステッドサイトにデプロイされており、サイト管理者であるお客様は/admin/config/upcoming-changesにアクセスして確認できます。
私たちはすでに「今後の変更」システムを使って、カテゴリ設定の簡素化、Foundationテーマの最新化、スプラッシュスクリーンへのカスタムSVG画像の許可など、いくつかのエキサイティングな新しい開発に活用しています。このシステムに対してはさらなる改善も計画しており、例えば既存の「What’s new?」管理者UIとのより深い統合などを検討しています。
変更をロールアウトするにあたって、サイト管理者からのフィードバックを歓迎しています。「今後の変更」を活用すればするほど、システムをより良くすることができます。各変更には、バグが発見された場合や管理者がアイデアや質問がある場合に投稿できる専用のMetaトピックがあります。このシステムに関する全般的なフィードバックについては、Metaのトピックをご覧ください！
原文はこちら：
Good Loopでは、Discourseのセルフホスティングを安価で提供しています。開発元であるCDCK社の協力のもと、公式ブログ記事の翻訳・公開など、日本での普及にも努めています。