Reinvent the Wheel（車輪の再発明）

　世の中には、たいてい似たようなシステムが存在しており、斬新で、過去に類例のないようなシステムなんて、なかなかお目にかかれません。

　にも関わらず、どこのプロジェクトでも、自社の独自性とかを理由に、新しいカスタムメードのシステムを設計したがるものです。こうした状況を“車輪の再発明”と呼びます。

　以下のような症状があれば、車輪の再発明アンチパターンにかかっている可能性があります。

・アーキテクチャとソフトウエアがシステムごとに検討され、複数のシステム間での相互運用性や再利用は検討されない
・市販のライブラリやミドルウエアを用いれば良い機能まで内製する
・1から作るため、アーキテクチャと要求仕様書などの完成度が低い

　こうした症状を防ぐためには、過去に作られた設計情報を生かすのが有効です。古い設計情報には陳腐化したものもありますが、過去のプロジェクトにおいて実用的なシステムを構築するための知恵もたくさんつまっています。

　過去のシステムは、今では古くなった技術で作られていたり、長年の変更・拡張で保守性が低くなっていたりなどの理由から、そのまま活用することはできないのですが、そうした過去の設計の中にある方式設計の工夫や、業務ドメインの設計情報など、捨てるには惜しいものもたくさんあるのです。

　このように、過去の設計情報から、新しいシステムを構築するために有用な情報を集めることを、アーキテクチャ・マイニング（architecture mining）と呼んでいます。

　過去の設計に生かし、車輪の再発明的な無駄な労力を費やすことを避けることは、工数の削減になるだけでなく、業務要求や技術要求に対する品質向上に大きく貢献するのです。

Architecture by Implication（含蓄アーキテクチャ）

　含蓄アーキテクチャとは、システムのアーキテクチャ仕様書がなく、担当アーキテクトの頭の中に頼ってシステム構築が行われることです。

　確かに、経験豊かなアーキテクトであれば、アーキテクチャに関する要件をいちいち文書化しなくても、関係者に適切な指示や調整を行い、運が良ければ立派にシステムを構築できるのかもしれません。しかしそれは、さまざまなリスクにさらされることにもなるのです。

　つまり、以下のような症状があれば含蓄アーキテクチャアンチパターンにかかっている可能性があるのです。

・アーキテクチャ計画と仕様書が存在しない
・アーキテクチャに関する潜在的なリスク（スケーラビリティ、ドメイン知識など）がプロジェクトが進行するにつれ顕在化してくる
・場当たり的なアーキテクチャであり、性能の不足、アーキテクチャのシンプルさ、ユーザーの使い勝手などが十分に考慮されず、こうしたリスクがプロジェクトの失敗につながる
・アーキテクトの勘と経験に頼るため、新技術が無視される（もしくは安易に新技術を採用する）

　含蓄アーキテクチャを予防するためにはどうしたらいいのでしょうか。

　そもそも、アーキテクチャには、主として以下のような種類があり、領域ごとに関係者も異なっています。
----------------------------
・ソフトウエアアーキテクチャ
・ハードウエアアーキテクチャ
・ネットワークアーキテクチャ
・永続化（データベース）アーキテクチャ
・セキュリティーアーキテクチャ
・システム管理アーキテクチャ　……などなど
----------------------------
　これらについて、それぞれの目的・目標を明確にし、関係者の意見を調整するためには、アーキテクチャの設計資料を作成し、情報を共有化する必要があるのです（とは言え、設計ドキュメントの量が膨大になると“委員会設計”アンチパターンになりかねないので注意が必要です）。

　次回（最終回）は、プロジェクト管理のアンチパターンを紹介します。

【参考文献】
William J. Brown (著) 、Raphael C. Malveau (著) 、Hays W.“Skip” McCormick III (著) 、Thomas J. Mowbray (著) 、岩谷宏 (訳)

『「アンチパターン」ソフトウエア危篤患者の救出』ソフトバンククリエイティブ刊 ISBN 978-4797321388