回答。

質問の背景:

用語集は、プロジェクトチームの全メンバー間での共通言語の基盤です。ITプロジェクトにおいて用語の解釈の違いは、論争やエラー、リターンを引き起こします。大企業では、同じ用語がビジネス、法律、ITで異なる意味を持つことがあります。用語集を導入し、維持することは、アナリストが発生する言語の障壁に対する進化的な回答です。

問題:

中央集権的な用語集がないと、「壊れた電話遊び」が生じます：普通の言葉が異なる解釈をされ、隠れた意味が増え、技術的およびビジネスの記述が食い違います。契約者と技術チームが互いに理解している保証はありません。

解決策:

• システムアナリストは、プロジェクトの開始時に用語集の作成を開始し、すべてのステークホルダー（ビジネス、IT、契約者、サポート）から用語を集めます。
• 各用語は、簡潔な説明、適用例、およびその用語の「オーナー」を示して記録されます。
• すべての参加者に表示および編集の権限がある一元的な保管場所（Confluence、Wiki、社内ポータル）を提供します。
• 要件の更新や新しいエンティティの出現に応じて、用語集に最新の変更が加えられます。
• 文書およびコミュニケーションにおいて、ビジネスまたは技術用語ごとに必ず定義へのリンクが追加されます。
• 用語集の最新性を維持する責任者（アナリストまたは特別に任命された「キーパー」）が指名されます。

重要な特徴:

• プロジェクトのすべての参加者を用語集の作成に巻き込むこと
• 文書からの用語へのリンクを強制的に導入すること
• ビジネスとITが参加する用語の論争の定期的な見直しとモデレーション

トリックのある質問。

他のプロジェクトからの既存の用語集を使用し、プロセスで追加することはできますか？

いいえ。用語が似ているにもかかわらず、同じ言葉（例えば、「クライアント」、「注文」）が異なるビジネスでは異なる現象を示します。他者の定義をコピーすることは、誤解を引き起こすだけです。

用語集はビジネスアナリストまたは言語学者の仕事だけだと考えられがちです。それは正しいですか？

いいえ、すべての人（システムアナリスト、開発、テスト、ビジネス、実装）が参加する必要があります。共同作業だけが、解釈の完全性と明確さを保証します。

用語集を単独の文書としてディスクに保存し、更新しなくてよいですか？

いいえ、静的な文書はすぐに陳腐化し、いかなる変更も迅速に反映され、プロジェクトのワークフローに統合されるべきです。陳腐化した用語集は誤った決定の元です。

一般的なエラーとアンチパターン

• 用語集が「後で」延期され、その結果、すべての文書に重複または未形式化の定義が入ります。
• 用語集の管理責任者が不在。
• プロジェクト文書で用語へのハイパーリンクを使用する必要性を無視する。

実例

ネガティブケース

大規模な金融機関には共通の用語集がなく、「支払い」という用語がさまざまな部門で異なる解釈をされていました。これにより、矛盾する指示が出され、リリースに欠陥が生じ、顧客からの苦情が発生しました。

利点:

• スタート時の時間の節約。

欠点:

• チーム間の議論、確認にかかる時間の浪費。
• インシデントや再作業の増加。

ポジティブケース

新製品では、初日からウィキ用語集が作成され、プロセスの中で更新されました。契約者と内部IT部門は自分たちの定義を常に更新し、陳腐化した用語は削除または移動されました。

利点:

• 合意の速度が速い。
• 用語の解釈の相違による論争やバグが最小限。

欠点:

• 定期的なモデレーションと用語集の構造の維持が必要。