システム開発に欠かせない「共通認識」。シーケンズ図の書き方と失敗しないコツについて。

シーケンス図とは？

システム開発を行う際は、システムの設計書を書き起こし、その内容に基づいて開発を進めていきます。シーケンス図というのは、このシステム設計書で使われる、システムの概要や仕様。そしてシステムが行う処理の方法や内容を詳細に記載された図のことです。

システム開発を行う過程では様々なフェーズがあり、それらのフェーズごとに開発が進行していきますが、そのフェーズごとに詳しい内容が記載され図解化されたものがシーケンス図なので、開発中はもちろん、システムローンチ後の保守や運用の場面でも基本的なシステム内容を確認するために使われることも多いのが特徴です。

シーケンス図を作成する必要性

そもそも、なぜシーケンス図があるのでしょうか？シーケンス図が無い場合と比べると、シーケンス図があればシステム設計の段階でもフェーズごとに様々な状況を判断する物差しになり、クライアントにシステム概要を説明したり、ローンチ後の保守・運用業務や将来的な追加開発案件が発生した際にも、システムの全体像を掴みやすく、整合性を取った円滑な開発を行うことができるというメリットがあります。

システム全体の大前提が視覚化されているため、開発中のプロセスにおいても、その後の保守・運用の段階においても、関係者同士の認識齟齬やコミュニケーションミスのようなリスクを軽減できる効果があるのです。

シーケンス図の必要性やメリットについて、他にもいくつかご紹介します。

システムが処理する内容を簡潔にまとめることができる

システムが行う処理の概要や仕様、そして手順について整理することができるというのはシーケンス図を作成する大きな理由とメリットの1つです。通常、シーケンス図は定められたルールに従って視覚的に理解できるように、容易な形で記述されます。

そのため文字のみで記述された「仕様書」を読み込むよりも、視覚化されていることからシステムの詳細をより正確に、理解することができるのです。視覚化され図解化されている状態であるため、文字のみの仕様書よりも全体像をスムーズに把握することが可能で、そのことによりミスの発見も仕様書の内容と照らし合わせるよりも早く正確に行うことが可能になります。

開発規模が大きくなり、開発に関わるエンジニアの数も増えてくるとシステム概要や仕様を理解することがどうしても難しくなります。大規模な開発や複雑なシステム開発になればなるほど、シーケンス図を作成する必要性は高くなると考えて良いでしょう。

外部との状況共有や説明に利用可能

開発関係者間での共通認識として作成され、開発フェーズに合わせてシステムの処理手順などを可視化しているのがシーケンス図ですが、可視化されていることから外部＝クライアントに対して開発中のシステム概要や、仕様を説明する時にも活用することができます。

システムの概要や詳細内容をクライアントや外部の人達に説明する際には、言葉や口頭だけで説明するよりも視覚化されたもので説明するほうが良い場合があります。特にIT関連やシステムに関する知識が多くない方への説明に関しては、専門用語などを使うよりも図解などを使ってイメージとして説明したほうが理解してもらいやすいことは多々あります。

仕様書と同様に、シーケンス図もシステム全体を定義する情報がすべてまとまったものとして作成されていますので、どのようなシステムが開発されるのか？どのような処理が行われることになるのか？など、システム全体の共通認識を作る際にも非常に有効です。

保守・運用や追加の開発プロジェクトに利用可能

保守・運用段階や、追加の開発案件が発生した場合にもシーケンス図は活用することが可能です。すでに完成している既存システムのシーケンス図を参照すれば、特に追加開発の対象になる部分の概要や仕様をイメージとして把握することができますし、さらに仕様書を合わせることでより強固で確実な理解につなげることができます。現状の理解が深まり確実になれば、追加の開発要件や効果的な機能の追加など、具体的な施策や提案を行うことが可能になります。

保守・運用の場合は日常業務として行わることになるため、決まったメンバーで業務を回すことが多くなります。そのため共通認識がすでに存在する状態を保つことが比較的簡単ですが、新規の開発や追加の開発になると、新しい開発メンバーが入ってくることも多いため、以前からいたメンバーと新規のメンバー間で認識や理解に差が生まれる可能性が高まります。

また、以前開発に関わっていたメンバーであっても時間があいてしまえば開発が終了したシステムの概要や仕様を忘れてしまっていることもあるため、このような状況ではやはり視覚化されたシーケンス図があることによって記憶を取り戻す作業も効率化することができます。

その意味では、開発を進めるにあたっての共通認識構築を容易にするためのものでもありますが、シーケンス図には情報資産としての側面もあるという考え方をすることもできるのです。

シーケンス図の「構成要素」

シーケンス図は視覚化することでシステムの構成や仕様を理解できるようにするものであり、一定のルールによって作成されます。複雑なシステムになればそれだけシーケンス図そのものの構成要素も増えますが、コツを掴めば不慣れな人が見ても読み解くことができるシーケンス図を作成することができます。

システム全体を理解できるように図解することになるため、シーケンス図にはどうしても複雑なイメージを持ちがちですが、現実的には「ライフライン」「実行仕様」「停止」「メッセージ」の4つが大きな構成要素であることを抑えることでわかりやすいシーケンス図を書くことができます。

1.ライフライン

オブジェクト名やクラス名を記述し、示すための要素です。

2.実行仕様

ライフライン上で実行されることになる処理の仕様が記述された要素。設置場所はライフライン上です。

3.停止

ライフライン上で処理が実行されていない状況を示している要素です。実際の処理完了後にライフラインを破棄する際にも使われます。

4.メッセージ

送付先のライフライン上で実行される処理に対するメッセージです。同期や非同期、さらに応答、ファウンド、ロストなどの5種類から成ります。

シーケンス図内で示される様々なサイン

シーケンス図において、条件の分岐や並行して行われる処理、繰り返し行われるループ処理などを示す図形や記号のことを複合フラグメントと言います。

シーケンス図中で要素を記述しておけば、対象システムが行う処理の手順そのものを把握することは可能ですが、実際の処理内容がどのようなものなのかという具体的な内容までは判断できません。

そのためシーケンス図として、より視覚的にわかりやすく完成度を高めるために、この複合フラグメントを記述することでその後にどのような条件があり、どのような処理が行われるのかということを記述することになります。

実際に使われる複合フラグメントの記号が表す意味は以下の通りです。

1.alt＝条件分岐

2.opt＝条件が満たされた場合にのみ実行される

3.ref＝別のシーケンス図を参照する

4.par＝並列処理が行われる

5.Loop＝繰り返し処理を行う

6.break＝処理を中断する

7.critical＝マルチスレッド環境で同期処理などを行い、排他制御を行う

8.assert＝処理が妥当かどうかの定義を表す

9.ignore＝無効な処理

10.consider＝重要な処理

シーケンス図を作成するためのコツ

ここまでの解説で、シーケンス図がシステム開発における重要ツールであることはご理解頂けたことと思います。しかし、ただ作成すればいいというわけではなく、書き方のポイントを押さえておかないと、逆に理解することが難しい内容にになってしまうリスクもあります。そのため、シーケンス図の作成には書き方のコツを身につけることが必要で、コツを身につけるためにはいくつかの重要ポイントを理解しておく必要があります。

まず1つ目のコツは、シーケンス図を使う場面を想定・想像して作成することが必要です。自分だけが理解できればいいということではなく、コツとしては自分以外の誰かが読んだ時でもわかるような書き方を徹底することです。

2つ目コツは、複数のメンバーが共有することになっても内容がわかるように作成することです。共有することと同時に、複数のメンバーでシーケンス図を作成することもあり得ます。そのような場合に備えて書き方を統一し、どのような内容が書かれてもわかかるように書き方のルールを定めておくことも重要です。

3つ目のコツは、クライアントや外部の協力者などを共有することを想定して、誰にでも分かりやすい内容を意識して作成することです。シーケンス図は開発業務における様々な業務フローを、関係者が円滑に、正しく理解できるようにするために使用されるものです。そのため、可能な限り多くの人が読み取れる書き方をすることが求められます。限られた人でなければ読み取れないものは実用性が低くなってしまいますし、書き方として正しいとは言えません。

シナリオを明確にし、冗長化を避け簡潔にまとめる

シーケンス図を実際に作成する際には、開発工程のシナリオを明確にすることを意識しましょう。この部分が不明確なままではシーケンス図としての視認性が悪くなりますし、その結果として実用性も低下してしまいます。書き方の注意点としては、発注者＝クライアントとの打ち合わせ、疑問点のヒアリングと明確化を徹底することです。業務フロー自体が不明瞭なままではシーケンス図のベースが不明瞭であることになってしまうからです。

複数のシナリオを並行して記述しないということも重要です。複数のシナリオが併記されていると論点がブレてしまい、理解度が下がることにつながってしまいます。1つのシーケンス図には1つのシナリオのみを記述し、他のシナリオについて言及する場合には注意書きや外部参照、あるいは別のシーケンス図へ誘導するなどの工夫をすることがコツです。

また、あまりにも詳細に記述しすぎて、シーケンス図が冗長化し複雑になってしまうことは避ける必要があります。開発フローについては書こうと思えば相当な長文で記述することは当然可能です。詳細に説明し、できる限り正確に記載する書き方は場合によってはあり得るものです。しかし、シーケンス図のように開発フローのポイントを「誰にでもわかりやすく」「正確に」「視覚化する」ということを目的にしたものの場合は、あまりにも情報量が多すぎると本来共有すべき論点がぼやけてしまう可能性があります。

共有する相手は社内のメンバーであると同時に、社外のクライアントでもあります。双方どちらが見たとしても同じように理解できる内容にするためには、書き方や表現は統一し、なおかつどちらにとっても理解しやすい約束事に基づいて記述するのがコツです。

もし、どうしても作成するシーケンス図が長くなってしまいそうな場合は、シーケンス図そのものを複数に分けてパターン分けをしたり、外部参照として情報を追記するような工夫をすることも重要です。

詳細設計書作成における課題

システム開発を行う場合、多くの案件で課題になるのが、要件定義書や仕様書、システム設計書やシーケンス図まで含めた「ドキュメント」全般の記述ルールや作成ルールが統一されていないという点です。

記述・作成ルールが統一されていなかったり共通認識が成立していない場合は、それぞれのドキュメント作成担当者ごとに記載される様式や構成が微妙に異なったりしてしまうため、「このドキュメントはこの人でなければ作れない、説明できない」という状況を招いてしまい、作業効率に支障が出てしまう場合があります。

シーケンス図は開発工程の全体像やその後の業務フローを視覚化してわかりやすくすることを目的に作成されるものです。そのため、様々な工程に関するドキュメントをまとめることが必要なので、ドキュメントの書き方が共通化されていないと最終的にはシーケンス図の作成に時間がかかってしまうという問題が発生することになってしまいます。

シーケンス図作成工程に支障を出さないために

ドキュメント作成時に手間を発生させないためには、「誰を対象としたもので」「どのレベル、どの内容までをどこまで詳細に記載するか」などを前もって定義しておくのがコツです。最低限のドキュメント構成が決められていて、どのドキュメントも同じ構成で作成され、一定の内容が担保された状態であれば、ドキュメントそのもののクオリティーを平均化し汎用性が高まります。

シーケンス図作成の目的は開発内容の共有を汎用化することが目的ですから、記載される内容のクオリティーやレベルが平均化され、汎用性が高まった状態が理想的だと言えるのです。

まとめ

ここまでシーケンス図の書き方とコツについてご紹介してきました。シーケンス図とはどのようなものなのか？シーケンス図の必要性や、どのような構成になっているか？作成ポイントと、最終的にわかりやすく簡潔にまとめるコツなどもご紹介しました。システム設計に関わろうと思っている方は是非今回の内容を参考にしてみてください。