概要設計とは、システム開発の際、そのシステムに必要な機能を定義し設計し、可視化する工程です。この工程は、外部設計や基本設計とも呼ばれます。
この記事では、概要設計書について詳しく解説をしております。概要設計書の定義や記載するべき内容、書き方におけるポイントなどについてご紹介しております。
概要設計書とは？
概要設計書は、開発するシステムに必要な機能を定義し、設計したドキュメントです。
概要設計の工程では、要件定義で定めた必要な要件に対して、具体的な画面レイアウトなどを起こしていく工程になります。クライアントと必要な機能にズレがないかを画面レイアウトの設計を通して確認し、その後の詳細設計に入れるように誰が見てもどんな機能が必要なのかわかるように設計しまとめたものが概要設計書です。
概要設計は、その名の通り「概要」を設計したものになるので、実際に開発工程に入る前には、プログラマが作業できるレベルで記載された詳細設計書が必要となります。
概要設計は詳細設計に入る前のアウトラインを定める工程と言えます。
1.1概要設計書の作成目的
概要設計書を作成する目的は、要件定義で決めた要件を具体化し、クライアントとの認識を合わせ、その後の詳細設計に入るために必要なシステムのアウトラインを作成することです。
要件定義段階で作成する機能一覧では、「○○が検索できること」など文字で必要な機能が表現されているため、どうしても読み手によって解釈が分かれてしまう余地があります。概要設計では、画面レイアウトなどを起こしながら、要件定義で定めた機能を具体化していくことで、そういった認識齟齬が起きる余白を減らし、実際に作るものを明確にしていきます。そういった観点では概要設計の目的は「クライアントや開発を承認するレビュアーとの合意形成」とも言えます。
概要設計書の書き方ポイントとは？
概要設計に求められることはどの会社でも大きく変わらないと思いますが、実際の概要設計書の書き方は様々です。開発するシステムの規模や種類によっても、書く粒度は異なります。場合によっては、概要設計を承認する立場のクライアントに合わせて書き方を変えるなんてこともあります。ここでは、概要設計書を書くうえで重要なポイントについて詳しく解説をしていきます。
2.1 設計書の位置づけを明確にする
繰り返しになりますが、概要設計の目的は必要な機能を具体化し、クライアントと合意し、その後の詳細設計に入れるようシステムのアウトラインをまとめることです。
ですが、どのレベルでまとめるべきかはプロジェクトやクライアントの理解度によっても異なります。自社で利用するシステムを自社内で素早く開発するというプロジェクトであれば、関係者はシステム開発にある程度以上明るいと思われるので、必要最低限の記載でよいかもしれません。一方、クライアントから受託した案件で、クライアント側の関係者が多い場合は、誰が見てもわかるようにわかりやすくも、抜け漏れなくしっかり定めて作成する必要があるでしょう。発注者がエンドユーザーではなく、一次請けのプライムベンダーの場合、そのプライムベンダーの品質基準を満たす設計書でないとなりません。
このように目的を同じとした設計書であっても、誰向けかによって求められるレベルが変わってきます。ですのでまず書き始める前にこの設計書は、誰向けでどのレベルまで記載しないとならないのかの位置づけを明確すると良いでしょう。
2.2 設計書の記載のレベルを事前に合意しておく
概要設計の位置づけを明確にしておくことが重要とご説明しましたが、その認識が納品先であるクライアントとあっていなければ、あまり意味がありません。
クライアントから細かいレベルのものを要求されることはあまりないかもしれませんが、プライムベンダーから指摘が入ることは少なくありません。そうならないためにも、予め自社が想定する概要設計の範囲と設計書の記載内容を事前に発注元に提示し、合意をとっておきましょう。この合意は契約前にとっておかないと、想定よりも作成に工数がかかってしまい利益や納期に影響が出てしまう、なんてこともあります。時には担当窓口とは合意はとれていたのに、品質管理の部門からNGが出て再度作り直さないとならなくなるといったこともあります。こういったトラブルを避けるためにも、範囲や内容については予め確認するようにしましょう。
一方クライアント側からすると「設計書を作っていないで、早く実際に動くものを作って欲しい」なんて要望もあります。設計書はその後の工程をスムーズに進め、余計な追加コストの発生を防ぐためにあるので、しっかりとした設計書を作ることはクライアントにとってもメリットがあるのですが、ご理解いただけないケースもあります。
そうした場合には、設計書の重要性をご理解いただき、しっかりレビューについてもご協力いただくことを了承いただく必要があります。
2.3 要件定義がしっかりできているかを確認する
概要設計の前段階で作成されるのが要件定義書です。
要件定義では必要な機能要件や非機能要件を要件定義書に定めます。概要設計はこの要件定義で定めた内容を具体化する工程ですので、要件定義書が必須となります。
「要件定義は自社で行ったから、設計から入って欲しい」といった場合や「別のベンダーで要件定義は行ったから、設計から入って欲しい」といったご相談もときにはあると思います。しかし、そこで作られた要件定義書が十分かどうかは実際見てみないと判断できません。
もし、要件定義書が自社が概要設計を行えるレベルではない、あまりも粗いものであった場合、概要設計という名の要件定義をやり直すことになります。最初からその想定で見積ができていればよいのですが、仮に想定していなかった場合、コストとスケジュールに大きな影響があります。どのレベルで要件定義が完了して、どういった要件定義書が作成されているかは必ず確認しましょう。
また、自社が要件定義を行った場合でも、十分に要件が定義されているかを第三者がチェックするという運用があると安心です。スケジュールの都合上、バタバタっと要件定義を終わらせて締まっているような場合、結局概要設計の段階でしわ寄せがあるので、プロジェクトの失敗リスクが高まります。
しっかりとした概要設計を行うためには、要件定義がしっかりできているかを確認することが重要です。
画面設計書の作成ポイント概要設計書の作成・管理でよくある課題
3.1 ルールやフォーマットが統一できていない
概要設計書に限らず、社内にある書類の多くはExcelやWordで作成されていることでしょう。ExcelやWordが便利なシーンも多くあります。使い慣れているソフトを使って概要設計書を作ることは非常に楽でしょう。
ただ、ExcelやWordは個人がそれぞれで利用するものです。つまり、概要設計書が属人化してしまうのです。その結果、個人個人で概要設計書の書き方が異なるといった事態が発生します。
概要設計書に限らず、文書のルールやフォーマットは統一しなくてはいけません。しかし、ExcelやWordを使って個人が概要設計書を作成している以上、どうしてもルールやフォーマットの統一が完全にできていないという問題があります。
3.2 デグレが起きる
一度完成した文書を変更する際は、変更履歴を残しておくほうがよいでしょう。しかし、ExcelやWordで作成し、バージョン管理をするとなると、複数のファイルに分けて保存する必要があります。ファイル名に日付やバージョン番号をつけて保存する、といった運用は良く目にします。
この運用のデメリットは、複数ファイルに分かれることでデグレしてしまうリスクがあることや、同時編集にあまり向かないことです。
Microsoft365を利用することでexcelやwordを同時編集することが出来るのですが、結局複数のファイルに分かれてしまうと、作業者が古い方のファイルを編集してしまったりすることがどうしてもおきます。
運用上ルールを徹底することで、ある程度は防げますがヒューマンエラーになるので、そういったことが起きうるという前提で管理する必要があるということが課題です。
3.3 最新の設計書がどれかわからない・そもそもない
開発したシステムを改修する、追加開発する際に過去の設計書は欠かせません。ないと影響範囲の調査や仕様の理解が困難だからです。
しかし、納品時の納品物としての仕様書は残っているけど、その後保守や細かい追加開発で編集した設計書がどこにあるかわからない、といったことはよく起こります。本当に必要なのは一番最近の修正が行われた設計書なのに、見当たらず結局今のソースと納品時のソースの差分から変更点を読み取る、なんてこともあります。
社内の運用ルールを徹底すれば防げることではあるのですが、管理コストが高い運用とも言えます。実際の現場の立場からすると、ちょっとした変更であってもいちいち細かく保存して残さなければならないというのはストレスでもあります。設計書が常に最新の状態になっていると、生産性が高いことも理解しているのですが、ついつい目の前の忙しさにかまけて怠ってしまうということは日本中で起きています。
まとめ
概要設計書について詳しく解説をしてきました。概要設計書はシステム構築において欠かすことができない存在です。これからシステム構築関係の仕事をするという方は、ぜひこの記事で紹介した概要説明書についての情報を理解しておきましょう。
