概要

ソフトウェア設計を学び始めたとき、設計原則として「責務を分けよう」「疎結合にしよう」と言われても、実際にどのような設計・実装をすればよいのか、具体的なイメージが湧きづらいと感じたことはありませんか？本セッションは、マインスイーパという身近なゲームを題材に、具体的な設計とコードを通じて、これらの設計原則への解像度を高める体験を提供します。

マインスイーパには、セルやその状態、ボード（座標平面）、プレイヤー操作、難易度など様々な概念が存在し、設計を思考しながら学ぶ題材として適切なゲームであると考えています。セルの開封のように単純なロジックに見えても、「セルは状態を持つのか？」「セルは座標平面に依存するのか？」「セルからその近傍のセルを隠蔽するべきなのか？」など考慮点が多く、設計次第でコードの拡張性や可読性が大きく変わります。

本セッションでは、そんなマインスイーパをRubyによる純粋なオブジェクト指向で設計していきたいと思います。主な設計トピックは下記の通りです。

• 責務の境界線を定義し、情報隠蔽をする
• 具体よりも抽象的なインターフェースへ依存して、疎結合にする
• シンプルなインターフェースで強力な機能を提供する”深い”モジュールを目指す

これから設計を学びたい初学者や、日々の業務で「なんとなく設計している」中級者に向けて、責務と疎結合への解像度を高め、もう一歩深く設計を理解するヒントを持ち帰れるセッションを目指します。

詳細

対象とするターゲット

• 初学者
  • AIに設計を任せ切ってしまっている方
  • 設計の指針を持てていない方
  • 設計の技術書籍を読んで学んだが、あまりピンと来ていない方
• 中級者
  • 設計の技術書籍を読んで学んだが、より実践的に学びたい方
  • Ruby on Railsなどのフレームワークに従っての設計はできるが、そのレールからはみ出た設計に自信のない方
  • GoFのデザインパターンなどを学んだが、暗記になってしまいその本質が掴めていない方

トーク構成

• マインスイーパとは(3min)
  • ルール
• ER図の全体像(2min)
  • クラス図
• セル(3-4min)
  • 責務の境界線を定義し、情報隠蔽をする
    • 座標平面に依存する？
    • 状態を露出させる？
• セルの近傍(4min)
  • 具体よりも抽象的なインターフェースへ依存して、疎結合にする
• グリッド(3min)
  • 二次元配列を隠蔽する
• グリッドのファクトリ(3min)
  • シンプルなインターフェースで強力な機能を提供する”深い”モジュールを目指す
    • 複雑なロジックは隠蔽し、シンプルなインターフェースでグリッドを作成するインターフェース
    • シンプルファクトリパターン
• マインスイーパークラス(3min)
  • 多数のモジュールを利用するメインモジュール
• テスト容易性(3min)

このトークの意義

昨今のAI時代において、私は初学者がAIに取って代わられないために重要なのは「設計」であると考えています。 しかし同時に、初学者がその設計力を育む経験を得づらい環境に置かれていることを危惧しています。

インターフェースを定める「設計」と、その実体である「実装」を比較したとき、事業へのインパクトがより大きいのは明らかに「設計」です。実装は情報が適切に隠蔽され、副作用がなければ容易に差し替え可能ですが、設計は他のモジュールにも波及し、システム全体の構造を左右します。

しかし近年、AIネイティブ世代の初学者が、この重要な「設計」までもAIに全面的に委ねてしまう傾向があると感じています。答えが定まらない中でも試行錯誤し、概念を言語化しながら思考を深める、そうした経験を経ずに、AIに舵を預けてしまっているのです。

私はその原因を、初学者が「設計のポイント」や「思考の取っかかり」を持たないことにあると考えています。

本トークは、そうした初学者の方々に対し、設計を自ら考え始めるための“思考の種”を提供するものです。設計入門の資料は数多くありますが、本トークでは具体的な事例と思考プロセスの両面から、より実践的に「設計」を掘り下げます。