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

おしまい