Masassiah Blog

現役サラリーマンのスキルアップのための読書まとめ

エンジニアなら知っておきたいシステム設計とドキュメント

『エンジニアなら知っておきたいシステム設計とドキュメント』(梅田 弘之,インプレス,2022年1月21日)を読了。

遅延原因のトップは,「システムの仕様変更が相次いだ」というものです。これは,それ自体が根本的な原因というよりも,例えば「要件定義や基本設計が甘かった」などによって生じたものと考えられます。(p. 11)

私が携わる業務システムの抜本的な改修は,要件定義のフェーズにある。

ここで,しっかり仕様を決めていけば,システムの仕様変更のリスクを低減することができる。

プロジェクト管理手法「PYRAMID」→統合型プロジェクト管理システム SI Object Browser PM

設計ドキュメント標準「DUNGEON」→ソフトウェア設計書作成 CAD SI Object Browser Designer(p. 41)

プロジェクト管理手法と設計ドキュメント標準のノウハウは,取り入れていきたい。

令和時代の設計書の基本方針(p. 97)

  1. 設計書を読んで,ユーザーがイメージできる(基本設計)
  2. 設計書を読めば,プログラマーがプログラミングできる(詳細設計)
  3. プログラマーの裁量に任せるべきところまでは書かない
  4. 全体を通しで統一的な仕様は,別途,共通仕様書に記載する
  5. 必要最低限なことをシンプルに各(「厚い」より「薄い」方が価値がある)
  6. 必要に応じてフォーマットをカスタマイズできる

ユーザにも読んでもらえる基本設計書を書けるようになろう。

この言葉(One Fact One Place)は世界的な ERP ベンダーの SAP が広めたもので,1 つの事実を示すデータは 1 つの場所にしか存在させないという意味です。(p. 106)

One Fact One Place になっているかを確認しよう。

C : Create (データの作成)

R : Read (データの読出)

U : Update (データの更新)

D : Delete (データの削除)(p. 157)

CRUD の概念を知っておく。

令和時代の非機能要件(p. 165)

非機能要件の大枠を検討するときの参考にしよう。

セキュリティの 6 つの基本原則(p. 209)

  1. 「チェックリスト点検」から「リスクベース思考」へ転換する
  2. 「インフラ」ではなく「ビジネス」を守る
  3. セキュリティリーダーは,「ディフェンダー」ではなく「ファシリテーター」になる
  4. 情報フローを「制御」するのではなく「理解」する
  5. セキュリティ技術の限界を理解する
  6. セキュリティ被害は避けられないと認める

セキュリティの基本原則であるが,別の分野にも応用できそうだ。

更新履歴