シーケンス図の基礎・重要性・例について

初めに

・設計力
・論理的思考の組み立て
・納期に間に合う技術
どれも超大事で、以前上司に磨くように言われた項目です。

どんなにモダンな言語を扱えても、設計力がなかったり、論理的思考ができなったり、そもそも納期に間に合わなかったら全く意味がないのです。

ということで、一旦基礎の振り返り（インプット・アウトプット）をしてみようと思います。

※以下内容は以前私がノンビン塾で学んだ事＋α（オリジナル）の内容となります。

シーケンス図とは

シーケンス図とは、「システム開発において設計（プログラム処理の流れ等）を視覚的に表現する手法」です。

イメージしにくい場合は、身近な例でいうと理解が進むかもしれません。
「誰・何がどういう時系列で、どんな動きをするかを表現する手法」となります。（後述）

ある一定のルールに従って、視覚的に分かりやすい形で表現できる為、
文書だけの仕様書を読むよりも、システムの詳細についてスムーズかつ正確に理解することができます。

他にも、他人への説明・引継ぎ時に大活躍します。

シーケンス図の重要性

シーケンス図を読んだり書けたりすると、
１）システムの概要・仕様・手順について、自分である程度整理できるようになります。
２）他人と仕様の確認・レビューを効果的に実施できるようになります。
３）運用中の機能追加・保守・バグ修正の際に仕様の確認がすぐにできます。

ただし、仕様変更時等で常にシーケンス図を更新し続けないと、
何が正しいのか分からなくなり、混乱を招きますので要注意です。

書き方

主に使用する要素

ライフライン	実行仕様	メッセージ
オブジェクト名やクラス名が入ります。	ライフライン上で処理が実行されている事を意味します。	上から ・同期 ・非同期 ・応答 となります。

他にも条件分岐や外部参照等要素はありますが、ここではできるだけシンプルにするため割愛いたします。
※検索するといっぱいヒットします。

例題

身近な例で紹介してみようと思います。

【テーマ】
　ケニーがある課題の報告を上司に行うシーケンス図

１）ケニーが上司に報告を行い、フィードバックをもらいます。

上記のとおり、ケニーが上司に対して報告を行い、上司の中で処理され、フィードバックをもらっています。

ただしかし！
ケニーが課題に対して上司に報告する前は何もしていないのか？というと、そうでもないですよね。
色々動いて検討した結果、上司に報告しているわけです。
その辺を２）で書いてみます。

２）ケニーは上司へ報告する前に同僚Aさんに相談していました。

そう。ケニーは同僚Aさんに相談した上で、上司に報告していたんですね。

ただしかし！
同僚Aさんに相談しただけで上司に報告したのでしょうか？
その辺を３）で追加してみます。

３）ケニーは同僚Aさんからアドバイスを受け、報告内容を修正していました。

そう、同僚Aさんからのアドバイスを元に、報告内容を修正していたんですね。
このように追加すると明確に表現できるようになります。

ケニーから見るとこれで完結しているようにみえますが、実は同僚Aさんは別軸（非同期的に）で動いていた事がありました。
その辺を４）で追加してみます。

４）同僚Aさんは事前に上司に対して報告内容の概要を伝えて（根回しして）、ケニーをサポートしました。

ケニーが報告内容を修正している間に、別軸で何らか動きがあるケース。
こういったケースってよくありますよね。

ということで、ひとまず完成です。
ケニーが上司に報告する流れをシーケンス図で表現してみました。

このような感じで、実はシーケンス図って身近な事例で何でも表現する事ができます。
シーケンス図を持って上司や同僚に相談してみることで、
指摘をもらったり、アドバイスをもらいやすくなったりします。
（どの動きを改善したらよいのか、抜け漏れ等）

やってみましょう

【例題】
　あなたはある新規プロジェクトに参画しており、
　プロジェクトリーダーから課題Aを割り振られました。
　その課題Aにとりかかるところから、機能実装し、
　プルリクを出すまでの流れをシーケンス図で表現してみましょう。

最後に

シーケンス図は、普段何気ないことでも頭の中の整理をできたり、
何らか失敗した際などに、図に落としこんでみると新たな発見や改善点が見えてくるかもしれません。

日常でも十分に使えますし、常日頃から頭の中でシーケンス図を意識して生活するだけで、
実際の業務にも活きてくると思いますので、引き続き私自身もシーケンス図頑張っていこうと思います。