システム開発の設計には、大きく分けて基本設計と詳細設計の2種類があります。詳細設計は専門的な工程のため、実際にどのような作業を行なうのかよく分からないという方も多いかもしれません。
この記事では、おもにWebシステム開発における詳細設計がどのような工程なのか、詳細設計で作成する内容や、作成する際のポイントなどと併せて説明します。
関連記事:Webシステム開発にかかる費用の相場は?コストを最適化してシステム開発を進めよう
システム開発における詳細設計とは、基本設計で定めた内容を、現実的にどのように実装していくのかを決める工程です。システム内部の仕様を定義する作業なので、内部設計とも呼ばれます。
一方で基本設計とは、システムが外から見たときにどのように動作するのか、つまり「何の機能を実装するのか」を決める工程です。外観上の動きを設計するため、外部設計と呼ばれることもあります。
例えば、Webシステム開発の基本設計では、画面をどのようなレイアウトにするのか定めます。しかし、基本設計だけでは「定めたレイアウトを実現する方法」が明確ではありません。そこで、詳細設計では「どうやってそのレイアウトを実現するのか」を考え、設計書を作成します。
つまり、詳細設計はエンジニア・プログラマー向けに、開発の指示書を作成する工程といってもよいでしょう。詳細設計を行なうことで、開発だけではなく、開発後の保守・運用の際にも役立ちます。
詳細設計は非常に専門的な内容のため、プログラミングや開発の知識がない場合は、理解が難しい部分も多くあります。しかし、詳細設計でどのようなことを行なっているのかを知ることで、発注者側としてもシステム開発全体の流れを把握するのに役立つでしょう。
なお、基本設計については以下の記事で詳しく説明しているので、併せて参考にしてください。
関連記事:システム開発の基本設計とは?作成ツールや作成時のポイントも説明
詳細設計を作成することには、どのような意味があるのでしょうか。詳細設計の具体的な役割について説明します。
詳細設計の役割を把握する際に理解しておきたい用語が、3層アーキテクチャ(3階層アーキテクチャ)です。3層アーキテクチャとは、以下の3層に分けて構造化されたシステムを指します。
1.プレゼンテーション層
2.ビジネスロジック層(アプリケーション層)
3.データ・アクセス層
これらの3層に分けて整理することで、システム全体のパフォーマンス向上や、開発・保守作業の効率化につながります。それぞれの層の特徴と管理する機能は、以下のとおりです。
システムのユーザーインターフェース部分であり、エンドユーザーが実際に目にし、操作をするのがプレゼンテーション層です。情報をユーザーに与え、同時にユーザーから情報を得る役割を持っています。
Webシステムを例に挙げると、ECサイトにおける商品の表示、クリックする部分などがプレゼンテーション層にあたります。
【管理する機能】:ページ表示の要求、HTML出力、入力値の妥当性チェック、処理結果の表示、ページ遷移 など
システムの核ともいえる部分で、プレゼンテーション層で入手した情報を処理する役割を担うのがビジネスロジック層です。
ビジネスロジックとは、システムで展開するサービス独自のフローやルールを、処理手順に反映したプログラムを指します。
各種ECサイトなど、機能が類似しているように見えるWebシステムであっても、運営企業やサービスが異なれば、ワークフローやユーザー情報の処理方法も異なるでしょう。
その独自ルールとシステム内部を連携させることが、ビジネスロジック層のおもな役割です。
【管理する機能】:ページ表示用データ取得、ユーザー情報の業務処理、データ振り分け など
プレゼンテーション層、ビジネスロジック層を経て処理された情報を、保管するのがデータ・アクセス層です。
ECサイトの例でいえば、ユーザーの購入した商品・支払いデータなどが、データ・アクセス層で管理されます。
【管理する機能】:ページ表示用データ取得、入力値の反映、他システム呼び出し など
ここまで説明したプレゼンテーション層とデータ・アクセス層の大部分は、基本設計で作業を行ないます。しかし、ビジネスロジック層が担う情報の処理フローなどは、基本設計ではカバーできません。
詳細設計の大きな役割は、インターフェースのロジックとともに、ビジネスロジックを包括的に設計・実装することです。3層アーキテクチャにおいて、共通する各種ロジックとビジネスロジックを適切にまとめておくことで、その後の開発や運用の生産性向上につながります。
つまり詳細設計とは、開発や保守・運用をスムーズに進めるために、機能やロジックをあらかじめ整理しておく作業だといえるでしょう。
ここからは、詳細設計で作成する具体的なドキュメント内容について説明します。以下は、詳細設計で作成する一例です。
アクティビティ図とは、ユーザーの行動に基づいて分岐する、システム処理の流れを示した図です。
情報の処理フローは、ユーザーの行動によって決まります。例えば、ECサイトへの訪問客を想定すると、まずログインするのか・ユーザー登録するのかで行動は分岐するでしょう。
ユーザー登録をする場合、「ユーザー情報を入力」→「ユーザー登録」→「ユーザー情報をデータベースに送信」というフローを作成します。
一方でログインする場合、「ログイン画面で情報を入力」→「データベースでユーザー情報を照会」→「認証NGを出す or 認証OKを出す」というフローが必要です。
最終的にこのユーザーがログアウトするまでには、商品購入や支払いなど、さまざまなフローが発生します。このように、行動の開始(ログイン)から終了(ログアウト)まで、ユーザーのアクションに基づく処理の流れを明確にするのが、アクティビティ図の役割です。
アクティビティ図を作成することで、システム上で想定されるユーザーのアクションや、必要な処理・機能を可視化できます。
時間軸にしたがって、プログラムの概要や処理フローを示したのがシーケンス図です。
例えば、ECサイトのユーザー登録では、次のような流れをプログラミングします。
「トップ画面:ユーザー情報の入力」→「顧客登録コントロール:登録」→「顧客登録画面:ユーザー登録画面へ転送」
シーケンス図を作成しておくことで、スムーズな開発に役立つだけではなく、どのような手順で何の処理が実行されるのかを整理できます。シーケンス図は視覚的に理解しやすいので、システム処理の流れについてクライアントとすり合わせを行なう際にも、活用できるのがメリットです。
IPOとは、ビジネスロジックやシステムの機能について、Input(入力)・Process(処理)・Output(出力)の3段階で記載した図です。IPOを作成することで、入力データの処理方法を把握し、出力データ作成までのプロセスが明確になります。
例えば、ECサイトでの商品購入の成立をIPOで表すと、以下のとおりです。
「Input:商品購入」→「Process:支払い方法の認証」→「Output:受注」
ただ、実際には1つのアクションに対するIPOは複数の処理をまとめて行なうバッチ処理の設計に、多く活用されます。
膨大な量のデータをスムーズに管理するために、システム開発では一連の流れに沿ってデータが構造化されます。データベース設計とは、何の情報をどのような構造で整理するのか、具体的に定めたものです。
そのデータベース設計において、一般的に用いられる設計図として「ER図:Entity Relationship Diagram(実体関連図)」が挙げられます。
ER図では、Entity(モノ)とRelationship(関係)を組み合わせて、処理の流れを表現します。例えば、ECサイトで「利用者が商品を購入する」という処理は、「利用者・商品」というEntityと、「購入する」というRelationshipで表されます。
このように、ER図を積極的に活用することで、複雑なシステムの構造を把握しやすくなるでしょう。
このER図は、基本的に上流工程のなかで段階的に作成されるものです。基本設計でもER図は作成されますが、実はこの時点では特定のデータベース向けの設計にはなっていません。
詳細設計で、具体的なデータベースと紐付くようにより深い部分まで設計されて、ようやくER図は完成です。
最後に、詳細設計を行なう際に気を付けるべきポイントについて説明します。
詳細設計はプログラマー・エンジニアが、開発をスムーズに進めるために行なう作業です。詳細設計を確認しながら実際にプログラミングするため、わかりにくいドキュメント内容では意味がありません。
また、保守・運用時に詳細設計を確認することもあります。詳細設計を見て「どのような処理がされているか」が一目で理解できることが、保守・運用作業にも役立つのです。
・箇条書きを活用する
・図表を使う
・文章はできるだけ短くする
・難しい言葉や造語は使わない
など、詳細設計を作成する際は、専門的でありながらもわかりやすさを徹底的に意識することが重要といえるでしょう。
システム開発の用語には、「サーバー/サーバ」「Web/WEB・ウェブ」など、表記ゆれが起こりやすいものが多くあります。表記ゆれがあると読みにくくなり、スムーズな理解の妨げになるので、極力排除することが大事です。
口調の統一(です・ます調なのか、だ・である調なのか)や、主語・視点の統一なども意識します。
詳細設計は、いわばプログラマー・エンジニアに向けた指示書です。つまり、技術的なことも含め的確な指示を開発者に伝えるには、作成者自身もプログラマー・エンジニアでなければ作成できないでしょう。
ドキュメント内容自体は専門的なため、当然相応の知識が必要です。しかし、上述のとおり、伝わりにくい言葉や構成で詳細設計を作成してしまうと、その後の開発や保守・運用に支障をきたすかもしれません。
したがって、要点をうまくまとめられる、客観的に理解しやすい資料を作成できるような者が、詳細設計を作成するのが望ましいといえます。
詳細設計を行なう際は、開発方針や開発に関するルールについて、改めて確認しておくことが大事です。
開発方針の共有がうまくいっていない場合、クライアントの発注イメージと異なるものを想定して詳細設計を進めてしまう可能性があります。
また、使用するライブラリ・プログラミング言語の指定、記述ルール書の作成なども忘れずに行なっておきましょう。
システム開発では、完全にイチから開発するのではなく、さまざまなライブラリを活用します。どのようなライブラリ・プログラミング言語を使い、どのような記述ルールのもとで設計を進めるのかをあらかじめ決めることで、効率良くスムーズに開発を進められるのです。
詳細設計は、基本設計で定めた内容を、現実的にどのように実装していくのかを決める工程です。詳細設計をしっかりと作り込んでおくことで、開発や保守作業などの生産性向上にもつながります。
専門的な内容ではあるものの、発注者側も詳細設計のドキュメント内容について知っておくことで、開発会社とのコミュニケーションがスムーズにとれるでしょう。シーケンス図など処理が可視化された資料を活用して、処理フローの共有も可能です。
途中で疑問に感じることがあれば、遠慮なく開発会社に確認してください。
DeFactoryでは、システム開発の立ち上げ支援・各フェーズのフレームワーク活用法もサポートしています。その他、アイデア着想、ユーザーヒアリング、テストマーケティング、アジャイル・MVP開発と、システム開発における立ち上げ支援を全力サポートいたします。
また、経験豊富なエンジニアと事業開発経験者で、開発だけでなく事業設計から「一気通貫」した伴走を行ないます。
事業開発や立ち上げを検討しているご担当者様がいらっしゃいましたら、問い合わせページから資料請求や無料相談などお気軽にご連絡くださいませ。