新卒から4年間、20年もののWebサービスと向き合って学んだソフトウェア考古学 / phper-kaigi-2025-guri

プロポーザル: https://fortee.jp/phperkaigi-2025/proposal/all?q=guri&f=all&l=

古いコードベースを読み解く作業はしばしば「ソフトウェア考古学」と呼ばれ、多くの人にとって大変で辛い作業と思われがちです。
しかし、サービスの歴史を辿ることで当時の設計思想や変化の過程を知ることができ、それ自体が良い設計を体験し、学べる貴重な機会でもあります。
私の実体験としても20年もの歴史のあるWebサービスの考古学からは学べることがたくさんありました。

本トークでは、新卒5年目エンジニアである私が、20年以上稼働し続けるWebサービスの改善に向き合う中で試行錯誤したことをお話しします。

お話すること

古いコードベースを読み解き改善を行った事例とその課題
Webメディアの広告運用のための管理画面改修
歴史の塊のバッチ処理をPerlからPHPに移行する
全体を知るための「鳥の目」と細部を観察するための「虫の目」の考え方
鳥の目で意図や構造を理解する作図ツールなどを使ったコードの読み方
虫の目で詳細を把握するためのデバッグ方法
「どこまで深掘りするか？」の判断基準
ソフトウェア考古学の経験から学んだこと
理解しやすいコードを書くコツ
自分が書いたコード、その後どうなった？上手く行ったこと、行かなかったこと
ソフトウェアの健全な変化を助けるドキュメントとは？

話さないこと

トークの中で出てくるツール自体の詳細な使い方
リファクタリングやデータ移行といったソフトウェア改善に伴う手順の詳細

聴いてほしい人

コードベースが古い環境で悩んでいる人
歴史のあるコードを改善したいと思っている人
プロダクションコードに初めて触れ、規模の大きさや複雑さに圧倒された経験のある新卒の人たち

Transcript

1. 新卒から4年間、20年もののWebサービスと 向き合って学んだソフトウェア考古学 株式会社 CARTA HOLDINGS ⼩栗 ⼤輝 / ぐり（X: @_guri3） PHPerKaigi 2025 day2 Track C 2025.03.23 13:00
2. 株式会社CARTA HOLDINGS ⼩栗 ⼤輝 ぐり X: @_guri3 略歴 • 2020年新卒⼊社 • 20年もののWebサービスのリアーキテクチャ プロジェクト 関連書籍 過去スライド 配属⾯談にて レガシーシステムの改善をやってる チームがあるんだけど、どう？ 面白そう！やってみます！ CARTA本 第3章 「VOYAGE MARKETING 20年級大規模レガシーシステムとの戦い」 に登場する話と地続きのお話
3. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービス「ECナビ」
4. 20年もののWebサービスの中⾝って どんな感じ？
5. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 様々な年代に書かれたコードや技術選定の結果が並行運用されている • Perlで書かれた旧システムとPHPで書かれた新システム • Oracle DatabaseとMySQLの共存 • 年代によって変わる実装方針の混在 • テストコードが存在しない
6. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 様々な年代に書かれたコードや技術選定の結果が並行運用されている • Perlで書かれた旧システムとPHPで書かれた新システム • Oracle DatabaseとMySQLの共存 • 年代によって変わる実装方針の混在 • テストコードが存在しない 2つの言語を行き来しつつ理解。 PHPでも10年前のコードはずいぶん書き味が違うな...
7. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 様々な年代に書かれたコードや技術選定の結果が並行運用されている • Perlで書かれた旧システムとPHPで書かれた新システム • Oracle DatabaseとMySQLの共存 • 年代によって変わる実装方針の混在 • テストコードが存在しない こっちのテーブルはOracle、あっちのテーブルはMySQL。 頭が混乱するよ〜
8. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 様々な年代に書かれたコードや技術選定の結果が並行運用されている • Perlで書かれた旧システムとPHPで書かれた新システム • Oracle DatabaseとMySQLの共存 • 年代によって変わる実装方針の混在 • テストコードが存在しない 手続き的に書かれているコードもあればオブジェクト指向的に書かれているコードもある。 フレームワークなんてありません。スクリプトのmain関数実行！！とか
9. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 様々な年代に書かれたコードや技術選定の結果が並行運用されている • Perlで書かれた旧システムとPHPで書かれた新システム • Oracle DatabaseとMySQLの共存 • 年代によって変わる実装方針の混在 • テストコードが存在しない ガードレールがないので、変更によってどこが壊れるかわからない不安が常に付きまとう
10. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 古いコードほどなぜそう作ったのか？という理由を追うのが難しい • 似たような機能をもった複数の管理画面 • 抽象化されていると思ったら個別の実装も存在していたり • コメントにドキュメントへのリンクが！
11. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 古いコードほどなぜそう作ったのか？という理由を追うのが難しい • 似たような機能をもった複数の管理画面 • 抽象化されていると思ったら個別の実装も存在していたり • コメントにドキュメントへのリンクが！ どちらかに統合するつもりだった？ 別々の要件を満たすために必要だった？
12. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 古いコードほどなぜそう作ったのか？という理由を追うのが難しい • 似たような機能をもった複数の管理画面 • 抽象化されていると思ったら個別の実装も存在していたり • コメントにドキュメントへのリンクが！ リファクタリングをやり切れなかった？ 追加の仕様に対応する必要があった？
13. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 古いコードほどなぜそう作ったのか？という理由を追うのが難しい • 似たような機能をもった複数の管理画面 • 抽象化されていると思ったら個別の実装も存在していたり • コメントにドキュメントへのリンクが！ 切れてます...😭
14. ただコードを読むだけでも⼤変
15. でも、理解しないことには どう直せば良いかわからない
16. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 リアーキテクチャにおいて、既存システムの把握は重要 • 既存の問題点を正しく認識しないと改善に繋がらない ◦ 何を解決すれば現状よりよくなったと言える？ ◦ 表面的なコードだけでなくなぜそうなっているのかの意図も重要 • 開発時のスコープや設計方針の意思決定の材料 ◦ 今ある資産はどこまで使える？ → 開発工数に大きく影響する • ビジネスロジックの抜け漏れが起きかねない ◦ 移行後のシステムでは業務が回せない！？なんてことにも
17. 古いコードベースを どうやって理解していく？
18. ソフトウェア考古学
19. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 ソフトウェア考古学 “正確なドキュメントがない場合、または知識のある人にアクセスできな い場合、最後の手段は、ジョブ制御言語 (JCL) などのシステムを呼び出す コードを含む、レガシーシステムのソースコードを分析することです。 この作業は、ソフトウェア考古学と呼ばれることがよくあります。” Agile Legacy System Analysis and Integration Modeling https://agilemodeling.com/essays/agileLegacyIntegrationModeling.htm
20. ソフトウェア考古学 古いコードベースを読み解き 当時の設計思想や変化の過程を知ること =
21. AGENDA 02 古いコードベースを理解するのはなぜ難しい？ 03 04 具体的な進め⽅ ソフトウェア考古学の経験から学んだこと 01 古いコードベースの改善はなぜ必要？
22. AGENDA 02 古いコードベースを理解するのはなぜ難しい？ 03 04 具体的な進め⽅ ソフトウェア考古学の経験から学んだこと 01 古いコードベースの改善はなぜ必要？
23. 古いコードベースの改善はなぜ必要？
24. 01. 古いコードベースの改善はなぜ必要？ 古いコードベースの改善はなぜ必要？ 以下のような問題を引き起こす • 開発のアジリティの低下 • 影響範囲が不明瞭なことによる予期せぬバグ
25. 01. 古いコードベースの改善はなぜ必要？ 開発のアジリティの低下 ビジネスの問題を素早く解決出来なくなる こういう機能を追加して欲しいのですが... 誰もわからないので、調査からになりますね... 工数もやってみないとわかりません...
26. 01. 古いコードベースの改善はなぜ必要？ 影響範囲が不明瞭なことによる予期せぬバグ こんなところが壊れるの！？ メソッドに型定義を付けたら予想外のところで使われててエラー
27. 01. 古いコードベースの改善はなぜ必要？ 影響範囲が不明瞭なことによる予期せぬバグ こんなところが壊れるの！？ CARTA本 第5章 「サポーターズ 事業を止めない手段としてのシステム刷新」 “部屋のドアノブを回すと風呂の底が抜ける”
28. 他にも様々な困りごとがありますが
29. 01. 古いコードベースの改善はなぜ必要？ 古いコードベースは雪だるま式に難しくなる • 様々な都合で理想の形に持っていけない場合もある • どこかのタイミングで対応しないとどんどん難しくなる • さらに手を入れづらくなり、場当たり的な対応 しか出来なくなるというループに陥る
30. 01. 古いコードベースの改善はなぜ必要？ 古いコードベースの改善はなぜ必要？ • そりゃそうだよね、と思われるかもしれません • なぜわざわざ確認したかというと ◦ 色々あって大変&基本的に長期戦 ◦ やる意味が腹落ちしてないとどんどんスピード感が失われる ◦ 最初にやる意味を明確にする&迷う時があれば何度も立ち返る
31. AGENDA 02 古いコードベースを理解するのはなぜ難しい？ 03 04 具体的な進め⽅ ソフトウェア考古学の経験から学んだこと 01 古いコードベースの改善はなぜ必要？
32. 古いコードベースを理解するのは なぜ難しい？
33. ⾃⾝の持つメンタルモデルとの乖離が ⼤きい‧多い
34. 02. 古いコードベースを理解するのはなぜ難しい？ メンタルモデル “メンタルモデルは、目の前の問題について推論するために、 ワーキングメモリの中で概念を抽象化するものである” プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ 6.2 メンタルモデル
35. 02. 古いコードベースを理解するのはなぜ難しい？ メンタルモデルのこのトークでの解釈 “メンタルモデルは、目の前の問題について推論するために、 ワーキングメモリの中で概念を抽象化するものである” プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ 6.2 メンタルモデル 過去の経験や一般的な設計パターンなどに基づいて形成された 自身のコードに対する認識や解釈、期待
36. メンタルモデルと実際のコードとの 乖離が⼤きいほど理解が難しくなる
37. 例えば
38. 02. 古いコードベースを理解するのはなぜ難しい？ メンタルモデルと実コードの乖離の例 その1 メンタルモデル この関数はget〇〇という名前がついているからデータを取得するだけだ
39. 02. 古いコードベースを理解するのはなぜ難しい？ メンタルモデルと実コードの乖離の例 その1 メンタルモデル この関数はget〇〇という名前がついているからデータを取得するだけだ 実際は... 副作用のある登録処理や更新処理が内部で動いていた
40. 02. 古いコードベースを理解するのはなぜ難しい？ メンタルモデルと実コードの乖離の例 その2 メンタルモデル オブジェクト指向をベースに設計・実装されているだろう
41. 02. 古いコードベースを理解するのはなぜ難しい？ メンタルモデルと実コードの乖離の例 その2 メンタルモデル オブジェクト指向をベースに設計・実装されているだろう 実際は... 手続き型の考え方で設計・実装されている
42. 02. 古いコードベースを理解するのはなぜ難しい？ 古いコードベースにおけるメンタルモデルの乖離 古いコードベースにおいてメンタルモデルと実コードの乖離は 大きくなりやすく、乖離が起こるタイミングも多い なぜ...？20年もののWebサービスの中身を振り返ると • 様々な年代に書かれたコードや技術選定の結果が並行運用されている • 古いコードほどなぜそう作ったのか？という理由を追うのが難しい
43. 02. 古いコードベースを理解するのはなぜ難しい？ 古いコードベースにおけるメンタルモデルの乖離 古いコードベースにおいてメンタルモデルと実コードの乖離は 大きくなりやすく、乖離が起こるタイミングも多い なぜ...？20年もののWebサービスの中身を振り返ると • 様々な年代に書かれたコードや技術選定の結果が並行運用されている • 古いコードほどなぜそう作ったのか？という理由を追うのが難しい 様々なコンテキストが入り混じっている
44. 古いコードベースを理解するのは なぜ難しい？ ⾃⾝の持つメンタルモデルとの乖離が ⼤きい、多い =
45. 古いコードベースに合わせて メンタルモデルを 構築する‧柔軟に切り替える
46. AGENDA 02 古いコードベースを理解するのはなぜ難しい？ 03 04 具体的な進め⽅ ソフトウェア考古学の経験から学んだこと 01 古いコードベースの改善はなぜ必要？
47. 具体的な進め⽅
48. 03. 具体的な進め方 素直に読み進めると時間がたくさん掛かる 具体的にどういう仕事があったか • Webメディアの広告運用管理画面改修 ◦ 同じような管理画面が複数存在して差分を特定するのも一苦労 • Perlの旧基盤のバッチ処理をPHPの現行基盤に移行 ◦ Perl ↔ PHPで頭を切り替えながら作業を進める必要がある ◦ 古いバッチは実装の考え方が今と違ったりする
49. ⿃の⽬と⾍の⽬ 問題を解くこと https://blog.kentasuzuki.net/2017/04/blog-post_12.html
50. 03. 具体的な進め方 ⿃の⽬ 俯瞰して依存関係などの全体構造を把握する
51. 03. 具体的な進め方 ⾍の⽬ コード1行1行レベルの詳細を把握する
52. 03. 具体的な進め方 メンタルモデルを構築するアプローチ 鳥の目と虫の目を使って全体構造と詳細を行き来することで 古いコードベースのメンタルモデルを構築 全体構造 詳細 新たなメンタルモデル の構築
53. 03. 具体的な進め方 メンタルモデルを構築するアプローチ 読み取った事実や構築したメンタルモデルは成果物としてアウトプット
54. 03. 具体的な進め方 メンタルモデルを構築するアプローチ 読み取った事実や構築したメンタルモデルは成果物としてアウトプット “メンタルモデルは、目の前の問題について推論するために、 ワーキングメモリの中で概念を抽象化するものである”
55. 03. 具体的な進め方 メンタルモデルを構築するアプローチ 読み取った事実や構築したメンタルモデルは成果物としてアウトプット “メンタルモデルは、目の前の問題について推論するために、 ワーキングメモリの中で概念を抽象化するものである” わかったことは頭の中から外に出すと、また別の領域や さらに複雑な構造などを把握するのにリソースを使える
56. 03. 具体的な進め方 メンタルモデルを構築するアプローチ 読み取った事実や構築したメンタルモデルは成果物としてアウトプット これこそがソフトウェア考古学の成果
57. ⿃の⽬で全体構造を把握する
58. 03. 具体的な進め方 ⿃の⽬で全体構造を把握する • 依存関係などから大きな構造を読み解く • データのインプット / アウトプットの把握 • システムの変化や時の流れを観察する
59. 03. 具体的な進め方 依存関係などから⼤きな構造を読み解く • まずはなるべく大きな構造を読み解く ◦ 例えばクラスの依存関係やパブリックなインターフェースなど ◦ 何もわからない状態から輪郭を作っていく ▪ 規模感・複雑さ・重要な処理が書かれていそうなところ
60. 依存関係などから大きな構造を読み解く @startuml class HogeController { } @enduml コントローラーなどのわかりやすい エンドポイントから始める
61. 依存関係などから大きな構造を読み解く @startuml namespace Controller { class HogeController { } } namespace Function1 { class ServiceFactory { } interface ServiceInterface { } namespace Hoge { class HogeService { } } namespace Poyo { class PoyoService { } } } HogeController ..> ServiceFactory ServiceFactory --> ServiceInterface HogeService --|> ServiceInterface ~~~ @enduml わかりやすいデザインパターン(Factory) どういう意図で設計したんだろう？
62. 依存関係などから大きな構造を読み解く @startuml namespace Controller { class HogeController { } } namespace Function1 { class ServiceFactory { } interface ServiceInterface { } namespace Hoge { class HogeService { } } namespace Poyo { class PoyoService { } } } HogeController ..> ServiceFactory ServiceFactory --> ServiceInterface HogeService --|> ServiceInterface ~~~ @enduml あー、この辺を抽象化して実行時に使い分け したかったんだなー
63. 依存関係などから大きな構造を読み解く：成果物の例
64. 03. 具体的な進め方 データのインプット / アウトプットの把握 • バッチ処理の場合特に有効（自分の場合はPerl→PHPへの移行） • 表面的な画面があるわけでは無いのでパブリックなインターフェース としてデータのインプット・アウトプットから把握するのが有効 • どういったデータが入って、作り出すことを目的としているのか ◦ どのテーブルからどのテーブル？ ◦ データの内容
65. 03. 具体的な進め方 データのインプット / アウトプットの把握 キャンペーンに参加したユーザーから抽選して当選ユーザーを決める インプット なんらかの処理 アウトプット
66. 03. 具体的な進め方 データのインプット / アウトプットの把握 キャンペーンに参加したユーザーから抽選して当選ユーザーを決める インプット なんらかの処理 アウトプット users、campaigns、campaign_participationsテーブルから取得
67. 03. 具体的な進め方 データのインプット / アウトプットの把握 キャンペーンに参加したユーザーから抽選して当選ユーザーを決める インプット なんらかの処理 アウトプット 途中のゴニョゴニョは無視
68. 03. 具体的な進め方 データのインプット / アウトプットの把握 キャンペーンに参加したユーザーから抽選して当選ユーザーを決める インプット なんらかの処理 アウトプット winning_usersテーブルに保存
69. 03. 具体的な進め方 データのインプット / アウトプットの把握 • インプットとアウトプットの情報を元にER図を書き起こす • テーブル間の関係性に注目 ◦ ECナビの古いテーブルには外部キーが存在しない😭 ▪ IDEで出力したりしても何もわからない ◦ 命名や、データの入力時の挙動などで関係性を想像して書く
70. 03. 具体的な進め方 データのインプット / アウトプットの把握：成果物の例
71. 03. 具体的な進め方 システムの変化や時の流れを観察する • （あれば）Gitのblameをざっと眺める ◦ 最近まで変更が加えられている部分 ◦ 最初に作られたところからずっと変わってなさそうな部分 • どこに柔軟性が必要なのかをシステムの変化から学べる
72. ⾍の⽬で詳細を把握する
73. 03. 具体的な進め方 ⾍の⽬で詳細を把握する • プリントデバッグとデバッグツール • リファクタリングをしてみる • コードの深堀りと枝切りの判断
74. 03. 具体的な進め方 プリントデバッグとデバッグツール • パブリックなインターフェースからさらに一歩踏み込んで処理を追う • 成果物はプログラムの詳しい挙動を記した文書やシーケンス図など
75. 03. 具体的な進め方 プリントデバッグとデバッグツール if文ひとつとっても正しく理解できているか自信が持てない • 仕様の追従のために条件が追加され組み合わせが膨大だったり どういう意図で追加された？ 今も必要？ ただ読み進めるだけではすぐに迷子になってしまう
76. 03. 具体的な進め方 プリントデバッグとデバッグツール • 脳内インタプリタで実行 • var_dumpなどを利用して特定の値の遷移を知る • PsySHやXdebugなどのデバッグツールを利用 読み進めるスピード（や手間）とどこまで詳細を追うかで使い分ける
77. 03. 具体的な進め方 プリントデバッグとデバッグツール 使い分けイメージ 詳細度 低 遅 速 高 スピード 脳内インタプリタで実行 手軽で速いが詳細を追ってくと認知負荷が高い
78. 03. 具体的な進め方 プリントデバッグとデバッグツール 使い分けイメージ 詳細度 低 遅 速 高 スピード var_dumpなどを利用して特定の値の遷移を知る 少し手間が増えるがより詳細を追うことができる
79. 03. 具体的な進め方 プリントデバッグとデバッグツール 使い分けイメージ 詳細度 低 遅 速 高 スピード PsySHやXdebugなどのデバッグツールを利用 プロジェクトによっては下準備が必要 さらに詳細を追うことができる
80. 03. 具体的な進め方 プリントデバッグとデバッグツール • 脳内インタプリタで実行 　　　　　　↓ 頭の中だけでは把握し切れない • var_dumpなどを利用して特定の値の遷移を知る ↓ 特定の場面の複数の状態が絡み合っている • PsySHやXdebugなどのデバッグツールを利用 メンタルモデルとズレていればいるほど より詳細を追いすり合わせることが必要
81. 03. 具体的な進め方 プリントデバッグとデバッグツール • 脳内インタプリタで実行 　　　　　　↓ 頭の中だけでは把握し切れない • var_dumpなどを利用して特定の値の遷移を知る ↓ 特定の場面の複数の状態が絡み合っている • PsySHやXdebugなどのデバッグツールを利用 使い慣れているツールがあればあまり変わらないかも どの程度メンタルモデルとのずれが生じているかを意識することが大事
82. 03. 具体的な進め方 リファクタリングをしてみる 手を動かせそうならリファクタリングをしてコードに触れてみる “試行リファクタリング” レガシーコード改善ガイド P226 - 227
83. 03. 具体的な進め方 リファクタリングをしてみる 手を動かせそうならリファクタリングをしてコードに触れてみる “試行リファクタリング” レガシーコード改善ガイド P226 - 227 明らかなデッドコードを削除してみたり リリースは出来なくてもOK。出来たら嬉しいけど
84. 03. 具体的な進め方 コードの深堀りと枝切りの判断 どこまでコードを深ぼるか？究極は目的による 自分のイメージでは 意思決定に必要な情報が揃うまで なぜそうなっているのかを「自分の言葉で説明できる」
85. 03. 具体的な進め方 コードの深堀りと枝切りの判断 どこまでコードを深ぼるか？究極は目的による 知りたい情報の粒度に合わせて枝切りをする • 今は〇〇機能の依存関係だけ明らかにしよう → 実装の詳細は気になっても追わない • 「鳥の目」「虫の目」で自分が今何を理解しようとしているのか？ を常に意識
86. ⾏ったり来たりしながら理解を深める
87. 03. 具体的な進め方 ⾏ったり来たりしながら理解を深める 鳥の目: ざっとみたときに似たような管理画面が複数ある。なぜ？
88. 03. 具体的な進め方 ⾏ったり来たりしながら理解を深める 鳥の目: ざっとみたときに似たような管理画面が複数ある。なぜ？ 虫の目: 詳細なコードを追うと、新たな仕様追加に追従した形跡がある
89. 03. 具体的な進め方 ⾏ったり来たりしながら理解を深める 鳥の目: ざっとみたときに似たような管理画面が複数ある。なぜ？ 虫の目: 詳細なコードを追うと、新たな仕様追加に追従した形跡がある 鳥の目: ざっとみたときに似たような管理画面が複数ある。これは、追加 された仕様に新たに対応するために生まれた画面だ。
90. 03. 具体的な進め方 ⾏ったり来たりしながら理解を深める 鳥の目: ざっとみたときに似たような管理画面が複数ある。なぜ？ 虫の目: 詳細なコードを追うと、新たな仕様追加に追従した形跡がある 鳥の目: ざっとみたときに似たような管理画面が複数ある。これは、追加 された仕様に新たに対応するために生まれた画面だ。 行き来することで設計思想や変化の過程を読み取ることができる
91. AGENDA 02 古いコードベースを理解するのはなぜ難しい？ 03 04 具体的な進め⽅ ソフトウェア考古学の経験から学んだこと 01 古いコードベースの改善はなぜ必要？
92. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 ソフトウェア考古学の経験から学んだこと • 規模の大きいシステムは愚直に読んでいくだけでは理解できない ◦ 自分の思い込みなどの積み重ねが理解を困難にしたり 誤った理解に繋がる ◦ 鳥の目・虫の目を意識したコードリーディングを活用することで 自身のメンタルモデルをすり合わせながら意図や背景を明らかに していく
93. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 ソフトウェア考古学の経験から学んだこと • 理解しやすいコードを書くコツ ◦ 前提としてあるべき姿に常にシステムが追従しているのが一番 ◦ 歴史を学ぶ中で変更が多い場所、作ったきり変更されにくい 場所がだんだんわかってくる ▪ 最初から変更を考慮した設計にできれば設計思想の乖離 が起こりづらい
94. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 ソフトウェア考古学の経験から学んだこと • 意思決定の記録が残っているとわかりやすい ◦ 常に最新に更新されているドキュメントでなくても良い ◦ 詳しく仕様が書いてあるよりもなぜそうしたか？の方が大事 • メンタルモデルにずれが発生しそうな部分への予防 ◦ どうしても根本対応仕切れなかった仕様改修箇所に積極的にコメントを書く
95. 最後に
96. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 最後に 続く調査や新規開発への憧れなどでモチベーションが下がることも... • 今まで紡がれてきたものをより良い形に直してさらに長く価値を提供 できるようにする大事な仕事 ◦ 「レガシー」には後世に引き継がれる価値というポジティブな 意味合いもあるそう • そもそも考古学が必要になるまで成長しているサービスはすごい
97. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 最後に ソフトウェア考古学って大変なイメージ（自分がそうでした）ですが、 今回のトークで自分でもできそう！というイメージを持って少しでも やってみようかな〜と思ってもらえると嬉しいです
98. No day but TODAY CARTA HOLDINGSについて 約 53% 電 通 （株） VOYAGE GROUP 約 47% 既存株主 事業例 サービス例 CARTA HOLDINGSについて
99. 新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 ありがとうございました • ビジネスの要求に対応するためには古いコードの改善が必要 • 自身の持つメンタルモデルとのずれがコードの理解を難しくする • 「鳥の目」で全体把握、「虫の目」で詳細を把握 • ソフトウェア考古学で変更の傾向を学ぶことができる 学んだことを設計に反映する • 意思決定についてのスナップショットが有効 メンタルモデルとの乖離や驚きが生まれそうなところに コメントが補足されていると理解しやすい