現場で役立つシステム設計の原則第9章を読んで|気付きや今後参考にしたいことなどをまとめてみました

はじめに

現場で役立つシステム設計の原則第9章 オブジェクト指向の開発プロセスを読んで、

今まで現場で設計をしてきた自分の観点で、

特に重要だと感じたポイント、気付き、今後参考にしていくべきだと感じたことをまとめてみました。

 

MEMO

現場で役立つシステム設計の原則を読んでみて、

今後現場で取り入れたいこと、気付きなどなど

まとめ記事を作ったので是非こちらも見てください!!

現場で役立つシステム設計の原則を読んでみて(まとめ記事)|気付きと現場で取り入れたいことについて

 

現場で役立つシステム設計の原則第9章を読んでの気付きなど

9章は要求分析と設計を同じチームや人でやることのメリットについての

話が中心の章でした。

 

それでは、印象に残った箇所を紹介していきます。

 

昔求められたものと最近求められるものとの違い

かつてはパターン化された処理を、

大掛かりに自動実行する設備を何年も使い続けることに経済価値を生んだ。

そのため従来のやり方では要件定義や設計に何ヶ月も時間をかけるのが当たり前だった。

 

現在は顧客のニーズが多様になり、事業環境は変化を繰り返す。

事業活動を支える道具である業務アプリケーションも変化に対応するために

短期間での開発、修正、拡張が必要になった。

 

本にはこのような記載がありました。

 

昔求められていたものは、

要求が途中でコロコロ変わることがあまりなく、

1度開発したものを修正したり拡張したりすることがなかった。

それに対し、現在は要求が複雑で、ビジネス環境も変化するため

短期間で開発する必要があり、変化に対応するために修正や拡張が当たり前。

という違いがあることを改めて認識しなければならないと思いました。

 

だからこそ、同じ業務ロジックをあちこちに書いたりして修正や拡張時に

大惨事にならないように、ドメインモデルでロジックの置き場をきちんと整理する必要があり、

修正を安全に影響範囲を小さくする設計が重要になるのだと・・・

 

 

要求分析と設計を1チームで行えば品質が上がり、ドキュメントが減らせ、開発スピードが上がる

従来の要求分析と設計を別担当者が行うやり方では、

要求分析と設計がつながらず不連続になる。

その結果、本来は1つの関心事がプログラムのあちこちに書かれることになる。

 

本にはこのような記載がありました。

 

要求分析をして何ヶ月もかけて作成したドキュメントを、

別のチームでまた一から読み込んで設計に落とし込む。

となると、別の人が読めるようにドキュメントをかなり丁寧に作り込む必要があり、

とはいえ、別チームなので認識齟齬は発生し・・・といったことになるのかなと思いました。

 

要求分析から設計・製造までを同じチームや同じ人でやれれば、

必要以上に丁寧にドキュメントを作る必要もなければ、

認識齟齬なども起きなくなるかと思います。

 

さらに、

要求分析の時点で、

分析結果をソースコードに記録していけると、

動くものが進捗として管理でき、余計なドキュメント作りの作業や、

ダブルメンテナンスなどにもならずかなり効率よく進められるのかなと思います。

 

 

ただ、自分が経験してきた現場では、

このドキュメントを作らないというところだけを真似して、

ソースコードが全て。

だけど、業務の内容をソースコードが表現できていない、

業務ロジックがあちこちに散らばっている。

という悲惨な事態になっているところを見かけたことが何度もあります。

 

 

分析と設計が一致していない場合はソースコードがドキュメントの代わりとして

機能しない。それにも関わらず、設計書はない。

分析と設計を頭で都度頭で変換かけながらぐちゃぐちゃなソースコードを読む必要がある。

こうなると最悪です・・・・そりゃバグも出るわ、、、

 

 

契約は準委任契約で、業務にも関心が持てるメンバーで体制を組めるとベスト

見積もりまでは準委任契約で、設計以降は請負契約でとする現場がよくある。

請負契約をすると、業務環境が変化した際、発注・受注側の両方で不幸になる。

 

プログラミングが一定レベルでき、 業務にも関心が持て、

業務要件をそのままソースコードで表現できるメンバーで体制を組めるのがベスト。

 

本にはこのような記載がありました。

 

要求分析と基本設計までを準委任契約で行い、見積もりが出せたら、

そこからは要求が変化することはない前提で請負契約。

ただ、開発が進む間にも要求が変化し、

契約外だから・・・

この要求は無理やり押し込んで・・・

という現場は何度も見てきてなんども炎上してきました。

 

開発の進め方にも問題はあるのでしょうが、

契約から見直す必要があったのかと、気付かされました。

 

 

一方で体制については、

業務環境が激しく変わり、多様な要求を分析して設計してソースコードに落とし込む

ことが求められる今、

マニアックなプログラミング力より、

要求を分析して、業務ロジックをドメインモデルで整理でき、

ソースコードに落とし込める力とのバランスが求められるのは最近の現場では実感しています。

 

そういう人がチームに数人いれば一応回りますが、

そうでないSEやプログラマーは徐々に求められなくなると

危機感を持った方がいいのかもしれません。

 

 

まとめ

現場で役立つシステム設計の原則第9章 オブジェクト指向の開発プロセスを読んで、

この辺りは自分の経験的に重要だなと感じたので、

普段から意識して現場での作業をしていこうと思います。

  • 昔求められたものと最近求められるものとの違い
  • 要求分析と設計を1チームで行えば品質が上がり、ドキュメントが減らせ、開発スピードが上がる
  • 契約は準委任契約で、業務にも関心が持てるメンバーで体制を組めるとベスト

 

まずは、

昔と今の求められていることの違いを理解し、

今求められていることに対して効率よく、品質よく開発を進めるための工夫としては何ができるのか??

を考えなければなとこの章を読んで改めて思いました。

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください