Open1
設計とドキュメント（メモ）
tt1112システム設計とドキュメント
第1章
システム開発プロジェクトを成功させるリスク管理
- プロジェクトの成功率は高くなっている
- 定量管理の普及
- プロジェクトの規模が大きくなるほど成功率は下がる
- プロジェクトの失敗原因
- システム仕様変更が相次いだ
- 各フェーズの見積もりが甘かった
- システムの不具合など想定外の問題が発生した
- エンドユーザーの協力が得られなかった
- プロジェクト失敗が生じやすいのは全ての工程
- 上流工程に要因があり、それが下流工程での失敗につながる
- プロジェクト失敗を防ぐ３つのノウハウ
- 工程QA
- Quality Assurance 「品質保証」
- 各工程のアウトプットに問題がないことを保証する
- 見積もり審査会
- 見積もり提出前に行う
- さまざまな観点からなるチェック項目表を見積もり担当者とPMで作成する
- 体制、スケジュール、コスト、技術
- その内容を審査会で複数人が評価する
- リスク標準
- プロジェクトにおけるリスクを洗い出す
- 洗い出しは標準化しておく
- 工程QA
- プロジェクトの失敗は「プロジェクト管理の強化」と「良いドキュメント」の両輪があって初めて防げる
第2章
今、システム開発の実態はどうなっているのか
- プログラミングの工数は3割以下
- プロジェクト管理費や要件定義、稼働後フォローを含めた場合
- 設計・開発・テストだけの場合は半分
- 4:5:6:5の法則
- 要件定義 : 設計 : 製造 : テスト
- 新規開発の割合は3割以下
- 保守・運用のことをよく考えるべき
- システム開発におけるドキュメントは、新規開発だけでなく保守・運用を楽にするために重要である
第3章
システム開発ドキュメントの体系と最近の動向
- 良い設計をするための3ステップ
- 開発ドキュメントを体系化する
- 個々のドキュメントの標準化をする
- 設計者全員に設計者の技術方法をレクチャーする
- アジャイル開発の比重が大きくなっている
- アジャイルならではの設計書のあり方を考える
- カスタマイズ案件の割合が増えてる
- 一からの新規開発だけでなくカスタマイズ開発における設計書の書き方を統一する
- オフショア開発/ニアショア開発の割合が増えてる
- 阿吽の呼吸に期待しない設計書の書き方を定義する
- どの開発手法でも設計書の重要性は変わらず、それぞれに適したあり方や書き方を選択する必要がある
第4章
なぜ設計書を作成するのか
- 設計書を作成する3つの目的
- 完成イメージを共有
- プログラマーへの仕様指示
- 保守・運用の負担を軽減する
- 小さな変更でも反映させる意識がなければ設計書の信頼は落ちていく
- 設計書の品質を維持するには
- 必ずレビューをする
- モジュールの関連がわかるような設計書を書く
- 常に設計書を書くことが正解ではないが、書かないことが正解でもない
第5章
システム開発で必要とされるフロー
- 設計書の標準化によって得られる３つの効果
- 設計作業の効率化
- プログラミングの効率化
- 保守・運用の効率化
- プロセスの標準化とドキュメントの標準化
- プロセスの標準化
- WBSの標準
- 見積もりの基準
- ドキュメントの標準化
- 要件定義書
- ユースケース図
- 業務フロー
- 画面遷移図
- プロセスの標準化
- 全てのドキュメントを作成する必要はないが、システムの特性や組織の文化に合わせて自分たちの流儀を持つべき
第6章
データ中心設計（DOA）に基づいたデータモデリング
- データは構造化することで価値が生まれる
- 石油にかわって情報は産業を発達させる資源である
- 人が理解しやすいようにビジュアルなモデルにすることでデータが価値を持つ
- データを構造化してER図にする
- E（Entity）データの集合
- R（Relation）データの関係
- ３つのデータモデル←図にする
- 概念データモデル
- 論理データモデル
- 物理データモデル
- 王道のデータモデリング
- 大きなデザインから順次詳細な内容にしていく
- 可逆性がなくER図のメンテが大変
- 論物一体方式
- 論理と物理を同じ構造にする
- 中間にエンティティ図を入れる
- 論物一体モデルの定義内容
- 物理モデル情報と論理情報
- ドメイン
- コード定義
- リレーション
- 王道が正しいとは限らない、必要に応じてモデリングの仕方を変える
- アプリケーション設計とデータベース設計は同時に行われるから
- 開発の途中でデータベース定義の変更がはいるから
第7章
令和時代の設計書の基本方針
- ユーザーがイメージできるようにする基本設計
- プログラマーがプログラミングできるようにする詳細設計
- 必要最低限なことをシンプルに書く
- プログラマーの裁量に任せるべきところは書かない
- 余計な記述は仕様の誤解を招く
- 厚い設計書は読み手の読む気を奪う
- 全体を通して統一的な仕様は、別途、共通仕様書に記載する
- 必要に応じてフォーマットをカスタマイズできる
標準化は必要だが、カスタマイズできるフォーマットであること
第8章
設計書の概要説明は意外と重要
- One Fact One Place
- 一つの事実を示すデータは一つの場所だけあるべき
- 複数箇所に同じデータがあると変更の手間
- ページ（シート）ごとに記述していると、変更漏れをした際に矛盾を生んでしまう
- 項目定義書を変更したら画面レイアウトも自動で変わる、ような仕組みが必要
- 概要説明の記述に手を抜かない
- 最初に概要や役割を理解した上で読む方が理解が進む
- その設計書を読む全ての人間に理解できる内容であること
- 概要の書き方をレクチャーする運用いれて徹底する
- 変更履歴には簡潔に正確な内容を書く
- どこが変わったのか一目でわかること
- まとめるのが苦手な人のためにも書き方をレクチャーする
第9章
画面レイアウト設計の標準化
- ユーザにどのような入出力があるのかを伝える