はじめに
設計レビューで「なぜこの構成にしたの？」と聞かれて、うまく答えられないことがありました。自分の中では判断しているのに、聞かれてから整理し始めてしまう。
振り返ると、自分の判断基準は「既存機能への変更影響が少ないこと」にほぼ一点集中していました。間違ってはいないけど、それしか言えない。パフォーマンスやスケーラビリティも何となく意識していたはずなのに、「具体的にどこまで考えればいいのか」がわからなかった。結果として、レビューで聞かれてから「えーと、こっちの方が変更しやすいと思って……」と後出しで整理することになっていました。
前回の記事で「ソフトウェアアーキテクチャはトレードオフがすべてだ」という言葉を紹介しましたが、同じ本にはトレードオフを語るための言葉も書かれていました。それが「ility」です。
ilityとは何か
ilityは、-ilityで終わる品質特性の総称です。本には数十のilityが載っていますが、身近なものだと以下のようなものがあります。
- 可用性（Availability）: システムがどれだけ止まらずに動くか
- 拡張性（Scalability）: 負荷が増えたときにどれだけ対応できるか
- 保守性（Maintainability）: コードの変更・修正がどれだけやりやすいか
- パフォーマンス: レスポンスタイムやスループット
アーキテクチャを評価するための「ものさし」で、他にもテスト容易性、デプロイ容易性、耐障害性などがあります。
ポイントは、全部を満たすアーキテクチャは存在しないということです。何かを優先すれば、何かが犠牲になります。だからトレードオフです。どのilityを優先するかについては、後のセクションで触れます。
ilityを知ると何が変わるか
たとえば、ある機能でキャッシュを導入するかどうかの判断を考えてみます。
キャッシュを入れればパフォーマンスは上がります。ただ、キャッシュの無効化やデータの整合性を管理するコードが増えて、保守性は下がります。キャッシュとDBの間でデータがずれるリスクも生まれます。
ilityを知る前なら「キャッシュ入れると複雑になるからやめておこう」で終わっていたところが、「保守性を優先した。現状のデータ量とアクセス頻度ではレスポンスタイムが要件を満たしているので、パフォーマンスとのトレードオフとして許容できる」と説明できます。判断の中身は同じでも、語れる解像度が変わります。
自分の場合、部署とユーザーを紐づけるテーブルの設計をレビューで聞かれたことがありました。「全部署」を表現するのに、カラムにフラグを持たせて1レコードで済ませるか、全部署分のレコードを愚直に作るか。自分はフラグ方式を選んだのですが、「全レコード作ればよくない？」と聞かれて、うまく答えられませんでした。
ilityの言葉があれば、こう言えたはずです。「全レコード方式はシンプルだけど、部署が増えるたびにデータのメンテが必要になり保守性が下がる。フラグ方式は特殊なロジックが入るが、部署の増減に影響されない。保守性と拡張性を優先してフラグ方式を選んだ」と。
「なんとなく意識してる」を具体化する
ilityは曖昧な判断を具体的な問いに変えてくれます。
「将来的に拡張しやすいように」という言葉は設計の現場でよく出てきます。でも、これだけでは何も決まっていません。何が増えるのか。ユーザー数なのか、機能なのか、データ量なのか。どこまで増えたときに今の設計が破綻するのか。
拡張性（Scalability）という名前がつくと、こうした問いが自然に立ちます。「拡張性を考慮する」ではなく、「ユーザー数が10倍になったときにレスポンスタイムが2秒以内に収まるか」という具体的な問いになります。ilityは答えを出す道具ではなく、「どの品質をどこまで求めるか」という問いを立てる道具です。
そしてこれらの判断軸は開発者間の共通言語としてコミュニケーションのコストを下げてくれます。
どのilityを選ぶか
ilityの一覧を見ると数が多くて、全部を検討しなければいけないように感じるかもしれません。ただ、本にはそれ自体がアンチパターンだと書かれています。サポートするilityが増えるほど設計は複雑になり、それぞれが互いに足を引っ張ることもあります。
本で紹介されているやり方は、ドメインの関心事からilityを「翻訳」するというものです。たとえば「市場投入までの時間」が重要なプロジェクトなら、アジリティ、テスト容易性、デプロイ容易性といったilityが候補になります。「ユーザー満足度」が優先なら、パフォーマンスや可用性が重要になる。ドメイン側の言葉とilityの対応を考えることで、候補を絞り込めます。
もう一つ印象に残ったのは、主要なステークホルダーに上位3つのilityを順位つきで選んでもらうというやり方です。全員の意見が一致することは少ないですが、何が最も重要かについての議論が生まれ、それがトレードオフの判断材料になります。
自分のような開発者の場合、アーキテクチャ全体を設計する場面は少ないかもしれません。でも、機能の設計やテーブル設計のような小さな判断でも「今回はどのilityを優先しているのか」を意識するだけで、レビューでの説明が変わってきます。
まとめ
ilityは新しい知識というより、自分が無意識にやっていた設計判断に名前をつけるものでした。
名前がつくと、判断を事前に言語化できます。レビューで聞かれてから整理するのではなく、提案時点で「保守性を優先した。パフォーマンスはこの水準まで許容する」と語れる。全部のilityを完璧に検討する必要はなくて、「自分はどのilityを優先して、何を犠牲にしたか」を言えるだけで十分だと思います。
参考
- Mark Richards, Neal Ford著『ソフトウェアアーキテクチャの基礎 ― エンジニアリングに基づく体系的アプローチ』オライリー・ジャパン