〜AI時代の「設計ガバナンス」〜SQuaREの保守性副特性から学ぶ、モジュール性を統治する審美眼

1. はじめに

生成AIが即座にコードを出力してくれる現代、エンジニアに求められるスキルは「書く力」から、そのコードが将来の負債にならないかを見極める**「審美眼」へとシフトしていると考えています。
AIは「動くコード」を数秒で出せますが、そのコードが「変更に強いか」までを保証してはくれません。そこで、AIが出力したコードを適切に統治（ガバナンス）するための客観的な判断基準が必要になります。
私は、その基準として国際規格であるSQuaRE（ISO/IEC 25010）の保守性モデルを活用するのが最適だと考えています。
SQuaREにおいて「変更に強いか」という観点は保守性という特性でモデリングされており、この保守性には5つの副特性があります。
本記事では、保守性の土台であり、設計ガバナンスの要とも言える「モジュール性」**にスポットを当て、モジュール性の高いソフトウェアを見極めるための視点を深掘りしていきます。

2. SQuaREの保守性について概要説明

SQuaRE（Systems and software Quality Requirements and Evaluation）は、システム及びソフトウェアの品質要求を定義し評価する際の共通言語として機能する国際規格シリーズです。ISO/IEC 25010シリーズとして体系化されており、多様なステークホルダ間での品質に関する共通認識を形成するための枠組みを提供しています。
このSQuaREにて、保守性は5つの品質副特性で構成されています。

出典：P115.SQuaRE 品質モデル（製品品質）¹より抜粋

SQuaRE及び保守性の概要については過去の記事「質とスピード」の質って具体的に何？ - SQuaRE（ISO/IEC 25010）で理解する保守性の5つの要素を参照ください。

3. モジュール性

3-1. モジュール性とは？

モジュール性の真の目的は**「負債」を「資産」に変えること**であると考えます。
多くの人は「モジュール化＝ただのコードの整理」だと考えています。しかし、その本質はもっと戦略的なものです。
モジュール性を高めて修正による不用意な変更を抑えることで、安全な修正が可能になります。加えて、小さなモジュールとすることで理解のコストを下げ、部品の組み合わせによる再利用性を高めることが可能となります。

3-2. 3つの視点と得られるメリット

モジュール性を構成する要素について、「内部・境界・外部」という3つの視点に切り分けるとスッキリと考えられると思います。これら3つの視点を整えることで得られるメリットは以下の通りです。

視点	構成要素	得られるメリット (品質特性)
内部	高凝集	修正性: 機能に必要な要素を1箇所に閉じ込め、修正の影響をその境界内で完結させることができる 解析性: どこに何があるかすぐわかる
境界	カプセル化	修正性: 内部構造を隠蔽することで、中身を自由に作り変えられる。加えて内部データを壊されないため、データ整合性を守れる。
外部	疎結合	修正性: 不用意な変更を抑えて安全に修正できる 再利用性: 使い回しやすい 試験性: モックへの置き換えがしやすい

---

3-3. モジュール性を支える3つの視点について

高凝集（内部）

「モジュールが独立して、同じ目的を持った仲間だけが入っているか？」を問う視点です。

• 考え方:
  • 例えば、市役所の「税務課」が「ゴミ拾いのルール」まで持っていたら、職員も市民も混乱します。なので市役所は各「課」が独立しています
  • これと同様にモジュールの中身も、一つの専門領域に特化させます
• メリット：
  • 解析性（Analyzability）:
    • 「税率計算を直したい」ときは税務モジュールだけを見ればよくなり、考える範囲を局所化できます
    • 関連するロジックが1箇所にぎゅっと集まっている方が修正箇所の特定やコードの意図把握を容易になります
  • 修正性（Modifiability）:
    • 関連するロジックが1箇所にぎゅっと集まっていることで、修正箇所が限定的になるため、修正効率が上がります

カプセル化（境界）

「外部の人間が、執務室の中まで勝手に入ってこないように守れているか？」を問う視点です。

• 考え方:
  • 市民（外部）が職員のデスクの引き出しを勝手に開けて、書類を書き換えることは許されません。やり取りは必ず「受付窓口（公開メソッド）」越しに行い、中の事務手順（実装詳細）は隠蔽します
• メリット：修正性（Modifiability）:
  • 窓口の出し方が変わらなければ、中の事務処理を変更・改善しても外部に影響を与えません。同様にソフトウェアの文脈で言うと適切なインターフェースによって、内部構造は隠蔽され、リファクタリングに強い構造となります
  • また、内部のデータを直接操作させないことで、モジュール内のデータが意図せず変更されないため、モジュール内のデータの正しさが常に保たれます

疎結合（外部）

「隣の市や県とやり取りする際、相手方の手続きを把握しすぎていないか？」を問う視点です。

• 考え方:

  • 境界の視点は「自身のモジュールを相手にどのように利用してもらうか」という視点でした。反対に、「自分が相手のモジュールをどのように利用するか（依存するか）」というのが外部の視点です。
  • 相手の役所の「内規」や「事務処理の手順」を知らなくても、「全国共通の申請書（インターフェース）」さえあれば連携できる状態を目指します。
  • そうすることで、相手の実体に直接依存せず、抽象的な約束事で繋がります。
  • 疎結合であれば、ある構成要素への変更が他に与える影響を最小限に抑えられるため、リファクタリングや仕様変更が容易になります。
  • 身近な例: 標準ライブラリがその理想形です。例えば、私たちは List インターフェース の add や get という窓口だけを知っていればよく、その実体が ArrayList なのか LinkedList なのか、内部でどう配列を操作しているかを気にする必要はありません。この「中身を知らなくても確信を持って使える」感覚こそが、目指すべき外部の視点です。

• メリット:

  • 修正性（Modifiability）:
    • 疎結合であれば、利用しているモジュールの内部構造がどれだけ劇的にリフォームされても、自分のコードには一切影響が及びません（「影響の隔離」）。
    • 逆に密結合な状態は、相手の執務室の中に土足で踏み込んでいるようなものです。相手が机の配置（内部構造）を変えただけで自分の仕事が止まってしまい、想定外の箇所でデグレード（退行）を引き起こす原因になります。
  • 再利用性（Reusability）:
    • 特定の相手にべったり依存せず「共通様式（API, Interfaceなど）」で動くモジュールは、別のプロジェクトにも簡単に持っていくことができます。
    • これは、依存先が具体（実装）ではなく抽象（インターフェース）に限定されているため、「その部品を使いたいだけなのに、関係ない他の部品まで大量に持ち込まなければならない」という依存の肥大化（芋づる式）を防げるからです。
  • 試験性（Testability）:
    • 抽象（インターフェース）に依存していれば、具体をモックに置き換えるだけで単体テストができます。
    • モックへの置き換えが簡単にできることで、もしテストが失敗しても、原因が「相手方」にあるのか「自分（モジュール）」にあるのかを即座に判断できます。

4. まとめ：モジュール性は「秩序」への投資

モジュール性を高めるということは、コードの中に**「秩序」**を築く作業に他なりません。

1.　「内部」を整えて、専門職を育てる（高凝集）：解析性を高め、理解のコストを下げる。
2.　「境界」を固めて、不正と混乱を防ぐ（カプセル化）：修正の自由とデータの整合性を守る。
3.　「外部」との癒着を断ち、自立した連携を可能にする（疎結合）：不用意な影響を遮断し、再利用性と試験性を高める。

この3つの視点を意識するだけで、AIが生成した無秩序なコードを、洗練されたアーキテクチャへと昇華させる「審美眼」が身につきます。

次回予告

保守性の土台である「モジュール性」が整うと、その上に乗る**「再利用性」や「解析性」**の質も劇的に向上します。次回は、これら他の副特性についても、具体的な実践テクニックを交えて解説していく予定です。お楽しみに！

1. IPA つながる世界のソフトウェア品質ガイド」 ↩