社内LTでソフトウェア設計のすゝめを比較的新しいエンジニア向けにしたので、その資料を公開します。

1. ソフトウェア設計のすゝめ
株式会社ドワンゴ 吉村総一郎 (@sifue)

2. ソフトウェア設計を
なぜするのか？

3. そもそも設計って
必要なの？

4. プロトタイピングしながら作って
いくなら必要ないんじゃないの？

5. そうじゃない場合もある

6. 例えばどんな時か
複雑な要件を扱わなくてはならない時
考慮の抜け漏れのしやい複雑な業務用件
無停止メンテナンスなどの運用
耐障害性
拡張性
多くのシステムと連携

7. 複雑な要件を持つシステムは、
建築物で言えば高層ビルのようなもの
膨大な建築法
電気
ガス
空調
間取りの使い勝手
(トイレの数？)

8. 複雑な要件の考慮が抜けている場合には
大きなコストを払うことになることもある

9. 犬小屋をプロトタイピングで作って
それを拡張、改修し続ければ高層ビルになるか？

10. ならない
当初犬小屋で良かったものが要求の変更で
高層ビルが求められる悲劇がそこにはあるが...

11. できるのはハウルの動く城

12. 致命的な問題にぶち当たれば作り直しが必要
ある日突然考慮漏れの要件にぶち当たってシステム停止に陥ることも

13. ただ逆に要件の衝突が起こらないような
シンプルな要件のプロダクトなら
プロトタイピングを利用した
インクリメントな開発はかなり有効

14. とはいえ複雑そうなものは
設計を考えよう

15. でも突然ソフトウェア設計しろと言わ
れても何をするかよくわからない…

16. そんな方におすすめの第一歩

17. 図を書いてみよう

18. 図といっても
書き方がわからない…

19. そんなあなたに
おすすめの記法

20. UML

21. UMLとは
統一モデリング言語
(Unified Modeling
Language)という、1997年
に選定された世界的に利用
できるソフトウェアのため
の設計図の書き方
現在は、UML 2.4.1が最新
であり、13種類の図の書き
方を利用することができる

22. UMLがない場合の図は
どんな感じか？

23. 家計簿アプリの設計の例
変動費
月次集計サービス
支出
固定費
実は同じものを表しているのに、記法が違うために四角がど
ういう意味で、丸がどういう意味でとか、緑の線があれで、
青い線があれとかを毎回説明しなくてはいけない

24. つらい
設計レビューをする前に全員が図の記法を理解する
ところから始まる。設計レビューに途中からやって
きた人が図の記法がわからない...。新たにjoinした
メンバーも資料を見て意味がわからない。

25. UMLはそういう問題を
解決してくれます！

26. どんな図があるのか？よく使うだろう5つを紹介
ユースケース図: 要件の構造を表現
コンポーネント図: システム構成を表現
パッケージ図: パッケージの構成を表現
クラス図: クラスの関連を表現
アクティビティ図: フローチャートのようなもの

27. 家計簿アプリの設計
ユースケース図

28. 家計簿アプリの設計
コンポーネント図

29. 家計簿アプリの設計
パッケージ図

30. 家計簿アプリの設計
クラス図

31. 家計簿アプリの設計
アクティビティ図

32. こんなふうに記述できます

33. 図はわかってけど
何で書けば良いの？

34. おすすめのUMLモデリングツール
Gliffy
Astah Community
PlantUML

35. Gliffy
Confluenceのプラグイン
結構きれい
図が大きくなると重い
制約が緩めでUML以外の記
法もできる
クラス図の例

36. Astah Community
MacとWinで動くJava製のデ
スクトップアプリ
ページに添付すると
Confluenceで図を表示もで
きる
UMLに違反してる図は書き
にくいクラス図の例

37. PlantUML
テキストベースでUML書け
る(<|-- が継承とか)
最近流行ってる
Confluenceでも記述可能
GUIのサポートないので
UMLの仕様を知っている
必要があるクラス図の例

38. 以上紹介したツールを使ってソフ
トウェアの設計や設計レビューを
やっていきましょう！

39. おすすめ本
UMLの本というより総合的なソフトウェア開発の本

40. 設計のやり方はわかったけ
ど、具体的に何するの？

41. 設計の目的って何？

42. 設計とは、
要求に対して、狙った要件を設定で
きるようにすること。正解はない。

43. よく出てくる設計ノウハウ
システム構成をレイヤー化する/しない
モジュール化する/しない
モジュールをレイヤー化する/しない
SOLID原則を守る/守らない

44. システム構成をレイヤー化する/しない
多層アーキテクチャ
レイヤごとは疎結合にする
右は3層+LBの例
レイヤ毎に再起動更新できる
レイヤごとで台数を増やし負荷をコ
ントロールできる
レイヤが増えると管理コストは増え
る

45. モジュール化する/しない
汎用サブモジュールをくくり出
せ、重複が減って保守コストが
下がる
モジュールごとで人を割り当て
るので更新衝突が少なくなる
モジュール化することで開発コ
ストは増える

46. モジュールをレイヤー化する/しない
DDDのレイヤー化アーキテク
チャの例
ビジネスロジック(domain層)
がapplication層やui層のフ
レームワークのVerUP等の変更
をうけない
依存関係の強制を守るために依
存関係の逆転則とかを使わなく
てはいけないなど高コスト

47. SOLID原則を守る/守らない
以下は、コストと再利用性のトレードオフとなる
単一責務の原則: いろいろやるクラスを作らない
オープンクローズドの原則: 状態の変更からは守り、クラス
の自体の拡張を提供する
リスコフの置換原則: 継承は意味として親と子の交換可能で
あるようなクラス設計にする
依存関係逆転の原則: インターフェースを使ってレイヤ間の
依存関係を一方向にする
インターフェースの分離の原則: 内部実装を隠ぺいする

48. 依存関係逆転の原則の例
インターフェースを作ってそれを依存先で実装する

49. 適切な設計の目的を果たすための
色々なパターンがあるのでぜひ探してみてください
マーチン・ファウラーのリファクタリング
GoFのデザインパターン
PoEAA
エリック・エヴァンスのドメイン駆動設計
Lean architecture
Microservices

50. 要件漏れ/衝突が起こらないよう、開発者
の狙い通りに開発していけるようしっかり
レビューしながら考えていきましょう！

51. 以上
ご清聴ありがとうございました