#はじめに
20年前のIT業界のバズワードである**「オブジェクト指向」。**
昨今では当たり前の概念になっている。
一方で初学者が「オブジェクト指向」という言葉自体を聞くことも随分減ったと思われ、また「ポリモーフィズム」や「カプセル化」等の用語を聞くことも随分減ったと思われる。
最も、昨今のSPA全盛&サーバレス&NoSqlの時代感においてオブジェクト指向を学ぶ意味とは....?
#そもそも、オブジェクト指向を学ぶ必要はあるのか？
#####はい。（断言）
全てのIT技術は「巨人の肩にのっており」技術の経緯を学ぶ必要がないことはありません。（もちろん限界はありますが...）
#オブジェクト指向でなぜ作るのか（いきなり結論）
#####1.ユーザもしくはビジネスサイドとコミュニケーションが取りやすいから
#####2.エンジニア同士でのコミュニケーションが取りやすいから
#そもそも、昨今のITシステム開発の流れは？
前近代的なウォーターフォール的な開発はだいぶ廃れ、アジャイルひいてはDevOpsが当たり前。
すなわち開発はどんどん効率化を求められておりエンジニアにとっては辛い。
当たり前ではあるが、開発をより効率化するために、それぞれのロールでのコミュニケーションがより求められている。
具体的には、ビジネスサイドとエンジニアサイドとのコミュニケーション（下記図の①）
及び、エンジニア同士のコミュニケーション（下記図の②）。
#で、オブジェクト指向って何？
オブジェクト指向自体は開発思想のことで、大きくはUML（Unified Modeling Language）をベースとした設計とオブジェクトプログラミングをベースにした実装（デザインパターンを参考にすることもある）に分けれる。
#さて、いい感じのITサービスを作るには？
まず、UMLをベースとしたビジネスサイドとのコミュニケーションが必須であると考える。
（すなわちオブジェクト指向必須）
そのため下記のような図(UML)を必ず書く。
（どれを書くかはPJによって異なり、ホワイトボードに殴り書きの場合のこともあるが必ず書く。）
######ユースケース図
######業務フロー図
######ER図
######シーケンス図（概念）
######シーケンス図（詳細）
#それで、効率よく高速に開発を行うには？
オブジェクト指向の概念をベースとしたエンジニア同士のコミュニケーションが必須であると考える。
ひいては、ビジネスサイドから要請されるであろう今後の拡張を鑑みて、設計・実装する必要がある。
そのためにはオブジェクト指向の知識は必須。
(オブジェクト指向プログラミング自体は今となっては当たり前であり、通常のフレームワークの中に組み込まれており難しくない。)
参考：15分でわかる かんたんオブジェクト指向
https://qiita.com/koher/items/6878c80014992900add7
#結局、オブジェクト指向でなぜ作るのか？
#####1.ユーザもしくはビジネスサイドとコミュニケーションが取りやすいから
オブジェクト指向と密接に結びつくUMLは、ノンエンジニアとのコミュニケーションのためにIT業界の先人が作りだした英知の結晶であり今後もなくなることはない。
#####2.エンジニア同士でのコミュニケーションが取りやすいから
UMLをベースにした設計、ひいてはビジネスサイドからの要請を先回りして設計・実装する際に、エンジニア同士の共通言語としてのオブジェクト指向プログラミングへの知識は欠かせない。
##補足
1.歴史的名著である下記はエンジニアであれば誰もが一読すべき。
「オブジェクト指向でなぜつくるのか 第2版」
https://amzn.to/2XNCE6B
2.私は「高速で開発すること」＝「なんでも自動化する」といった関係に違和感を持っております。自動化できることには必ず限界があるので、「高速で開発する」にはビジネスサイドを先回りした設計が何よりも重要であると思ってます。
3.自分で書いておきながら「オブジェクト指向 概要」の絵は、かなりあやしい...。
4.そもそも全くこのエントリー自体「オブジェクト指向」をほぼ全く説明していない...。