初心者向け技術書の重要性
ManaのWebクリエイターカフェ。WebデザイナーでWebクリエイターボックスを運営しているManaです。
この番組では、Webコンテンツ制作で役立つ知識やノウハウ、キャリアのお話をしていきます。
今回のテーマは、初学者に優しい技術書とは、です。
初心者向けにWebサイト制作についての本を書いてたりする私なんですが、
いろんな本があって、選ぶのも読むのも大変だったりするんですよね。
そういった技術書について、今回はお話ししていきたいと思います。
それでは、今回のゲストを紹介します。合同会社DMM.comエンジニアのミノクドさんです。
ミノクドさん、簡単に自己紹介をお願いします。
よろしくお願いします。ミノクドと申します。
合同会社DMM.comに所属してまして、エンジニアをやっております。
現在はDMMで共通基盤として用いられているDMMプラットフォームというものがあるんですけども、
そこの設計品質を高めて開発性を高めるというような活動をやっております。よろしくお願いします。
よろしくお願いします。
ミノクドさんと初めて会ったのが、去年のITエンジニア本大賞2024というところで、
私が特別賞をいただいたんですが、それを選んでいただいた超本人ということで、
若干緊張はしておりますが、その説ありがとうございました。
ありがとうございました。
すごく小学生に寄り添った、本自体もそうでしたし、
プレゼン内容が本当に小学生に寄り添ったような形をとっていたというところがすごく良かったので、
まあ、僭越ながら僕の方からも。
ありがとうございます。
私もこれ本当にまたお礼を改めて言いたかったんですけど、
すごく覚えているのが、受賞した方ってその後インタビューだったりとか、
関係者の方にすごい囲まれて、いろんな方とお話ししなきゃいけないんですが、
それを全部待っていただいて、その後改めて私にお声掛けいただいて、
改めておめでとうございますと言っていただいたのをすごく覚えていて。
そうでしたっけ?
忘れちゃいました。
そうなんです。私こんなに嬉しく覚えていたのに。
そうなんですか。大変失礼いたしました。
そうなんです。改めてこういうところを実際読んで、こういうところ良かったよとか、
こんなプレゼン良かったよって言っていただいたのにすごく嬉しかったので、
改めてありがとうございましたって言おうと思ったら忘れられていた。
そうなんです。そういうね、ちょっとしたところが心に残っておるところです。
はい。
みのくどうさん、先ほどちょっとお話ししてたんですけど、
いろんな登壇とかもされていて、年間何件くらい登壇されてるんです?
去年は16回でした。
すごい。月1は確実にあるってことです?
月1は確実にありません。月2とかもありましたし。
今年はこの収録含めて9回でした。
すごいですね。年に10回は最低でもある感じですね。
来月もまだ何かありそうな気配があります。
すごい。喋るネタがそこまでポンポン出てくる感じなんです?
そんな出てこない時もありますけど、出てくる時は出てくるかなという感じですね。
はい。
エンジニアということなので、基本的にはJavaとかを使ってらっしゃるんですかね?
所属していた会社によっては違っていて、ちょっと一昔前はCシャープを使ったりとか、
あと全職全全職とかではRuby使ったりで、現在はGoを使ってますね。
Goなんですね。
なるほど。それ関連のプログラミングだったり、趣味がリファクタリングっていうふうに本でも書かれてたので、
そういったお話をされていることが多いかなと思うんですが、
合ってますかね?
合ってます。
なるほど。脳内でリファクタリングするのが好きですっていうふうに本のプロフィールのところに書かれて。
リファクタリングの考え方
リファクタリングっていうのが、最終的な動作はそのままで、
内部のコードを書き換えて、より良いコードに書き換えるっていうことをリファクタリングって言います。
ちゃんとリファクタリングしないと負けた気がするんですよ。
誰に?
昔いた会社でリファクタリングするかしないかみたいな感じのところで、
結構バトったことがあって、
上手くリファクタリングできないと、リファクタリングを反対してた人たちから、
やっぱりできなかったじゃないかみたいな感じで、そういう胸のことを言われたことがあったので、
昔そういうことがあったんで、今は現職とかでも上手くリファクタリングできないと、
ほら見ろみたいな感じで、そういうのが頭に浮かんできて、
負けたくないか考え続けちゃうっていうところがあったりしますね。
うまくいくとすっきりしますもんね。
より良いコードに出会えたっていうのも、パズルを解く感じで楽しくなったりもしますし、
そういうところで戦ってたんですね。
はい。
なるほど、わかりました。
ITエンジニア本大賞について
私が今回ちょっと聞きたかったのが、先ほどのお話であったITエンジニア本大賞なんですね。
こちら私、今回審査員として選ばれてしまいまして、
そうなんですよね、受賞者が次の年の審査員になるっていうのが。
そうなんですよね。
この辺を聞ける人がもうほんといないので、
これも前回選んでいただいた三野九郎さんに聞かないとと思ってお声掛けしたんですけど。
僕も去年初めてだったんですけど。
聞きたいことがたくさんありまして、
まずこの、そもそもITエンジニア本大賞っていうのが、
エンジニア向けの本だったり、ビジネス賞っていうのもあって、
各ジャンルで10冊ずつ、全部で20冊最終的に選ばれ、
その中でプレゼン大会っていうのがデブサミであって、大賞を選ぶっていうようなものになってます。
ここで聞きたいのが、ベスト10を選ぶのが1月下旬ぐらいに発表されるんですね。
技術賞とビジネス賞で各10冊ずつで計20冊選ばれ、
2月13日にプレゼン大会があるので、この2週間で20冊読むってことですか?
いや、それはないですね。今もうエンジニア本大賞2025のサイトが開設されましたよね。
そこでいろんな人が投票されて、最後10冊残るんですけども、
そのうち、要は決勝戦って言えばいいのかな、最後プレゼンする3つ、
確か選定されるはずなんですよ、上位3つ。その3つについて、
招援者さんから本が送られてきます。
なのでその技術部門とビジネス部門、それぞれ3冊ずつ、計6冊送られてくるんで、
6冊に目を通したという形ですね。
なるほど、そうだったんですね。
20冊かって思ってたんですけど、6冊ならいけそうですね。
2週間で6冊、2日に1冊、まあまあですけど。
その中で結構読書感想文並みの感想をおっしゃっていただいてたので、
ガッツリ読んでらっしゃるんだなと思ってたんですよ。
ガッツリとではないですね。
本当ですか?
一応全部には目を通したんですけども、目を通した上で、
この本ではどういうことを特徴にしているかとか、
そういう特徴を拾い上げて、それがどのくらい価値をもたらしているのか、
そういう読み方をしましたね。
なるほど、なるほど。
読んでいく上で、他の方のレビューとかも参考にしました?
いや、それは参考にはしないですね。
しなかったです、僕は。
ご自身に読んだ感想と、なるほど、そういうことですね。
それって今までたくさんの書籍を読んでいらっしゃると思うんですが、
これまで読んできたものと審査する上での読み方って違いました?
そうですね、違うと思いましたね。
もちろん僕自身は設計関係の本ばかりほとんど読んでいるので、
そういう本を読む時は基本的に自分の技術を多身するという観点で読んでいましたけども、
それ以外のジャンルの本とかも当然候補としてノミネートされてくるわけなんで、
なので自分の知らないジャンルなわけですよ。
なので自分のスキルに付け足すとかっていうようなものではないと。
じゃあどういう本だかっていうと、自分の場合は、
この本っていうのはどういう問題を解決するものなのかとか、
達成したい目的って言って何なんですかっていうようなところって、
それが初学者にとってフィットするような方向性なものだったり、
そういう感じで読んでましたね。
なるほど、なるほど。
誰に伝えられるかとか、誰にお勧めできるかとか、
ご自身だけの視点ではなくて、他の人の視点でも見てみたってことですかね。
他の視点ではあまり意識はしないんですけども、
結局その技術書の類っていうのは、
そもそも技術というのは何らかの問題を解決するための手段なので、
なのでこの技術書はどういう問題を解決することをテーマにしているのかみたいな。
なるほど、ちょっとこれはいい言葉に出会ってしまった。
何かを解決するための技術なので、そこに注目するっていうのがまず一つ大切だと。
そういう観点で見ると、自分が知らないようなジャンルであっても、
どういう方向性の本なのかっていうのが分かってくる。
なるほど、なるほど。
やっぱり三野工藤さん的にあんまり心に残らなかったなっていうのは、
最終的に何がしたいんやっていうような本はあれってなる感じですかね。
そうです。それは本でもプレゼンでもそうだと僕は思ってて、
あまりパッとしない内容っていうのは、単に技術の紹介だけになっている。
これこれこういうふうにできますとかって言って、
じゃあそれは一体何の役に立つんですかみたいな感じのところが手薄なんですよ。
昨年のITエンジニアム大賞のプレゼンであっても、
ちょっと発表内容によっては単にその本に書かれてるんですよ。
初学者に優しい技術書
単にその本に書かれてる内容の概要だけを舐めて紹介するだけの感じのものっていうのは、
僕には響かなかったっていうか。
なるほど、そうですよね。
私もだからプレゼンするときは、何で書いたのかとか、
そういう本の表面上には残らないような思いが伝わるといいなって思って、
ああいうプレゼンになったんですが、そこがじゃあ伝わったっていうことですかね。
僕はそう思います。
なるほど、そういう視線で、
小学生の方って本を選ぶのがまず難しいかなと思うんですが、
そういった自分にとってこれは何が残りそうかっていうところで選んでみると良さそうですね。
だと思います。
なるほど、分かりました。
今までのエンジニア経験を登録することで、
厳選された企業から年収提示付きのスカウトが届き、
リアルな市場価値が測れます。
気になる方は、
転職ドラフトで検索してお気軽にご参加ください。
そこでですね、
三野九郎さん、また書籍が12月25日に発売されるということですが、
前回、ITエンジニア本大賞にも受賞された、
良いコーディションの書籍です。
前回、ITエンジニア本大賞にも受賞された、
良いコード、悪いコードで学ぶ設計入門が改訂版が出るということですね。
こちら、原稿で出ている本も読ませていただいたんですが、
前の本も400ページあって、
さらに追加されてるってことですか?
そうですね、30何ページぐらい増えてます。
すごいと思う。
まずその400ページ書いたっていうのも、
2年近く書きましたみたいなふうに書かれてたので、
ものすごい量だなと思ったんですが、
どういったところが変わりましたか?
一番大きく変わったのは、
説明する内容自体は、
趣旨としては変わってはないんですけども、
行集度とか結合度っていう言葉を使わなくしました。
それはなぜでしょうか?
行集度と結合度っていうのは、ソフトウェア設計によってよく持ち出される指標ではあるんですけども、
歴史的にはオブジェクト思考が登場する以前からある指標なんですよね。
で、行集度と結合度っていうのは、
良いものから悪いものまであるんですけども、
例えばその行集度で一番良い行集度に合わせて、
設計者としても必ずしも品質が高くなるとは言えないんですよ、実は。
結合度もそうであって、
ある程度、今、モダンな設計においては、
強く関係し合うものを一つのコンポーネントとしてカプセル化するみたいな。
でも結合度にしちゃうと、
とにかく依存を下げて全部バラバラにしろっていうふうになるんですよ。
そうすると結合度を下げたら、
必ず品質が良くなるのかって言ったら、そうはならないんですよね。
ですから、その行集度や結合度っていう言葉を使わずに、
そのカプセル化と関心の分離、この2つを使って説明する形にしちゃうと。
でもそっちの方が、最近勉強し始めた人にとっては、
すんなりと入りそうな単語ではありますよね。
なんで、ソリッド原則とかもあるんですけども、
それもはっきり言って、カプセル化と関心の分離で説明できちゃうんですよね。
プラス多体性、それはちょっと置いといて。
基本的にはカプセル化と関心の分離で、ほとんどのことは説明できてしまうみたいな。
だから思い切って書いてみようみたいな感じのところと、
あと初版でこうしてほしいっていうふうに書いたものの、
いささか読者さんの感想からはちょっといまいち反応が良くなかったような部分について、
ちょっと記述を強化したっていうか、
ぜひここは学んでほしいというようなところの記述を強化したって感じですかね。
この本、たくさんのコードの良い例というか、
こうするとより良くなるよっていう例だったり、
これ良くないよっていうような例だったりっていう、
コードのサンプルがたくさんあったと思うんですが、
この辺も結構変わったんですか?
ソースコード自体は変わってはなくて、
追加したソースコードはあります。
なるほど、なるほど。
説明の仕方をちょっと変えてっていう感じなんですね。
そうです。
これ技術書で本当に基本的なことからこれを守ろうねっていうことを書いていて、
ちょっと専門的な用語もたくさんあるんですが、
これすごいなって思ったのが単調になりやすい技術書なんですけど、
それが悪魔が出てきたりとか、
魔法とかゲームの例に例えて、
難しいと思われがちな内容ほど身近な例で例えてるっていうのが、
すごく親近感が湧くような技術書になってるっていうのが新しいなと思って読み進めてみました。
その追加されたところもわかりやすく身近にっていう感じで追加されてるんですかね?
そうですね。追加コンテンツに関しても身の回りのものに例えたりとかっていうような表現が入ってますし、
やっぱり人間って自分が知っている何かに基づいて理解しようとするんで、
一番ダメなのが専門用語を専門用語で説明するみたいな。
それは全くわかんないわけですよ。
だから、なるべくその日常生活でみんなが知っているようなことをメタファーにするっていうか、
急にして、それで理解を組み立てていったほうがわかりやすいだろうみたいな。
私も書いた本でプリンに例えたりとか動物園に例えたりとか、
いろんな例えが出てきたので、そういうところを見ると、
初学者の方でも読んでみようかなってなりますもんね。
特に読んでほしい人っていうのはどちらかというと初学者とかなんですかね?
そうですね。初学者向けです、はっきり言って。
あまりちょっとこういうこと言いたくないんですけども、
僕の本を読んだ人の中に一部には、
こんなこと知ってるからいちいちこんな本読まなくていいよっていうような感想をされた方が何人かいらっしゃったみたいなんですけども、
いや、それはあなたがそんな技術力の高いからなんですよと。
あくまでこの本はそれを知らない人の対象に書いてるのでっていうようなところですね。
そうなんですね。知ってることしか書いてませんでしたとか言われたら、そうですか。
問題解決のための技術
さすがですねっていう。
終わるんですよね。
なので、初学者、これから勉強しようとしてる方。
あと、学び始めて行き詰まった段階で読むっていうのもありかもしれないですね。
そうですね。
じゃあ、そういった初学者の方の勉強方法についてもちょっとお伺いしたいんですが、
今、いろんな媒体、著籍だけじゃなくて動画だったりとか、スクールに行くとかいろんな手段があると思うんですが、
どういった勉強方法がお勧めだよっていうのありますか?
それはもう、手を動かすっていうのが一番ですね、やっぱり。
手だけじゃなくて口を動かす。
これは僕の本の第二版にも追記したんですけども、とにかく手と口を動かすと。
口っていうのはその行動を読み上げてるってことです?
読み上げてるってことです。
設計の理由を説明するってことです。
要は、僕さっき言いました。技術は何らかの問題を解決するための手段であると。
なので、その技術の本質を知るためには、自分たちの解決したい問題は一体何なのかとか、
その問題ってどういう構造になってるのかっていうことをしっかり理解できないといけないわけですよ。
それを理解しないと、なんかこの技術使ってみようって言っても、その問題解決にいまいちマッチしないっていうか、
シグハグな設計になったりするわけですよね。
なので、ラーニングピラミッドっていうのがあるんですけども、
それは学習定着率を表した図なんですけども、その図ではただ本を読んだりとか、
講義で人の話を聞くっていうのは、ほとんど定着しなくて学習効率が悪いというふうにされてます。
逆に、自分で実際に話してみたりとか、人に説明するとか、実際に何かやってみるみたいな。
そういうアウトプットを伴うことで、ものすごく学習定着率が高まるっていうふうに言われてて。
僕、今DMMでエンジニアさん向けに設計の学習会をやってるんですね。
そこでは実際にソースコードを書かせたりとか、実際になんでそういう設計をしたのかって、
それによってどういう問題解決したのかって実際に説明させてるんですけども、
やっぱりうまく説明できてるほど良い設計ができてますね。
なんで自転車の乗り方って、自転車の乗り方についての本を読んでも実際できないと同じように、
やっぱりちゃんと設計するために、実際こう試行錯誤して考えてみて、実際にコード書いてみて、
じゃあなんでそれが良くなったかの、みたいな感じのところをちゃんと原音化するっていう。
そこが大事なので、だから別に僕の本こう読んでほしいとかって、
僕の本だけじゃなくて、それはマナさんの本であっても、誰の本であっても、僕はそうだと僕は思います。
アウトプットの重要性
なるほど、手を動かす。
で、あと登壇とかも最初のお話に戻りますが、登壇とかもアウトプットの一つであると思いますので、
そういったところもお勧めですかね。
そうですね、やっぱりその登壇するってなると、僕も毎回そうなんですけども、
何か発表内容を考えて個誌を書いてたりとかすると、
なんかこう自分で主張しようとしてるところの矛盾に気づいたりとか、
ここはちょっとこうした方がいいなみたいな、そういう気づきが得られたりとかっていうことがあるので、
ですからその、やっぱり登壇するってことは、しかもみんなさんの前で発表するんで、
初学者向けのアドバイス
そういう不確かなことは主張できないわけですよ。
ですから、自分の持ってる考えとかそういうところを整理するためには登壇ですごくいいんじゃないかなって僕は思います。
なるほど、で、書学者の方のあるあるなんですけど、間違ったらどうしようとか、
これ指摘されたら嫌だなとか、批判されたくないなっていうので裏足を踏んでる方もいらっしゃると思うんですけど、
その点についてはどう思いますか?
何でしょうね、物の本によると人ってこうポジティブなそのフィードバックよりネガティブなフィードバックの方を10倍強く感じてしまうみたいな、確かあるので。
それはありますよね。
だから最初に厳しい場に出てしまうのは結構そのトラウマになってしまうと思うんですよね。
だからそのある程度そのなんていうか優しい人っていうわけなんですけども、あんまりそういうネガティブなそのフィードバックがないようなところでまずやってみて、そこから順次慣らしていくとかって。
最初は5分のLTとかから始め、ポジティブな意見をもらい、そこからちょっと伸ばしたり、いろんなとこ行ったりとかそういう感じですかね。
僕はそうだと思います。
なるほど、わかりました。
それではみのくどさん、今回は結構小学者向けにお話を伺ったんですけど、今から始めますとか、今始めてますっていう人に向けて思ったことがあれば。
やりたい、自分のそのやりたいことっていうのをちゃんと言語化するとか、そのためになんか少しでもいいので行動してみるとかアウトプットしてみるっていうのが大事かなというふうに思います。
なんでかっていうと、そういう何か自分のやりたいことを言語化してみたりとか、実際にそれを行動してみると、自分が最初こうやりたいっていうふうに思ったことと実は違うことが自分に合ってるんだっていうふうな気づきがよくあります。
だから、自分って何なんだろうって、今後その自分は何者になりたいんだろうっていうふうな迷いって、もちろん若い方とか初めてそのエンジニアになられる方とかってそういう迷いはあると思うんですけども、そこの方向性ってやっぱりやってみないとわからないとかっていうところがあったりとかすると思うので、
やっぱり何にしてもやりたいこととかをちゃんと言語化してみたりとか、そうすればなんか自分は実はこういうことをやりたかったみたいなとか、実際に手を動かしてみることで、こっちの方が面白いかもみたいなそういう気づきがあったりとかするので、アウトプットしましょうねってところですかね。
書籍の紹介
そうですね。興味があったらとりあえず行動してみようというところですね。はい、わかりました。最後にお知らせなどあればお願いします。
12月25日、クリスマスですね。に僕の良いコード、悪いコードで学ぶ設計入門の改訂版が出ます。この本っていうのはソフトウェアにおける変更要請っていうものを扱ってまして、要はバグをなるべく埋め込まずに素早くそのコードを実装できるかどうか、コードを変更できるかっていうどういう変更要請って言うんですけども、そういう変更要請の設計を取り扱ってます。
で、この設計が良くないと非常に何やってもバグを埋め込んでしまう。皆さんバグ好きですかって嫌いですよね。自分で書いたコードによってバグが発生して、なんかすごい問題が生じたっていう風な事態に皆さん陥りたくないですよねって。
そういう人のための本なので、僕はバグなんかもう大嫌いだと埋め込みなくないと、ちゃんといつでも正しく動くコードを書きたいという風な方に是非お勧めなので、この本っていうのは非常に小学生の方にもわかりやすく書かれてますので、是非皆さんお手に取っていただければと思います。よろしくお願いします。
はい。12月25日発売です。是非読んでみてください。三野くろさん、今日はありがとうございました。
ありがとうございました。
さて、この番組では感想や質問、リクエストなどお待ちしております。番組詳細欄にあるリンクよりお気軽にご投稿ください。XではカタカナでハッシュタグWebカフェをつけてポストしてください。そしてApple PodcastやSpotifyのPodcastではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
ここで私がメンターをしているテックアカデミーについてのご紹介です。テックアカデミーは現役デザイナーからマンツーマンで学ぶことができるスクールです。キャンペーンコードをお申し込みの際の微行で入力すると、テックアカデミーの講座を2万円引きで受講できます。キャンペーンコードはWebカフェ、小文字のアルファベットでWEBCAFEです。概要欄のリンクから是非チェックしてみてください。またお会いしましょう。
Webクリエイターボックス マナでした。
