@tobiaseigen による Discourse for Teams に関するご指導、誠にありがとうございます。また、@david さん、素晴らしいニュースですね！未完了の業務管理がさらに容易になります。この投稿を利用して、なぜ私たちが Discourse に乗り換えたのか、その決定的な機能についてお話しさせていただきたいと存じます。
背景
私たちは、コロンビア市場向けにビジネス管理ソリューションを開発するソフトウェア開発者、機能アナリスト、システム管理者のチームです。ただし、私たちのロードマップには世界中が含まれています ;)。お客様向けのカスタムソフトウェア開発や独自の製品開発も行っていますが、現在の主力事業は Odoo ERP 上のサービス提供と拡張機能の提供です。Odoo が提供するすべてのアプリケーションの中で、私たちは会計、在庫、人事管理に特化しています。ご推察の通り、私たちは自社でも Odoo を広く活用しており、2015 年の設立以来、プロジェクト管理アプリケーションが最高の味方となってきました。そのカンバンインターフェース（Trello 風）により、チームは各実装プロジェクトで合意されたタスクのワークフローを管理できています。
しかし、プロジェクトの実装は顧客企業との関係の始まりに過ぎず、保守期間に入ると、効率的な管理と対外的なコミュニケーションが提供されなければ、状況は複雑化します。Odoo にはヘルプデスクアプリケーションがあり、メールを通じてユーザーとのチケットベースのコミュニケーションを管理できます。もちろん、私たちはこれもサポートサービス提供のために利用してきました。機能に関する簡単な質問への回答はこのツールで容易に管理できましたが、複雑なバグレポートが寄せられた場合、開発プロセスを支援するために別途ドキュメントを生成する必要がありました。このようなケースでは、Gitlab や Github Issues、さらには Python で社内開発したツールで解析するバージョン管理付きの restructuredtext ファイルを使用して、ベンダーに依存しない不具合報告フォーマットを確立してきました。
結果として、実行すべき作業が少なくとも 3 つの異なる場所で検索され、異なるインターフェースとワークフローを使用する状況に陥りました。日常業務を遂行するための社内外のコミュニケーションが危険にさらされ、それが「Odoo 中心主義」を破壊することになっても、代替のプロセスとツールを探すことを余儀なくされました。Discourse は長年フォーラムソフトウェアとして有名でしたが、その活動管理機能については最近、調査を行った後に初めて知りました。私たちが試すことにした動機は以下の 3 つです：非同期コミュニケーション、作業定義の均質化、そして WIP（進行中の作業）の制御です。
非同期コミュニケーション
Discourse の投稿はメールのようですが、それ以上です。WhatsApp、Slack、Messenger、Mattermost、Odoo Chat など、多くのツールが存在する現代において、私たちは常に「警戒モード」に慣れ親しんでしまいました。すべてが緊急に見えるため、短く、迅速で、表面的な回答を迫られます。考える時間もなく、修正する時間もありません。ただ書いて送信するだけです。例えばこの投稿を書くだけでも、予想よりもはるかに時間がかかりましたが、より緊急な業務を完了させた後に集中して、Discourse という素晴らしいツールに対して最も誠実で練り上げられたフィードバックを提供するために書きました（これくらいは当然のことです）。
投稿を書くことはメールを送るようなものですが、読むことは全く別の物語です。はるかに素晴らしいものです。投稿はチームの全メンバー（または許可された人々）間で一元化され、共有されます。コンテンツや場所（トピックやカテゴリなど）で検索でき、元の会話に参加していない外部ユーザーやスタッフもアクセス可能です。これは、意思決定の経緯やその背景を歴史的に記録しておくのに非常に役立ちます。
補足：python.org がメーリングリストや他の Python ベースのソリューションではなく、Discourse をコミュニティ管理アプリケーションとして採用した様子を見ると、ここで提供されているものは適合性、パフォーマンス、アクセシビリティの面で真に傑出していることがわかります。
作業定義の均質化
これが私たちが Discourse へ移行する主な理由です。前述の背景から、非常に多様で複雑な作業環境を想像されたかもしれません。確かに少し大げさに表現しましたが、設立当初から業務プロセスを文書化し、デジタルツールで管理できていました。しかし、時間が経過するにつれ、社内で「作業の単一表現」を維持できなくなりました。確かにコンサルティング活動用のタスクやサポート用のチケットはありました。開発はプレーンテキストで文書化された要件や、よく知られた Git 関連のイシューを通じて進められました。不足していたのではなく、むしろ過剰だったのです。情報源が多すぎ、共通のアプリケーション（例えば Odoo）内でも複数の形式（タスク、チケット、イシューなど）が存在しました。
もちろん、上記のいずれかを唯一の情報源として選択することもできましたが、それらのいずれも決定的な要素である「統合された外部フィードバック」を提供していませんでした。Discourse を使い始めてわずか 1 ヶ月で、ようやく製品ユーザーとつながっていると感じています。「彼ら」と「私たち」の区別はありません。なぜなら、私たちは同じインターフェースを使用しているからです。ただし、特定の領域や機能を制限することで、作業管理のコントロールを失う必要はありません。
最も素晴らしいのは、Discourse のトピックを通じて、顧客のニーズを理解するために使用しているそれらのアーティファクト（ブログコメントやヘルプデスクチケットに似たもの）を、社内限定のカテゴリで使用することで、実行予定のタスク、対応すべきイシュー、または実施すべき業務活動を表すことができる点です。私たちにとって、トピックには文脈に応じて有効な複数の同義語があります：イシュー、タスク、チケット、アクティビティ、チェックリストなど。オープンで親しみやすく、中央集権的に管理される均質な作業の形です。
Discourse for Teams について、Discourse フォーラムとは異なる別製品をリリースする予定だと読みました。つまり、Discourse（フォーラム）と Discourse for Teams は、2 つの異なるインスタンスとしてデプロイされることを意味します。その設計案については、ぜひ慎重に検討されることをお勧めします。なぜなら、その設計は組織の外部関係者と内部関係者の間で現在提供されている統合を不可避的に分断してしまうからです。
WIP 制御
最後に、Discourse を利用して得られた最大の驚きの一つは、組織内の進行中の作業（WIP）を制御できるようになったことです。実行すべき作業がすべて同じ「形」を持つため、組織が同時に保有すべき作業量の制限を定義するポリシーを策定しやすくなります。Assign プラグインを使用すると、タスクに独自の担当者（必要に応じて助けを求める「@」）が割り当てられ、その後、統合されたインターフェース（/g/staff/assigned/everyone）を使用して、システム全体の進行中の活動量（つまり WIP）を制御できます。
現在、私たちは 1 人あたり WIP 5 タスク/トピック/イシューという値で反復運用しています。チームが 14 人であるため、チームとしての最大容量は 70 です。これは私たちにとって非常に重要です。なぜなら、人生で最も難しい取り組みの一つである「見積もり」に安定性をもたらすからです。リトルの法則（https://en.wikipedia.org/wiki/Little's_law）によれば、キュー内の要素の長期的な平均数は、その平均到着率（スループット）に、各要素がシステム内に滞在する平均待ち時間を掛けたものに等しくなります。つまり、WIP を 70 に制限し、週に 140 チケットを受け取った場合、平均完了時間は 0.5 週間となり、210 チケットを受け取った場合は平均 0.33 週間となります。もちろん、これはシステムが安定状態にあり、バックログが無限に増加していないという前提に基づいています。したがって、WIP の適切な較正は反復的に行う必要があります。
私たちは（これからも常に）Discourse で表現できない作業の種類（メールメッセージの管理や CRM パイプラインの管理など）を少なからず持っていますが、実行すべき作業の大部分が Discourse トピックという単一の形を持つようになったため、WIP 制限のようなカンバンやアジャイルプラクティスの実装がはるかに容易になります。
もし Discourse for Teams が Discourse フォーラムの別インスタンスとして意図されているなら、両システム間で WIP の中央集権的で包括的なビューを維持するためのフェデレーション機能がないことは残念です。
この投稿が、コミュニケーションおよびコミュニティ構築プラットフォームとしての Discourse の改善に役立つことを願っています。改めて、このツールを提供してくださったことに心から感謝し、皆様のさらなるご活躍をお祈り申し上げます！
displays search with “Search posts by @tobiaseigen” tickbox. It would make more sense to see “Search assigned to @tobiaseigen”.
