シェア
はてブ 
2025年1月17日に開催されたオンラインイベント「改訂新版『ミノ駆動本』の活用方法 〜設計勉強会による効果的な学習アプローチ〜」。著者であるミノ駆動（@MinoDriven）さんから、所属されているDMM社にて実践され効果を上げている、設計学習方法についてお話しいただきました。
ご参加者からも、設計の「学習方法」について聞ける機会は貴重との声も多く、当日はチャット欄・Xともに大変盛り上がりました。また、多くのご質問も寄せられ、イベント中に可能な限り回答いただきましたが、時間の関係で回答しきれない質問も残りました。
「未回答Q&A特集」では、通常そのまま終わってしまうことが多いこうした未回答の質問について、ご登壇者のご協力のもと、イベント後に回答いただいたものをお届けします。
イベント参加者の皆さまはもちろん、当日参加できなかった方も、ぜひ本編のアーカイブ動画と併せてご覧いただき、改訂新版「ミノ駆動本」の活用方法のさらなるヒントを見つけていただければ幸いです。
※掲載の質問文は、内容に影響を与えない範囲で一部表現を調整しています。
Q&A
Q. 改訂前の本を持ってますが、改訂されてなにが変わりましたか？
以下の記事で詳しく解説しています。
7つのリニューアル！『改訂新版 良いコード／悪いコードで学ぶ設計入門』
Q. 生産性効率化にどの程度影響があったのか、定量的なものはありますか？
結論から述べると、生産性はこれから評価予定です。イベントで紹介した設計勉強会は2024年の秋から開始したばかりだからです。 ただし、生産性に関しては考慮が必要な背景がいろいろあります。前提として、まずその点を説明します。
書籍『リファクタリング』を執筆したマーチン・ファウラー氏が "Cannot Measure Productivity" で述べているように、生産性の計測は非常に困難です。コード品質だけでなく、ビジネスインパクトなどさまざまな要因の考慮が必要で、複雑性が高いです。
また、コード品質だけに着目した評価も困難です。例えば定量的な指標には循環的複雑度などがあり、評価には使えます。しかしコードが読みやすいかどうか（認知負荷）は、機械的な計測は困難です。拙著『改訂新版 良いコード／悪いコードで学ぶ設計入門』（以下改訂版ミノ駆動本）で解説している関心の分離も同様に、機械的な判断は困難です。同じ関心かどうか判断するには、ドメイン知識が必要だからです。
複雑で困難だからといって評価しなくても良いというわけではありません。複雑であることを理解した上で、部分的にも計測や評価をする姿勢が重要です。 弊社DMMのプラットフォーム開発本部では、設計勉強会を受講していただいたチームに対してリファクタリング計画の立案と実施をお願いしています。単に勉強会をやりっぱなしにするのでなく、着実に品質向上に結びつけるためです。
そして、数ヶ月毎にコード品質を評価します。定量的な評価にはSonarCloudを用います。定性的な評価には、チームメンバーへのアンケートを実施します。コードが読みやすくなったかどうかをアンケートに回答してもらいます（参考にした考え方は"Measuring Developer Productivity via Humans"の記事）。 部分的ではありますが、このようにして生産性評価を試みる予定です。
Q.ワークショップ中に各自にゼロから作ってもらうコードの規模感はどのくらいですか？数十行くらいになることが多いでしょうか？
学習内容や教材に使うプロダクションコードにもよりますが、多くてもだいたい100行以内には収まっています。
Q. データベースの設計をしくじると、コード全般へのインパクトが甚大です。データベース設計で気を付ける観点があれば教えてください。
「コード全般へのインパクトが甚大」とありますが、DBテーブル構造がアプリケーション層に影響するような構造になっていることが問題です。テーブル設計以前に、まずは影響が伝播しない設計が必要です。
それには改訂版ミノ駆動本で解説している「関心の分離」の考え方にもとづいて、アプリケーションとDBとで関心を分離することです。RepositoryパターンやQueryServiceパターンを使ってDBロジックを分離隔離することで、アプリケーションコードに影響しなくなります。
また、DBのテーブルとアプリケーションのドメインモデルは、構造が似ているようで異なります。テーブル構造に引きずられてドメインモデルを同じ構造にすると、アプリケーション層のロジックが混乱します。DBテーブルは永続化に特化した構造であり、一方ドメインモデルは業務課題の解決と整合性に特化した構造です。それぞれ要件が異なります。要件に応じた構造を設計しましょう。
DBテーブル設計は、正規化は最低限の基本であるとして、もう一歩踏み込んで大事なこととしては、単一責任原則を遵守するよう設計することです。改訂版ミノ駆動本でも解説していますが、単一責任原則を遵守するとは単一目的であることです。あるテーブルが複数の目的で使われるような構造（つまり文脈によってテーブルやカラムの意味が変わってしまう構造）を設計しないことです。
単一責任原則を遵守するDB設計には、T字型ER法が大変役立ちます。kawasimaさんの「イミュータブルデータモデル」の記事が詳しいです。WEB+DB PRESS Vol.130記載の「実践データモデリング」は、さらに詳しく分かりやすいです。
Q. スケジュールや予算の兼ね合いで、「設計に時間がかけられず、実装工程で、実装しながら設計を修正、訂正する」といった現場もあると思いますが、その場合は流れに任せて、最終的に問題点を正確に理解していくしかなさそうでしょうか？
イベントでは「問題コードは、変更容易性の高い理想構造とのギャップである」と解説しました。問題コードの把握には理想構造を正確に捉える、または設計する力が必要です。しかし複雑なコードを目にして理想構造がどうなっていればいいのか正確に類推するのは困難です。逆を言うと問題を正確に理解することが困難です。
大事なのは少しずつ理想に近づけていく姿勢です。設計に時間が割けないかも知れませんが、ほんの少しずつでも良いのでリファクタリングしてコードを改良していくと、少しずつ理想構造が見えるようになってきます。そうすることで何が問題だったのかも理解が進みます。
Q. 設計の考え方やエッセンスは理解できても、実際に実装するときに手が止まらないコツはありますか？（前提は組込み開発でC言語ですので多分色々と頑張る必要があると思います）
設計は一度で完成することはありません。継続的に改良していくものです。おそらくは、最初から完璧な設計を目指そうとして、ご自身でハードルを高めてしまい、手が止まりがちになるのではと推察します。
手を動かし続ける上で大事なのは設計要件を意識しながら何度も作り直すことです。私はそうしています。やりすぎて風呂に入りながら脳内でリファクタリングしていることもあります。
テストコードがあれば壊れる心配がありません。
Q. 普段はC言語でオブジェクト指向のように作ったコードを相手にしてます。C言語のコードでも役立ちそうでしょうか？
改訂版ミノ駆動本で取り上げているカプセル化や関心の分離、名前設計といった基本的な考え方はC言語でも活用できます。interfaceのような動的ディスパッチの仕組みは、C言語ではポインタキャストを用いて実現可能です。
Q. メンバー毎で見た場合、勉強会の参加は1回のみですか？それとも繰り返し参加するのでしょうか？
1回のみです。繰り返し勉強会での学習は、高い効果があるとは考えません。
基本スキルを身に着けていただいたら、あとは実践です。学んだことをしっかり意識して機能開発やリファクタリングに活用することでさらにスキルアップをのぞめます。これは自動車運転に似ています。ドライビングスクールで講習を受け免許取得後、実生活で運転し続けていくことで運転テクニックが実践レベルになります。
ミノ駆動さんよりメッセージ
登壇時も解説したように、読書だけでは効果は薄く、実際に手とクチを動かした人が大幅に設計スキルを伸ばせます。僕の改訂版ミノ駆動本を使い倒すぐらいのつもりでしっかりアウトプットしてほしいと思います。
アーカイブ動画
イベント本編は、アーカイブ動画を公開しています。こちらもあわせてご覧ください。
