Slide 1
Slide 1 text
@hanhan1978
レガシー回避のPHP開発術
保守性の高いアプリケーションを作る方法
2023-06-24 PHPカンファレンス福岡
Slide 2
Slide 2 text
@hanhan1978
● 富所 亮
● 所属
株式会社カオナビ
BackEnd Re-architecturing Team (BERT)
● 職業
バックエンドエンジニア
● ブログ
https://blog.hanhans.net
● Yokohama North AM
https://anchor.fm/yokohama-north-am
2
Slide 3
Slide 3 text
レガシーとはなにか？
3
Slide 4
Slide 4 text
4
レガシーの定義
Slide 5
Slide 5 text
5
“レガシーコードとは、単にテスト
の無いコードです。”
Slide 6
Slide 6 text
6
“毎日実行され、過去の意思決定をもと
にのがれようのない影響を及ぼし続ける
が、なんの活力もないようなコードがあ
る。それを丁寧な言葉で「レガシー」と呼
ぶ。”
Slide 7
Slide 7 text
7
“保守または拡張が困難な既存のプ
ロジェクトなら、なんでも「レガシー」
(legacy)と呼ぶことにしている”
Slide 8
Slide 8 text
8
“創業期の資金不足や人材不足によっ
て生じたコード上の課題全般を、広義
のレガシーコードと定義”
Slide 9
Slide 9 text
まとめると
9
Slide 10
Slide 10 text
● テストが無い
● 活力が無い
● 保守・拡張が困難
10
Slide 11
Slide 11 text
11
これらの性質が一つでもあればレガシーなのか？
Slide 12
Slide 12 text
12
白黒はつかない
All or Nothing ではない。
Slide 13
Slide 13 text
13
● レガシーではない部分（計画的に設計・実装）
● レガシーな部分（涙を飲んだ部分）FIXME, TODOなど
● レガシーな部分（知らなかった、未認識）
実際にはアプリケーション内に良い箇所・悪
い箇所が混在する
Slide 14
Slide 14 text
14
思考停止は危険
全体をまとめてレガシーと表現してしまうと
「さあ！フルリニューアルだ！」という話にしかならない
Slide 15
Slide 15 text
15
場合によっては
フルリニューアルは合理的な判断だが
大抵の場合はコストがかかりすぎる
→ かつ、その組織で１から作ってレガシーになったのよね？
Slide 16
Slide 16 text
16
場合によっては
フルリニューアルは合理的な判断だが
大抵の場合はコストがかかりすぎる
→ かつ、その組織で１から作ってレガシーになったのよね？
歴史に学べ！！！
Slide 17
Slide 17 text
17
この登壇内でのレガシーの扱い
Slide 18
Slide 18 text
18
● テストが無い
● 活力が無い
● 保守・拡張が困難
これらを「レガシーな性質」と呼ぶ。
Slide 19
Slide 19 text
19
アプリケーション内にある「レガシーな性
質」の割合に目を向ける
全体を包含して、思考停止しないこと
Slide 20
Slide 20 text
20
レガシーな性質≒技術的負債
ただ、このままだと解像度が低い
Slide 21
Slide 21 text
21
● 自然には少なくならない
● 時間とともに勝手に増える
レガシーな性質の特性
Slide 22
Slide 22 text
22
「改善しないと、改善されないんだよ？」
ねぇ知ってる？
Slide 23
Slide 23 text
23
レガシーな性質を減らす活動をしないとい
けない
Slide 24
Slide 24 text
24
レガシーを回避するとは？
Slide 25
Slide 25 text
25
ソフトウェア開発の目的はレガシー回避で
はない
Slide 26
Slide 26 text
26
● テストがあり
● 活力があり
● 保守・拡張が容易
これらは必ずしも必須ではない
Slide 27
Slide 27 text
27
プロダクトアウト＋カスタマーサクセスが目
的
-> みんなでアジャイル
Slide 28
Slide 28 text
28
ただし
レガシーな性質を放置すると
目的達成の足を引っ張るようになる
Slide 29
Slide 29 text
29
現状、達成されていることにも目を向けましょ
うね。
ところで
Slide 30
Slide 30 text
30
● 希望
● 利益
● 人々の生活
● ビジョン
これらを達成できていないものはレガシーにも
なれていない
Slide 31
Slide 31 text
31
● 希望
● 利益
● 人々の生活
● ビジョン
これらを達成できていないものはレガシーにも
なれていない
良い面にもきちんとフォーカスを
当てましょう
Slide 32
Slide 32 text
32
なるようになって、今がある
Slide 33
Slide 33 text
33
ソフトウェアが達成したい目的はそれぞれ
作られてきたコンテキストも様々
Slide 34
Slide 34 text
34
そのソフトウェアを作ってきた歴史がある
作ってきたチームがある
経済活動をしてきた結果として今がある
Slide 35
Slide 35 text
35
そのアプリケーションに不満があるかもし
れない
体制に不満があるかもしれない
やり方に不満があるかもしれない
Slide 36
Slide 36 text
36
それはそれで、ある種安定した状態
単純に、レガシーな性質を悪とみなして活
動しても、うまくいかんぞ！
Slide 37
Slide 37 text
37
無計画な開発による意図しない副作用
https://www.coastalwiki.org/wiki/Human_causes_of_coastal_erosion
Slide 38
Slide 38 text
38
テストがないことが普通の場所で、テスト
があることを普通にしようとするのは、不
自然な行為
（サバンナをのぞく）
Slide 39
Slide 39 text
39
現状維持しがち
● 今はこれで動いているんだから
● 今までこれでやってきたから
● 変更するのは大変だから
正常性バイアスとの戦い
Slide 40
Slide 40 text
40
”当たり前”を変える必要がある
Slide 41
Slide 41 text
41
例
● リファクタリング
● PHPStan対応
● Accessibility対応
● フレームワークのバージョンアップ
● プログラミング言語のバージョンアップ
● CIの速度改善
Slide 42
Slide 42 text
42
ここまでのまとめ
Slide 43
Slide 43 text
43
● レガシーはソフトウェアの性質
● なるようになったものは変わりづらい
Slide 44
Slide 44 text
44
レガシーな性質を減らすには、そもそもレガ
シーを生み出す既存の流れ全体に抗う必要
がある。
局地戦で改善できるほど甘い相手ではない
Slide 45
Slide 45 text
ソフトウェアはどうやって作られるか？
45
Slide 46
Slide 46 text
46
0 -> 1 のフェーズ
Slide 47
Slide 47 text
47
● リリースが命
● 動くことが最優先
Slide 48
Slide 48 text
48
色々とない
● 金がない
● 開発者がいない
あるのは達成したいこと
Slide 49
Slide 49 text
49
目先の対応が求められる
> 個社対応
Slide 50
Slide 50 text
50
● 人材も環境も不十分
● ドメインが安定していない
「レガシーコードとの付き合い方」における課題はこ
のフェーズで大量に生み出される
Slide 51
Slide 51 text
51
1->10のフェーズ
Slide 52
Slide 52 text
52
ちょっと余裕がでてくる
● 開発者の採用にお金を使える
● 安定したドメインが出来てくる
商売になる黄金パターンが生まれてくる
Slide 53
Slide 53 text
53
ソフトウェアの状態
まだ、ビッグリライトをする余地がある
Slide 54
Slide 54 text
54
技術的負債の要因とその効果
Software Architecture Metrics / Oreilly & Associates Inc, 2022
Slide 55
Slide 55 text
55
技術的負債の要因とその効果
Software Architecture Metrics / Oreilly & Associates Inc, 2022
リプレースで一気に負債を返済
Slide 56
Slide 56 text
56
● 事業成長が求められる
● 機能がどんどん追加される
このフェーズの先には、リプレース作戦を取るの
が非現実的になるくらいに、システムの横のサイ
ズが増える
Slide 57
Slide 57 text
57
このフェーズで、「リリース優先なので...」
を連発すると、改善の難易度がバク上が
りする
Slide 58
Slide 58 text
58
技術的負債の要因とその効果
Software Architecture Metrics / Oreilly & Associates Inc, 2022
リプレースが非現実的になるほど、機
能が増えて、複雑度が増す
Slide 59
Slide 59 text
59
10->100 のフェーズ
Slide 60
Slide 60 text
60
市場をある程度押さえてきた状態
さらに市場を取りに行くために、採用にコストを
かけてチームを増やす
組織も大きくなる。
Slide 61
Slide 61 text
61
● どんどん機能が増える！
● リプレースは、非現実的になる。
● レガシー解消のコストも大きい
● 結局リリース優先の圧力は強い
単純に、影響が大きすぎる＆同時並行で開発してい
るものが多すぎて改善活動を諦めだす
Slide 62
Slide 62 text
62
リプレースが出来ないならどうする？
Slide 63
Slide 63 text
63
【一発逆転】銀の弾丸を探す現実逃避
● サービス分割
● 一部機能をSaaSに寄せる
● マイクロサービス？？
● モジュラーモノリス
● Rustで書き直す
Slide 64
Slide 64 text
64
いわゆる茹でガエル
Slide 65
Slide 65 text
65
● なんかCI重いな？
● なんか開発に時間かかるな
● なんか色々面倒くさいな
こんなことをひしひしと感じているフェーズ
Slide 66
Slide 66 text
66
積み上がるレガシーを肌で感じる
ビジネスとしての成功と、開発効率のバラ
ンスを上手にとる必要がある
Slide 67
Slide 67 text
67
ここまでのまとめ
Slide 68
Slide 68 text
68
ソフトウェアは、社会を良くするという動機を持って
誕生して、だれかの役に立つことで、経済活動が
なりたつようになって、どんどん開発が進んで行く
Slide 69
Slide 69 text
69
レガシーな性質は、普通に開発しているだけで
積み上がっていく。
そして、改善活動はソフトウェアの開発プロセ
ス上は優先度の高くない活動。
Slide 70
Slide 70 text
ソフトウェアの各フェーズで何が積み上がるのか？
70
Slide 71
Slide 71 text
71
0 -> 1 のフェーズ
Slide 72
Slide 72 text
72
知識不足によるインフラ面、ソフトウェア設
計面の負債
とにかく最速で作って動かすことが重視さ
れている
Slide 73
Slide 73 text
73
反面、そのときのモダンなスタックで作られてい
るので、経年劣化は起きてない。
ソフトウェアの中身や、インフラ構成（カネがな
い）で「とにかくリリース優先」の影響を受ける
Slide 74
Slide 74 text
74
総じて、レガシーな性質は少なく、打ち手
は多いが、やる人がいない、指摘する人
がいない
Slide 75
Slide 75 text
75
例
● フロントエンドの人しかいないので、全部 Firebase
● ベンチャー優遇の、謎SAASを使っている
● ノーコードのツール類を組み合わせたキメラ構成
Slide 76
Slide 76 text
76
1->10のフェーズ
Slide 77
Slide 77 text
77
開発者が増える。このフェーズで、インフラのうま
い載せ替えなどをすると、負債は一気に減る。
例 コンテナ化、イミュータブルインフラストラク
チャー化など
Slide 78
Slide 78 text
78
技術的負債の要因とその効果（再掲）
Software Architecture Metrics / Oreilly & Associates Inc, 2022
Slide 79
Slide 79 text
79
ソフトウェア自体が機能数が少ない状態なの
で、大胆な施策も取りやすい。
このタイミングで、機能開発全振りにしてしま
うと、大胆な施策が取りにくくなる
Slide 80
Slide 80 text
80
単純にデータ量も少ないので、色々やり
やすい
一方で、セカンドシステム症候群にとらわ
れる可能性
Slide 81
Slide 81 text
81
負債解消のゴールデンタイムであるため、
アレもコレもと欲が出る
Slide 82
Slide 82 text
82
例
● 俺たちの考えた最強のインフラ（最強ではない
● 俺たちの考えた最強のアーキテクチャー（最強ではない
● 俺たちの考えた最強の.... (最強ではない
● プログラミング言語変更 (変更できない
Slide 83
Slide 83 text
83
一見して、簡単に倒せそうなサイズ感に見
えてしまうため、きちんとやろうとしすぎる
Slide 84
Slide 84 text
84
結果として、拡張性のないアーキテクチャーが出
来上がったり、一品物のカスタマイズインフラが出
来てしまい、採用に困るような名品が作られる
Slide 85
Slide 85 text
85
10->100 のフェーズ
Slide 86
Slide 86 text
86
基本的には 1->10 のフェーズと同じだが、ビジ
ネスドメインの安定がさらに進む
会社の各組織が大きくなり、コミュニケーションコ
ストが上がる。
Slide 87
Slide 87 text
87
失敗したときのコストが、内外に対して上がる
このあたりまでにレガシーな性質が解消されずに残っ
ている場合、追加で時の試練を受け始める
Slide 88
Slide 88 text
88
例)
● ソフトウェアのバージョン問題
● フレームワークのバージョン問題
● OSのバージョン問題
● 問題のあるデータベース設計
● 取り返しの付かない仕様ハレーション
Slide 89
Slide 89 text
89
時間経過によって、モダンの概念が変わってくる
仮想サーバー -> コンテナ化
分散システム -> マイクロサービス
Slide 90
Slide 90 text
90
今やるなら当然コレという方式がでてきてお
り、何もしてなかったからレガシーになりました
という状態
Slide 91
Slide 91 text
91
若手優秀層は、隣の芝生は青いな〜っとな
る。
つねにデバフを食らっている状態
Slide 92
Slide 92 text
92
このフェーズでは、チーム数や関連する人間
の数も増えている
いかなる改善を行うにもコストが大きい
Slide 93
Slide 93 text
93
チーム内合意では不十分で、横断的合意が
必要となる
新規加入するメンバーのオンボーディングが
問題になるのもこの頃
Slide 94
Slide 94 text
94
加入するメンバー数が多いので、教育に携わる
メンバーも増やす必要がある
EM的なポジションが不在 or EM的な性質を
持ったメンバーがいなくなると、フォローが減る
Slide 95
Slide 95 text
95
とにかく、問題が多いので、ソフトウェアのレガシー
な性質に対する関心も低い
チーム内で上手くやることが大事になる
レガシーな性質もサイロ化
Slide 96
Slide 96 text
なぜ、改善されないのか？
96
Slide 97
Slide 97 text
97
> 改善活動を行わない限り、メンテナンスコストは
上がる
当然ですが、開発にはコストがかかります。コストの
大半は人件費
開発は、つまり開発者を金で雇って、ソフトウェアに
変更を行うこと
Slide 98
Slide 98 text
98
開発コストに、改善活動は含まれるか？
スクラム開発では、スプリント内に、チームが
主体的に改善活動を意図的に取り入れている
チームもありますが、大半のチームは、そんな
余裕はありません。
受託では......
Slide 99
Slide 99 text
99
質とスピード
Slide 100
Slide 100 text
100
質とスピードは両立する
https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition
Slide 101
Slide 101 text
101
質とスピードは両立する
https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition
それが出来るチームならな！
Slide 102
Slide 102 text
102
大半のチームは、質とスピードの境地に達して
いない
せいぜい、APoSD における戦術的プログラ
マーと同じ状態
複雑性は上がるけど、とりあえず要件は満た
す
Slide 103
Slide 103 text
103
ほとんどの会社において、とりあえず要件は満たす
という開発チームが必要最低限のレベル
すくなくともリリースが出来るなら、経営陣としては問
題なく見える
Slide 104
Slide 104 text
104
ほとんどの会社において、とりあえず要件は満たす
という開発チームが必要最低限のレベル
すくなくともリリースが出来るなら、経営陣としては問
題なく見える
ソフトウェアのやばさは、目に見えにくい
Slide 105
Slide 105 text
105
チームの基本行動
Slide 106
Slide 106 text
106
ディレクション
チームリード
デザイナー
QC
プログラマー
● インフラ
● バックエンド
● フロントエンド
● アプリ
いわゆる開発チーム
チームトポロジーにおけるストリームアラインドチーム
Slide 107
Slide 107 text
107
場合によっては、ここにマネージャーというさらに
高次のマネジメントを行う人がいたり、スクラム
やっている場合は、スクラムマスターやPOがいる
Slide 108
Slide 108 text
108
さて、このチームだけで、レガシーを促進せず
に開発がやれるか？
ほとんどの場合、このチームはメンテナンスコ
ストを足す方向に開発します。
Slide 109
Slide 109 text
109
改善は、このチームの第一目的ではない
このチームは、顧客に価値を提供するために機能
開発を行う
OSのアップデートとか、脆弱性対応は優先度として
は一段下がる
Slide 110
Slide 110 text
110
技術的負債の要因とその効果
Software Architecture Metrics / Oreilly & Associates Inc, 2022
負債がたまる方向にしか行動しない
Slide 111
Slide 111 text
111
チームにおこる変化
Slide 112
Slide 112 text
112
上手くいっているチーム
Slide 113
Slide 113 text
113
機能開発は行えるチームが、仮にうまくまわっ
ていたとする
収益があがるので、企業はさらに投資を行う。
さらに市場を取りに行く。
Slide 114
Slide 114 text
114
投資をすると、会社は開発者を採用してチームを増
やして、開発を複数並行では実行する。問題はその
やり方。
Slide 115
Slide 115 text
115
よくあるパターンは、チーム解体
Slide 116
Slide 116 text
116
バラして増やす
Slide 117
Slide 117 text
117
バラして増やす
やったぜ！３倍のアウトカム！
（とはならない）
Slide 118
Slide 118 text
118
TeamB, TeamC の２つのチームが新設
当初のチームは解体されている
同じスピードでの開発は期待できない
Slide 119
Slide 119 text
119
増えた２チームは、同じスピード、少なくとも同じ
品質で開発することが、投資した側からは期待さ
れる
実際には人間関係の再構築
役割の再定義などが起こるので、当初の効率は下がる
Slide 120
Slide 120 text
120
チームにおこる変化２
Slide 121
Slide 121 text
121
● メンバー離脱
● メンバー同士の相性問題
● 評価への不満
買い手市場であるエンジニアは、自分が適切に評
価されていないと感じると、すぐに転職する
Slide 122
Slide 122 text
122
PHPの主戦場であるインターネット業界で
は、平均勤続年数は４年前後
https://web-camp.io/magazine/archives/77694
Slide 123
Slide 123 text
ここまでの話のポイント
123
Slide 124
Slide 124 text
124
みんなの大好きなクリーンアーキテクチャーの話も、イ
ミュータブルインフラストラクチャーの話も、アジャイルも
スクラムも出てきません。オブジェクト指向とかも知りま
せん。
Slide 125
Slide 125 text
125
そんなものに関係なく
サービスの成長と共にソフトウェアはレガシーな
性質を貯める方向に成長していく
Slide 126
Slide 126 text
126
ところで
レガシーな性質が溜まりすぎるとどうなるか？
Slide 127
Slide 127 text
127
Bobおじさんの著書 Clean Craftsmanship には、倫理
の話がでてくる。
つまり、プログラマーが匠としての意識、高い倫理を保
たず、テストも書かず、現状が悪化するにまかせた場
合、どうなるか？
Slide 128
Slide 128 text
128
例
1. Volkswagen の改ざんソフトウェア
2. HealthCare.gov におけるパフォーマンス問題
3. Knight Capital の誤発注による倒産
Slide 129
Slide 129 text
レガシーを積み上げにくくする
129
メモ、ここから３０分かかる
Slide 130
Slide 130 text
130
全てに先立つ意識
顧客中心主義
ソフトウェアだけを見てはいけない。良い価値提供
という北極星を忘れないように。
Slide 131
Slide 131 text
131
それって、精神論？
いやいや、誰も技術を軽んじたりしてない。極端
に考えるのはNG
Slide 132
Slide 132 text
132
https://mtx2s.hatenablog.com/entry/2023/04/26/230917
Slide 133
Slide 133 text
133
証明できるのか？
Slide 134
Slide 134 text
134
プロジェクトを改善をした状態、改善をして
ない状態で、それぞれ計測しないと、改善
の効果は証明できない？
そんなこと不可能では？
Slide 135
Slide 135 text
135
マインドチェンジ
正常性バイアスとの正しい向き合い方
Slide 136
Slide 136 text
136
> 改善を止めようとするなら現状維持のメ
リットをださないといけない
Slide 137
Slide 137 text
137
Q レガシーな性質を保持し続けるメリット
を教えてください？
A 無いなら改善が必要だよね？
Slide 138
Slide 138 text
138
戦略面の打ち手
Slide 139
Slide 139 text
139
チームを大切に
Team First
Slide 140
Slide 140 text
140
うまくいっているチームを解散させない
改善を活動内に含むことができるような強い
チームがこの世でもっとも大切
-> まじで解散させるのはサイコパス
Slide 141
Slide 141 text
141
教育施策
1. オンボーディングの充実
2. ドメイン知識の共有・促進化策
3. チーム横断のコミュニケーション施策
Slide 142
Slide 142 text
142
組織変更
機能開発を主とせず、横断的にDevOpsを行
うチームの結成なども候補にはあがる
Slide 143
Slide 143 text
143
ただ、職能組織でワークしてないからって、横
断的組織を作ったら即座にワークするわけで
はない。人による。
チームトポロジーより
> 職能集団はサイロ化する。
Slide 144
Slide 144 text
144
ただ、職能組織でワークしてないからって、横
断的組織を作ったら即座にワークするわけで
はない。人による。
チームトポロジーより
> 職能集団はサイロ化する。
横断的組織もサイロ化する危険
Slide 145
Slide 145 text
145
採用
平均勤続年数が4年という世界線
採用した人が4年経過する前に、新しい人を採用
できないと開発が回せません。
Slide 146
Slide 146 text
146
まとめ
Slide 147
Slide 147 text
147
1. うまくいっているチームを解体しない
2. プロだって、成果を出すには、時間がかかる
3. 自主的な横断施策を行う人材を、大切にする
Slide 148
Slide 148 text
148
組織変更だけはうまくいかない
結局は人なので、横断的活躍をするラジカル
なメンバーが内部に存在してくれる必要があ
る。
Slide 149
Slide 149 text
149
戦術面でのうちて
Slide 150
Slide 150 text
150
視野を広くもつこと
● 🙅フロントエンドなのでバックエンドわからん
● 🙅バックエンド専門なのでインフラわからん
● 🙅インフラなのでアプリケーションはわからん
Slide 151
Slide 151 text
151
問題は職能内に閉じないので、個人が自
分の専門領域に閉じこもると解決が難しく
なる。
Slide 152
Slide 152 text
152
自分しか対応できるひとがいないという状
況だったら、何が出来るか？
-> 「出来ない」で蓋を閉じないで、自分の
領域の横に手をのばすことが大切
精神論ではない。最善を尽くせ！
Slide 153
Slide 153 text
153
レガシーな性質が溜まりにくいアプリケー
ションの基本
Slide 154
Slide 154 text
154
12 Factor APP
まだまだ当たり前になっていない。
先進的というよりは、それに従うことで、自然と
運用・保守し易いアプリケーション＋インフラ環
境になるというイメージ
Slide 155
Slide 155 text
155
https://12factor.net/ja/
Slide 156
Slide 156 text
156
https://12factor.net/ja/
Slide 157
Slide 157 text
157
計算機科学の知識
● アルゴリズム
● 空間計算量、時間計算量
● プログラムがどのように実行されているのかの知
識
Slide 158
Slide 158 text
158
バグとは？
積み上がったスタックの経路上で、想定外
の状態が混入した結果
Slide 159
Slide 159 text
159
Why Programs Fail / Morgan Kaufmann 2009
Slide 160
Slide 160 text
160
Why Programs Fail / Morgan Kaufmann 2009
型がついていると状態を確定し
やすい
早めの型付けで安心
Slide 161
Slide 161 text
161
Working out loud
問題はまず認識されることが必要なので、
大声で叫べ！
Slide 162
Slide 162 text
162
https://blog.studysapuri.jp/entry/2018/11/14/working-out-loud
Slide 163
Slide 163 text
163
Slackが活発で、小さいやり取りが多い
チームはコミュニケーションの問題が少な
い（経験談）
Slide 164
Slide 164 text
164
テストは書け
テスト書くこと自体というよりは、テストを書きや
すいコードに自然になるというのがポイントです。
Slide 165
Slide 165 text
165
テスト書く -> 終わりではない
TDDでコードを改善するための、最初の
一歩がテストコード
みんなもサバンナで暮らそうな！
Slide 166
Slide 166 text
166
コレ一冊で、とりあえず現場では困らなくなる
Slide 167
Slide 167 text
167
その先はコレ！みんなで付録Cの話をしよう！
Slide 168
Slide 168 text
168
設計視点を持つ
🙅ただコードを書けば良いという意識
Slide 169
Slide 169 text
169
● 一貫性を保てているか？
● 理解しやすいか？
● 変更しやすいか？
● 場当たり的な対応をしていないか？
● 名前付けは妥当か？
将来のために出来ることはたくさんある！
Slide 170
Slide 170 text
170
クリーンアーキテクチャーや、DDDにつ
いての私見
-> 特効薬ではない。トップダウン・アプ
ローチとして使うとむしろ毒
Slide 171
Slide 171 text
171
発想法からの指摘
Slide 172
Slide 172 text
172
まず課題がある
次に解決策がある
課題を見ずに解決策を当てはめるのは🙅
Slide 173
Slide 173 text
173
設計力をあげるには？
ちょうぜつ本を読め！APoSDを読め！
視野を広く！
Slide 174
Slide 174 text
174
相談する
コミュニティを頼って！ PHP Slack
PHPerRoom に、野生のPHPerがいるぞ！
Slide 175
Slide 175 text
175
サーベイ系
ちょっと真面目な技術選定の話
Slide 176
Slide 176 text
176
この回、超おすすめ
Slide 177
Slide 177 text
177
広く世間に知識を求めて
少し良い技術選定が出来るように
Slide 178
Slide 178 text
カオナビ での取り組みを紹介
178
Slide 179
Slide 179 text
179
チーム横断課題への取り組み
Slide 180
Slide 180 text
180
CTO室
Slide 181
Slide 181 text
181
https://speakerdeck.com/kaonavi/growth-ready-engineering-team
Slide 182
Slide 182 text
182
レビューマスター
Slide 183
Slide 183 text
183
Slide 184
Slide 184 text
184
Slide 185
Slide 185 text
185
設計レビュー
Slide 186
Slide 186 text
186
Slide 187
Slide 187 text
187
BERT設計相談会
Slide 188
Slide 188 text
188
Slide 189
Slide 189 text
189
教育・採用への取り組み
Slide 190
Slide 190 text
190
カタリバ (社内勉強会)
Slide 191
Slide 191 text
191
Slide 192
Slide 192 text
192
kaonavi Tech Talk
Slide 193
Slide 193 text
193
Slide 194
Slide 194 text
194
エンジニア採用
Slide 195
Slide 195 text
195
Slide 196
Slide 196 text
196
Slide 197
Slide 197 text
197
アーキテクチャー施策
Slide 198
Slide 198 text
198
Architecture Decision Record
Slide 199
Slide 199 text
199
Slide 200
Slide 200 text
200
Package by Feature
Slide 201
Slide 201 text
201
Slide 202
Slide 202 text
202
Slide 203
Slide 203 text
203
Slide 204
Slide 204 text
204
Feature Toggle
Slide 205
Slide 205 text
205
Slide 206
Slide 206 text
206
その他、細かい施策
Slide 207
Slide 207 text
- PHPUnit
- PHPStan
- E2Eテスト
- メトリクス取得
- 書籍購入制度（ホンダナ）
207
Slide 208
Slide 208 text
208
今後目指したいこと
Slide 209
Slide 209 text
209
GQM
Slide 210
Slide 210 text
210
https://ieeexplore.ieee.org/document/5010301
Slide 211
Slide 211 text
211
https://blog.hanhans.net/2023/05/29/gqm/
Slide 212
Slide 212 text
目的指向
-> 企業のパーパスなどとすり合わせしやすい
-> ただの数字から目的思考のメトリクスへ
212
Slide 213
Slide 213 text
213
まとめ
Slide 214
Slide 214 text
- レガシー化させないことは目的じゃない
- 目的はもちろん達成する
- かつ、レガシー化させない
214
Slide 215
Slide 215 text
215
https://speakerdeck.com/soudai/learn-from-predecessors
Slide 216
Slide 216 text
216
救いがないと感じたとき、私は石切工が岩石を叩くのを見に行
く。おそらく100回叩いても亀裂さえできないだろう。しかしそれで
も100と1回目で真っ二つに割れることもある。私は知っている。
その最後の一打により岩石は割れたのではなく、それ以前に叩
いたすべてによることを。
Pounding the rocks
Slide 217
Slide 217 text
217
レガシーから目をそらすな！
Slide 218
Slide 218 text
@hanhan1978
相談・指摘・その他
下記のTwitterアカウントにどうぞ
218