sait0sのブログ

技術で広く浅く遊んでいる、エンジニアの真似事をしている学生です

エンジニアは本を読むべきか

最近、本を読む人って本当に減ってきていますよね。それは、エンジニア界隈も同じなのかなと思うこの頃です。

 

Twitterでも一時期、「リーダブルコードを読めとか、○○の本に載ってるとか言ってる奴は...」みたいなもの(これは、リーダブルコードを読んでいるエンジニアが優秀か?という投稿があらぬ方向へ広がった感じですが)だったり、「エンジニアだけど技術に興味なくて何が悪い?」系の投稿が増えてきている気がします。

 

そんな中で、他人に本を読むべきかについて議論してみたいと思います。

実際にどうなのか

ここからは、どちらかというと、本というより技術書寄りになります。

 

自分の周りでも、本を読まない人は非常に多いと感じています。サークルのメンバーや同期に「ここを教えて!」とちょくちょく聞かれるので、教えるついでに「ここら辺の本に詳しく載っているよ」とアドバイスはしますが、みんな読まないわけです。(ふわっと伝えるだけで、強制はしてない)

 

別に、無理に本を読め!とは思ってないですが、何度も同じことを質問されると内心モヤっとします。

 

あと、いろんな会社のEMやCTOなんかのような偉い人とカジュアル面談や面接なんかをする機会が多かったのですが、「新しい技術のキャッチアップはどうやっているの?」と聞かれたときに、「書籍はよく読みますね」と答えると、「おぉ~」と毎回驚かれました。それほど、本を読む人って少ないんだなぁと思った次第です。

なぜ本を読まないのか

  • 書籍が高い
  • 読む時間がない
  • その分野に興味がない•本を読みたくない

思いつく限りこんな感じですかね。

書籍が高い

一番考えられそうな理由です。技術書にもなると、一冊 2000~5000円くらいは普通にかかりますよね。きらら本ですら、1000円で買えるのに、、、

 

特に、若い人は意外にもお金がかかるわけです。飲み会だったり、美容だったり、生活費だったりと耳が痛い話ですね。

 

代替策

  • ブログや技術記事
  • Udemyや Youtubeなどの比較的安い動画コンテンツ
  • 会社の福利厚生や大学の図書館で購入

ブログや動画コンテンツは比較的安く済みます。今更言うまでもないですが、検閲や検証がされていなかったり、誤った情報である可能性があることに気を付けなければなりませんが、、、

やはり、すごくまとめられているものもあり、良いとは思うのですが、n+1 次ソースになるに連れて、ミスリードが発生しやすくなったり、重要なポイントや本質が抜けていたりします。一番良いのは、1次ソース(公式ドキュメントなど)を確認することですが、初心者からしたらあの呪文のような内容はやはり難しいです。そこで 、しっかりと検閲や検証されている技術書はベストな手段なのかなと思います。(たまに、よくわからないぼったくり本もありますが)

 

あとは、福利厚生や図書館で購入するですね。最近は、福利厚生で業務で使うなら好きな技術書を買っても良いよ!という会社は多くなったのではないでしょうか。(実態は、会社の共有図書というケースも多いのかもしれないが)

会社のお金で本を買えるのは、ラッキーですよね。こういうのは、どんどん使っていきたいです。(自分は気に入った本は手元に置いておきたいタイプなので、結局は買います)

そうは言うものの、インテリアになっていて、みんな読まないんですよね。うちの大学でも新しい図書の購入は、1人につき年10冊まで可能なのですが、サークルのメンバーは誰も活用していなかったです。図書の 1スペース全て自分が購入申請した技術書ということもありました。(そもそも、文系大学なので技術書自体が少ないのだが)

あと、会社の共有の技術書を借りる機会があったのですが、誰も読んだ形跡がなく、新品でした。まぁ、オライリーが置いてあるとそれだけで生産性が向上しそうな気はしますが、、、

読む時間がない

こっちもあるあるですね。社会人にもなると、まとまった時間が取れない。学生のうちも、研究やら自己研鑽やらでとてつもなく忙しい。(自分の大学生活に、遊びや青春なんて概念はない。なぜなら、コロナで2年間もオンラインでボッチ学生だったし、サークルや研究が本当に忙しかった)

本を読んでいる時間なんてないわけです。それでも、自分は空き時間にいつも読んでいましたけど。(そこまで言うほど、忙しくなかったかも)

 

代替策

  • どうにか時間を作る
  • 記事や動画などの手っ取り早い方法で済ませる

ここは、「頑張って時間を作りましょう」以外に言えることはないですね。早寝早起きするとか、余暇を上手く使うとか。

とはいえ、家族や人生まで捨てて技術に全振りするのはやめるべきだとは思う。そういう過激派の人たちがいることも事実なのだが、その人たちが幸せそうにしているところを見たことがない気がする。

 

あとは、記事や動画で済ませるということですね。先述した注意点と同じになりますが、そのまま流用せず、最低限の検証はした方が良いかなと思います。

その分野に興味がない•本を読みたくない

興味がない(嫌いな)人に何を薦めてもダメな気がする。自分だって、興味のない分野の本を薦められても読まない。何より無理強いさせるのは、人間関係が壊れる可能性があるのでおすすめしない。

 

それはそうと、業務で使うものだったり、これから必要になる分野くらいは理解していてほしいとは思う。新しいことに対して、本でなくても何かしらの方法でキャッチアップできないとエンジニアの前に、社会人としてやっていけない気がする。

とはいえ、「AWSの○○というサービスを業務で使いたいから自分たちでキャッチアップしといて!」というのも違う気はする。AWSなんかは普通に料金がかかるものだし、その会社が必要なものであるわけで、対応としては無責任な気がする。そこらへんは、会社が何かしらの支援をしてあげる必要はあるのかなと。(とはいえ、もちろん限度はあるべきだし、全面的な介護は違うと思っている)

何か話がずれましたね、、、

 

代替策

  • 必要に応じてキャッチアップすればよい

特にいうことなし。

結論

本以外の選択肢もあるし、それで良いのではないか」という現代特有の多様性を尊重した曖昧な意見にとどめておきたい。(というか、炎上したくない)

 

今までの「本から知識を得る」という風潮はなくなってきていると思っている。大学教育だってそうである。明治初期の大学教育は、イギリスの洋書を用いていた。もちろん講義は全て英語だったらしい。しかし、今では洋書どころか、参考図書や指定図書すらなく、講義は全てPower Pointで行われてさえいる。時代というべきなのか、学生を配慮したというべきなのか、、、 それはそうと、多様性があっても良いと思う。(なぜこの話をしたかというと、自分は経済学部で日本経済史専攻だから)

多様なメディアやコンテンツは増えているので、そこから学び始めるのでも遅くはないはず。

 

ただ、自分の好きな名言にこんな言葉がある。

本をよく読むことで自分を成長させていきなさい。
本は著者がとても苦労して身に付けたことを、たやすく手に入れさせてくれるのだ。

By ソクラテス

これはアカデミックに限らず、すべての分野に言えると思っている。本、技術書一冊、著者の努力と研究の成果である。「エンジニアが技術書を書くよりも、コンビニでバイトした方が儲かる」という意見もあるが、苦労してそれを伝えることに意味があるのかなと思う。

 

自分は、知らないことを知ることが楽しいと思っている。大学に入る前は、読書なんかせず、ゲームばっかりやっていた気がする。大学に入ってから、自分の興味のある分野(エンジニアリングや経済史)をさらに知りたいという探究心が付いたし、楽しいと思えるうちは楽しみたい。

読書量で見える景色

あと、自分は議論したいですね。「○○の部分はこう書いてあったけど、どう思う?」といった感じに。本から得られるものが絶対的ではないからこそ、人によってどう感じたのか?、現代ではどうなのか?、こういうケースの場合どうなのか?といったことを知りたいと思う。そこから、ベストプラクティスと自分の中での落としどころを見つけることこそが、本を読む意義なのかもしれない。(ただ読んだだけで、自己満足することに意味はないと思っている)

とまぁ、適当にまとめた次第です。自分は、技術に興味がなくても良いとは思っています。ですが、使用している技術は他人に教えられるくらいにはわかっていてほしいし、新しく必要となる技術もしっかりとキャッチアップしてほしいなと思う。引き継ぎが大変なので、、、

 

あと、本というか、技術書を読みたいという雰囲気は作っていきたいです。

特に、現代のソフトウェア開発を取り巻く環境の変化って激しいですよね。新しいものがいつの間にか陳腐化したり、昔のものが再び脚光を集めたり。敢えてレガシーのままにするという戦略もあります。ただ、新しい技術に消極的だったり、新しい環境に取り残されてしまうと、組織全体が保守的になってしまい、イノベーションは生まれないのかなと思っています。無理をしてでも新しくすることにも意義はあるのかなと。(リソースと時間があればの話)

 

そんなこんなで、本は素晴らしいよ!という話でした。

 

(注意とうか個人的な意見)

本を読んだからえらいとか、こういう知識があるからすごいみたいな風潮はよくないとは思う。それ以外にも、誰かの書いた記事や風説、Twitterなどの情報だけで、明確な根拠がなく批判するのもやめるべき。それは、批判ではなく、否定。どちらも敬意や配慮が足りていない気がする。

全て個人的な意見ですので、悪しからず。

「オブジェクト指向のこころ」を読んだ

今年の夏インターンで、アーキテクトやモデラーとして活躍するつよつよエンジニアを見て、何となくアーキテクトに憧れを抱くことがありました。そんな中で、「アーキテクチャやソフトウェア設計を理解するなら、オブジェクト指向デザインパターンは理解しておいたほうが良いよね!」とふと思ったわけです。

 

実は、デザインパターンJavaを始めて1年目くらいの大学1年のときに、かの有名な「Java言語で学ぶデザインパターン入門」を買ったものの、難しすぎて本棚に隠していました。(あと、カツオのたたきは食べたことない)

 

そんな中で、本屋をぶらついていたら、面白そうな本があったので衝動買いしました。

あと、今まで Javaばっかり触っていたので、「いくつか知ってるやつもあるし、余裕だろ」という甘い覚悟で臨みましたね。

対象読者

本書のサンプルコードは Javaで書かれていますが、専用サイトに C++C#での実装が記載されています。基本的に、オブジェクト指向の三大要素がわかっていれば、問題ないです。

 

読む際の注意点として、Java言語の interfaceとソフトウェアにおけるインターフェースを混同すると、何を言っているのかわからなくなります。本書に記載されている "インターフェース" は後者です。あと、ほとんど abstractクラスで実装されていますが、interfaceで実装できるのであれば、interfaceを使うのが一般的だと思います。

あらすじというか概要

第1部 (1~2章)

1章では、オブジェクト指向の三大要素や凝集度、結合度の概念について説明しています。エンジニアなら知っていて当然みたいな雰囲気はありますが、本質をしっかりと理解している人は少ないのではないでしょうか。自分はそうでした。

読んでいるときは「当たり前だよね!」と思っても、本書を読み終わった後でもう一度見ると、違った観点で理解が深まると思います。オブジェクト指向設計では、流動的要素を概念レベル、仕様レベル、実装レベルで抽出し、コードを実装していきます。これらをいかにオブジェクト指向を用いて影響範囲を抑えるかが重要です。この辺の概念は、次章以降でも何度も提唱されています。

 

2章は、UML(統一モデリング言語)の説明になります。次章以降からUMLを用いて解説されているので、UMLの読み方を学びます。すごく簡単なので覚えることは少ないですが、モデリングした設計が可視化されるので理解しやすくなります。

昔は、UMLが新たな言語として流行するみたいな雰囲気もあったようですが、今は全く使われていないですよね。

第2部 (3~4章)

3~4章では、この本でサンプルとして用いる CAD/CAMシステムの概要とそれを用いた実装例について説明しています。設計に携わった経験がある方なら、設計時の問題点をイメージしやすいのかなと思います。それをオブジェクト指向で解決するにはどうすれば良いか?ということを考えるパートです。

 

CAD/CAMシステムなんて、今は知らない人も多いのではないでしょうか。自分はコナンで初めて知りました。

第3部 (5~11章)

この章から、GoFデザインパターンに入っていきます。

最初に、"Facadeパターン" と "Adapterパターン" を見ていきます。クライアント側からシステムの実装や内部設計を意識させないために、カプセル化のみを用いた比較的簡単な解決方法です。この2つのパターンは、他のデザインパターンと同時に利用されることもあるので、かなり重要なパターンだと思います。

 

次に、"Strategyパターン" と "Bridgeパターン" になります。ここから interfaceや抽象クラスを用いるため、複雑になります。クライアント側から見た Aシステム、 Aシステムから見た Bシステムといった2つの観点からそれぞれ見ていく必要があります。どのようにオブジェクトに責任を持たせていくかといった考え方を持つ必要があるため、本当に難しいです。

 

最後が、"Abstract Factoryパターン" です。ファクトリの概念自体は DDDにも出てきますが、ほとんど同義なのかなと思います。各ファミリに対して、ファクトリが実装を提供するというイメージですね。まずファクトリを用意し、クライアントはファクトリを利用するが実装は関知しない、ファクトリ(もしくはConfig)が実装を決定するといった考え方が根底にあります。あと、Abstract Factory単体で何かを解決するということはないのかなと思います。後述にもある通り、生成に関するデザインパターンと一緒に用いることが多いと思います。

第4部 (12~13章)

ここでは、パターンの適用方法を見ていきます。概念レベルから問題点を抽出し、複雑にしていく必要があるということを述べています。その後に、CAD/CAMシステムからデザインパターンを組み合わせた解決方法について考えます。一番重要なことは、デザインパターンはシステムの問題点を解決するために提案された手段であるということです。そのため、デザインパターンの組み合わせは、各デザインパターンの問題点へのアプローチであるということを理解して、システムに適用する必要があると書かれています。

第5部 (14~16章)

モデリング手法や設計アプローチについての説明です。どのように分析し、モデリングをして、デザインパターンを適用して設計するかということが述べられています。SOLID原則を意識することやパターンへの過度な信頼は禁物であるということも書かれています。オブジェクト指向設計の際のアンチパターンについても語られているので、重要です。

第6部 (17~19章)

"Decoraterパターン" 、"Observerパターン" 、"Template Methodパターン" を見ていきます。ここでは、流動的要素をどのように保持していくかということに焦点を当てたものです。簡単に言うと、オブジェクト指向によるイベント管理方法になります。Java をやっている方なら、○○IventListenerとか○○Templateとか馴染みがあるのかなと思います。多くのJava ライブラリにも利用されているデザインパターンです。

第7部 (20~24章)

"Singleton / Double-Checked Lookingパターン" 、"Object Poolパターン" 、"Factory Methodパターン" を見ていきます。今までとは少し観点が違って、生成に関するデザインパターンになります。ファクトリからどのように実装を提供するかの違いになります。ここら辺は、馴染みのある人も多いのかなと思います。

第8部 (25~26章)

今までのまとめ!!

 

読んでみて

すごくわかりやすかったです。「Java言語で学ぶデザインパターン入門」がコードで理解するなら、こちらは理論で理解するという感じですね。

それでも、他の記事や実装例も参考にしましたし、実際にデザインパターンでの設計を見たことがないので、理解度7割って感じですが、、、(それと、内容が濃いため、全体は360ページ程度ですが読み終わるまでに300hはかかりました)

 

何となく気づいた人もいると思うのですが、23個全てのデザインパターンは取り扱ってないです。主要かつ重要なパターンに絞ったのかなと思います。

 

何度も書かれていますが、"オブジェクトへの責務" 、"オブジェクトの集約" 、"カプセル化" の重要性を説いています。

  • 継承よりも集約を用いること
  • カプセル化の本質は、(メンバーやメソッドだけでなく)型やオブジェクトの隠蔽
  • オブジェクトへの責務を明確にすること

これらを理解するのに、かなり時間がかかりました。現代のソフトウェア開発も同じですが、開発における不確実性要素に対して、いかに柔軟に対応することができるかということが根底にあります。これらを上手く使って、不確実性要素に対して最小限の変更に抑え、新規機能の追加では変更を加えないという SOLID原則に則った設計にすることが求められます。(注意点あり -後述- )

 

あとは、凝集度や結合度についても少し間違った理解をしていたのだと痛感しました。

単に、高凝集は関連するメソッド群でまとめたもので、疎結合は機能や役割ごとに分割させるという認識でした。流動性要素の集約やオブジェクトへの責務という観点からみると、持つべきでないモジュールやクラスに責務が与えられていたり、 if文や switch文で無理やり書いていたなと反省しました。(switch はパターンを適用するフラグと書かれているところが良かった)

 

そうは言うものの、責務を明確化することや集約することには限界はあると思う。設計時に分析して不確実性要素を洗い出すわけですが、あらゆることを想定したら分析地獄に陥るし、下手をすればクラス爆発を起こして逆に保守しにくくなってしまう。ここら辺は、システム要件やアーキテクトの腕次第なのかなと思います。ただ、何よりも難しいのは、複雑なシステムに対応するためにデザインパターンを複数用いて対処するということかもしれないです。単一のデザインパターンで解決できることの方が少なく、何かしらのパターンを組み合わせて対応することがほとんどであるということ。間違った組み合わせを選択すると、その先も地獄になってしまう。ここが本当に難しい、、、

 

最後に、DDD やアーキテクチャアジャイル開発にもつながる部分はたくさんあるのかなと思いました。ここら辺の知識が浅いので、今のところ何とも言えないが、こちらの知識もつけていきたいです。(単純に理解不足)

 

学生にオブジェクト指向は早すぎたかもしれないとは思いつつも、アーキテクトって何か響きがかっこいいですよね。それは別として、以前からこの分野には興味あったので、さらに追及してみたいですね。

 

(注意)

SOLID原則には触れているものの、ジレンマというか、トリレンマ(?)のように、これら全てのソフトウェア原則をカバーすることは絶対にできないと思っている。どれかを諦めなければならなず、絶対的なものではないというのは注意しなければならない。ここら辺は、メリット・デメリットと一緒に触れてほしかったです。