■ 1. ソフトウェア開発の難しさ：複雑さとの戦い
- ソフトウェアは機能追加により必然的に大規模化し機能間の関係が複雑さを生む
- 複雑さが個人やチームの許容値を超えると不具合増加・工数超過・開発停滞が発生する
- 複雑さを制御しシンプルさを保つことがソフトウェア開発の核心的課題である
■ 2. 複雑さへの対処：継続的リファクタリング
- 機能追加後に複雑化したまま放置せずその場でリファクタリングを行う
- コードへの理解が深い段階で修正することで修正コストが最小化される
- 「新規機能開発前に十分なリファクタリングをしているか」を方針として掲げる
- Joel Testの「バグ修正優先」をさらに発展させリファクタリングを先行させる
- リファクタリングを認めるプロジェクトは複雑さを抑制し順調に進む傾向がある
- 製造業のカイゼン（整理整頓）と同様にソースコードも継続的な整理整頓が有効である
■ 3. ソフトウェア開発の本質的な問題：「見えない」こと
- 良いものと悪いものの判断がすぐにはできないことが本質的問題である
- ホテルや自動車は素人でも品質の良否をある程度観察できる
- ソフトウェアのコードは熟練技術者でも数ヶ月読み込まないと良否の判断が困難である
- 言語が異なれば上級者であっても判断不能になる
■ 4. 「見えない」ことが引き起こす問題
- 上級者には明らかな問題が初心者・中級者には「意見の相違」として処理される
- 良くないコードがマネジメント層には問題に見えずリファクタリングの必要性が無視される
- 初心者・中級者が上級者のコードを誤って低く評価するケースも生じる
- コード断片の善し悪し→プロジェクト全体の善し悪し→プロジェクト運営の善し悪しと段階的に判断が難しくなる
- 顧客と開発者の意思疎通困難・開発者同士の相互理解困難・見積もりの困難もすべて「見えない」問題に帰結する
■ 5. 観察と誤った改善への注意
- うまくいっていないのにカイゼン不要と思い込み現状維持のまま手遅れになるケースがある
- うまくいっていることをカイゼンしようとして逆効果を招くケースもある
- 例：ドキュメント不要で順調だった開発にドキュメント作成を導入し開発速度が低下する
- 何がうまくいっていて何がうまくいっていないかを正確に観察することが重要である