回答。

問題の歴史：

非標準またはまだ形成されていないビジネスプロセスの自動化は、明確に規定されたシナリオが存在せず、高い変動性のために長い間難しい課題とされてきました。従来のシステム分析アプローチは常に適しているわけではなく、より柔軟な方法論が必要です。

問題：

こうしたプロセスでの主な問題は、その動的さです：開始時の説明はしばしば一部の操作の本質を反映しておらず、クライアントの要件は作業の進行に伴って迅速に変化したり明確化されたりする可能性があります。

解決策：

要件を正確に特定し記述するために、反復的なアプローチ（アジャイル、リーン）を使用し、観察や迅速なプロトタイピングを通じてデータを収集し、ユーザーを積極的に巻き込み（たとえば、ワークショップを通じて）、ユーザーストーリーの形式で要件を文書化し、Confluence、Miro、Figmaなどの形式で生きた文書を補完します。アプローチの主な特徴は以下の通りです：

• ユーザーおよびビジネスチームからの継続的なフィードバックの受け入れ
• あいまいなシナリオを具体化するためのプロトタイピングと迅速なMVPの使用
• 要件の漸進的な明確化：生存可能で再現可能なものだけを固定する

トリック質問。

不安定なプロセスの分析の最初と最後で要件は同じですか？

いいえ、分析の結果、要件は変わります：一部は時代遅れになり、一部はプロトタイプの実使用後にのみ正式化されます。

変わるビジネスプロセスを一度にすべて文書化する必要がありますか？

いいえ、確認済みで機能する部分だけを文書化し、それ以外は仮説として残すか、進展に応じて明確にします。

要件を固定するための手段を一つだけ選ぶべきですか？

いいえ、さまざまな聴衆や段階のために、スタンドアップボード、電子ドラフト、プロトタイプなど、いくつかのチャネルを使用することが重要です。

典型的なエラーとアンチパターン

• すべての側面を事前に詳細にする試み（ウォーターフォール）
• ユーザーからのフィードバックを無視すること
• 確認された文書のみまたは口頭の要件のみで作業し、生きた例なしに進めること

生活の例

ネガティブなケース：

会社はまだ完全に確立されていないプロセスを自動化することに決めました。アナリストはプロセスを厳密にスキームに従って記述し、従業員が話したことをすべて文書化しました。開始後、プロセスは急速に変化し、システムは新しい現実に対応できませんでした。

メリット：

• 既存のスキームの統合が迅速に行われました。

デメリット：

• プロセスは部分的にしか自動化されず、大部分の変更が考慮されず、高額な再開発が必要でした。

ポジティブなケース：

アナリストは、安定した段階だけを部分的に文書化し、最小限の機能を持つMVPを構築し、フィードバックを収集し、ビジネスと共に要件を明確にし、変更の余地を残しました。

メリット：

• 新しい要件への迅速な適応、再作成コストの最小化。

デメリット：

• 作業の全体像をすぐに把握することができるわけではありません。