設計とは何であろう？それは２つの世界,すなわちテクノロジの世界と人間の世界の両方に属するものであり,
それらを1つにしようという試みである.[実践ソフトウェアエンジニアリング ソフトウェアプロフェッショナルのための基本知識]より抜粋
Lotus 1-2-3の開発者であるミッチ・ケーパーの言葉です。
ソフトウェア開発において設計のとらえ方は人それぞれです。
製造業においては「品質は設計で作りこむ」といわれるくらい
設計は大事な役割を担っています。
しかし、ソフトウェア開発の世界では、
残念ながら設計書を納品のためだけに後追いで作るというケースが後を絶ちません。
設計書
ソフトウェア開発において設計書と呼ばれるものは非常に多いと感じます。
呼び方も人それぞれです。
一番シンプルな呼び名は以下でしょう。
これらにどれだけのものが含まれているかは未知数ですが、
僕が携わった業務の中で一番少ない設計資料はこれです。
- 外部設計書
- 内部設計書
外部と内部という表現でMECE(ミッシー：抜けなくもれなく)になっています。
ソフトウェアを表す最初の分け方としてはこれで十分なのかもしれません。
開発するソフトウェアの規模や種類によって作成する設計書が変わってきます。
アイロベックス WBSを参考にさせてもらいました。具体的にどんな資料かわからないものもあります。
- インターフェース設計書
- コーディング仕様書
- 画面一覧表
- 画面レイアウト
- 画面処理概要
- 画面項目定義
- 画面項目チェック仕様
- メッセージ仕様
- 画面遷移図
- 帳票一覧表
- 帳票レイアウト
- 帳票処理概要
- 帳票項目定義
- DB設計書
- 区分一覧表
- コード設計書
- テーブル一覧表
- ＥＲ図
- テーブル定義書
- データ量分析表
- 共通部品一覧表
- 共通部品処理記述
- プロセスフロー
- 機能処理記述
- 機能（プログラム）一覧表
- インターフェイスフロー
- インターフェイス機能処理記述
- インターフェイス機能一覧表
- 日次運用
- 月次運用
- 締次運用
- 期末運用
- 移行計画
- 移行処理手順
- 移行ツール設計
僕はSysMLを頻繁に使用しますのでこんな感じです。
必要に応じて取捨選択します。
- 要求図
- ユースケース図
- アクティビティ図
- ステートマシン図
- シーケンス図
- パッケージ図
- ブロック定義図
- 内部ブロック図
- パラメトリック図
SysMLではありませんがデータベースも頻繁に使うので
- ER図
- テーブル定義書
また、画面がうまく表現できないので
- 画面遷移図
- 画面定義書
- 画面項目定義書
辺りを作成します。
ソースコードこそが不具合も全て書かれた設計書だという方もいらっしゃいます。
さすがに暴論だと思いますが。
本末転倒の設計書
設計書が増えてしまうと、
機能拡張したい場合に設計書への影響範囲が大きくなってしまいます。
ドキュメントの変更がおいついていない。というのは良く聞く話です。
結局ソースコードを開いて確認した方が早いから
混乱の原因となる中途半端なドキュメントはいらない。
そう主張する人がいるのも理解できなくはない。
少し話をミッチ・ケーパーの言葉に戻します。
設計とは何であろう？それは２つの世界,すなわちテクノロジの世界と人間の世界の両方に属するものであり,
それらを1つにしようという試みである.融合する試みです。融合するためにはどうすればよいのかが書かれています。
運用後を意識して設計書なんていらないと言ってしまうのは残念です。
まとめ
ソフトウェア開発における設計とは何か。
それは、「テクノロジの世界と人間の世界を1つにしようとする試み」です。
ちょっとした異世界転生。
2つの世界という時点で、テクノロジー大好きっ子にはたまりません。
設計書はいわば異世界転生法です。
是非とも興味深いものに仕上げてください。
おわり
コメントを残す