ソフトウェア設計で大切なこと
同僚が書籍を読んだアウトプットとしてものすごく重要で核心的なことを言っているので引用します。
ソフトウェア設計において重要なのは下記の３つのこと。
概念: 責務を考える
仕様: インターフェースを考える
実装: 実装を考える
書かれたのをみて、それ！って思いました。実際に自分が行っているのはこういうプロセスです。
ただ自分なら少しだけタイトルを修正します。
分析: 責務を考える
設計: インターフェースを考える
実装: 実装を考える
自分の場合は開発ターゲットによりますが、全体のアーキテクチャーを考えて責務を決めて行くフェーズは分析が主でクラス図などを多用し、それに加えてモジュール間メッセージシステムなどの基本的な仕組みを検討していきます。
モジュールレベルの場合は、分析と設計はほぼ同時に行い外部インターフェイスを定義してシーケンス図を検討します。
分析・設計は、経験を積んだエンジニアは無意識に行っている場合もあるでしょうが、このようなプロセスの結果をドキュメント化したものを下記のように呼びます。
基本設計書
基本設計書には、システム全体に適用されるような基本的なインターフェイスなども含むこともありますし、その他要件に対する諸々の項目も必要でしょう。
（あるいはアーキテクチャー設計書。その他呼び方は色々ありそうです。）
また実装を考えた結果のドキュメントを
詳細設計書
と呼びます。
設計書って書いていますでしょうか？
また書いていたとしてその設計書は本当に価値があるものなのでしょうか？
詳細設計書に記載された内容の多くはソースコードを見ればほぼ分かります。設計書を見た方が圧倒的に早いですが、それでも適切なソースコードであればリバースエンジニアリング的に理解することはできるでしょう。しかしながら設計者がその責務の切り分けがなぜ重要だと思ったか「考えた」部分はなかなか読み取ることができません。
これを可能にするのが基本設計書ではないかと思います。したがって基本設計書には設計者の思想が織り込まれていることが望ましいと思います。
なぜそう考えたのか？
根拠は何か？
参照したアーキテクチャーはどれか？
この設計で非機能要件はなぜ満たされると考えているのか？
これに対して
Dependency Injectionがいいみたいなので試しに入れてみました
RxSwiftは良さそうだし使えるからいいんじゃない
などは設計とは言わないです。どちらかと言うとFeasibility studyとでもいうべきもので製品・商品に取り入れるのはとてもリスキーです（将来負債になる可能性が高い）。
分析・設計
話は変わりますが、別の同僚がQiita記事
Clean Architecture 達人に学ぶソフトウェアの設計と構造
で読書した学びを発信しています。
自分も読み進めている途中で感想文を近日中に書く予定ですが、↑こちらの記事もぜひ読んでみて下さい。
Amazon書籍へのリンクはこちら
Clean Architecture 達人に学ぶソフトウェアの構造と設計
その中で、
「オブジェクト指向とは？」
① データと関数の組み合わせ：☓
② 現実の世界をモデル化する方法： ☓
③ カプセル化・継承・ポリモーフィズム: △
結論どれもちがーうw
って書いてあるんですが、全く同意です。
理由は「オブジェクト指向分析・設計は言語仕様でもコンパイラの機能でもなく世界（モノ・コト）の捉え方（分析）であり、その結果をソフトウェアに再構成する力（設計）」だと思っているからです。
C++、Java、Swiftその他の言語ができるのは、実装とせいぜいインターフェースの記述方法をカッコ良く（またはカッコ悪く？）することくらいです。
なぜそれの責務とインターフェイスを選んだかという思索の部分に関してはあまり役に立っていません。（Swift脳やJava脳になることで思考が分析脳に近づくことは認めます）
分析・設計は「モデリング」と言い換えても良いと思いますが、この「モデリング」を行う際の寄って立つ考え方の中で現在の主流が「オブジェクト指向分析・設計」です。
昨今は関数型分析・設計というものもあるようですが、すいません、こちらは理解していません。
モデリング
モデリング、特にオブジェクト指向分析・設計のモデリングに関する説明をするのはかなり難しいのでここはオージス総研のページを読んで下さい。
しかし言えるのは、繰り返しますが
世界（モノ・コト）の捉え方（分析）であり、その結果をソフトウェアに再構成する力（設計）
です。
モデリングに本質的にプログラミング言語は（実装技術として関連があるものの）関係ありません。
UMLも関係ありません。
- Java、Swiftなどの言語はモデリングを具体化する際の言語であり手段
- UMLはモデリングの結果を表記する言語
そして「世界（モノ・コト）の捉え方」「再構成する力」である以上、結果は人によって異なります
経験がある人とない人、トレーニングを受けた人と受けていない人ではモデリングの結果は異なります。この異なる考え方をして異なる結果になった設計を、関係者（開発チームならば、それらの全員に）に理解してもらうのが「設計書」だと思います。
そしてUMLはこの結果を皆で共有するための（今のところ主流の）共通言語です。これが読めなければ設計を効率的に共有することは難しいと思います。
しかしUMLは結果を記述するだけなので、なぜそこに到達したかを共有することが大事だと思う！ということを念押ししてひとまず「つぶやき」終了します。