はじめに
最近、とある会社でアジャイル・コーチのようなことをしている。その中で、以下の3点を口うるさく唱えている。
- しっかり分析しよう
- なんのためにやってるか考えよう
- 技術力で解決しよう
RCA やレトロスペクティブでたびたび問題となる、影響範囲に起因した課題。どう見ても設計が悪いんだから、それを直しちゃえば良いし、それはコミュニケーションの改善では直らない。
でも稼働実績のあるお客様のコードを、がっつりリファクタリングするのは怖い。もはやハウルの動く城みたいになっちゃったレガシーコードをどうやってリファクタリングしてったら良いか分からない。次のメジャーバージョンアップまで塩漬けだ！
私が見ているチームだけでなく、割とどこでもある状況、もしくはリファクタリングしなきゃと思ってないかも知れない。
レトロスペクティブでディスカッションされる KAIZEN の半分くらいを設計やリファクタリングの話題が占めるようなデザイン力の強いチームにしたいと思った。やる気もあるし、うまく導ければできそうな雰囲気だし。
デザインパターンは難しい
デザインパターンは、ソフトウェアデザインの一部でしかないが、その習得はぶっちゃけ難しい。Head First Design Pattern を手にして、挫折した人も多いのではないだろうか。
デザインパターンを知っているのと、使えるのは違う。
デザインパターンを使えるのと、効果的に使えるのも違う。
そもそもデザインパターンは、複合的に使われることが多く、単品で使われることはあまりない。
超サイヤ人である状態が通常状態になるくらいに、デザインパターンが日常会話に溶け込んでいるのが望ましい。でも、そんなのどんだけ時間がかかるんだ？精神と時の部屋もないのに。というわけで、効率的に教えられる必要があって、通常業務に織り交ぜて検討できるようになっていて、やってるうちに最終的にはどういう意図でこの設計にしたのかを、言語化して説明できるようになっちゃうような教材が必要だった。
そんな教材はない。
ないので作った。作ってたらボリューミーになってしまったので、いつもは作った資料は PDF にして渡していたけど、どうせなんで Web にして公開した。
コーチしているチームには日本語が通じないので、英語で書いたが、ちゃんと日本語版も用意した。ベトナム語でくれとリクエストされたら翻訳するかも知れない。AIが。
アンチパターン駆動でやる
◯◯パターンを学習して、それを使ってなにかを作ってみよう！は、効率が悪いし、あんまり身にならない（かった）。いま、我々の眼の前には、ハウルの動く城という強大なアセットがそびえ立っているので、それをリファクタリングする過程で学べるのが良い。リファクタリングは、長年の運用でできがちなアンチパターンをみつけて、それを起点につぶしていくのがやりやすい。
という訳で、現場でありがちなアンチパターン（う◯こーど）を題材（11種類）に、問題点を明らかにしてリファクタリングをしていく。
リファクタリングは複数やる
デザインパターンに限らず設計は、何がしたいのか？何に困っているのか？何を解決したいのか？によって、最適なものが異なる。唯一無二の設計などないのだ。
アンチパターンを◯◯パターンを使ってリファクタリングしました。だけでは、どのような背景・意図でこのパターンを選んでリファクタリングしたのか、他の方法ではダメなのか説明できるようにならない。ここまでできて初めて「デザインパターン使えます」だと、私は思うので、そうできるように複数の異なるパターンでのリファクタリング例を付け加え、その比較を付けた。
デザインパターンはその適用意図を明確に説明できることが大事。
なお、より深い理解のための応用編として、デザインパターンの組み合わせ、似たようなパターンの比較、困りごとからのデザインパターンの適用などを付け加えた。
リファレンス的な使い方は推奨されていないが、手元に Head First Design Pattern（第2版が出てる！） などを置いて、比較しながら読み進めると、更に理解が深まることでしょう。
実務コードへの導入
勉強会しやすいように、各アンチパターンに、練習課題も付けた。勉強会がうまく回り始めたら、実務のコードで、紹介したアンチパターンに該当するようなコードや、良くないコードを引っ張ってきて、同じフォーマットで勉強会という名のペアプロならぬグルプロでリファクタリングを行えば良い。
無駄に会議を増やすのはオススメしないが、意味のある会議なら週1定例で1時間くらいとっても十分お釣りがくる。こなれてきたら、レトロスペクティブ内で済ませられるようになるかも知れない。
これで設計力強強のチームが出来上がるはずだが、やってみて改善点があれば随時アップデートしていく。やってみたけど、うまくいかなかった・こうしたら良かったなどのフィードバックをもらえたりなんかすると嬉しい。
ソースコードもドキュメントもサンプルコードも MIT/CC-BY-NC4.0 DEEDで公開した。
その他のこだわり
今回テキストを書き下ろすにあたり、これが原因で、デザインパターンや設計、ひいてはオブジェクト指向プログラミングが習得しづらくなってるんじゃないの？と思うことがある。
サンプルコードが Java
そんなこと！！と思うかも知れないが、世界で最も使われているプログラミング言語は、みんなにバカにされがちな PHP だし、学校で習うのは Python だし。学習コスト・教育コストの低い PHP や Python から入るエンジニアは多いというよりは、ほとんどだ。2025年のいま、Java で説明されましても感は否めない。
というわけで全ての例に、弊社でよく使う TypeScript に加え、PHP と Python のサンプルコードを付けた。
そして、今回、現場でよく見かけるアンチパターンも、割と実務で遭遇しそうな例を選んだ。というのも、設計系技術書やアジャイル指南書でよくあるような、車の製造で例えられたり、動物クラスを拡張してアヒルクラスを…など、分かりやすいのか分かりにくいのか分からず、実務のコードであぁこれ何か見たことある！って絶対ならないような例で学ぶのは、時間の無駄だと思うからだ。学んだだけで実際に使ったことのない知識は、時折思い出して復習することでより実務に接地した知識になる。どっかで見たことあるかもと思えるような例になっているべきである。
まとめ
アジャイル開発をより効果的に進める施策の一環として、設計力向上のために、実務ファーストで、実際の現場でお目にかかりそうなアンチパターンを起点に、複数のデザインパターンでリファクタリングを行い、その違いなどを吟味するチュートリアルサイトを作った。
勉強して終わりではなく、設計ディスカションが日常的にできるよう、実務に組み込めるような形で構成した（つもり）。
割と読み応えのあるボリュームになっているので、設計力に課題のあるチームやイマイチ効果の上がらないアジャイルチームなどで活用いただければ幸いです。