ビジネスアナリスト、デザイナー、開発者向けのコミュニケーションとドキュメントの標準的な方法
私は個人的なプロジェクトに取り組んでおり、ビジネスアナリスト、デザイナー、開発者がプロジェクトでコミュニケーションする方法を標準化して、彼らが解決しなければならない問題と解決策について話し合っています。 UXデザインはビジネス、テクノロジー、人々の間の実行可能なバランスを打つことについて話されていますが（ここに好きなベン図を自由に挿入してください）、アナリスト、デザイナー、開発者が情報を共有するための一般的な方法があるとは思いませんでした。
UXデザイナが情報をキャプチャする方法について詳しく説明する必要はありませんが、ビジネスアナリストとソフトウェア開発者を組み合わせたものよりも多くのアーティファクトを生成すると言えます。そこで、私がこの質問をする理由の背景として、ビジネスアナリストや開発者が使用してきたいくつかのことを強調したいと思います。
ソフトウェア開発者
フロントエンドソフトウェアアプリケーションの設計と開発のほとんどは、機能（C、C++）の混合を使用する一部のバックエンドまたはエンタープライズアプリケーション設計と比較して、Web用のビルド済み開発フレームワークまたはその他のJavaScriptライブラリに向かっているようです。オブジェクト指向（Java、C＃）プログラミング言語。
オブジェクト指向またはオブジェクトベースのプログラミング言語は、実際のエンティティをモデル化して、プロパティと動作をデジタルで複製できるようにします。これは、実際のシナリオをモデル化して問題を解決しようとする数学と同じです。オブジェクト指向言語のみに限定されるわけではありませんが、UML（ nified Modeling Language ）は、問題空間をモデル化してプログラミングソリューションの開発を支援する標準的な方法で情報を取得する標準的な方法です。
興味深いことに、プログラミング言語とUXの選択についても以前の質問がありますが、少し異なるものを扱っています： プログラミング言語とUXの選択
ビジネスアナリスト
従来、 ビジネスプロセスモデリング表記 （BPMN）は、ビジネスプロセスモデルでビジネスプロセスを指定するために使用されてきました。しかし、私たちが知っているように、現在のビジネス環境は主にユーザーエクスペリエンス主導の市場に向かっているため、多くの製品とサービスは主に「人」要素に焦点を当てており、これはBPMN言語の最新バージョン（2.0 ）使用されています。
ビジネス分析におけるUMLやBPMNのようなオブジェクト指向プログラミングにはすでに慣例があるのに、ビジネスアナリスト、デザイナー、開発者が取り組んでいる問題やソリューションを伝達するための標準化された方法がないのはなぜですか？あるいは、UML、BPMN、または他のいくつかの慣例が実際にうまく使用されている例はありますか？
質問-アナリスト、デザイナー、開発者が使用する標準はありますか？
私はこのようなものに出くわしていません。そして、これが事実であると思う理由は、
- BAや開発者のように、UXデザインには実際には「標準」はありません
- 3つの異なる標準を管理するのに比べて1つの標準を維持する利点はなく（3つすべてに適合する適切なソリューションがないため）、1つではなく4つを処理することになります。
- 単一の標準を保証するには分野間にあまりにも大きな違いがあります
- 誰もそれを試みたことがない、または成功した試みがなされていない
[〜＃〜] update [〜＃〜]：この最近の質問だと思った about OOP =（オブジェクト指向プログラミング）とUXデザイン 多くの関心を集めたことは、おそらくさらに調査する価値があることを示しているため、2番目の報奨金（最初の報奨金は要求されていません）が提供されています。
TLDR;
BPMN 2.0は、より専門的な標準間のギャップを埋める標準の良い候補のようです。
私は、自動化された人間のプロセスにBPMN（2.0）ワークフローを使用する組織の一員であることから、自分の視点からのみ回答することができます。それはまだ開発中ですが、利点はすでに目に見えています。これは、会社のすべてのことを伝えます。これは、全体的なビジョンとUXに最適です。 （BPM/RPA）ワークフローに従うようにプログラムされたマシンによって処理されている注文を例にとると、ユーザーが製品を使用できるようになるまでに数分かかります。設計チームはそのワークフローを使用して、遅延が発生する場所（および理由）を確認できます（通知の送信を決定するなど）。この注文プロセスのカスタマージャーニーには、この遅延を示し、必要に応じて自動化されたプロセスにズームインできる別のBPMNワークフローがあります。このための優れた BPMNドキュメントおよび編集ツール sがあり、CRMまたはHRMシステムと同じように組織に統合されると、チームを刺激して、他のチームに対して透明性を必要とするワークフローを作成し、ワークフローを使用してシステムを自動化します。たとえば、設計チームは受信する設計要求のワークフローを使用でき、会社全体がそれを見つける場所、それを読み取る方法、したがってそのプロセスがどのように機能するかを知っています（そしておそらく改善などを提案します）。
それでも、すべての分野には、文書化、通信、自動化するための独自の方法があります。 BPMNはこれを変更する予定はありませんが、それらの間のギャップを埋めるのに適しているようです。これは、オブジェクト指向プログラミングやUML（アクティビティ図を除く）については言えません。たとえ可能であるとしても、その概念は技術的な側面に非常に基づいており、非技術者にとっては学習曲線が高く、それをサポートすることは困難です。
多くの形式のドキュメントがあるので、あなたの質問から、私はプロセスのドキュメント化についてのみ話していると思います。
Aフローチャートは、アナリスト、デザイナー、開発者が使用する標準です。
- プログラマーがアルゴリズムに注意するために使用します。
- デザイナーがユーザーインタラクションに注意するために使用します。
- アナリストがビジネスプロセスを注記するために使用します。
BPMNはフローチャートに基づいており、UMLのアクティビティ図とよく似ています。 BPMNとアクティビティ図はどちらもフローチャートの拡張機能です。 UXには標準のフローチャート拡張はないため、通常、設計者は自分で拡張します。
フローチャートはより抽象的で高レベルなものであるため、3つの役割すべてのコラボレーションにうまく使用されます。