第16章 設計を妨げる開発プロセスとの戦い
この章では、開発現場で設計の品質を損なう要因として「開発プロセス」そのものがどう関わってくるかを多角的に掘り下げています。技術の話だけでなく、チームや組織、心理や文化にまで踏み込んだ内容は、読みながら自分自身の現場を何度も思い出すものでした。
コミュニケーションと設計の密接な関係
コンウェイの法則と逆コンウェイの法則が紹介され、「チーム構造＝プロダクト構造」という現実から逃れられないことがよく分かります。コミュニケーションのしづらさが、コード構造の歪みに直結する——これは理屈ではわかっていても、実際の現場ではなかなか解決が難しいテーマです。
ここで強調されるのが「心理的安全性」の大切さ。声をあげられないチームに健全な議論は生まれません。何よりもまず「発言できる場」をつくる。これが最初の一歩であり、かつ一番難しい。
「早く終わらせたい」の罠と設計の本質
現場でしばしば見かける「スピード重視」の空気。動くコードが早く出てくると、なぜかチームの空気が和らぎ、評価もされがちです。でもそのコードは、果たして半年後も保守可能なものなのでしょうか？
TDDの導入が実装速度に良い影響を与えるという実験結果は、設計とスピードが対立しないことの示唆に富んでいます。個人的には「実装が早い＝設計が良い」の裏付けをもらったような気がしました。
また、「クラスを増やすとパフォーマンスが落ちる」という意見が、未だに根強いことにも驚かされます。ここでは「早すぎる最適化」というアンチパターンを避けるためにも、計測と根拠を大切にすべきだという教訓が提示されます。
設計ルールとチーム力の関係
設計ルールを「多数決」で決めることの危険性には思わず頷いてしまいました。経験の浅いメンバーの反対でルールが成立しない……そんな経験、ありませんか？
ルールづくりはシニアエンジニアの責務であり、意思をもって導くべきもの。そして、そのルールには「意図」や「背景」を明示することで初めて、形骸化せず意味あるものとして運用できます。設計とは「ルールを守ること」ではなく「ルールを育てること」でもあると感じました。
実装と品質の細やかな戦い
割れ窓理論とボーイスカウトの規則は、すでに耳慣れた概念かもしれませんが、改めて実装に置き換えて読むと、現場での「ちょっとした気遣い」がコード全体の品質を左右することに気付かされます。
誰かが意図的に割った窓には、その理由を記しておく。そこには“壊した責任”を明確にする覚悟があります。また、「なぜこの実装なのか」という説明がコミットメッセージにあると、未来の仲間たちがきっと救われます。
既存コードに潜むアンカリング効果やジョシュアツリーの法則の話も興味深く、「目にしているのに気付けていない」ことの恐ろしさにハッとさせられました。
コードレビューという文化を育てる
レビューが単なるチェックリストではなく、チームの設計力を育てる場であるという意識は、とても大切な視点です。
特に印象的だったのは、「レビューにおける敬意と礼儀」についてのパート。Google Chromiumのレビュー指針は、レビューを文化として根付かせる上で非常に参考になります。
「能力と善意を想定する」
この一文だけで、レビューの空気はがらりと変わるはずです。褒めるコメント、感謝のコメントがあるだけで、レビューが「指摘」から「対話」に変わります。
チームの設計力を育てるためにできること
設計力の底上げには、「仲間集め」と「小さな実感」がキーワードです。クープマン目標値という現実的な指標も登場し、ボトムアップの活動にも希望が持てます。チーム20人なら2人が旗を振ればいい。そう考えると、やれそうな気がしてきます。
そして「実感」の大切さ。改善前と改善後を自分の手で比べること、そしてその変化を共有すること。この体験が、設計力の芽を育てていきます。
設計活動を浸透させる仕組み
勉強会の活用方法として、単なる読み合わせでなく、手を動かし、改善を共有する形式が推奨されているのは非常に実践的です。参加者それぞれが普段触れているコードを使うことで、自分事として捉えられるのも良い工夫です。
また、リーダーやマネージャーへの説明の重要性にも触れられています。変更容易性の価値を伝えるには、一人で戦うのではなく、仲間と共に向かう。これは心強い言葉でした。
最後には「設計責任者」という役割の明確化の話も出てきます。全員が設計に強くなくても、誰かが意識しているだけで、チームの設計意識は段違いに変わるはずです。
おわりに
この章は、「設計とは単なるコードの話ではない」というメッセージに溢れています。チームの空気、レビューの文化、組織との関係性、学びの共有。それらすべてが設計を良くする土台となる。
設計品質を高めるには、設計だけに注目していてはダメなんだ。そう気付かされる、まさに「設計と戦う」ための実践知が詰まった章でした。