開発者が知っておきたい複雑さの正体/where-the-complexity-comes-from
by
Ryo Tomidokoro
×
Copy
Open
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
開発者が知っておきたい 複雑さの正体 PHPカンファレンス福岡2025 2025-11-08 / hanhan1978 This presentation is built with ❤ and k1LoW/deck
Slide 2
Slide 2 text
Name : hanhan1978 / Ryo Tomidokoro From : 横浜市 Job : Backend Expert @ kaonavi inc Podcast : Yokohama North AM
Slide 3
Slide 3 text
目次 1. 複雑さとは? 2. ソフトウェア開発の流れ 3. 複雑さがやってくる物語 4. まとめ
Slide 4
Slide 4 text
1. 複雑さとは?
Slide 5
Slide 5 text
『A Philosophy of Software Design』より 複雑さとは「開発者がシステムを理解・変更することを妨げるものすべて」
Slide 6
Slide 6 text
『ソフトウェア設計の結合バランス』より 2章 結合と複雑性:クネビン 2-1 複雑性とは何か 複雑性とは理解のしにくさ 複雑性は主観
Slide 7
Slide 7 text
ようするに
Slide 8
Slide 8 text
「 分かりにくい!」と感じたら複雑
Slide 9
Slide 9 text
数字で測れる複雑さもある ● 循環的複雑度 (Cyclomatic Complexity) ● 結合度 (Coupling) ● 凝集度 (Cohesion)
Slide 10
Slide 10 text
循環的複雑度の高いコード例
Slide 11
Slide 11 text
循環的複雑度の高いコード例
Slide 12
Slide 12 text
結合度の高いコード例
Slide 13
Slide 13 text
結合度の高いコード例
Slide 14
Slide 14 text
クラス図だと理解しやすい
Slide 15
Slide 15 text
結合度を下げる改善例
Slide 16
Slide 16 text
凝集度の低いコード例
Slide 17
Slide 17 text
凝集度の低いコード例
Slide 18
Slide 18 text
Laravelで稀によく見るコード
Slide 19
Slide 19 text
Laravelで稀によく見るコード 同じキー名を何回使う気だ!!!
Slide 20
Slide 20 text
複雑なコードは、なんとなく分かった
Slide 21
Slide 21 text
では
Slide 22
Slide 22 text
複雑なコードはなぜ書かれるのか?
Slide 23
Slide 23 text
単に技術力の不足? そのif文はどこからやってくる?
Slide 24
Slide 24 text
2. ソフトウェア開発の流れ
Slide 25
Slide 25 text
ソフトウェア開発プロセス
Slide 26
Slide 26 text
エンジニアが目にする複雑さは 実装段階にて表出する ソフトウェア開発プロセス
Slide 27
Slide 27 text
しかし複雑さは どの段階からでも入り込んで来る
Slide 28
Slide 28 text
3. 複雑さがやってくる物語
Slide 29
Slide 29 text
要件で生じる複雑さ
Slide 30
Slide 30 text
例えば ● 事業の成長に伴う要件増加 ● 特定顧客からのカスタマイズ要望 ● 時代の変化・外部環境の変動
Slide 31
Slide 31 text
具体的なケース ● 「来季までに、X個の新機能を作ろう!」 ● 「A社さんだけ、処理が変わるようにしよう」 ● 「GDPRによるCookie利用の許諾チェック」 ● 「消費税xx%に変更、商品に軽減税率適用」
Slide 32
Slide 32 text
消費税計算のコード例
Slide 33
Slide 33 text
購入時期によって、税率が変わる仕様変更
Slide 34
Slide 34 text
商品種別、消費者行動で、税率が変わる仕変
Slide 35
Slide 35 text
設計で生じる複雑さ
Slide 36
Slide 36 text
例えば ● アーキテクト不在/役割不明確 ● 流行や技術選定の影響 ● いわゆるコンウェイの法則
Slide 37
Slide 37 text
具体的なケース ● 「何を作るか不明確だが戦術DDD風?のディレク トリ構造が先に決まっている」 ● 「CI/CDが計画されていない」 ● 「組織共通が決まってない」 ● 「職能組織内のコミュニケーション不全」
Slide 38
Slide 38 text
普通のMVCフレームワーク
Slide 39
Slide 39 text
無根拠な設計判断で戦術DDD風にすると
Slide 40
Slide 40 text
ファイル数が ...
Slide 41
Slide 41 text
ちょっとつらい ...
Slide 42
Slide 42 text
こっちの方が適切なパターンが多々ある
Slide 43
Slide 43 text
実装で生じる複雑さ
Slide 44
Slide 44 text
例えば ● 条件分岐の安易な追加 ● Switch文 ● オプション引数の追加 ● テストしづらい構造 ● わかりにくい命名
Slide 45
Slide 45 text
とはいえ... ● 技術は技術課題しか解決できない ● 適応課題から生じる複雑さは視野の広い解決策が必要 ● 最初から良い解決策は思いつけないことも多い
Slide 46
Slide 46 text
参考資料
Slide 47
Slide 47 text
SOLIDの原則ってどんなふうに使うの? https://speakerdeck.com/hidenorigoto/solidfalseyuan-ze-tutedonnahuunishi-ufalse
Slide 48
Slide 48 text
予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント https://speakerdeck.com/twada/growing-reliable-code-phperkaigi-2022
Slide 49
Slide 49 text
A Philosophy of Software Design, 2nd Edition 「複雑さ」がメインテーマ
Slide 50
Slide 50 text
まとめ
Slide 51
Slide 51 text
どうすれば「複雑」を予防できる?
Slide 52
Slide 52 text
普段の心構え ● 越境した学習を行う ● コミュニケーションを取る ● システム思考で考える ● フィードバックループを回す
Slide 53
Slide 53 text
でも 初手では防げないことも多い
Slide 54
Slide 54 text
だからこそ ● 要件・設計へと視野を広げて解決策を探る ● やれることから、少しでも改善をいれていく ● 諦めない!くじけない!
Slide 55
Slide 55 text
No content
Slide 56
Slide 56 text
おしまい