内部設計の要素や作成時のポイントについて、疑問を抱いている方は少なくないのではないでしょうか？
本記事では、内部設計の基本から内部設計書の要素、作成時の4つのポイントについて解説しています。また、内部設計と外部設計の違いについても解説しています。
開発者が納得して作業に取り組むためにも、内部設計書の作成方法について理解を深めていきましょう。
内部設計の基本
ここではまず、内部設計の基本をおさらいしていきましょう。内部設計とは、システム開発工程の一部のことで、システムに設定する機能を具体的にどのように実現するかを決める工程のことです。
システム開発には外部設計と呼ばれる工程もあり、両者の違いが明確でない方もいるのではないでしょうか。
ここでは、内部設計の詳細だけでなく、外部設計との違いについても説明していきます。
内部設計とは？
内部設計とは、先ほども記載したとおり、システム開発におけるひとつの工程を指します。システムに求められる機能を実現するためのシステムやプログラムなど、開発者寄りの設計工程であることから詳細設計とも呼ばれます。
システム開発においては、はじめに要件定義を行い、外部設計をした後、内部設計に移るという流れでシステム設計が行われます。
内部設計の目的は、外部設計をもとにシステムの全体像を具体化していくことです。完了すると、次は各機能のプログラミング作業へと移っていきます。すべての工程でいえることですが、内部設計で実現困難な設計をしてしまうと、次のプログラミング作業に大きな負担をかけてしまうでしょう。
最悪、外部設計の見直しなど、開発が中断してしまうこともあります。各設計では、上流工程の内容を反映することも必要ですが、後の作業のことも意識して設計する必要があるでしょう。
続いては、外部設計と内部設計の違いについて、ご説明していきます。
外部設計との違い
外部設計とは、開発システムに求められる要求をどのような機能を使って実現するかを設計する工程です。外部設計は、基本設計とも呼ばれ、要件定義と呼ばれるクライアントの要求を引き出し、システムに求められる機能や目的などを決める工程で決まったことをもとに設計を進めていきます。システムの基本の設計だけでなく、開発のスケジュールや予算、保守・管理に関する取り決めを決めるなど、開発者だけでなく、ユーザーやクライアントも意識した設計をすることになります。
内部設計と外部設計の違いは、
ユーザー、クライアントから見える部分を設計するか、見えない部分を設計するかという点です。
外部設計とは、ユーザーが直接関わる部分の設計を指します。ユーザーが直接関わる部分というのは、画面の操作であったり、システムの直接的な機能だったりといった部分です。クライアントが要件定義としてシステムに求めてくる事項があります。それらのほとんどは外部設計に該当します。
対して、内部設計の成果物はほとんど開発者向けに作られます。クライアントが確認することはないため、クライアントやユーザーからは見えない部分を設計することになります。
外部設計書と内部設計書の違いについてはこちらでも詳しく記載しております。
外部設計書と内部設計書の違いとは？作成ポイントまで解説！
内部設計に必要な要素
ここでは、内部設計に必要な4つの要素について解説していきます。
機能分割
内部設計では、まず外部設計で必要と決まった機能を分割していきます。
例えばECサイトの場合だと、商品の表示、カート、注文といったように機能を分けていきます。そこから各機能ごとの設計を行っていきます。各機能の説明も記載して定義をはっきりさせておきましょう。
データフロー設計
データフロー設計では、データフロー図を作成していきます。データフロー図は、図形と線などを用いて各機能間でのデータの流れを可視化するためのものです。開発者だけでなく、ITに精通していない人でもわかりやすいため、重宝されます。
データベース設計
データベース設計ではさらに、物理設計、論理設計、索引設計の3つに分類されます。物理設計は、データを格納するための領域や格納方法を決めるため、テーブルやインデックスのを定義します。
論理設計では、データの整理や選択を行います。また、索引設計は、データベースの性能を向上させることを目的とした工程です。
入出力の設計
入出力する情報に対して、データ項目の桁数や編集の方法、詳細なレイアウトを含めた帳票設計を行います。
また、入力情報を入れたときの画面の遷移やエラーへの対応方法を決定します。
内部設計書の作成ポイント
次に内部設計書の作成時のポイントについて、4つの項目を挙げましたので順に解説していきます。いづれも読み手がプログラミング作業などを担当する開発者であることを意識しておくことがポイントです。
読み手の視点に立つ
先述した通り、内部設計の成果物は、実際にプログラミング作業を行う開発者向けに作成されます。そのため、ここでは開発者の視点に立って成果物を作成する必要があります。プログラミングに、精通していない人でも分かるように作成する外部設計の成果物とは異なり、開発者と成果物の作成者の間で、認識に違いがないように作成することが最も重要です。
まずは、説明を簡潔かつ明瞭に書くことを意識しましょう。一文一意（一つの文に一つのメッセージを込めること）なども意識して、読み手にストレスがかからない文書の作成を心がけてください。多少専門用語を織り交ぜても、内容がスッと入ってくる説明が書けるといいですね。
見出しを記載する
どこに何が書いてあるかが素早くわかるように、目次・見出しを設定しましょう。
また、見出しのフォントサイズ、種類を変えたりして、強調しておくなどもおすすめです。段落前に適切な余白を入れることでも、読み手のストレスを軽減することができます。
表記ゆれに注意する
表記ゆれなども開発者の誤解を招いたり、読み手のストレスになるので、内部設計書を作成したあとに表記のゆれがないいかどうか確認しましょう。
表記ゆれには例えば、
- 「ください」と「下さい」
- 「見積もり」と「見積」
- 「サーバー」と「サーバ」
などが挙げられます。
曖昧な表現は避ける
成果物の作成者と開発者の認識の齟齬（そご）がないように、曖昧な表現は使ってはいけません。ところどころむやみに表現を変えてみたりぜず、適切な決まった表現を用いましょう。
また、数字などを使って具体性を高めるのも効果的です。
内部設計書の作成でよくある課題とは？
ここでは、内部設計での成果物である内部設計書を作成するにあたり生じる課題について考えていきます。
内部設計書の作成で、よく見られる課題として、「設計書の属人化」が挙げられます。属人化とは、設計書の作成者以外が詳細な内容を把握できていない状態のことを指します。これを放置してしまうと、設計者に都度確認が必要になることから、作業効率の悪化が懸念されるでしょう。また、設計書の内容と異なる作業を実施してしまうなどの、トラブルも起こりえます。
では、なぜ設計書の属人化が発生してしまうのでしょうか。それは、設計書に関して、共通の基準（ルール）が存在しないことが影響しています。
「これは、こう記述すべき」「設計書は、このソフトで作成すべき」など、具体的な決まりがないため、それぞれ独自の基準のもと作成を行います。そのため、設計書によって基準が異なり、読み手側が理解できない部分が出てしまうのです。
「では、共通の基準を設ければいいのでは？」という意見もあるかと思いますが、新たにイチから決まりを作成して、設計者の間に浸透させることは、容易なことではありません。
また、最近では、設計書のテンプレートを作成するケースも増えているようですが、あまりおすすめはできません。というのも、設計内容によって必要な項目は異なり、テンプレートを作成しても、すべてのケースに活用できないからです。
まとめ
本記事では、内部設計の概要から内部設計のポイント、設計での課題と解決策を紹介させていただきました。外部設計との違いなどについても記載しており、皆さんの内部設計の理解が進んでいれば幸いです。
外部設計と内部設計での、成果物の読み手を意識して作成することで、より洗練された設計書が作成できるのではないでしょうか。
プログラム作業を担当する開発者に外部設計の決定事項を漏れなく正確に理解してもらうことで、クライアントの要求を満足させるシステム開発が行えるはずです。
