LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

技術選定とアーキテクチャレビューが担う役割

技術選定・アーキテクチャレビューの外注とは、システム開発の上流工程で行う「何を選ぶか」「その設計が妥当か」という意思決定を、外部の専門パートナーの支援を受けて進める取り組みを指します。プログラミング言語やフレームワーク、データベース、クラウド基盤の選択（技術選定）と、決定した設計を第三者が点検する工程（アーキテクチャレビュー）は、いずれも実装が始まる前に確定させる必要がある判断です。

この2つの工程は、実装以降のコスト・保守性・拡張性の大半を規定します。AWSは自社の設計原則をまとめた文書で、アーキテクチャの決定内容を運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性という6つの観点から評価する枠組みを公開しています^*1。Google Cloudも同様に、運用の卓越性・セキュリティ・信頼性・コスト最適化・パフォーマンス最適化・持続可能性の6つの柱で設計を評価する考え方を示しています^*2。両社の枠組みは提供事業者ごとに具体的な実装は異なりますが、いずれも「複数の評価軸を並べて判断する」という構造が共通しています。

技術選定・アーキテクチャレビューの外注支援とは、こうした評価軸に基づく点検を、実装を担うチームとは別の立場から行ってもらう委託形態です。次のセクションから、技術選定とアーキテクチャレビューそれぞれの評価軸を具体的に見ていきます。

言語・フレームワーク・DB・クラウド——技術選定の評価軸

技術選定では、プログラミング言語・フレームワーク・データベース・クラウド基盤という4つの領域を、単独の性能比較ではなく複数の評価軸を組み合わせて判断する必要があります。性能だけを基準にすると、チームが運用し続けられない選択をしてしまうリスクがあるためです。

主な評価軸は次の5つに整理できます。第一に要件適合性です。想定する処理量・レイテンシ要件・データ量の増加見込みに対して、その技術が実績のある範囲に収まっているかを確認します。第二にチームのスキル適合です。開発チームが習熟している言語・フレームワークであれば学習コストが小さく、逆に不慣れな技術は初期の開発速度に影響します。

第三にエコシステムと保守性です。ライブラリの更新頻度・コミュニティの活発さ・長期サポートの有無を確認します。第四に総保有コスト（TCO）です。ライセンス費用だけでなく、運用人材の確保コストや将来のバージョンアップ対応コストも含めて比較します。第五に採用リスクです。特定のベンダーや特定の技術に依存しすぎることで、将来の移行が難しくなる度合いを評価します。

これらの評価軸は、どれか一つが優れていれば選定が決まるものではありません。要件適合性が高くてもチームのスキルが不足していれば開発が停滞し、TCOが低くても採用リスクが高ければ長期的な負担が残ります。複数軸を並べて比較し、どの軸を優先するかを意思決定者が合意した上で選ぶ進め方が実務では求められます。

非機能要件で見るアーキテクチャレビューの観点

アーキテクチャレビューとは、確定した設計案が要件を満たしているかを、実装前または実装の初期段階で第三者が点検する工程を指します。レビューの中心となるのは、機能要件ではなく非機能要件です。

代表的な観点は、可用性・性能・拡張性・セキュリティ・運用性の5つです。可用性は障害発生時にサービスを継続できるかどうか、性能は想定される負荷に対して応答時間が要件内に収まるかどうかを確認します。拡張性は将来のデータ量・利用者数の増加に対して、設計変更を最小限に抑えて対応できるかどうかを見る観点です。

セキュリティは、認証・認可の設計や通信・保存データの保護方針が適切かどうかを確認します。運用性は、監視・ログ収集・障害対応の手順が設計に組み込まれているかどうかを見る観点です。AWSの設計原則でも、これらの非機能要件を運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性という6つの柱として体系化しています^*1。

非機能要件の点検には、体系化された評価手法も存在します。カーネギーメロン大学のソフトウェアエンジニアリング研究所（SEI）が開発したATAM（Architecture Tradeoff Analysis Method、アーキテクチャ・トレードオフ分析手法）は、性能・セキュリティ・信頼性・修正可能性などの品質属性間のトレードオフを、複数のステークホルダーが参加する形式で洗い出す手法です^*3。ATAMのような手法をそのまま導入しなくても、複数の非機能観点を並べて確認するという考え方は、規模の大小を問わず設計レビューに取り入れられます。

第三者レビューが内部バイアスを排除する理由

設計を担当したチーム自身がレビューを行う場合、自分たちが下した判断を否定しにくいという心理的な傾向が働きます。第三者によるアーキテクチャレビューを取り入れる意味は、この内部バイアスを構造的に減らせる点にあります。

外部の視点が入ることで、設計担当者が前提として受け入れていた制約——たとえば「この言語を使うことは決定済みだから議論しない」といった暗黙の前提——を、改めて評価軸に沿って問い直す機会が生まれます。これは設計者の能力を問うものではなく、同じ人が意思決定と検証を両方担うことの構造的な限界に対応する仕組みです。

レビューの結果や判断の根拠を記録に残す手法として、ADR（Architecture Decision Record、アーキテクチャ決定記録）が実務で使われています。ADRは、ソフトウェアエンジニアのMichael Nygard氏が2011年に公開した記事で提唱した形式で、構造・非機能特性・依存関係・インターフェースに影響する決定を、その背景や根拠とともに短い文書として記録する手法です^*4。後から参加したメンバーが「なぜこの技術を選んだのか」を追跡できるようにすることが目的とされています^*4。

技術選定・アーキテクチャレビューを外注する際は、レビュー結果をADRのような形式で文書化してもらうことで、意思決定の根拠が担当者個人の記憶に依存せず、組織の資産として残る点も外部支援を受ける利点の一つです。

外注時の委託範囲——どこから任せるか

技術選定・アーキテクチャレビューの外注を検討する際は、委託範囲を工程単位で切り分けて整理する必要があります。全工程を一括で依頼する形と、レビューのみを依頼する形では、必要な情報提供の量も進め方も異なります。

内製で技術選定・アーキテクチャレビューを完結させる場合、要件定義・非機能要件の整理・複数技術の比較検証・レビュー観点の設計という広い領域を、実装チームと兼務する形で担う必要があります。特に複数の技術候補を実際に検証する工程は、候補ごとに検証環境を構築し比較する作業を要するため、実装と並行して進めるチームには負担が大きくなりやすい領域です。

外注で任せられる範囲は主に3つに分けられます。1つ目は技術選定そのものの支援で、要件を踏まえた候補の絞り込みと評価軸に基づく比較を担います。2つ目は設計済みアーキテクチャのレビューのみで、社内で決めた設計案に対して非機能観点の点検を受ける形です。3つ目はADRの整備支援で、過去の決定を含めて意思決定記録を体系化する作業です。

委託範囲を誤って設定すると、レビュー担当者が実装の詳細を把握できず的確な指摘ができない、あるいは委託先が要件を十分に理解せず的外れな提案をするといった行き違いが生じます。委託前にどの工程を任せ、どの工程を社内に残すかを明確にしておくことが、外部支援の効果を左右する分岐点になります。

発注側が準備すべき情報とレビューの進め方

外部にアーキテクチャレビューを依頼する場合、発注側が事前に用意する情報の質が、レビューの精度を左右します。準備が不十分だと、レビュー担当者が前提を推測で補うことになり、指摘の的確さが下がるリスクがあります。

まず用意すべきは、非機能要件を含む要件定義の文書です。想定利用者数・想定データ量・可用性目標（たとえば稼働率の目標値）・レスポンスタイムの許容範囲を明文化しておく必要があります。次に、現在の設計案を図と文章の両方で示す資料です。システム構成図だけでなく、各コンポーネントがなぜその構成になっているかの背景も併記すると、レビュー担当者が設計意図を正確に理解できます。

アーキテクチャレビューを内製で行うには、非機能要件の評価手法・複数のクラウドサービスの特性理解・過去の障害事例に基づく判断経験など、複数分野の知識を持つ人材が必要です。社内に該当領域の経験者が少ない場合、レビューの網羅性が担当者の経験に依存し、見落としが生じるリスクが高まります。

レビュー結果を受け取った後は、指摘事項を「対応必須」「検討推奨」「参考情報」のように優先度で分類し、対応必須の項目から着手する進め方が実務的です。すべての指摘を同じ重みで扱うと、実装スケジュールへの影響が大きくなりすぎるため、優先度付けを発注側と委託先の双方で合意しておく必要があります。

LASSICの技術選定・アーキテクチャレビュー支援

LASSICは元請として、システムの保守・運用を担う立場から、稼働後の運用性を踏まえた設計レビューの視点を提供します。実装後の保守フェーズまで見据えた技術選定・アーキテクチャレビューの支援を必要とする企業に向けて、要件整理から評価軸の設計、レビュー結果の文書化までを支援する体制を整えています。

まとめ：技術選定・アーキテクチャレビュー外注の3つの判断軸

本稿では、技術選定とアーキテクチャレビューという上流の意思決定を、外部支援でどのように補強できるかを整理しました。要点を3つに集約すると、第一に技術選定は要件適合・チームスキル・エコシステム・TCO・採用リスクという複数の評価軸で判断すること、第二にアーキテクチャレビューは可用性・性能・拡張性・セキュリティ・運用性という非機能観点で点検し第三者の視点を加えること、第三に外注する場合は委託範囲を工程単位で切り分け、発注側が要件定義と設計資料を事前に整えることです。

技術選定・アーキテクチャレビューは、実装後の修正が難しい判断が多く含まれる工程です。社内のリソースだけで評価軸を網羅できない場合は、外部の第三者視点を取り入れることで、意思決定の精度を補強する選択肢があります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Amazon Web Services「AWS Well-Architected Framework」（2024年）https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
2. *2　出典：Google Cloud「Google Cloud Architecture Framework」https://docs.cloud.google.com/architecture/framework
3. *3　出典：Carnegie Mellon University Software Engineering Institute「Architecture Tradeoff Analysis Method (ATAM) Collection」https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
4. *4　出典：Michael Nygard「Documenting Architecture Decisions」Cognitect Blog（2011年）https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions

Tweet