ステート図とアクティビティ図の比較:AIの支援のもとで、どちらを使うべきか マリアが初めてカスタマーサポートチームのデジタルワークフローを構築し始めたとき、ただ一連のステップを作成しているだけだと考えていた。彼女は次のようにフローを描いた。「顧客がチケットを開く → サポート担当者が受領 → 対応 → ケースを閉じる」。シンプルで論理的だった。しかし、実際にケースを扱う中で、自分のモデルがチケットの人生を捉えていなかったことに気づいた。チケットが時間とともにどのように変化したか、一時停止したか、担当者間を何度もやり取りされたかを。 当時は気づかなかったが、彼女は2つの強力なUML図の種類、すなわちステート図とアクティビティ図。そして、どちらを使うべきか明確な基準がなかったため、彼女は常に間違った図を使い続けていた——結果として、混乱が生じ、理解の穴が生まれ、見逃されたパターンが続出していた。 AIを活用したモデリングの登場だ。 静かにクリックした瞬間、マリアはAIチャットボットにシンプルなプロンプトを開いた: 「カスタマーサポートチケットのワークフロー用のUMLアクティビティ図を生成してください。」 画面には、すっきりと流れるように配置されたステップの連続が表示された——まさに彼女が欲していたものだった。しかし、そこで彼女は一時停止した。新たな考えが浮かんだ:もしチケットのステータスが変化したらどうなるだろうか?たとえば、エスカレーションされたり、遅延されたり、フォローアップ付きで解決されたりした場合。 彼女は再び入力した: 「カスタマーサポートチケットのライフサイクルを、オープンからクローズまで示すUMLステート図を生成してください。エスカレーションや再割当といった遷移を含めて。」 結果はまったく違った。単なる順序ではなく、状態のタイムライン——それぞれに明確なトリガーと結果が設定されたものだった。一時停止やフィードバックループ、プロセスが生き生きと感じられるような条件を示していた。 この瞬間は、図の話だけではなかった。それは理解. 選択が重要な理由:現実世界のシナリオにおけるステート図とアクティビティ図の違い UMLは単なる図形や線の集合ではない。システムや行動、プロセスについて、チームが明確に話し合うための言語なのである。 アクティビティ図は何が起こるかに注
