重要だと感じたポイント、気付き、今後参考にしていくべきだと感じたことをまとめてみました。今後現場で取り入れたいこと、気付きなどなどまとめ記事を作ったので是非こちらも見てください!!現場で役立つシステム設計の原則から学んだことや気づきまとめ現場で役立つシステム設計の原則第9章を読んでの気付きなど9章は要求分析と設計を同じチームや人でやることのメリットについての話が中心の章でした。それでは、印象に残った箇所を紹介していきます。大掛かりに自動実行する設備を何年も使い続けることに経済価値を生んだ。そのため従来のやり方では要件定義や設計に何ヶ月も時間をかけるのが当たり前だった。現在は顧客のニーズが多様になり、事業環境は変化を繰り返す。事業活動を支える道具である業務アプリケーションも変化に対応するために短期間での開発、修正、拡張が必要になった。本にはこのような記載がありました。要求が途中でコロコロ変わることがあまりなく、1度開発したものを修正したり拡張したりすることがなかった。それに対し、現在は要求が複雑で、ビジネス環境も変化するため短期間で開発する必要があり、変化に対応するために修正や拡張が当たり前。いう違いがあることを改めて認識しなければならないと思いました。要求分析と設計がつながらず不連続になる。その結果、本来は1つの関心事がプログラムのあちこちに書かれることになる。本にはこのような記載がありました。別のチームでまた一から読み込んで設計に落とし込む。なると、別の人が読めるようにドキュメントをかなり丁寧に作り込む必要があり、とはいえ、別チームなので認識齟齬は発生し・・・といったことになるのかなと思いました。認識齟齬なども起きなくなるかと思います。動くものが進捗として管理でき、余計なドキュメント作りの作業や、ダブルメンテナンスなどにもならずかなり効率よく進められるのかなと思います。自分が経験してきた現場では、このドキュメントを作らないというところだけを真似して、ソースコードが全て。業務ロジックがあちこちに散らばっている。いう悲惨な事態になっているところを見かけたことが何度もあります。分析と設計が一致していない場合はソースコードがドキュメントの代わりとして機能しない。それにも関わらず、設計書はない。分析と設計を頭で都度頭で変換かけながらぐちゃぐちゃなソースコードを読む必要がある。契約は準委任契約で、業務にも関心が持てるメンバーで体制を組めるとベスト見積もりまでは準委任契約で、設計以降は請負契約でとする現場がよくある。請負契約をすると、業務環境が変化した際、発注・受注側の両方で不幸になる。業務要件をそのままソースコードで表現できるメンバーで体制を組めるのがベスト。本にはこのような記載がありました。要求分析と基本設計までを準委任契約で行い、見積もりが出せたら、そこからは要求が変化することはない前提で請負契約。契約外だから・・・この要求は無理やり押し込んで・・・という現場は何度も見てきてなんども炎上してきました。契約から見直す必要があったのかと、気付かされました。要求を分析して、業務ロジックをドメインモデルで整理でき、ソースコードに落とし込める力とのバランスが求められるのは最近の現場では実感しています。いう人がチームに数人いれば一応回りますが、そうでないSEやプログラマーは徐々に求められなくなると危機感を持った方がいいのかもしれません。普段から意識して現場での作業をしていこうと思います。今求められていることに対して効率よく、品質よく開発を進めるための工夫としては何ができるのか??を考えなければなとこの章を読んで改めて思いました。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。