悪しきコードの痛みを知り、設計スキルを高める方法を学ぶ　全17章からなる『良いコード/悪いコードで学ぶ設計入門』

第1章：悪しきコードの弊害から痛みを知る

仙塲大也氏（以下、仙塲）：ここからは各章の紹介です。本書は1章から17章までの全400ページあります。第1章「悪しき構造の弊害を知覚する」。1章と2は、新卒さん向けの章です。「設計なんかぜんぜん知らないですよ」という方向けの章です。

そもそも設計って、「設計しなきゃ」という危機意識が必要なわけですね。その危機意識の醸成には、悪しきコードによる弊害を知覚する必要がありますよ。悪しきコードの弊害を数例用いてダイジェスト的に紹介して、痛みを知ってもらおうという章です。

第2章：「設計とは？」を学ぶ

第2章「設計の初歩」。本格的な設計は3章の「クラス設計」から始まりますが、いきなりクラス設計となるとちょっと重いので。第2章で簡単な命名や小さいメソッドの設計とかをベースに、「どういうことをするのが設計なの？」というところを学びます。1章と2章をつうじて、設計がぜんぜんわからない新人の方でもステップアップしやすい構成になっています。

第3章：Value Objectを中心に学ぶ

3章「クラス設計 すべてにつながる設計の基盤」。3章から設計解説の本番がスタートします。この章はValue Objectを中心に学ぶところです。インスタンス変数しか持っていない、データしか持っていないクラスを“データクラス”と呼びますが、（これは）いわゆる低凝集なんですよね。

そういった貧弱なデータクラスを高凝集なValue Objectへ成長させる例を用いて、「クラスってどうやって設計するの」という基本を解説する章です。ここは全章にわたっての設計の考え方というか、基盤になる部分なので超重要な章です。なので、本書全体を理解するには、この3章の理解が必須です。

ここで出している設計は、ほかの章で説明しているいろいろな章の応用になってくるので、「まずこの基本をしっかり押さえましょう」というところです。

第4章：「不変を活用して予測しやすい挙動の設計」を解説

第4章「不変の活用 安定動作を構築する」。変数の値を変えられるとか、状態変更が可能なことを“可変”、変えられないことを“不変”と言います。可変が前提のロジックだと、変数が自分が意図しない間に違う値にすり替わっている感じで、挙動の予測がすごく難しくなるんですね。保守とかがすごく大変になる。

だから、近年すごく着目されていますが、「不変を活用して予測しやすい挙動の設計をしましょうよ」ということを解説をする章です。

第5章：低凝集に陥りがちなパターンと対策を解説

第5章「低凝集 バラバラになったモノたち」。強く関連し合うデータと、それを操作するロジックがバラバラに散在している構造を“低凝集”と言います。低凝集というのは、重複コードや修正漏れを生じさせやすくて、なにかと厄介な構造なんですよね。ソースコードが巨大化していくと、どんどん低凝集で関係しちゃうものが分散しがちになる。

そういう低凝集に陥りがちな、いろいろなパターンがあるので、「こういうことをすると低凝集になるよ」みたいなパターンを網羅して、それぞれの対策方法を解説していく章です。

第6章：条件分岐の複雑さを低減した設計の解説

第6章「条件分岐 迷宮化した分岐処理を解きほぐす技法」。条件分岐は、普通にプログラミングでは基本のキで出てくるような、条件に応じて処理を切り替えるプログラミングの基本制御です。この条件分岐を杜撰に扱うと、ロジックがメチャメチャ複雑化して、混乱して理解ができなくなる。

だからこの章は、「条件分岐の複雑さを低減して、ちゃんと自分たちのコントロール下に置きましょうよ」という、そういう設計方法を解説しますよ。

特に、ロジックの単純化を握るインターフェイス。インターフェイスってなかなか使いこなせないと思いますが、それをちゃんと使えば、ものすごく劇的にロジックが単純化するので、そこについて重点的に解説しています。

第7章：コレクション周りのロジックを簡明にする設計を解説

第7章「コレクション ネストを解消する構造化技法」。配列やリストというのは、コレクションです。ああいうコレクションって、繰り返し処理というか、ループ処理を伴うと思います。

ループ処理の中にif文が紛れて、ループのネストとif文のネストが複雑に絡み合ったりして、コレクション周りでもロジックがすごく混乱しがち。だから、コレクション周りのロジックを簡明にする設計を解説する章です。

第8章：単一責任原則をベースした密結合構造→疎結合構造にする設計の解説

第8章「密結合 絡まって解きほぐせない構造」。責務がいろいろと異なるさまざまなロジックが複雑に絡み合って、依存関係がものすごく強い構造を“密結合”と言います。密結合になっていると、わずかなロジック変更でも本当にいろいろな箇所に影響が伝搬して、意図しないところがバグになったり、すごく変更に弱くなってしまいます。

8章では単一責任原則をベースに、密結合な構造を疎結合な構造へ改善する設計手法を解説します。よく設計の話になると、“単一責任原則”や“責務”という言葉が出てきますが、「これっていったい何なんだろう」という話が何回もされたりすると思うんですね。

この章を見ると「単一責任っていったい何？」「責務って何？」というのがしっかり理解できて、自分でもちゃんと説明ができるようになります。

あと、密結合はいろいろな要因によって陥りがちなんですよね。なので、密結合に陥るいろいろな悪しきコードパターンといいますか、実装パターンのいろいろシリーズと、その対策方法として取り揃えている章です。

第9章：邪悪な実装シリーズを解説

長い。やっと9章（笑）。「設計の健全性をそこなうさまざまな悪魔たち」。ここは設計という観点とはちょっと違うと思いますが、実装上の一般的な問題ですよね。null問題や例外の握り潰しといった、邪悪な実装シリーズを解説する章です。

null問題とか例外の握り潰しとかも、実装としてはすごくチープで簡単なんですけど、単純だからこそ新人さんってけっこう陥りがちなんですよね。でも、こいつらはみんな凶悪だと。

なので新人さんには、こういう凶悪な罠にはまってほしくないので、ぜひこの章に目を通してほしいと思います。これをしっかり守るだけでも、会社の先輩方から叱られずに済みますよというところですね。

第10章：最適なロジック構造を作るための名前の設計方法の解説

第10章は「名前設計 あるべき構造を見破る名前」。この章は、僕の本の中で、ページ数としては確か一番多いはずです。よく命名って可読性、読みやすさとかに関係すると言われていますが、そうではなくてロジック構造をムチャクチャ左右します。なので、いい加減な命名をすると、あっという間によくない構造ができ上がっちゃうんですよね。

ここでは僕が提唱する「目的駆動名前設計」という考え方をベースに、最適なロジック構造はどうなればいいかを導き出すための名前の設計方法を解説します。

目的駆動名前設計と、すごく仰々しく書いていますが、これってモデリングの考え方とつながっていて。モデリングが何かと言ったら、要はシステム化する対象です。ソフトウェアを設計する時にはモデリングをするわけですが、そのモデリングをする時は、ある目的を達成するためにその対象の特徴的な一部分だけを切り出して抽象化するので。

いずれにしても、モデリングをする時には、何のためにそこを抽象化するのかという目的が必ず視野に入ってくるわけですよ。だから、「名前を決めるのも当然目的から入るべきでしょう」という考え方を“目的駆動名前設計”と言っています。なので、「目的をベースに名前を設計しましょうよ」というコンセプトの設計の考え方ですね。

あと、命名でついつい陥りがちな罠がいっぱいあるので、それの対策方法も数多く解説しています。なので、名前を設計するいろいろな状況に対応できるようになる章です。

第11章：コメントの書き方の解説

第11章「コメント 保守と変更の正確性を高める書き方」。コメントの書き方です。コメントは読み手の理解を促すために記述をしますが、いい加減なコメントを書くと、読み手に正しく意図が伝わらなかったり、逆に嘘を伝えてしまう可能性があります。

なので、そういう状態に陥らないよう、ちゃんと保守や変更の役に立つようにするコメントの書き方を解説する章です。

第12章：メソッド設計の解説

12章「メソッド（関数） 良きクラスには良きメソッドあり」。メソッドの作りって、クラスの作りに密接に連動します。メソッドの設計がよくないと余波でクラスの設計も悪化するし、逆もまたしかりであると。そういう観点で、メソッドをどう設計すればいいかを集中的に取り扱っている章です。

第13章：モデリングの解説

13章「モデリング クラス設計の土台」。さっきもちらっと言いましたが、物事の特徴や関係性を簡単に図で表したものをモデルと言って、そのモデルを作る活動のことをモデリングと言います。

モデルはクラス設計の土台になるので、モデルがいい加減だったり、そもそもモデリング自体をしないとクラス構造がすごく粗悪になって、変更がとても難しくなってしまうわけですよね。

なので、ちゃんとモデリングをしないと、どんな悲惨なことになるかを押さえ込んだ上で、「じゃあどうやってモデリングをするのがいいのか」を解説している章です。

第14章：リファクタリングで陥りがちな罠とテクニックの紹介

第14章「リファクタリング 既存コードを成長に導く技」です。ここで聞いているみなさんにとっては、リファクタリングは当たり前の知識かもしれませんが、新人さんにとっては、「リファクタリング is 何？」みたいな感じで、わからない部分もあったりするので。新人さんがステップアップをしやすいようにと設けた章です。

ただ、新人さん向けというだけではなくて、よくあるのが、「レガシーコードにそもそもまずテストがない」という問題があったりします。テストがないコードをどうリファクタリングすればいいかとか。

それから、リファクタリングでやってしまうとまずい方法もやはりあるので、リファクタリングの時に陥りがちな罠とか、中級者以上にも有用なテクニックも紹介しています。

第15章：設計にまつわる考え方や取り組み方の解説

15章「設計の意義と設計への向き合い方」。15章、16章、17章の後半3章は、ソースコードは登場しません。15章は、設計にまつわる考え方や取り組み方を解説する章です。

「我々はいったい何のために設計をするのか」とかという設計の意義や、我々が設計に対してどう向き合って、どう設計品質を高めていけばいいのかを深掘りしつつ解説する章です。

それに伴い、設計品質の指標がありますが、いろいろなソフトウェアの品質の指標であるメトリクスとか、メトリクスをコントロールする各種ツールを紹介する章でもあります。

この章は、設計と会社の事業成長の関係性もさることながら、設計がエンジニア自身のスキル成長に影響するところも解説するので、けっこう重要な章です。

第16章：設計を妨げてしまう開発プロセスの解説

16章「設計を妨げる開発プロセスとの戦い」。設計がうまく働かないのって、設計スキルが未熟であること以外に、そもそもの開発プロセス、組織的な問題がやはりあるんですよね。

この16章では、設計を妨げてしまう開発プロセスをちょっと解説します。例えばそれがメンバー間のコミュニケーションであったり、心理的な要因であったり、組織上の課題であったりにフォーカスをして、それぞれ何がまずいか、それぞれの対策方法を解説しています。

第17章：自主的に設計スキルを高めていくための方法の解説

17章が最終章です。「設計技術の理解の深め方」。読者さんがこれから自主的に設計スキルを高めていくための方法を解説します。

中・上級へのステップアップに有用な技術書を、用途や難易度に応じていろいろと紹介します。設計技術書って、やはり設計をあまり学んだことがない方にとってはけっこう難しいことを書いていて、「これは何を書いているんだ？」と、ちょっとわからない側面もあるんですけど。

僕の本で設計知識の足固めをしておけば、「そういえばこれ、なんかミノ駆動本で見たぞ」みたいな。進研ゼミっぽい感じで、スムーズにスルスルと理解が進むんじゃないかと思います。あと、設計技術の効率的な学習方法も最後に解説しています。

書籍の副教材『バグハンター2 REBOOT』

（スライドを示して）おまけですが、これは僕が作ったバグ退治RPG『バグハンター2 REBOOT』というゲームです。この本の副教材的な位置づけです。これはバグとか悪しきコードが敵となって襲いかかってきて、それに対して、いろいろな設計スキルで倒していくゲームです。プレイ動画を用意しましたので、ご覧ください。

（デモ動画開始）

初っ端からやばいやつがいるわけですよ。「staticおじさん」とか「巨大データクラス」とか「長大な関数」とか。なんかいつもセットになっていそうなやつがセットで登場している。

「グローバル変数」とか、うんちゃらManagerとか。ちなみに今光っている「SingletonManager」は実在します。あと、「秘伝のソース」とか絶対触りたくないようなやつまで敵として登場します。触ったらどうなるかは、このゲームでバトルをしてからのお楽しみということで。

こういうアカン敵どもが、それぞれユニークな攻撃を仕掛けてきます。左側の赤いウネウネしたやつがスパゲッティコードです。スパゲッティコードに殴られると混乱するんですね。下にいるガイコツみたいなやつは、「スマートUI」というモンスターですが、こいつは密結合という技を使って防御をガチガチに固めてくるんですね。

こういうアカンやつらを、いろいろな設計スキルを使って退治していくシステムになっています。今さっそく「バリューオブジェクト」という技を仕掛けていますが、「イミュータブル」とか、僕の本でも出てくるいろいろな設計スキルが実際に技となって登場していきます。

司会者：芸が細かいなあ。

仙塲：これは「多重ネストswitch文」というボスです。この敵に対して、今「ポリモーフィズム」という技を仕掛けています。

このあと何が起こるかは知識のある人だったらたぶんわかると思いますが、ものすごいダメージを与えられます。なので、実際の設計テクニックと効果を知っていると、ゲームでもけっこうニヤリとできてしまうという。そういう実際の設計スキルをちゃんと考えています。

敵を倒すとスキル習得に必要なアイテムを落としてくれるんですね。この習得のアイテムが「単一責任の原則」とか、ソフトウェア原則です。これを集めていって、新しい設計スキルを覚えて、敵を倒すための技を覚えていくものになっています。

例えば「バリューオブジェクト」ですが、習得するものが「名前可逆性」とか「ロジック＆データ一体化」とか「求めるな、命じよ」とかで。要は、バリューオブジェクトと実際に関係のあるソフトウェア原則がこのスキルの習得のために必要になってくるという、けっこうガチめの内容になっています。

（デモ動画終わり）

僕の本もそうですが、設計関係っていろいろな用語や原理原則がわんさか出てくるんですよね。覚えるのがなかなか大変です。ですが、このゲームをプレイしているだけで、今お見せしたような設計関係のいろいろな用語と出会うことになります。

遊びながらいろいろな用語に触れられて、「ああ、そういえばなんかこんな敵には、あのスキルが効いていたな」みたいな感じで、イメージしながら学びやすくするために、そういう作りにしてあります。「ちょっとした学びになるゲームですよ」というところですね。

ちなみに、今回僕が書いた本は執筆に1年9ヶ月かかりましたが、このバグハンターの制作には4年かかりました（笑）。それだけ僕がひどいコードは嫌いだという話です。

このゲームはブラウザーゲームで、PCでもスマホでも無料で遊べます。ぜひ手に取って遊んでいただけると、本書の内容と合わせて効果的に学習が進むんじゃないかなと思いますので、よろしくお願いします。

（次回に続く）