システムモデリングをする際に欠かせない絵がいくつかありますが、その中でもシーケンス図があります。この図は特定の結果を返すべきイベントのシーケンスを定義するのに使われます。まず特定のオブジェクトを並べ、その下にダッシュラインを垂直に引くのですが、これをライフラインと呼び、時間の流れを示す軸として使います。そして、水平にメッセージが伝わる様子を矢印で描きます。✨
よく描かれた様々な図は、システムを全く知らない開発者でも、全体のシステム構造や依存関係を簡単に理解し、作業に取り掛かれるという利点があります。それでも大きなシステムの場合、全ての機能やイベントの図を作成するのは負担が大きいですよね。昔は設計と開発を明確に分けて作業することが多かったため、正確なコミュニケーションのためにUMLを使っていました。しかし、最近ではAgileのように、複数の作業者が同じ場所で密に協力しながら速いペースで開発を進める方法論が流行しているため、あまり使われなくなっているようです。（もちろん、長所と短所は明確にありますので、プロジェクトの性質や周囲の状況に応じて適切に手法をカスタマイズして方法論を定義する必要がありますね。）🚀
実際、UMLや方法論よりも、ある機能を実装しようとしているのに様々な面でスムーズにいかない時や、何らかの問題を解決しなければならない時に、シーケンス図をかなり有効に活用できるという話をしたかったのです。通常、そのような作業を行う際には開発者と協力者たちが一緒に議論をしますが、互いに情報や知識のギャップがあるため、言葉だけでは状況を把握するのに思ったより時間がかかることが多いです。賢い人たちを集めても意外とそのような状況がしばしば発生します。そんな時、このシーケンス図を使えば、お互いに状況を把握し、問題を解決するのにかなり役立ちます。🔍
少し前に、チャットサービスプラットフォーム内で同じ会社が提供する認証サービスを使用する機能を実装しようとしたことがありました。しかし、満足のいくユーザー体験が得られませんでした。そこで、開発者の説明を聞きながら他の方法を探そうとしましたが、認証関連のプロセスが非常に複雑で、ざっくりと理解するだけでは問題解決が不可能だと分かりました。その時、開発者と一緒にシーケンス図をまず描きました。開発者であっても、AからZまで全ての部分を一人で開発することは稀なので、構造を誤って理解している場合がよくあります。一緒に一つ一つライフライン上にメッセージ線を描いていくと、そのような部分が整理され、現状を完全に把握することが可能になります。ここで最も重要なのは、作業を進めていて何か曖昧な場合、必ずそれを解消しなければならないということです。通常はクラス（またはサブシステム）を分離して別のライフラインを作成しますが、少し前に話した認証サービスを例に挙げてみましょう。🔄
最初に、顧客が利用するチャットプラットフォームとして一つのライフラインを作成するのは全くおかしくありません。しかし、サブシステム間のメッセージ線を描いていると、メッセージの伝達に論理的な問題が生じます。その理由は、チャットプラットフォーム内で会話スレッドの領域とインアプリブラウザが互いに排他的に動作するためです。そのような場合は、チャットプラットフォームを再度会話領域とインアプリブラウザに分けて、異なるライフラインを持つように調整すると、より完全に構造を描くことができます。（認証の場合、メッセージ（認証情報）の伝達と、どのサブシステムがその情報を知っているかが重要ですからね。）🔗
しかし、シーケンス図でも解決できない領域があります。それは、理解した状態で解決策を見つける部分です。限られた構造の中で新しい価値を生み出すにはやはり創造的な発想が必要です。ある場合には「この問題を解決する方法がない」ということをはっきり理解することもあります。それが役立ったかどうかは分かりませんが…💭
