ものづくりに限らず、サービスなどにおいても「設計」は欠かせない工程です。住宅建築でも設計書が無いと建築は不可能ですし、記事コンテンツを作成する際も「どういった記事を書くか？」という設計の有無によって、良いコンテンツになるかどうかが分かれます。システム開発においてもこれは同じことで、設計の良し悪しによって完成するシステムの成否が変わってきてしまいます。
今回はシステム開発に携わっている方だけでなく、直接関わりが少ない方にも向けてシステム設計の位置づけと課題をご紹介します。「システム開発への理解が足りないな…」と感じている経営者や役員の方などにもぜひ参考にしていただきたいと思います。
設計ってなに？
設計という言葉には「ある目的を具体化するために、図面や計算書を使用してその方法を具体的に計画するもの」という意味があります。建設業なら住宅の設計図を作成しますし、記事コンテンツ作成の場合は骨子というテーマや大まかな構成を決めて執筆にあたります。
システム開発における設計とは、目的のシステムを開発するために必要な要素について具体的なシステム構成や構築方法などを計画してゆくことを指します。これには大まかに「基本設計」と「詳細設計」という2通りの設計があります。
≪基本設計≫
システムを使用するユーザーや運用担当者の視点から基本的な振る舞いや入出力データなどを記述した設計書を作成する工程です。前提として定義されている業務要件に沿って、そのシステムにどのような機能を実装するか、データの入出力画面のデザイン、使用するデータに関する情報や外部システムとの連携なども設計します。基本設計を細分化すると5つの設計に分かれます。
①業務フロー設計…誰がどのタイミングでそのシステムを利用するのかで、実際の業務フローに沿って設計します
②データベース設計…システムが利用するデータ(入力するもの、出力するもの)について設計します
③機能設計…システムが実行する作業内容について、ユーザーが意識しない内部的な部分も含めて設計します
④画面設計…システム画面のレイアウトやデザイン、操作方法などを設計します
⑤帳票設計…システムからどんな帳票を出力するか、印刷物や出力したファイルなどのデータ表示デザインを設計します
≪詳細設計≫
システム開発者視点でシステムの内部的な動作などを設計する工程です。「内部設計」とも呼ばれます。基本設計を具体的な実装方法(プログラム)に落とし込んで設計し、プログラマーはその設計書を参考にシステムを構築していきます。機能設計や画面設計ではログイン時のデータ表示を「氏名」「メールアドレス」などユーザー視点で記述するのに対し、詳細設計では「name」や「mail_address」などシステムが内部的に使用する名称や記述も決定します。
このように「基本設計→詳細設計」と落とし込んでいくことで、システム設計を具体化していき次の工程である「コーディング(プログラムを記述すること)」に移行します。海外も含めシステム設計には標準とされる明確な書式はありません。なので、業界や企業ごとに独自の設計書式を用いるのが一般的です。
開発モデルに見る設計の位置づけ
一口にシステム開発といっても大まかに2通りに分類されるので、開発モデルによって設計の立ち位置も変わります。ここでは、ウォーターフォール開発モデルとアジャイル開発モデルにおける設計について解説しましょう。
≪ウォーターフォール開発モデル≫
滝の水が上から下へ流れるように、上流工程から下流工程へ一連の計画で開発していく手法をウォーターフォール開発モデルと呼びます。基本としては「要件定義→基本設計→詳細設計→コーディング→テスト→完成」という流れで進んでいきます。
ウォーターフォール開発モデルは計画性が高い開発モデルなので長期プロジェクトに適しています。ただし、手戻りが発生するとプロジェクトが大幅に遅れる可能性があるため、工程ごとに明確な成果物を定めることが大切です。
基本設計と詳細設計の工程によってその後のシステム完成度が変わるため、慎重に設計を進める必要があります。
≪アジャイル開発モデル≫
ウォーターフォール開発モデルには一連の流れがあり、プロジェクト全体を通して一つに繋がっています。それに対して要件ごとに短い開発期間を設けてプロジェクトを進めていくのがアジャイル開発モデルです。システム要件の優先度から開発を進めることでプロジェクト全体の開発期間を短くし、かつ素早く完成形に近づけるという開発モデルです。その特徴から近年主流になっている開発モデルでもあります。
アジャイル開発モデルにおける設計の位置づけでは「100％の完成度を求めないこと」です。俊敏に開発できるというメリットを失わないためには、70～80％程度の完成度で素早く開発しシステムを評価、さらに改善していくというサイクルが重要になります。開発チームによっては明確な設計を持たない場合もあるでしょう。
以上のように開発モデルによって設計の位置づけは異なります。
システム開発における設計の課題とは
ウォーターフォール開発モデルにせよアジャイル開発モデルにせよ、設計工程において課題になるのが「属人化」です。属人化とは特定の人物しかその設計について理解しておらず、改修が難しい状況を指します。いずれの開発においてもひとりで完結するプロジェクトはありません。そのため次工程でありコーティングにおいても属人化は重大な課題であり、徹底的に排除しないと様々なトラブルを引き起こします。では、設計の属人化はなぜ発生してしまうのでしょうか？
理由①設計に関する基準が無い
システムを構築するためのプログラミングでは世界標準の言語を使用するので、ある程度の属人化は防げる傾向にあります。もちろんロジックの作り方には個人差がありますが、プログラミング言語のフレームワークを逸脱することはありませんので、言語さえ習得していれば理解は難しくありません。もちろん、それでも属人化が発生することはあるので、一定のガイドラインを設けて誰もが理解できるプログラムのコーディングをルール化することは大切です。
一方で設計の世界には世界標準などが存在せず、最悪の場合社内の開発チームによって設計方法やその成果物が異なります。これが設計において属人化が発生しやすい大きな理由です。
理由②標準化のための仕組みを持たない
設計から属人化を排除するためには組織が定めるルールを作成する必要があります。これを標準化というのですが、単にルールを作成するだけでは属人化は排除できません。徹底した属人化の排除には標準化の仕組みが大切です。
具体的には誰もが同じように設計を作れるツールを導入することで設計を標準化し、属人化をなくします。たとえばシステムインテグレータが提供するSI Object Browser Designerでは、専用フォームにて基本設計と詳細設計を行うことですべての開発者が同じ設計書を作成できます。
さらに項目一覧(表)を自動生成、イベントやロジック情報を入力するとI/O関連図を自動生成できます。２度手間であった作業が自動化されることにより、設計がスピーディに行えるとともに不整合や記載のミスを防ぐシステムです。
システム開発における設計は、その結果作成されるアプリケーションの品質を大きく左右します。高品質な設計を実現するためには、属人化を徹底的に排除し、かつ設計に関する間違いは早い段階で改修するという姿勢が大切です。そのためには、標準化のツールが非常に大きな役割を果たします。
皆さんがシステム開発に携わる、あるいは開発についてより深く理解したいというときはまず設計を重視し、その位置づけと重要性についてぜひご理解ください。そして標準化という最大の課題をツールでサポートすることで設計品質が向上すれば、システムはより良いものになるはずです。
