概要

システム設計に「間違い」はあっても「正解」は存在しない。あるのは、そのときの状況に応じた“最適な妥協”である。 設計とは、さまざまな制約の中で意思決定を行い、将来に向けて形を与える行為である。

「設計の賞味期限」という観点を通じて、どのように設計の寿命を見積もり、制約と向き合うべきかを考察する。

設計の賞味期限とはなにか？

「いつまで持てばよい設計なのか？」

この問いを意識することで、設計は現実的なものとなる。 設計には永続性を持たせるべき領域もあれば、あえて短命でよい領域もある。

賞味期限を考えることは、「制約の受容」にもつながる。すべての設計は制約の中で行われるものである。

設計は制約との対話である

設計とは、本質的には制約の表現である。 無制限の時間、予算、人材、将来の見通しが存在するのであれば、制約を持たない。 しかし現実には、「誰が保守するのか」「いつまで使うのか」「何が変化し得るのか」といった制約が常に存在する。

「この設計は◯年もてばよい」という判断は、設計に対して意図的な制約を与える行為である。 それは、過剰設計を避け、将来のリプレイスも見越した柔軟な思考をもたらす。

観点別に見る設計の賞味期限

いくつかの視点で具体例を踏まえて考える。

1. 事業視点：変化の速さと不確実性

• スタートアップ期は仮説検証が優先され、設計の寿命は1〜2年あれば良いかもしれない
• 成熟した事業は安定性が求められ、3〜5年持てば良いかもしれない

2. 組織視点：チーム構造と人の流動性

• 属人性の高い設計は寿命が短くなりやすいかもしれない
• チームのスキルセットや人数の変動に備えた設計は、長持ちしやすいかもしれない

3. プロダクト視点：機能の安定性と進化性

• 頻繁に変わる機能は「短命設計」で問題ないかもしれない
• 変化しにくい基幹機能は「長寿命設計」が必要となるかもしれない

4. 技術視点：技術スタックの変遷と依存

• OSSのメンテ終了やライブラリの陳腐化は設計の寿命に影響を与える可能性がある
• 技術のアップデートサイクルが早い領域は長寿命の設計が難しいかもしれない

設計に賞味期限を与えるということ

設計に「賞味期限」を持たせることで、次のような効果がある。

• 意思決定が現実的になる
• 後続の保守・リプレイスがしやすくなる
• 過剰設計のリスクを回避できる
• 設計に対する期待値が揃う

これは、設計に対する「責任の範囲」を明確にする行為でもある。

実務での問いかけリスト

• この設計は何年持たせたいのか？
• この設計の制約は何か？（事業・組織・プロダクト・技術）
• 設計の妥協点は何か？それは誰にとって妥当か？
• この設計は将来の誰に引き継がれるのか？

まとめ

• 設計の賞味期限とは、設計における制約の有効期間である。
• 賞味期限を考える視点は事業、組織、プロダクト、技術など様々な観点がある
• 設計の賞味期限を考えることで、意思決定の明確化や過剰設計の回避に役立つ

コードは書いた瞬間から負債化するものだと思うが、ビジネスの成長に追随できなくなる状態をどれくらいの期間で考える（≒負債を許容する期間。賞味期限）かどうかは、設計に良い示唆を与えてくれる。

実際には様々な要因が重なりあって賞味期限が想定より短かったり、長ったりすることもあると思うが、制約を考えるヒントとして賞味期限という観点を持つと良い思う。