はじめに
同じ要件をもとに設計しているのに、設計者によって成果物が異なることがあります。
障害調査を重視して詳細なログを残す設計もあれば、運用負荷を考慮して必要最低限に抑える設計もあります。バックアップの保存期間や権限管理の方針、将来の拡張性をどこまで考慮するかについても、人によって判断が分かれることは珍しくありません。
では、どちらかが間違っているのでしょうか。
実際にはそうとは限りません。同じ要件であっても、プロジェクトの目的や予算、納期、運用体制が変われば、優先されるものも変わるからです。
設計とは、決められた要件をそのまま形にする作業ではありません。さまざまな条件を踏まえながら、何を優先するかを決める工程です。
この記事では、設計者によって成果物が変わる理由を通して、設計の本質について考えていきます。
設計は技術だけでは決まらない
設計では、技術的に優れた構成を考えるだけでは十分ではありません。
システム開発には、利用者だけでなく、運用担当者、保守担当者、インフラ担当者など、さまざまな立場の人が関わります。それぞれが求めるものは必ずしも同じではありません。
例えば、運用担当者は障害調査のために詳細なログを求めるでしょう。一方で、開発期間が限られていれば、実装範囲を絞る判断が必要になることもあります。
また、予算の都合で冗長構成を見送ることもあれば、システムの重要性を考えてコストをかける判断をすることもあります。
設計者の役割は、それぞれの要求を個別に満たすことではありません。目的や制約を整理し、プロジェクト全体として何を優先するのかを決めることです。
設計とは、技術だけでなく、プロジェクト全体のバランスを考える仕事でもあるのです。
優先順位が変われば、設計も変わる
設計では、すべての要求を満たせることはほとんどありません。
ログを充実させれば障害調査はしやすくなりますが、その分だけ保存容量や運用負荷は増えます。
権限管理を細かくすれば安全性は向上しますが、運用は複雑になります。どちらが正しいという話ではありません。
システムの目的や利用者、運用体制、予算、納期などを踏まえ、何を優先するかによって最適な設計は変わります。だからこそ、同じ要件であっても設計者やプロジェクトが違えば、成果物も変わるのです。
良い設計は、理由を説明できる
設計レビューでは、成果物だけを評価しているわけではありません。
本当に確認しているのは、「なぜ、その設計を選んだのか」です。
ログを充実させた理由は何か。
クラスの責務を分割した理由は何か。
共通化を見送った理由は何か。
その選択が、システムの目的や制約を踏まえたものであれば、設計には根拠があります。
反対に、「前のプロジェクトでもそうしていた」「何となくこちらの方が良さそうだった」という理由では、設計の良し悪しを客観的に議論することはできません。
良い設計とは、誰もが同じ設計を選ぶことではありません。
置かれた条件を踏まえ、その選択を説明できる設計です。
まとめ
設計とは、何を優先するかを決める仕事です。
設計者によって成果物が異なるのは、設計者の能力だけが理由ではありません。
システムの目的、関係者の立場、予算、納期など、置かれている条件が違えば、優先されるものも変わります。設計とは、そうした条件を整理し、プロジェクトにとって最も重要なものを優先する仕事です。
そして、その選択に理由があること。それが、良い設計につながります。
コメント