ソフトウェア設計の実践的な考え方

①ソフトウェア設計の難しさ
②良い設計とはなにか？
③良い設計の効果
④ソフトウェア設計の実践技法
・既存コードの設計を改善するというアプローチ
・小さな設計改善
・大きな設計改善
・戦略的な設計改善

#javado 札幌 Java Doでしょう 31 「設計doでしょう」の発表資料

Transcript

1. ソフトウェア設計の 実践的な考え方 2025年10月4日 有限会社システム設計 増田 亨 #javado 札幌 Java Doでしょう 31 「設計doでしょう」
2. 自己紹介 専門領域 • 業務系アプリケーションの開発 最近の仕事 • 大きな泥団子退治のアドバイザ • エンジニアの成長支援（設計スキル向上） 2 増田 亨（masuda220） 著書(2017) 訳書(2024) ＊１ ＊2 *1 増田 亨(2017) 『現場で役立つシステム設計の原則』技術評論社 *2 Vlad Khononov(著) 増田 亨、綿引 琢磨(訳) 2024 『ドメイン駆動設計をはじめよう』オライリージャパン
3. お話する内容 ① ソフトウェア設計の難しさ ② 良い設計とはなにか？ ③ 良い設計の効果 ④ ソフトウェア設計の実践技法 • 既存コードの設計を改善するというアプローチ • 小さな設計改善 • 大きな設計改善 • 戦略的な設計改善 3
4. ①ソフトウェア設計の難しさ 4
5. ソフトウェア設計 ４つの難しさ ソフトウェアは複雑である ソフトウェアは変化を繰り返す 未知の課題に不確実な状況で取り組む 設計に使える時間は限られている 5
6. ソフトウェア設計 ４つの難しさ ソフトウェアは複雑である ソフトウェアは変化を繰り返す 未知の課題に不確実な状況で取り組む 設計に使える時間は限られている 6 どのくらい実感していますか？
7. ②良い設計とは何か？ 7
8. 設計の本質 良い設計は悪い設計よりも変更しやすい 8 『達人プログラマー ―熟達に向けたあなたの旅』第２版 Andrew Hunt(著)David Thomas(著)村上雅章(訳) 2020年 発行：オーム社 セクション８ Tips14
9. より実践的なソフトウェア設計の本質 整理整頓されたコードは 乱雑なコードよりも 変更が楽で安全である 9
10. 良い設計と悪い設計の違いを意識する 10 良い設計 変更が楽で安全 整理整頓されたコード 悪い設計 変更が厄介で危険 乱雑なコード
11. ③良い設計の効果 11
12. 良い設計（整理整頓されたコード）の効果 • 変更する時、どこに何が書いてあるか見つけやすい • 何かを確認するために読む範囲が狭い • 意図が理解しやすい／誤解や見落としが少ない • 変更箇所が少ない（重複が少ない） • 変更が影響する範囲を推測しやすい • 変更が影響する範囲が狭い • 変更結果を確認するテスト量が少ない 12
13. 良い設計（整理整頓されたコード）の効果 • 変更する時、どこに何が書いてあるか見つけやすい • 何かを確認するために読む範囲が狭い • 意図が理解しやすい／誤解や見落としが少ない • 変更箇所が少ない（重複が少ない） • 変更が影響する範囲を推測しやすい • 変更が影響する範囲が狭い • 変更結果を確認するテスト量が少ない 13 乱雑なコードは この裏返しになる
14. ④ソフトウェア設計の実践技法 14
15. 設計原則や設計パターン 原則やパターンを理解して知識を増やす価値は高い モジュール化、関心の分離、構造化、抽象化、… しかし、その知識が実際の良い設計（整理整頓された コード）に結び付かない 原則やパターンの知識があっても悪い設計がはびこるの はなぜか？ 15
16. 良い設計を実践できない理由 ⚫ 実際に必要なのは一般解ではなく個別解 ⚫ 不確実かつあいまいな状況で未知の課題に取り組む 似ている状況、似ている課題であっても、同じではない ⚫ 最初は良い設計でも時間とともに劣化し続ける ⚫ 設計に使える時間は限られている ⚫ 良い設計を実コードで経験的に学ぶ機会が少ない ⚫ 良い設計の効果を実感できる機会が少ない 悪い設計の痛みを実感する機会は多いが… 16
17. 実践的な設計アプローチ ✓ 既存の乱雑なコードを対象に設計改善を繰り返す ✓ 変更が必要になった時、必要な範囲の乱雑なコードを 整理整頓する ✓ 整理整頓されたコードに対して機能の修正追加を行う ✓ 乱雑なコードを整理整頓する効果を体験する 17
18. ソフトウェア設計のアンチパターン ⚫ 初期の設計（無知の設計）に時間をかける ⚫ 設計の良し悪しの判断に変更容易性以外を持ち込む ⚫ 乱雑なコードの整理整頓と機能の修正追加を混同する ⚫ 乱雑なコードを整理整頓しないで機能を修正追加する ⚫ 機能の修正追加をしない個所を整理整頓する 18
19. 設計改善（コードの整理整頓）三つのレベル ➢ 小さな設計改善 ➢ 大きな設計改善 ➢ 戦略的な設計改善 • 三つのレベルを並行して進める（段階論ではない） • 下に行くほど、効果がはっきりするのに時間がかかる • 下に行くほど、良い設計か悪い設計か判断が難しい 19
20. 小さな設計改善 初級レベル 乱雑なコードを整頓する６つの技法 ① コメントアウトされたコードの削除 ② デッドコードの削除 ③ チャンキング（空白行によるコード分割） ④ 説明用変数の導入 ⑤ ヘルパーメソッドの抽出 ⑥ ガード節の導入 全員が、いつでも、自発的に （相談・レビューなしで） 目指す状態 20
21. 小さな設計改善 中級レベル 乱雑さの原因をクラスに抽出して整理する ① 値の算術演算・比較演算の抽出（値オブジェクト） ② コレクション操作の抽出（コレクションオブジェクト） ③ 条件分岐の抽出（区分オブジェクト） ④ 入り組んだ計算判断を独立させる(メソッドオブジェクト) 全員が技法を知っていて リード役が支援、レビュー 目指す状態 21
22. 小さな設計改善の参考図書 22 第１部 整頓 第Ⅱ部 管理術 第3章 コードの不吉な臭い ４章～１０章 第1章 ちいさくまとめてわかりやすく 第2章 場合分けのロジックを整理する
23. 大きな設計改善（持続的なコード整理） • 入出力と計算判断の分離 • 画面処理／データベース処理／通信処理から、計算判断を分離する • アプリケーション記述とプリミティブ記述の分離 • アプリケーション特化のデータ型を独自に設計する • 独自のデータ型を使ってアプリケーションを記述する • 独自のデータ型内部にプリミティブなデータ型の操作を閉じ込める • 業務知識を使ってコードの名前空間を整理する • 業務の概念、構造、関心事の視点からコード整理の構造を決める 23
24. 大きな設計改善の参考図書 24 第3章 業務ロジックをわかりやすく整理 第4章 ドメインモデルの考え方で設計する 第12章 大きなリファクタリング
25. 戦略的な設計改善（戦略的なコード整理） ✓ 事業戦略とソフトウェアの実装を結びつける ✓ 差別化戦略に適合するように、ソフトウェアの設計方 針と開発の優先順位を決定する 中核メンバーが リードする 目指す状態 25
26. 戦略的な設計改善の参考図書 26 【エッセンシャル版】
27. 差別化戦略と業務領域の分類 27 競合他社との差別化 中核の 業務領域 業務ロジック の複雑さ 優先的に 取り組む 補完 一般 簡略に済ませる 模倣、流用、購入 他社と同じ 自社独自
28. 業務領域の分類と開発方針 中核 一般 補完 競争優位性 ◎ × × 複雑さ ◎ 〇 × 変化 〇 × × 開発方針 独自開発 製品購入 模倣 CRUD/ETL 簡易開発 28
29. まとめ 良い設計は悪い設計よりも変更しやすい 整理整頓されたコードは乱雑なコードより変更が楽で安全 機能の修正追加が必要な個所を対象に設計改善を繰り返す 小さな設計改善、大きな設計改善、戦略的な設計改善を 並行して進める 29