【1章~2章】Clean Architectureを読んで変更に柔軟なシステムを作る！@Clean Architectureを読んで学んだことメモ

メンテナンスしやすいシステムが作りたい！
いや、Webエンジニアとして作らねばならない！

ということで読み始めました
「Clean Architecture 達人に学ぶソフトウェアの構造と設計」！

読んだ章から学んだことや感じたことを自分のメモとして順番にまとめていきたいと思います。「これは少し違うんじゃない？」などあればコメントで頂けると嬉しいです！

第1章 設計とアーキテクチャ

システム開発にかけられるお金・人手・時間は限られています。その限られたリソースで必要な条件を満たすシステムを作るためにアーキテクチャを学ぶ必要があります。
また、知識が無い状態では同じ過ちを繰り返してしまいます。「このシステム、一から作り直した方が早いだろう。」と感じることがあっても、アーキテクチャの知識が無ければ同じ問題を抱えたシステムが生まれてしまいます。本書を読んでクリーンで優れたアーキテクチャを学びましょう。

第2章 2つの価値のお話

作り終わったらそれっきりというのはシステムは存在しないと思います。後で変更が加えられることになったとしても、対応できるようなアーキテクチャである必要があります。

■開発者の責任は『アーキテクチャの重要性を主張すること』である。

本書には、『ビジネスマネージャーが重要視するのは「振る舞い」である。
そして「アーキテクチャ」の重要性が軽視され、変更しにくいシステムが出来上がってしまう』とあります。

ここで「ビジネスマネージャーとは」で検索してみました。

BMの仕事が一番大事になるのは、受注後の遂行段階である。そして、客先との交渉（ならびに、その準備）が主要な仕事の柱となる。追加や変更に伴う交渉においては、BMが過去の書類やメールなど、証拠（エビデンス）を全部まとめ上げる仕事をしてくれる。そして変更に伴うインパクトや、作業費用を見積もるのもBMだ。
引用：https://brevis.exblog.jp/25905973/

上記の内容から、システム開発だと「プロジェクトマネージャー」が当てはまるのではないかと思います。

そのため、プロジェクトマネージャーの言うままにただ従うだけではなく、開発者としてアーキテクチャの重要性を主張することが"開発者の責任"である、というように理解しました。そうしなければ出来上がるのはコスパの悪いシステムであり、開発者には不具合修正に追われる日々が待ち受けている…恐ろしいです。

プロジェクトマネージャーに意見するのは少し気が引けるかもしれませんが、良いシステム開発のためには「振る舞い」と「アーキテクチャ」両方の価値が優れている必要があります。これからの自分たちのためにも「アーキテクチャがなぜ必要か」ということを理解し、開発者としての責任を果たせるようにしましょう。

おわり

まずは1章、2章を読みました。
『システム開発にはアーキテクチャが重要であり、その重要性を主張することが開発者の責任である』という内容でした。根拠あるアーキテクチャの重要性が主張ができるように引き続き読んでいきたいと思います。
それでは！

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)