現場で使える設計法則をクイズで学ぶ！
第7章：法則 要約＆クイズ

要旨

理由

• 依存関係によるオーバーヘッド

  チームメンバーが増えるほど、打ち合わせや確認の相手が増える。仕事を分けても、調整やコミュニケーション（情報のやり取り）に時間が取られて、かえって遅くなりやすい。

• 教育コスト

  新しく入った人には、今の状況やシステムのしくみを教えなければならない。そのために、もともといたメンバーの時間が削られ、全体の生産性が下がる。

• 人≠人の非交換性

  人には得意・不得意や、担当領域の知識、チーム内で共有している文脈（ハイコンテキスト）があって、「この人の代わりなら誰でもいい」とはいかない。

結論

その他（アンチパターン）

• アンチパターンとは、やりがちな「失敗パターン」を名前とセットでまとめたもの。あらかじめ知っておくことで、「あ、これはあのパターンだ」と気づき、同じ失敗を避けるための反面教師として使える。

要旨

理由

結論

その他（組織×プロセスの相性）

• 技術ごとに縦割り（DBチーム・メインフレームチーム・Webチーム・テストチーム…）の組織でアジャイル開発（短いサイクルで回す開発）をしようとすると、チーム間の依存が多くなり、結局大きな塊でのウォーターフォール（計画から実行までを段階的に進め、原則として後戻りしない開発手法）に戻りがち。
• 機能をまたいでメンバーを集めたクロスファンクショナルチーム（機能横断チーム）を作り、1つのユースケース（利用シナリオ）がそのチーム内で完結するような体制を目指す。

要旨

理由

結論

その他（運用のコツ）

• 小さな改善をコツコツ続ける（命名の見直し・重複コードの削除・関数の切り出し・テスト追加など）。
• 放置しない文化をチームで共有し、「気づいたら直す」「せめてメモを残す」を当たり前にして、技術的負債（後回しにしたツケ）がたまらないようにする。

要旨

理由

結論

その他（兆候・対策）

• 腐敗の兆候（見逃さない）

  • 硬さ

    ちょっとした変更でも、依存が絡み合って広い範囲をいじらないといけない状態（高結合）。

  • 脆さ

    ある場所の変更が、一見関係なさそうな部分まで壊してしまう状態。

  • 移植性のなさ

    特定の環境や設定に強く依存していて、ほかの環境へ持っていきにくい状態。

  • 扱いにくさ

    ビルドやテストにすごく時間がかかる／開発環境の都合で作業がしづらい状態。

  • 複雑さ

    「念のため」「いつか使うかも」で機能を足し続け、不要な要素が増えている状態（YAGNI違反）。

  • 繰り返し

    似たようなコードがあちこちにコピペされている状態（DRY違反）。

  • 不透明さ

    コードを読んでも何をしているのか分かりにくい状態。

• アジャイルで腐敗を許さない

  最初の設計にしがみつかず、シンプルさを維持しながら、頻繁にユニットテスト・受け入れテストを回して柔軟性を保つ。

• チーム文化で腐敗を止める

  その場しのぎの修正をそのままにせず、割れた窓を早めに直す意識を共有する。リファクタリング（振る舞いを変えずにコードを整理・改善すること）に前向きに取り組む人を評価する。

要旨

理由

結論

その他（パレートの法則／ホットスポット活用）

• パレートの法則（80:20の法則の例）
  • 売上の8割は、2割の主力商品から出ている。
  • 道路の交通量の8割は、2割の主要道路に集中している。
  • 所得の8割は、2割の富裕層が持っている。
  • あるソフトの利用時間の8割は、2割の機能に集中している、など。
• ソフトウェアへの適用
  • 障害（バグ）の8割は、2割のコードに集中している（品質ホットスポット）。
  • 処理時間の8割は、2割のコードが占めている（性能ホットスポット）。
  • → まず計測してホットスポットを見つけ、そこにレビュー・テスト・チューニングを重点的に行うと効果が大きい。

要旨

理由

結論

その他（実践・効果）

• 実践

  • そのプロジェクト特有の概念（ドメイン概念）には、一貫性のある用語を付ける。
  • コード・設計書・日常会話・ドキュメントで、同じ言葉を使うようにそろえる。
  • コードレビューで名前の使い方がブレていないかをチェックし、必要なら用語集に追記する。
  • 新しい発見があれば、積極的に名付けて、チームに共有する。

• 効果

  • いままで漠然としていてよく見えなかった問題が、名前をつけることで見えるようになり、意思疎通や設計の質が上がる。結果として、学びと再利用のスピードが上がる。

要旨

理由

結論

• ユーザーは誰なのか？
• ユーザーは何をするためにこのソフトを使うのか？
• ユーザーは本当は何を必要としているのか？
• ユーザーは何が必要だと「思って」いるのか？
• ユーザーは何を望んでいるのか？（たいていは、派手な新機能より基本機能の安定と使いやすさ）

その他（フィーチャークリープ対策）

• 定義要望を何でもかんでも取り込んで、機能が増えすぎてしまうことをフィーチャークリープと言い、システム崩壊の第一歩になりやすい。
• 方針「NO」と言える勇気を持つ。どうしても機能を足す必要があるときは、できるだけ
  • 本体コードを大きく変えず、ラッパー（外側の殻）や拡張として実現する。
  • プラグイン方式で、コア部分を変えずに追加機能を差し込める形にする。
  • コア（中心部分）はシンプルさを守り、KISS や YAGNI の原則を崩さない。

要旨

理由

• 車輪を知らない…世の中にすでにあるライブラリ・OSS（オープンソースソフトウェア）などの情報を知らない／調べていないため。
• 車輪を作りたい…あえて自分で作りたいというこだわりやエゴから、「自分のライブラリを作ってみたい」となってしまう場合。

結論

その他（再発明が妥当な場合）

• ビジネス目的
  • プロダクトの中核や差別化ポイントはあえて自作して、外部ライブラリへの依存リスクを減らす場合。
  • 特定の会社やサービスに強く依存しすぎないよう、自分たちでコントロールできる部分を確保しておきたい場合。
• 学習目的
  • 勉強として、あえてゼロから設計・実装・テスト・不具合修正まで一通り経験し、しくみの理解やスキルアップを狙う場合（ただし本番にそのまま使うかは別問題）。

要旨

理由

結論

その他（例・対策）

• 典型例
  • 「Webサーバーをインストールしたい」→ ファイルが大きくてダウンロードが遅い → 高速なダウンロードツールを入れよう → なぜか動かない → 事前に必要なモジュールを入れよう → そのためのユーザー登録が必要 → 登録ページがエラー → ブラウザをアップデート…と進むうちに、最初の目的が何だったか分からなくなる、など。
• 対策
  • 最初に目的・制約・かけてよい時間（タイムボックス）を書き出しておき、そこから外れていないかを意識する。
  • 行き詰まったら、抱え込まず早めに相談・エスカレーション（上司や専門部署など上位の者に判断や対応を仰ぐこと）する。
  • これまでにやったことをメモしておき、同じところをぐるぐる回る思考ループや、頭のオーバーフローを防ぐ。
  • 今回の経験をふり返って、手順書やナレッジ（有益な知識や知見のこと）として残し、次回は同じ毛刈りをしなくて済むようにする。