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

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

はじめに

先日Kindle本が安かった時にこちらの本を購入しました。
「クラウド時代のシステム仕様のまとめ方」というキャッチフレーズに惹かれて読んでみた次第です。
私は地方のSIer所属なので、自社の設計書は世間一般のものとどう違うのかという視点で読んでみました。
結論としては大体ウチと一緒だなという感想です。
おそらくフォーマット作った人も様々なプロジェクトや書籍を参考にしたのでしょうから、当然といえば当然ですね。
トータルするとシステム設計における設計書の流れ、各設計書の意味を把握するのに良い本だと思います。

以下、読んだ上でウチとは状況が違うんだな・・・と思った点です。
もしかしたらSIerあるあるかもしれません。
そういう現場もあるんだなと思って読んでください。

設計書は必要最低限でシンプルであるべき（けどできてない）

これは全くもってその通りであると思います。
プログラマーの裁量に任せるべきなとこまで書いた重厚な設計書は書くべきではありません。
設計書レビューやメンテナンスが苦しくなるだけです。

が、私の周りに限っては「適切なメンバーを揃えることが難しく、頭数を揃えるのでやっと。」という状況が少なくありません。
（コロナ禍による案件減少で人手が余り気味なので、例えアンマッチでも仕事があるなら捻じ込まざるを得ないというまた違う場合もあります。）
従って、一から十まで書いた設計書を用意してその通りに作業してもらうよう仕向けないと回せないという状況も確かにあります。
ここまで書くならソースコード書いた方が早くない？と思うこともしばしばあります・・・。
設計書を全力で書いてレビューし、更にコーディング終わったらまたレビューはかなり辛いですね。
あのガッツリの設計書を通りに書いたのならソースコードは重箱の隅しか指摘することないですよ・・と思うこともあります。

仕方がない部分もありますよねと自分を言い聞かせてはいますが、
一から十の指示が文章ベースなのだけは大変まずいと思っています。
文章量の割には、コードに対する指示が薄いので品質が低いということがよく起きます。
現在は、クラス図やモジュール関連図を増やしていき、文章量を減らすよう活動中です。
視覚でわかる情報とコードに対する指示を増やしていき、レビューの負荷を減らしつつ身のある設計書に変えていきたいですね。

業務フローはシステムの外まで意識して書く

現状、私の周りではUMLは業務フロー（アクティビティ図）を重視しています。
ユースケース図はほとんど使っていなくて、業務フローに吹き出しなどを追加してユースケース図を兼ねてるような感じになってます。
あとは画面レイアウトを重視してますね。
私達のお客さまにはユースケース図が刺さらないことが多いので、業務フローや画面レイアウトを中心に使っています。

業務フローを書く時は「システムを中心に考えすぎない」・「システムの世界で止めない」を意識しています。
例えば、帳票を出す機能があるとしたら、「帳票を出力」で終わらせない。
出力をした帳票を「誰が見て」、「それを元に何をして」、「その結果どうなるのか？（特にお金に対する影響）」までなるべく書きます。
この辺りの考え方はシステム中心で業務フローを書いてしまったが故に、業務に対する理解が浅くなってしまったという苦い経験から来てます。

ER図はテーブル名のみ

ER図については私はテーブル名だけ書くようにして、カラムなどはER図には載せないようにしています。
理由はこれらを全体を俯瞰できることが重要だと思っているからです。
というより、テーブル数が多すぎてカラムまで載せてるととても見渡せません・・・。
システムやモジュールの分割がしっかりできてないということでもありますね💦
マイクロサービス・・・とまではいかなくても、もうちょっと分割・疎結合の方向に持ってくことが今後の課題です。

テーブル名だけでER図を書くことについては、特段問題は起きていません。
正直、データベースは大体の人が慣れてるので、カラムはわざわざER図に書かなくてもみなさんテーブル一覧・定義・DDLなどを見て把握されますね。

最後に

正しいかどうか、採用されるかどうかは別として、もっと良いやり方はないか？と考えることはとても大事だと思います。
今回紹介した本や本感想記事が各々の設計手法の答え合わせや改善に繋がると幸いです。