ソフトウェアアーキテクチャ設計のヒントとベストプラクティス

きちんとした計画を立てずにプロジェクトを始めることはないと思います。ソフトウェアアーキテクチャの設計もまったく同じです。この設計プロセスを効果的に行うことで、あらゆる要件に適切に対応し、ステークホルダーから意見を集める機会を設けることができます。

技術的なビジュアルを使って慎重に計画を立てれば、システムやソフトウェア、アプリケーションのプロトタイプ作成に取り掛かる前にソフトウェアのアーキテクチャと設計の概要を把握することができます。

ソフトウェアアーキテクチャ設計とは？

ソフトウェアアーキテクチャ設計では、プログラミングの知識を使ってソフトウェアの高次的な設計を計画し、後から細部を追加できるようにします。ソフトウェアチームが全体像を描き、プロトタイプの準備を開始するプロセスです。

ソフトウェア開発者は、こうした設計をヒントやベストプラクティスに沿って進めることで、ソフトウェアの特性を徹底的に考え、ソフトウェアアーキテクチャの設計方法を決定することができます。

ソフトウェアアーキテクチャ設計の5つのステップ

1. 顧客の要件を明確に把握する

どの設計にも、機能要件と非機能要件の両方が含まれます。こうした要件は、ソフトウェアアーキテクチャの指針となり、ステークホルダーを満足させられる最終製品の完成という形でプロジェクトを完了する上で欠かせないものです。

最初の時点で要件を明確に理解しておかないと、チームが方向性を見失ったり、他の要件を犠牲にして誤った要件に注力してしまったり、社内リソースを不相応につぎ込んでしまうなどのリスクが生じます。

理解を深めるには、ビジュアルを活用するのが一番です。Lucidchart などのインテリジェント作図ソフトウェアを使って以下の手順で要件をマップ化してみましょう。

• 俯瞰的な視点から始める : まずは鳥瞰的に、要件のスケッチから始めます。マインドマップの作成が効果的です。

• 機能要件をマッピングする : 動詞を使って名詞をグループ化していきます。例えば、機能領域のマインドマップの場合、「表示する」や「編集する」などの動詞を「アカウント」や「プロフィール」に関連付けることができます。

• 非機能要件を検討する : マインドマップを作成しながら非機能要件もメモしておくと後で便利です。「パフォーマンス」などの要件は重要ですが、マインドマップに載せるには抽象的すぎるためです。

こうした要件は、作業範囲を決め、プロジェクトを計画する時点で使用します。

2. 各コンポーネントについて考え始める

機能要件はプロジェクトに非常に大きく影響するため、要件をマップ化した時点で設計やテクノロジーの選択肢がほぼ決まってしまう可能性もあります。

実装のことはまだあまり考えず、ここでは、設計やプロジェクト計画にとって大きな課題となる要件を見極める必要があります。特定の仮定や選択に基づけば、そもそも実現が不可能となる要件もあります。

• 「理想の世界」をまず想像する : 完璧な設計ができるとしたら、どんなものになるか想像してみます。

• 要件のもつ意味を検討して文書化する : チームでドラフトを作り、徐々に発展させていきます。まず、設計の真の要件がどのようなものか読み解きます。ステークホルダーの要望リストに互いに矛盾する項目があったり、他の機能要件や非機能要件と合わない点があることもあるでしょう。

• アーキテクチャの最終的な設計は後回しにする : このプロセスではアーキテクチャの計画が変更される可能性が非常に高いため、最初に作ったドラフトがそのまま実現することはまずありません。

3. アーキテクチャを部分別に分割する

いよいよ、設計をどう実現するかを検討するアーキテクチャの計画段階に入っていきます。ユーザーに価値を届け、適切に開発リソースの使用を図れるような計画を立てるには、アーキテクチャを分割して考えるとよいでしょう。

ケーキを切るときを例に考えてみましょう。大半の人はケーキを縦に切りますが、こうすると、例えば、一切れにクリームとフィリング、そしてスポンジが2～3層入ることになり、すべての要素が含まれます。他方、ケーキを水平にスライスすれば、層が別々になります。

これをソフトウェアアーキテクチャに当てはめてみると、まず層があり、縦に切れば個別の機能を中心としたストーリーができ、横に切れば個別のコンポーネントが現れるということになります。プロジェクトには、こうした水平方向と垂直方向の両方の考え方が必要です。

アジャイルは垂直方向でのスライスを重視しているため、スピーディに価値を提供することができます。顧客に製品の進捗状況を迅速に伝え、開発チームには機能の背後にある各層のフィードバックが提供されます。eコマースウェブサイトのソフトウェアアーキテクチャを例に取れば、例えば決済プロセスなどが垂直のスライスとなるでしょう。

垂直の「決済」部分には、決済情報を保存するデータ層、中間層のAPI、購入者が目にするトップ層のユーザーインターフェイスが含まれるため、提供する機能やイテレーションの対象とする部分を選ぶことができます。

ソフトウェアアーキテクチャプロジェクトに関連する層を図式化することで、全体を可視化し、各層が他の層に及ぼす影響を確認することができます。計画の際には、アジャイル型の垂直の部分一つ一つのつながりを図にしてみましょう。

4. プロトタイプを作成する

プロトタイプを常に作成することで、早い段階で失敗でき、迅速にフィードバックを集めて概念実証を見出すことができます。このプロセスが、作業を検証し、前提条件が有効で漏れがないかどうかを確認する上で重要となります。

プロトタイプを作成する際は、最初の数回のイテレーションは荒削りなものに過ぎず、また最終的なイテレーションも完全に完璧なものではないことを念頭に置いておきます。プロトタイプを作るメリットには、プロトタイプが完成製品として捉えられないため、大半の人がある程度荒い部分を想定してこのプロセスに取り掛かれる点もあります。

プロトタイプの段階は、テストに代わるものではありませんが、必要となるテストの重要な一部を占めています。この段階を活用しましょう。

• 改訂履歴を丁寧に残す : 失敗の繰り返しを防ぐには、プロトタイプ作成過程で学んだ点を文書として残すことが大切です。設計に関する意思決定や途中での変更など、すべてを徹底的に記録しましょう。

• 信頼できる唯一の情報源を確立する : 複数の変更や異なるバージョンで進行が妨げられないよう、ドキュメントを集約した情報源を中心に確実なバージョン管理を行うようにします。

• プロトタイプを図式化する : プロトタイプの変更管理や各バージョンの差異の視覚化に図が役立ちます。

5. 非機能要件を特定し、定量化する

機能要件に加え、非機能要件を検討することも大切です。非機能要件はシステムの特性を定義するもので、機能要件と同様、設計に不可欠なものです。

非機能要件はプロジェクト全体に対する高次的な品質要件であることが多いですが、そうとは限らず、ソフトウェアアーキテクチャの一部のみに関する非機能要件があるシステムもあります。したがって、ローカルな非機能要件についてはステークホルダーを巻き込んで検討を進めることが大切です。例えば、プロジェクトのある垂直部分に対してはカスタマーサービスチームの関心が特に高く、そのチームが非機能要件に関して独自の期待を持っているといったこともあるでしょう。

ただ、要件としてパフォーマンス、ポータビリティやスケーラビリティが欲しいとするだけでは不十分で、期待するレベルを数値化することが欠かせません。どんなプロジェクトであっても、絶対的に完璧なパフォーマンスを実現できることはありません。「パフォーマンス」は、他の要件が満たされるよう指定し、制限する必要があります。

設計を形作る上で非機能要件は重要な役割を果たしますので、必ず定義する必要があります。他にも、以下のような要件を検討していきます。

• パフォーマンス : 個々のスライスやレイヤーに加え、システム全体のパフォーマンスの高さ

• スケーラビリティ : ニーズに合わせてシステムを拡張する現時点と将来での可能性

• ポータビリティ : データのポータビリティとシステムコンポーネントの潜在的なポータビリティ (該当する場合や必要な場合)。

• 拡張性 : 将来のシステムや会社の成長に合わせてシステムが適応可能な程度と適応にかかる労力

• コンプライアンス : プロジェクト全体の設計に大きな影響を及ぼす重要な要素

非機能要件を図式化すれば、こうした要件がどう数値化されているかを確認し、特定の要件を関連するコンテキストの中で検討できるようになります。この時点ですべてを最適化する必要はありませんが、後の段階で非機能要件を最適化するために必要な労力とリソースについては考えておくようにしましょう。

ソフトウェアアーキテクチャ設計のベストプラクティス

よい設計の原則に従ってソフトウェアアーキテクチャ設計を進めるには、これらのベストプラクティスを参考にしてみましょう。

設計をビジュアル化する

設計のコンセプトワークや実装の際にビジュアルを使用することで、設計の背景にある俯瞰的な視点をチームに伝えることができます。プロセスを可視化し、設計におけるさまざまな選択の側面を示すには、図が最適です。

パターンを選ばない

設計プロセスはパターン化することなく、大局的な視点で進めます。パターンを使わず、非常に高次的な水準から全体のコンポーネントを見ることで、システムのオーバーエンジニアリングのリスクを減らすことができます。

最初の設計は初回のイテレーションに過ぎないことを理解しておく

最初の設計は、アーキテクチャ開発で直面するであろう技術的な課題や障害を確認するために行うもので、あくまでプロトタイプに過ぎないと認識しておきましょう。

アーキテクチャ設計は時間が経つにつれて作り込まれ、発展していき、次第に細かい部分まで把握できるようになります。

スコープクリープに注意する

ついさまざまな要素をスコープに詰め込みたくなりますが、スコープクリープが起こると、他の要件が犠牲となり、必要なリソースの消費につながります。これを避けるには、要件を組み込んでプロジェクト計画案を作成し、非機能要件の制限についてステークホルダーと話し合うようにします。ステークホルダーの期待に沿わない点があれば、後にプロジェクトに悪影響が及ぶ可能性もあります。

境界やインターフェイスを意識する

設計を計画する際には、コンポーネント間のインターフェイスとシステムの境界に注意を払います。プロトタイプや次回のイテレーションに取り組む際にこうした情報を参照しやすくなるよう、負担の割り当てを開始します。

ソフトウェアアーキテクチャ設計の改善のために

計画、ステークホルダーからの意見とプロジェクト要件を概説する適切なアプローチがあれば、ソフトウェアアーキテクチャ設計の有効性が高まります。ソフトウェアやシステム、アプリケーション開発の初期段階で計画をしっかりと行えば、プロジェクトもスムーズに進むはずです。