大規模開発では「どのように作るか」も重要

ソフトウェアの開発に限った話ではなく、ものづくり全般に言えることですが、開発の規模が大きくなればなるほど難しくなるのが、プロジェクト全体の整合性の確保です。そこで、全体の意思統一を図るためにも、早い段階で基本的な設計方針を決めることが重要となります。

具体的には、ソフトウェア全体を小さなソフトウェアの「部品」に分けます。その際に、どれくらいの規模でいくつに分けるか、「⁠部品」同士をどのように連携させるかといったソフトウェア全体の構造や、必要とされる機能をどのように実現するかといった処理方式を決めます。

ソフトウェア開発ではこのような設計方針をソフトウェアアーキテクチャと呼び、一種の制約としても機能します。このような制約のもとに開発を進めることで、ソフトウェア品質を（より高いレベルで）一定に保ち、リリース後の機能拡張やメンテナンス性の向上も高めることができます。

先人の知恵「設計パターン」を活用する

このようなソフトウェアアーキテクチャを、プロジェクトごとに新規に設計するのは大変です。そこで、「⁠設計パターン」を活用するのが一般的です。設計パターンというのは、先人たちが試行錯誤を繰り返してきた中で「このケースではこうやって作る」という知識を集約し、汎用性を持たせてカタログ化したものです。

ソフトウェアの設計を担当するアーキテクトは、複数ある設計パターンの中からプロジェクトに最適なパターンを選択する必要があります。いま、ある機能を実現するのに下記の2種類のパターンが利用できるとします。

• 設計パターンA：拡張性に優れているが、開発コストが大きい
• 設計パターンB：低コストで開発可能だが、将来性に不安が残る

ここでどちらを選択するのかはケースバイケースです。プロジェクトの予算、開発期間、チームの技術力、求められているパフォーマンスなどから、最適解を総合的に見極める必要があります。

パターンごとのトレードオフを見極めて「実装ありき」の設計を心がけよう

このように、設計パターンにもそれぞれ一長一短があります。いわゆる銀の弾丸はありません。そのトレードオフを適切に判断するためにも、アーキテクト自身が実装のイメージを持つことが重要です。

企業向けのエンタープライズシステムも、今後はますますクラウドへの移行が進むものと思われますが、基盤となる技術や実装するための手法が変わったとしても、その上で動作するソフトウェアの「設計」という根幹は大きく変わりません。

『アプリケーションアーキテクチャ設計パターン』では、そのようなブレることの少ないコアの技術を、エンタープライズシステムの心臓部であるサーバサイドを中心に、シングルページアプリケーション（SPA）の台頭で再び重要性を増してきたクライアントサイド、SQLなどの伝統的な処理方式とビッグデータ技術という新潮流が混在するバッチ処理、システム間連携と、さまざまな分野を網羅して解説しています。

サンプルコードも豊富に掲載しており、実装のイメージもつかみやすくなっています。これから設計にチャレンジするエンジニア、自身の知識を整理したいアーキテクトにとってバイブルとなる一冊です。