設計が難しいので「システム設計の謎を解く」を読んでみた

最近は設計ばかりしています。

でも設計って難しい。とちょっと心が折れかけているので助けを求めて読んでみました。

すごく勉強になったというか、認識が曖昧だったので助かりました。

基本的にウォーターホールでの開発経験しかないので、

設計とはなんぞやという私の認識は

要件定義が終わったらやるやつで、UMLで書いたりなんかめんどくさいマトリクスつくったり処理を言葉で書くやつ

ってかんじでした…

現場では要員に対して設計はスキル的に難しいが製造ならできるだろう、とかって決めたりすることがあるけど、スキルの問題と業務知識が足りないからなーと思っていたんだけどそもそも設計で何をしなきゃいけないのかをちゃんとわかっていない問題がある

いやプロジェクトとしても粒度とかはちゃんと決めないといけないってこともあるけど。

これは若手を中心だから、設計しなきゃいけないってなったら誰かが教える必要があるけどまあOJTではそもそも論みたいなのはとばされがちなので仕方ないっちゃ仕方ないのかな…

・設計は選択！

正解はないけど、機能要件・非機能要件やプロジェクトとしての指針みたいなところから最適を見つけるのが設計

・要件を満たすように設計する

いや当たり前なんだけど、そうだよね、やっぱりそうだよねって思ったところ

・設計書間の整合性を保つ

これが難しい。いつもぐちゃぐちゃになったり受け入れテストとかでNGになってだいぶ前工程まで手戻りになったり気づいたら前のやつは直さない人がいたりとか

・インプットを明確にする

気づいたらインプットから離れちゃったりするよね、あはははは

いやあ、設計って難しいしプロジェクトの中でも本当に重要だなあと思いました。

あと、例がわかりやすかった。交通費精算システムで、ありがちなんだろうな～こういうのがって思った。

あとやっぱり設計書間での矛盾がないようにするのが面倒で難しいのはいい解決方法がほしいところ

解決策～～～もし思い浮かんだら実践してみて記事をあげられるといいな

自分としては、UMLあたりをあまり触れていないのでいい設計書の書き方とか知りたいのも含めて、勉強したいところ。図解になってるとわかりやすいと思うので。

あと目下の課題がコンプライアンスの知識を増やすところかな、お客さんが結構コンプライアンスの認識が弱いので法律を盾にパワハラからみんなを守らなきゃいけなさそう。

設計をこれからやる人、設計やらされているけど正解がわからなくて困っている人に特に読んでもらいたい本なので気になった人は読んでみてください。

でぐれない