Java Doでしょう 31増田亨さんと設計の実践的な考え方を学ぼう！に参加した時のメモ書き（覚書）

Last updated at 2025-10-06Posted at 2025-10-05

この記事について

2025/10/4(土)に開催されたJava Doでしょう 31増田亨さんと設計の実践的な考え方を学ぼう！に参加させていただきました。

覚え書きとして、メモできた範囲でこちらにまとめます。
（間違えてたりしたら教えていただけるとありがたいです<(_ _)>）

勉強会の内容

Java Doでしょう 31
テーマ: 増田亨さんと設計の実践的な考え方を学ぼう！

内容を聞いてメモしたこと

🔍：調べたこと　💭：個人的な感想、思ったこと　👀：印象に残ったこと　⭐：ポイントかな、と思ったこと　📖：本

オープニング「20年間の開発で振り返る設計の選択の影響」

山川広人さん（JavaDo・公立千歳科学技術大学）

過去に作ったもので、SQLで計算とかデータ成形とかを頑張って、それをjavaを使って表示させるだけのものがあった
- 設計がガタガタ（動けばいい）なので、機能追加とかで常にリバースエンジニアリングをする必要があった
  - システムが大きくなってくると限界がある(´;ω;｀)

講話：ドメイン駆動設計や設計の実践的な考え方

増田亨さん

資料

本も書いていらっしゃる
ソフトウェア設計難しさ4つ
- ソフトウェアは複雑である
- ソフトウェアは変化を繰り返す
- 未知の課題に不確実な状況で取り組む
- 設計に使える時間は限られている（とりあえず動くことが優先）
設計の本質
- 良い設計とは何か
  - →良い設計は悪い設計よりも変更がしやすい
    - →整理整頓されたコードは乱雑なコードよりも変更が楽で安全である
- 良い設計（整理整頓されたコード）の効果
  - 変更するとき、どこに何が書いているか見つけやすい
  - 何かを確認するために読む範囲が狭い
  - 意図が理解しやすい/誤解や見落としが少ない
  - 変更箇所が少ない（重複が少ない）
  - 変更が影響する範囲を推測しやすい
  - 変更が影響する範囲が狭い
  - 変更結果を確認するテスト量が少ない
  - ⭐乱雑なコードはこれの裏返し！！
- 設計原則や設計パターン
  - 原則やパターンの知識を増やす価値は高いが、実際のいい設計（整理整頓されたコード）に結び付かない
    なぜ知識や理想があっても悪い設計がはびこるのか？
- 良い設計を実践できない理由
  - 実際に必要なのは一般論ではなく個別解
  - 不確実かつ曖昧な未知な課題
    - システム化の連携が当たり前になり、自己完結するのではなく、必ず外部と連携するオープンなシステムになる→外部と連携する＝未知な要因になる
- 実践的なアプローチ
  - 既存の乱雑
  - 👀実践とは自分の足で一歩ずつ歩いていくこと
- ソフトウェア設計のアンチパターン
  - 初期の設計（無知の設計）に時間をかける
  - 👀「パターンを使っている」というのが価値にはならない
- 設計改善（コードの整理整頓）三つのレベル
  - 小さな設計改善
  - 大きな設計改善
  - 戦略的な設計改善
  - ⭐仕事でシステムをつくる都合上、時間が無いので三つ同時にやらなくてはいけない
- 小さな設計改善
  - （初級レベル）
    - 乱雑なコードを整頓する技法
    - 使ってないコードの削除
      - 使ってないのか自信がないならログとかを仕込んで確認して消せばいい
    - 👀目指す状態
      - 全員が、いつでも、自発的に小さな設計改善を行う（相談・レビュー無しで）
  - 中級レベル
    - 乱雑さの原因をクラスに通出して整理する
    - コレクション（if文やwhile文とかの分岐が発生するもの）は、別なクラスとかにしてしまって隠ぺいする
      （ロジックが分からんけど、値を入れると結果が返ってくるという状態にする）
- 📖：Tidy First?
  - 1章と2章

- アプリケーション記述
  アプリケーションに特化したデータ型を独自に作ってそれをつかうようにする
  例：金額計算を
  　　✖Int（プリミティブなデータ型）とかを使って金額を計算する
  　　◎mony型というアプリ独自の型を作ってアプリ内で必ずそれを使うようにする
  例：通信成功失敗の結果を
  　　✖BooleanでTrue、Falseのフラグで返す
  　　◎SendResult型を作って、SUCCESS、FAILUREを返す
- 大きな設計改善
  - 入出力の都合と、計算ロジックの都合を分けて考えると楽になる
- 📖：前提知識がいっぱい書いてある本
  - 〔エッセンシャル版〕マイケル・ポーターの競争戦略

質問

[Q]
機能の追加や変更が必要な個所以外は、整理整頓しないというのはなぜ
[A]
ビジネス的にはあまり良くないという話。（時間がかかってしまう）
ビジネス的には、なるべく早く進めなくてはいけないため、これをやると時間がかかってしまって良くないということ
技術者的な観点からは推奨する

モデル駆動設計ワークショップ

お題：調整さんみたいなのを作る
モデル駆動設計
- どうしようかなって考える＝モデル
  実際にコードを書く＝設計
⭐他の人はどう考えたんだろう？を知ることが目的
データの状態（ステートマシン的なの）
結果を返す型を作ること！！
時間が無いので今回画面は考えなくていい

私が考えたやつ

できたとこまで載せます<(_ _)>
イメージの図を貼りますが、凄い雑です。
コードは全然できてないです。(言語はKotlinを使いました)

時間の都合上、以下を前提として考えました。

既に候補日が表示されている状態
DBに出欠を入力するメンバーの名簿を持っている
それぞれのメンバーが出欠を入力する欄が表示されている

状態遷移図もどき

「状態」の定義は、StateEnumクラスで持つイメージだった

/**
 * 状態の定義.
 */
enum class StateEnum {
    /**
     * 入力待ち.
     */
    INPUT_WAIT,

    /**
     * 入力済.
     */
    INPUT_END,

    /**
     * 回答済.
     */
    ANSWERED,

    /**
     * 未回答
     */
    NOT_ANSWERED,

    /**
     * 再調整.
     */
    RESCHEDULE_REQUIERD,

    /**
     * 確定.
     */
    DECIDED,
}

構成イメージ

懇親会

お勧めしていただいたAndroid Kotlinの初心者向け動画
- DroidKaigi 2025 - [JA] 未経験者・初心者に贈る！40分でわかるAndroidアプリ開発の今と大事なポイント | Shinobu Okano
  https://www.youtube.com/watch?v=6urkj9g2qgw
- DroidKaigi 2025 - [JA] Android値受け渡し大全〜設計を制する者が「渡す」を制す！〜 | みっちゃん
  https://www.youtube.com/watch?v=wIR-zMqJdKk

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Java Doでしょう 31増田 亨さんと設計の実践的な考え方を学ぼう！に参加した時のメモ書き（覚書）