システム設計のセオリー(システム セッケイ ノ セオリー)

システム設計には様々な考え方があります。しかし目的は明白です。
情報システムの価値を最大化するために、ユーザーと開発チームとを橋渡しして、
「ビジネスの要件を正しくシステムの実装へとつなぐ」--これ以外にありません。
本書はその手順を明示します。各工程の目的・作業内容・成果物・留意点を示しながら、
データ・業務プロセス・画面 UI といった設計対象ごとに「概要定義から詳細定義へ」
「論理設計から物理設計へ」と進める手順を説明します。
特定の開発手法や方法論に囚われることなく、情報システムを設計する上で
知っているべき原理原則、実装技術や環境変化に左右されない「システム設計のセオリー」を
厳選して集約しました。
序章
0.1 システム設計へのアプローチ

第 1 章 情報システムと設計
1.1 情報システムにおける設計
1.2 設計の全体像と基本方針

第 2 章 論理設計のはじめに
2.1 要件定義でやっておくべきこと
2.2 実装への下準備

第 3 章 データ設計のセオリー
3.1 データの設計
3.2 外部インターフェースの設計
3.3 データの実装

第 4 章 プロセス設計のセオリー
4.1 業務プロセスの概要定義
4.2 業務プロセスの詳細定義

第 5 章 機能設計のセオリー
5.1 機能の概要定義
5.2 機能の詳細定義

第 6 章 ユーザビリティ設計のセオリー
6.1 ユーザビリティの概要定義
6.2 ユーザビリティの詳細定義

第 7 章 設計の ToBe を実装の AsIs へつなぐために
7.1 インフラ系と運用系の仕様固め
7.2 SOA ・アジャイル開発への期待

ユーザーが語る業務上の要求を、開発チームが作れる仕様へ正しく翻訳する。業務システム開発の設計工程が担うこの仕事を、工程ごとの目的・作業内容・成果物・留意点の形で示すのが『システム設計のセオリー』 (赤俊哉 著、リックテレコム、 2016 年 3 月刊) です。「ユーザー要求を正しく実装へつなぐ」という冠が付き、版元はシステム設計の目的を「ビジネスの要件を正しくシステムの実装へとつなぐ」ことに置いた上で、特定の開発手法や方法論に囚われず、実装技術や環境変化に左右されない原理原則を厳選して集約した本と説明しています。プログラミングはできるのに、設計工程で何をどの順番に決めればよいか分からない開発者に向けた専門書で、若手の設計をレビューする立場の人が判断基準を言語化する助けにもなります。

序章と全 7 章、データ・プロセス・機能・ユーザビリティの設計対象別

序章「システム設計へのアプローチ」に続き、第 1 章で情報システムにおける設計の位置づけと全体像・基本方針を示し、第 2 章「論理設計のはじめに」で要件定義の段階でやっておくべきことと実装への下準備を扱います。第 3 章から第 6 章が中核で、データ設計 (データの設計・外部インターフェースの設計・データの実装) 、プロセス設計 (業務プロセスの概要定義と詳細定義) 、機能設計 (機能の概要定義と詳細定義) 、ユーザビリティ設計 (ユーザビリティの概要定義と詳細定義) を、設計対象ごとに章を分けて進めます。第 7 章「設計の ToBe を実装の AsIs へつなぐために」は、インフラ系と運用系の仕様固めと、 SOA ・アジャイル開発への期待で締める構成です。全体は序章と 7 つの章から成り、設計対象ごとの章では「概要定義から詳細定義へ」「論理設計から物理設計へ」という同じ進め方が繰り返されます。

概要定義から詳細定義へ、論理設計から物理設計へ進める理由

業務システムの設計が難しいのは、ユーザーの言葉 (業務の流れ・扱う情報・画面で見たいもの) と実装の言葉 (テーブル・トランザクション・ API ・画面部品) の間に翻訳が必要で、しかもその翻訳を一気に行うと、後で業務理解の誤りが見つかったときの手戻りが実装全体に波及するからです。そこで、まず概要を定義して業務の骨格を固め、合意が取れてから詳細へ降りる。データについても、まず論理設計で「何を管理するか」を実装技術と切り離して決め、次に物理設計で DBMS や性能の制約を反映する。二段構えにするのは、決めるべきことを決める順番に並べて後戻りのコストを小さくする、手順上の工夫です。設計対象をデータ・プロセス・機能・ユーザビリティに分けるのも同じ理由で、一つの成果物に全部を詰め込むと、どこが未決定かが見えなくなります。目次でデータ設計がプロセス設計や機能設計より前に置かれている順序は、業務手順より寿命が長いデータ構造を先に固めるという業務システム設計の伝統的な考え方と整合します。第 2 章が 要件定義 の段階でやっておくべきことから始まるのも、翻訳の入力を先に整えるという意味で理にかなった並びです。

開発手法に依存しないセオリーという立ち位置、 2016 年刊の前提と類書

本書は特定の開発手法や方法論に依存しないと版元が明記しており、ウォーターフォールの成果物一覧でもなければ、アジャイルの実践書でもありません。第 7 章の節題に SOA とアジャイル開発が「期待」として並ぶことは、 2016 年 3 月という刊行時点の技術環境を映しています。マイクロサービスやクラウドネイティブといった語彙で語られる 2020 年代のアーキテクチャ論をこの本に求めるのは筋が違いますが、データをどう切り分け、業務プロセスと機能をどう対応させ、画面で何を見せるかという判断は、実行環境が変わっても残る部分です。類書との使い分けでは、羽生章洋『はじめよう! システム設計』 (技術評論社、 2018 年) が UI ・機能・データの三点を手早く読める導入書として先に置けるのに対し、本書は工程・成果物・留意点を設計対象ごとに書き下ろした本として、その次に読む位置にあります。ドメインモデルを中心に据える ドメイン駆動設計 とは出発点が異なり、本書は工程と成果物の側から設計を組み立てる立場です。コードからシステムまでの設計書をレイヤーごとに学ぶ順番は 設計・アーキテクチャ本ガイド に整理しています。

業務システムの設計を任された人に向く前提と、向かない人

前提として、何らかの業務システムの開発に携わった経験と、リレーショナルデータベースの基本 (テーブル・キー・正規化の考え方) があると、データ設計の章を実感を持って読めます。データ設計を深く掘るなら、データベース本ガイド に挙げた設計寄りの本を併読すると、論理設計と物理設計の中身が具体化します。一方で、クラスやモジュールの分け方、デザインパターンといったコードレベルの設計を学びたい人には本書は射程外です。個人で Web サービスを作る場面のようにユーザーと開発者が同一人物なら、本書が前提とする橋渡しの必要性自体が薄くなります。版元の分類上も専門書に位置づけられており、入門書というより体系書として読む本です。

元が取れるのは、 SIer や社内情報システム部門で初めて設計工程を任された開発者、レビューで「なぜその設計なのか」を若手に説明する言葉を持ちたいリーダー、そして要件定義と実装の間で仕様の抜けを何度も経験してきた人です。読み終えると、設計書を「書式を埋める作業」ではなく「決めるべき事項を順番に確定させる作業」として組み立てられるようになり、どの工程で何が未決定かを自分の言葉で指摘できます。手法の流行に左右されない設計の骨格を一冊で持ちたい人にとって、 2016 年刊であることは弱点ではなく、長く手元に置ける理由になります。