赤俊哉のレビュー一覧

ユーザー要件を正しく実装へつなぐシステム設計のセオリー

赤俊哉

ユーザー要求を正しく実装へつなぐ―システム設計のセオリー
著：赤　俊哉

情報システムの構築は、がんじがらめのなかで、細かい作業をシステムが完成するまで延々と続けていく。一行一句も間違えることができない、苦行の如しである。

基本設計と詳細設計の粒度は、本書でも明言できておらず、あいまいさを残したままである

本書は、セオリーであり、仮説であり、理論であるので、具体的な方法論については、さらに具体的な書を参考にしたほうが良いと思えるのである

要件の確認からはじまって、保守の手順の策定まで、長い長い道のりを経なければ、まともな情報システムを創ることができないと本書はいっています

気になったのは、以下です

・本書の特徴　基本設計に、論理設計と物理設計を重視する

　①要件定義（論理設計）
　②基本設計（論理設計）
　③基本設計（物理設計）
　④詳細設計（物理設計）

・システム設計における、２つの基本方針
　①最小の労力で最大の効果を実現する
　②成果物はより少なく、しかし、より良く

・設計で決める３つの定義
　①データ
　②業務プロセスとその機能
　③データと業務業務プロセスの交差点、データと機能の交差点

・データへの操作：ＣＲＵＤ：クラッド
　①Ｃ：生成
　②Ｒ：参照
　③Ｕ：更新
　④Ｄ：削除

・設計情報を一元管理せよ
　①変更時の影響分析が容易になる
　②コミュニケーションコストを削減できる

・細分化された工程

2.1.1 工程名：要求から要件へのトレース
　入力：要求仕様書、ＲＦＰ，業務規定、業務ルール
出力：要件定義書、要求要件追跡書
処理：要求を要件の形にまとめ、要求のぬけもれを防ぐ

　　要求：本当に欲しいもの
　　要件：本当に要るもの

2.1.2 工程名：設計範囲全体を把握しよう
　入力：要求仕様書、ＲＦＰ，業務規定、業務ルール、要件定義書、要求要件追跡書
出力：システム全体図
処理：対象となりシステムの全体像を把握する

　　前提条件、制約条件を明確にしておく、メモ書きで構わない

2.1.3 工程名：設計標準をつくろう
　入力：システム全体図
出力：設計標準
処理：設計を行う際の、標準規約を定める

　　文字コード
　　ＵＩ標準
　　データ標準
　　業務フローに関する標準
　　開発標準
　　コーディング規約

2.1.4 工程名：非機能要件の概要定義
　入力：要求仕様書、ＲＦＰ，業務規定、業務ルール、要件定義書
出力：非機能要件定義書
処理：非機能要件を検討し、方向性を確認する

　　非機能要件　ＦＵＲＰＳ　Ｆ：機能性、Ｕ：操作性、Ｒ：信頼性、Ｐ：性能、Ｓ：保守容易性

2.2.1 工程名：アーキテクチャ方針を考えよう
　入力：要件定義書、システム全体図、非機能要件定義書
出力：アーキテクチャー方針
処理：アーキテクチャー方針を明確にする

　　業務体系　
　　データ体系
　　適用処理体系
　　技術体系

2.2.2 工程名：システムインフラの構成を考えよう
　入力：要件定義書、システム全体図、非機能要件定義書、アーキテクチャー方針
出力：ハードウェア構成要件定義書、ソフトウェア構成要件定義書、ネットワーク要件定義書、移行要件書
処理：システムの基本構成とシステム移行に関する要件を明確にする

2.2.3 工程名：運用まわりの要件を考えよう
　入力：システム全体図、非機能要件定義書、各要件書
出力：運用要件書、信頼性要件書、性能要件書、セキュリティ要件書
処理：運用に関する要件を明確にする

3.1.1 工程名：概念データモデルをつくろう
　入力：要求仕様書、ＲＦＰ，業務規定、業務ルール、要件定義書、システム全体図
出力：概念データモデル、ビジネスルール集
処理：データ構造を見える化し、ビジネスの全体像と静的側面の概要を把握する

　　データモデルは、４種
　　①サブジェクトエリアモデル
　　②概念データモデル
　　③論理データモデル
　　④物理データモデル

3.1.2 工程名：論理データモデルを作ろう
　入力：概念データモデル、ビジネスルール集、ＴｏＢｅ詳細業務フロー図、画面ＵＩラフデザイン
出力：論理データモデル、ドメイン定義書、用語集、ビジネスルール集
処理：データ要求と静的ビジネスルールを把握する

⇒主キーの設定、正規化
　⇒用語集をつくろう

3.1.3 工程名：物理データモデルをつくろう
　入力：論理データモデル、用語集、ビジネスルール集、ドメイン定義書、論理ＣＲＵＤマトリクス、アーキテクチャー設計書
出力：物理データモデル、ドメイン定義書
処理：データ要求、静的ビジネスルールを最適に実現する実装を可能とする

3.1.4 工程名：コードを設計しよう
　入力：論理データモデル、用語集、ドメイン定義書、物理データモデル
出力：コード定義書、コード仕様書
処理：コード化が必要な属性を抽出し、コード体系を決定する

3.2.1 工程名：外部インタフェースの要件を明確にしよう
　入力：システム全体図、概念データモデル、要件定義書
出力：外部インタフェース要件定義書、概念モデル
処理：開発予定のシステムの範囲を明確化し、外部システムとのインタフェース要件を把握する

3.2.2 工程名：外部インタフェースの概要を定義しよう
　入力：外部インタフェース要件定義書、論理データモデル
出力：外部インタフェース概要定義書、論理データモデル
処理：外部インタフェースを項目単位まで確定し、連携方式を検討する

3.2.3 工程名：外部インタフェースの詳細を定義しよう
　入力：外部インタフェース概要定義書、物理データモデル
出力：外部インタフェース詳細定義書、物理データモデル
処理：外部インタフェースを確定し、連携方式を確定する

⇒連携方式とは、ETL

3.2.4 工程名：データ移行を設計しよう
　入力：移行要件書、論理データモデル、物理データモデル
出力：移行設計書、手順書、物理データモデル
処理：旧システムから新システムへのデータ移行の仕様を確定させる

3.3.1 工程名：データベースに実装しよう
　入力：物理データモデル、ドメイン定義書、外部インタフェース詳細定義書、移行設計書
出力：実装な可能なデータベース定義体、テーブル定義書、インデックス定義書、ビュー定義書
処理：実装可能なデータベース定義体を作成し、システムのデータに関する実装を確立する

　⇒チューニング
　　①インフラの対応
　　②ＳＱＬ文のチューニング
　　③データベーステーブルの非正規化

　　・ACID A:原子性　C:一貫性　I:独立性　D:永続性

4.1.1 工程名：ＴｏＢｅ業務フローの概要を定義しよう
　入力：要求仕様書、ＲＦＰ，業務規定、業務ルール、現行業務フロー、要件定義書、システム全体図
出力：ＴｏＢｅ概要業務フォロー図
処理：新システム稼働時のプロセスモデルの全容を把握できるようにする

　　ＢＤＦ，他に、ＢＰＭＮ，ＵＭＬなど
　　⇒　業務フロー図の階層は、３～５階層が目安
　　⇒　すべてのフロー図に～すると、記述する

4.1.2 工程名：ＴｏＢｅ業務フローの詳細を定義しよう
　入力：要求仕様書、ＲＦＰ，業務規定、業務ルール、現行業務フロー、要件定義書、概念データモデル、ＴｏＢｅ概要業務フローズ
出力：ＴｏＢｅ詳細業務フロー図
処理：新システムのプロセスモデルを確定する

　　⇒　粒度
　　⇒　スイムレーン

4.1.3 工程名：ＡｓＩｓ業務フローを分析しよう
　入力：要求仕様書、ＲＦＰ，業務規定、業務ルール、現行業務フロー、ＴｏＢｅ詳細業務フロー図
出力：ＡｓＩｓ業務フロー図
処理：ＡｓＩｓ業務フローを作成し、現状分析を行う

4.1.4 工程名：業務プロセス個々の概要を定義しよう
　入力：概念データモデル、ＴｏＢｅ詳細業務フロー
出力：プロセス概要定義書
処理：新システム稼働時の業務プロセスの存在意義を明確する

　　⇒　ユースケース

4.2.1 工程名：画面のラフイメージを考えよう
　入力：概念データモデル、ＴｏＢｅ詳細業務フロー図、プロセス概要定義書
出力：画面ＵＩラフデザイン
処理：該当業務プロセス、機能のデザインイメージ、必要項目の早期把握を可能にする

4.2.2 工程名：業務プロセス個々の詳細を定義しよう
　入力：ＴｏＢｅ詳細業務フロー図、プロセス概要定義補、画面ＵＩラフデザイン
出力：プロセス詳細定義書
処理：必要とされる機能と使用項目を確定する

5.1.1 工程名：画面・帳票の概要を定義しよう
　入力：ＴｏＢｅ詳細業務フロー図、プロセス概要定義書、画面ＵＩラフデザイン、プロセス詳細定義書
出力：画面帳票概要定義書（入出力定義書）、論理データモデル、機能定義書、画面ＵＩラフデザイン
処理：画面・帳票の入力要件、出力要件を明らかにしていく

IPO Input/Process/Output

⇒　必要なら、モックアップ（プロトタイプ）を作る

5.1.2 工程名：バッチ処理の概要を定義しよう
　入力：外部インタフェース概要定義書、ＴｏＢｅ詳細業務フロー図、プロセス詳細定義書
出力：バッチ概要定義書
処理：バッチ処理の概要を定義することにより、その入出力要件を明らかにする

5.1.3 工程名：論理ＣＲＵＤマトリクス分析をしよう
　入力：物理データモデル、ＴｏＢｅ詳細業務フロー図、プロセス詳細定義書、画面帳票概要定義書
出力：論理ＣＲＵＤマトリクス
処理：データとプロセス、データと機能の交差地点を明確にする

5.1.4 工程名：サブシステムに分割しよう
　入力：システム全体図、論理データモデル、論理ＣＲＵＤマトリクス
出力：サブシステム定義書
処理：システム化の管理・作業単位となるサブシステムへの分割を行う

5.1.5 工程名：物理ＣＲＵＤマトリクス分析をしよう
　入力：物理ＣＲＵＤマトリクス、物理データモデル
出力：物理ＣＲＵＤマトリクス
処理：実装イメージのデータと業務プロセス、および、データと機能の交差地点を明確にする

5.1.6 工程名：サブシステム定義を詳細化しよう
　入力：物理データモデル、サブシステム定義書、物理ＣＲＵＤマトリクス
出力：サブシステム定義書
処理：システム化の管理対象および作業単位となるサブシステムの粒度を確定する

5.2.1 工程名：機能の詳細を定義しよう
　入力：画面ＵＩラフデザイン、画面帳票概要定義書（入出力定義書）、機能定義書、サブシステム定義書、バッチ概要定義書
出力：機能定義書
処理：機能定義を確定させる

5.2.2 工程名：画面帳票の詳細を定義しよう
　入力：画面ＵＩラフデザイン、画面帳票概要定義書（入出力定義書）、サブシステム定義書、機能定義書
出力：画面帳票詳細定義書
処理：画面帳票及び、ＵＩの定義を確定する

5.2.3 工程名：バッチ処理の詳細を定義しよう
　入力：外部インタフェース詳細定義書、バッチ概要定義書、機能定義書
出力：バッチ詳細定義書、ＴｏＢｅ詳細業務フロー図
処理：バッチ処理の詳細定義として、その入力要件と出力要件を具体的に定義する

5.2.4 工程名：共通で使用する機能を定義しよう
　入力：バッチ詳細定義書、機能定義書、画面帳票詳細定義書（入出力定義書）、アークテクチャ設計書
出力：機能定義書
処理：共通で使用する機能の詳細定義を行うことにより、処理パターンの共通化を実現する

5.2.5 工程名：実装の準備をしよう
　入力：機能定義書、画面帳票詳細定義書、バッチ詳細定義書、各構成仕様書、各対策設計書、アークテクチャ設計書
出力：機能ごとの詳細定義書、システム全体の詳細定義書
処理：アプリケーションの実装に必要な事柄を整理する

　　⇒　クラス図の作成

6.1.1 工程名：ユーザビリティの要件を明確にしよう
　入力：画面ＵＩラフデザイン、プロセス詳細定義書
出力：ユーザビリティ要件定義書
処理：ＵＩのユーザビリティに関する要件を明確にする

　　⇒　画面効果、アニメーション
　　⇒　画面遷移

6.1.2 工程名：ユーザビリティの概要を定義しよう
　入力：画面ＵＩラフデザイン、ユーザビリティ要件定義書
出力：画面帳票概要定義
処理：ＵＩのユーザビリティ要件を、画面ＵＩラフデザインに反映させる

　　⇒　代表的ユーザ：ペルソナの設定

6.2.1 工程名：アクセシビリティの定義をしよう
　入力：画面ＵＩラフデザイン、ユーザビリティ設計書
出力：画面ＵＩラフデザイン、ユーザビリティ設計書
処理：ＵＩのアクセシビリティを向上させるための要件を明確にし、画面ＵＩデザインとユーザビリティ設計に反映させる

6.2.2 工程名：ユーザビリティの詳細を定義しよう
　入力：画面ＵＩラフデザイン、ユーザビリティ設計書、画面帳票詳細定義書
出力：画面ＵＩラフデザイン、画面帳票詳細定義書
処理：ユーザビリティの実現手段を画面設計として具体的に設計していく

　　⇒　操作性の確認

7.1.1 工程名：アプリケーションアーキテクチャを設計しよう
　入力：アーキテクチャ方針
出力：アーキテクチャ設計書
処理：アプリケーションアーキテクチャーを定義設計する

　　⇒　共通機能の基本方針の決定

7.1.2 工程名：システムインフラの構成仕様を固めよう
　入力：各要件書、アーキテクチャ設計書
出力：各構成仕様書
処理：要件定義段階で検討した各要件書に対して詳細定義を行う

7.1.3 工程名：運用まわりの共通仕様を固めよう
　入力：各共通要件書、アーキテクチャ設計書
出力：各対策設計書
処理：システム共通である、運用・保守、障害・セキュリティ対策の使用をまとめ、アプリケーション以外の共通設計を行う

　　⇒　運用手順、保守手順の設定

・ＳＯＡへの適用　ＳＯＡがトップダウンなら、マイクロサービスはボトムアップ

・アジャイル開発　使いどころがある、基幹システムはウォータフォールのほうが成功率は高い

目次

はじめに
設計工程と説明の流れ

序章
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・アジャイル開発への期待

あとがきに代えて
参考文献
索引

ISBN：9784865940053
出版社：リックテレコム
判型：A5
ページ数：427ページ
定価：3300円（本体）
発売日：2016年03月10日

ユーザー要件を正しく実装へつなぐシステム設計のセオリー

赤俊哉

情報システムの構築をユーザー企業側の視点で書いてくれている数少ない書籍だと思う。今後、なんども読み返すことが多くなりそう。

システム設計のセオリー II クラウドベース開発

赤俊哉 / 川又眞綱 / 中西良明

クラウドに特化したことだけではなく、ソフトウェアのシステム設計全般に必要な知識に、クラウド開発するなら考えることを付加した内容でした。

システム設計のセオリーⅠを読まずに本書を読んでみました。
先にⅠを読んだ方が良いかもしれません。

あと、誤字、脱字が目立ちました。

ユーザー要件を正しく実装へつなぐシステム設計のセオリー

赤俊哉

各設計に必要なインプットと、なぜアウトプットとして各設計書を作成するのかが説明されています。
本の内容は「〇〇を〜〜する」という内容も多く、現場で設計をする時に何をすればいいのかわからない時には役立つと思いました。
設計を十分に学習・経験された方にとっては、物足りない内容に感じてしまうかもしれません。

だまし絵を描かないための－－要件定義のセオリー

赤俊哉

冗長な表現、同じようなことをあちこちで語り直す、という感じは否めないのと、肝心の図式が抽象的すぎて、正直あまりわからない。。と、初心者は思うと思う。が、ある程度やってきてて、我流の棚卸し的に振り返る目的で読むと、言ってることのイメージわくのと、結構自分がやってきてる方法とまんま近いとこもあったので、すーっと流し読みでも満足度あった。

ユーザー要件を正しく実装へつなぐシステム設計のセオリー

赤俊哉

End to Endでドキュメント体系を整理してくれていて、かつ、それぞれのインプットアウトプットの関係も明示されているのが良かった。

ただ、そこまでやるなら、各ドキュメントの例を多少充実させた方が役立ち度は上がったと思う。
また、筆者が経験でこう思う、という類での記載が多いけれど、ベースとなっている著名な考え方などのバックボーンが弱く、なぜそうなのか？というところの後ろ支えが心許ないので、経験者のエッセイの域を出ないように感じた。

SE職場の真実 どんづまりから見上げた空

赤俊哉

実はこの書籍の著者の方とは、とあるIT系のコミュニティで面識があります。（とはいってもお会いしたのが一度だけですが・・・）
いわゆる「IT土方」からキャリアをスタートし、事業会社の情報システム部門・営業・工場責任者を経て、現在では自社のIT戦略を担当されているそうです。
興味深いのは、それまでのご自身の経験を血肉にして、業務システムに関して独自の哲学を持たれているという点です。

テクノロジーや方法論には流行り廃りがつきものですが、こうしたブレない「哲学」を貫く姿には一種の憧れのようなものを感じますし、是非自分もそうありたいと思った次第です。