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

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

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

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

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

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

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

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

令和時代の設計書の基本方針（p. 97）

設計書を読んで，ユーザーがイメージできる（基本設計）

設計書を読めば，プログラマーがプログラミングできる（詳細設計）

プログラマーの裁量に任せるべきところまでは書かない

全体を通しで統一的な仕様は，別途，共通仕様書に記載する

必要最低限なことをシンプルに各（「厚い」より「薄い」方が価値がある）

必要に応じてフォーマットをカスタマイズできる

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

この言葉（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）

「チェックリスト点検」から「リスクベース思考」へ転換する

「インフラ」ではなく「ビジネス」を守る

セキュリティリーダーは，「ディフェンダー」ではなく「ファシリテーター」になる

情報フローを「制御」するのではなく「理解」する

セキュリティ技術の限界を理解する

セキュリティ被害は避けられないと認める

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