理想形を知ることで、理想でないものを認識できるようになる　『良いコード/悪いコードで学ぶ設計入門』の5つの特徴、習得可能な2つのスキル

本日のお品書きと自己紹介

仙塲大也氏：今日は「『良いコード/悪いコードで学ぶ設計入門』でエンジニアリングの当たり前を変える」というタイトルで発表します。「#ミノ駆動本」は、書籍にも記載のある公式のハッシュタグです。今日のイベントや、これからの僕の本に対する感想などは、このハッシュタグを付けていただけると感想を見つけやすいので非常にうれしいです。よろしくお願いします。

本日のお品書きです。まず自己紹介と本書の概要。あと、本書で向上が期待できるスキルと本書の特徴、評判の声と各章の紹介。それから、この本によってこの先に目指す世界と、執筆の裏話という流れで進めていきます。

まずは自己紹介。私、Twitterでは「ミノ駆動」と名乗っています。中の人は仙塲大也と申します。職歴としては、電子機器メーカーや大手精密機器メーカー、前職のクラウドワークスを経て、ちょうど1年前の2021年に、READYFOR株式会社というクラウドファンディングのサービスの会社にジョインしました。

READYFORでは、Railsのレガシーなシステムがありますが、アプリケーションアーキテクトとしてそれの技術的負債解消のためにリファクタリングをしたり、拡張性を向上させるようなシステム設計をすることを中心に従事しています。

Twitterでは、悪しき構造が招く凄惨な結末を風刺した「クソコード動画」の作者でもあります。よろしくお願いします。

書籍の販売状況

満を持して出てきたのが、クソコード爆殺本ではなく、『良いコード/悪いコードで学ぶ設計入門』。サブタイトルが、『保守しやすい成長し続けるコードの書き方』になっています。

ちなみに、「成長し続ける」の成長は、増田さん（増田亨氏）が以前、「変更容易性を高めるコードというのは、単に変更しやすいだけじゃなくて、ソフトウェアが成長することだ」とツイートされていて、そこを参考に取ったものです。

この本は、さまざまな悪しきコードを例に、どう設計すればいいのかを学ぶための技術書です。今日（2022年4月26日時点）、Kindleで発売でしたが、本はまだ発売になっていなくて。発売前からAmazonの「ほしい物ランキング」の和書全体で1位になっている。IT本限定だったらわかりますが、IT本限定じゃなくて和書全体で1位になっているという状態でした。

「ヨドバシ・ドット・コム」や「楽天ブックス」では、予約段階でも在庫切れを起こしていたという。現在では予約の在庫もたぶん回復しています。

在庫切れが相次いだために、4月7日に初版部数がいきなり2倍に増刷されました。それでも在庫が足りなくて、先日増刷に増刷が重ねられて、発売前なのに部数が1万部を突破しました。これは編集者さんに言わせると、ほぼ前例がないぐらいの規模だそうです。編集者さんも経験したことがないと驚いていました。

今日、先行して紙版よりも先に電子版が発売されました。「Kindle」や「楽天Kobo」とか、あと「Gihyo Digital Publishing」とかで今日買ってすぐに読めます。電子版を手に入れた方がもう感想のツイートとかをされていて、非常にうれしく見ています。イチ早く読んでみたい方は、ご購入されるといいと思います。

紙版の正式な発売日は4月30日、今週の土曜日ですね（2022年4月26日時点）。紙版が全国発売になる流れです。ちょうどゴールデンウィーク前なので、ゴールデンウィーク中のちょっとした勉強とかお楽しみとして読んでいただければと思います。

書籍を読んで向上が期待できる2つのスキル

本書で向上が期待できるスキルは、大きく分けて2つあります。まず1つは、「悪しきコードが見えるようになる」。これは僕がよく出す例です。「この図形ってなんでしょうか？」と。正方形ですよね。正方形は、4辺の長さが全部同じで、内角がすべて90度だという定義がされています。だから、それがわかっていればこれが正方形だとわかるわけです。

「じゃあ、これは正方形？」と言ったら、やはり違うわけですよね。定義を知っているからこれは正方形じゃないことがわかる。理想形を知っているからそういう判断ができるわけですよね。

だから理想形を知ると、理想形と違うもの、理想じゃないものを認識できるようになる。ほかに、大昔は疫病の原因がよくわからなくて、悪魔のしわざだと恐れられてきたわけです。

でも後の研究によって、実はその正体が病原菌だとわかって、対処方法が劇的に革新されていった。

だから、悪しきコードも同じで、理想形を知ってその正体が何であるかを見破ることで正しく対処できるようになるという考え方でこの本は書いてあります。

「どこが悪しきコードなのか見えない」とか、見えていても「簡単なのはわかるけど、それ以外はなんかよくわからないな」となっていても、この本で学ぶと「読める、読める！」じゃないですが、「見える、見えるぞ！」みたいな。ムスカ大佐の気分になれて、とてもうれしいわけです。悪しきコードが光って見えるようになります。

この本を読む前でも、どれが悪しきコードなのかってある程度見えていると思うんですよ。でも、この本を読むともっと見えるようになる。だから「わあっ！」て。「俺はこんなにもひどいコードに囲まれていたのか！」「ぎゃあ、やめてくれ！」みたいになると思うんですよね。動悸、息切れ、引きこもりになるかもしれない。はい、以上（笑）。

次、2つ目の習得スキルです。これが本番ですが、変更に強い構造を設計するスキルです。バグをなるべく埋め込まず、正確に素早くコードを変更できるようになるスキルです。ただし、本を読んだだけだとなかなか身に付かないので練習は必要です。

書籍の特徴1：ターゲットは初級から中級

次は、本書の特徴です。5つぐらいあった気がします。まず特徴の1つとして、この本は初級から中級向けをターゲットに書いた設計の入門書です。

（スライドを示して）簡単な図にしました。ソフトウェアの、特に設計スキルとかの習熟レベルってけっこうピンキリで。これは僕の私見ですが、最初プログラミング入門書から始まって、だんだんスキルアップをしていって、中級レベルにいったぐらいでリファクタリングやレガシーコード改善ガイドみたいなものに差しかかって、もっと先にドメイン駆動設計があるとか。そんな感覚でいます。人によっては感覚は違うかもしれませんけど。

「普通に学んで経験を積んでいけば、自然にスキルアップするの？」と思いきや、「現実にはこうなんじゃねえの？」と。だから、初級から中級に向けて、現実にはけっこういきなり深い谷が現れる。

だから、プログラミングの入門書を学習し終わった時に、その後にどうやって設計スキルを向上させていけばいいのか。それは自力ではなかなかたどり着けないというか、多くの人がそういうふうに苦しんでいるんじゃないかなって思います。

先が見えていればいいと思うんですよ。（スライドを示して）でも現実には「実際はこうなんじゃねえの」って。だから、ここがもうゴールになっちゃって、先の世界が「えっ？　そんなのないよ」みたいな。「ここがゴールだよ」みたいな感じで、この先の世界が実は認知されていないんじゃないかと。

こういう課題に対してこの本は、要は初級と中級の間に架ける橋だと僕は思っています。なので、無理なく設計を学べるレベル感を意識して執筆していました。ちなみに、橋になる本と言えば、増田さんの『システム設計の原則』です（笑）。

僕の本の最後のほうには、中級以降にどう学んでいけばいいかとか、より高いレベルの技術書を紹介したり、あと「ここは自分でどうやってスキルアップしていけばいいの？」みたいな感じのことも記載しています。

中堅の方が新卒の方に設計のレクチャーをする場面もあったりすると思います。例えば、新人の方に命名とか責務の重要性を説明しようにも、おろそかにしたら何が起こるかの例えをいちいち出すのって、すごく難しいと思うんですよ。

実コードで見せられればいいと思うんですけど、なかなかそういう局面はないと思っていて。結局、具体性を持って「何がどうなればいいのか」という例えを出すのが非常に大変である。

その例えがないとしても、設計上押さえるべき説明のポイントはあると思います。でもそれが聞かれて都度口頭で答えるていると、説明が五月雨式になったり抜け漏れがあったり、ちゃんと整合性のある説明ができない局面があったり。いまいち意図が伝わらない事態に陥りがちな部分がもちろんあると思うんですよね。

なので、本書はどのページを開いてもソースコードがあるぐらいになっています。具体的な事例を出して、どういうのが悪しきコードなのか。それの何がまずくて、設計でどう解決すればいいのかを、僕なりにちゃんと要点を押さえて整理して記述しているので、新人教育にはピッタリだと思っています。なので、チーム全体の設計力向上とか、底上げを期待できると僕は思います。

本書は初心者向けというわけではなく、僕ならではのユニークな設計観点をいろいろと盛り込んでいるので、中級以上の方にもおすすめというか、読んでいただけると、また学びがあるのかなと思います。

書籍の特徴2：膨大なサンプルコードと事例での説明

2つ目の特徴としては、先ほどもお話しましたが、膨大なサンプルコードと事例で説明していますよ。どこを開いても、ほぼソースコードで満たされています。それほど具体事例が豊富なので、圧倒的ボリュームです。

上位の設計技術書となると抽象論がけっこう多くて、具体的なソースコードを取り扱った設計を満足にしていないケースがあったりします。本書はそういうものではなく、ちゃんと具体的なソースコードを示して、イメージしやすい構成になっているところが魅力の1つだと思っています。

書籍の特徴3：実践で使えるオブジェクト指向設計

特徴の3つ目は、実践で使えるオブジェクト指向設計。僕はアプリケーションアーキテクトとして、業務でリファクタリングとか設計全般を推進しています。なので、いつも技術的負債と戦っているんですね。そもそも「技術的負債をなんとかしてくれ」という依頼のもとに僕は仕事をしているので、ふだんから泥臭いコードの最前線で戦っているわけです。

この本に記載したノウハウは、僕がまさにふだん実際に仕事で使っている、本当に使えるコード改善のためのオブジェクト指向設計です。オブジェクト指向設計の参考書は、お作法的なことしか書いていなくて、「応用的にどう書いていいんだろう」みたいな。「実際の実装課題とか設計課題に対してどう使っていけばいいんだろう」というところが、教科書的でいまいちわかりにくい部分がもしかしたらあるかもしれません。

ですが、そうではなく、僕が実際に使っているノウハウなので、理論武装ができるというか、そのまま使って戦えるものだと自負しています。

（スライドを示して）これは何を言っているかというと、僕が「この本を出しますよ」と書いた時に、僕のフォロワーさんで、「いい設計をしようにも、上とか周囲がぜんぜん理解してくれん」「彼らをどう説得すればいいんだろう」と悩んでいる方が1人いて。

僕はかつて、職場の技術的負債がいよいよヤバくなったことがあって、僕はかねてから設計的なまずさに関して声を上げていたので、真っ先に立候補して「リファクタリングをさせてください」と言ったんですね。

でも、反対勢力のほうが多いわけですよ。「そんなリファクタリングなんかしていたら利益が出せなくなってしまうじゃないか」みたいな。彼らの言い分はわかりますが、血がドクドクと流れているような状態で、「とてもじゃないけど戦えねえだろ」みたいなところで、「設計的にはテコ入れをしなきゃいけない」と言いました。

当時は反対勢力のほうが圧倒的多数だったんですよ。僕が反対勢力を説得するために「なぜこういう設計をしなきゃいけないのか」とか、「この設計はこの実装課題に対してどう効いてくるのか」ということを、理論武装して彼らに説明する必要があったんです。

その時に実践した、「なぜこうしなきゃいけないのか」というノウハウに基づいてこの本は書きました。なので、設計一つひとつについて「なぜやるのか」「どういう効果があるのか」も手厚く解説しているので、ちゃんと設計の理論武装ができるというところです。

それから、何日か前にもツイートしたんですが、やはり設計って銀の弾丸ではないので、「この設計パターンを覚えればもう無敵だ」というものでもないんですよ。

「この技術課題に対してこの設計は適合するかどうか」という技術選択を必ずしなきゃいけないわけです。僕もいつもそれを考えています。いつも杓子定規に、自分が知っているノウハウをなんでもかんでもやればいいというわけじゃなくて、リファクタリングをするにしても、「次にこういうことで機能を盛り込みたいから、いついつまでの期間にこれをやってほしいと。

それをやるために、どういう計画に落とし込んでやらなきゃいけないか」となると、時間やコストはトレードオフになったりするので。

「じゃあ、その限られたコストの中でどういう設計に落とし込めばいいんだろう。理想的な設計は全部はできないけれど、ここまでだったらやれるんじゃないか」「設計要件を満たせるんじゃないか」とか、そういう技術選択をちゃんと毎日僕はやっているんです。

だから、「そういう技術選択がなぜできるのか」は、「この設計はどういう設計効果があるのか」「やればどのぐらい効果があるのか」「どういう課題に適合するか」という理屈を知っているから、「これは使える」「今回はコスト高いからこれは使わない」という選択ができるようになります。

そういう時においてもちゃんと技術選択ができるようになるために、設計の背景や理由を本書では学べます。

書籍の特徴4：Javaで書かれている

4つ目の特徴は、Javaで書かれています。なぜJavaを採用したかというと、広く読んでいただくことを意図しています。一番使用者数が多いのがJavaなのでJavaを採用したというところですね。

もう一言言うと、Javaはけっこう設計関連の話題が豊富です。みなさんがご自身で設計関連の学びを深めたいという時に、Javaを知っていれば、そういういろいろな技術サイトとかを回って歩いて、自分で学んでいけるのかなと。

そういった意図があるのでJavaを使っていますが、Javaの本ではないと。そういう意図（があるの）で、Java独自の言語仕様やフレームワーク知識はあまり用いていません。ほかの言語でも読み替えが容易になるように配慮しています。

最近のソフトウェア業界は、特にWebアプリだけが注目されているように見えますが、Windowsとかスマホのネイティブアプリとか、ハードウェアレイヤーに近い組み込みソフトウェアとか、ゲームとか、いろいろなITの領域があると思うんです。

僕自身はWebアプリの経験もあるし、ネイティブや組み込みの経験もあるので、特定のIT領域に限定しないで、オブジェクト指向言語ならどれでも適用可能な設計をしようということを考えて記述をしていました。

そのため、データベースやHTML、ファームウェア技術や特定のフレームワークなど、そういった知識は本書では取り扱っていません。

書籍の特徴5：ドツボにはまりやすそうなパターンを網羅している

これが僕の本にはあってほかの本にはない、最大のユニークな特徴です。ドツボにはまりやすそうなパターンを網羅している。

僕はこれを「再現性のある罠」と呼んでいます。これは何を言っているかというと、僕は先ほど、Webアプリやネイティブアプリ、組み込みソフトウェアとか、いろいろな分野のサービス開発の経験があると言いました。

サービスが異なっても、中に書いているソースコードの悪しきコードの傾向って、ほとんどみんな同じなんですよ。みんな同じ罠にはまっているんです。

「これはこの分野はWebアプリだったから」とかではなく、若干そういう傾向もあるかもしれませんが、少なくとも僕が観測してきた結果としてはそんなことはなくて、みんな同じドツボにはまっている。だから、そういう再現性のある罠に対応する、再現性のある対処方法を豊富に解説しているのが、僕の本の一番の特徴かなと思っています。

つまり、この本に書かれていることを遵守すれば、すべてじゃないにしても、たいていの悪しきコードは解決するんじゃないかと豪語しています（笑）。

あとこれも僕の本の最大のユニークな特徴ですが、悪しきコードが最も書かれやすいタイミングが何かと言ったら、やはり仕様変更時だと思うんですよね。そもそも、悪しきコードって変更容易性にかかわるところなので、変更というのが一番のキーになります。

なので、仕様変更をした時に、やってしまいがちな実装とかがあると思うんですよね。「みなさんが仕様変更をする時に、ついついこういうコードを書いちゃいますよ。でもこれはダメなんですよ」というところに着目して、僕の本は書いています。

仕様変更時にやってしまいがちな悪しきコードとか実装とかコードとかに着目して、どう改善すればいいかを解説している本です。

「仕様変更時に、こういう酷いことが起こるぞ」ということが書かれている本って、少なくとも僕が知っている範囲ではあまり見たことがない。もしかしたらあるかもしれませんが、知っていたらどなたか教えてください。少なくとも僕が見てきた範囲ではないので、このあたりは僕の本のユニークな特徴なんじゃないかなと思います。

すでに僕が献本した方とか、先行して入手された方から評判の声が届いています。ちょっと読み上げますが、「設計やコードの実例がすべてにあってボリュームがすごいです」とか、「さっそく読み始めたけど、目次を見てあまりの重厚さに怨念の深さを感じる」という。実際、怨念駆動で書いた本なんですけれど（笑）。

ほかには、「4章を読み始めたけど、例が多いので改善するためのイメージがしっかり湧いてよき」「要点が整理されていてすごくいい」と。あと「アンチパターンの説明が具体的であり、どうすればよいかがちゃんと説明されていてよき」とか。

設計の有識者のみなさん、DDDのログラスの松岡さんからは「すごいボリュームです！」「コード例が豊富で、抽象論ではなく具体的な議論に使えてすばらしいと思います！」と。kawashimaさんからも、「ソフトウェア設計版『独学大全』って感じで、分量とコンテンツの詰め込みが半端ない」という、非常にうれしい声をいただいています。

（次回に続く）