SaaS製品がアーキテクチャに適合するかどう評価しますか？

Question

IT Interview Practice · Accepted Answer

**SaaS製品のアーキテクチャ適合性**は、実際の連携動作と運用動作がソリューションの制約を満たすかをテストして評価します。これは候補製品の適合点と不足点を調べる作業であり、単なるソフトウェアの内製・購入判断ではありません。

## 連携マップから始める

```text
[Identity provider] --> [Candidate SaaS] <--> [Integration adapter]
                              |                      |
                        [Data export]          [Internal systems]
```

各接続について、必要な動作、ベンダーが文書化した機能、試用で得た証拠、残る不足点を記録します。選択肢を採点する前に、必須条件に関わる障害と好みを分けます。魅力的な機能がいくつあっても、必須機能の欠如を埋め合わせることはできません。

## 検証する領域

- **ID：** サインイン連携、アカウントのプロビジョニング、ロールの対応付け、適時のアクセス剥奪。
- **データ：** 所有権、対応する保管場所、エクスポートの完全性、識別子、複数コピーにまたがる削除動作。
- **インターフェース：** APIの対象範囲、クォータ、ページネーション、Webhookの再送、バージョン方針、サンドボックスの制限。
- **運用：** サポートのエスカレーション、サービスの約束、監査の可視性、復旧責任。
- **撤退：** 製品を置き換える際にデータを取得し、利用側を再接続できる現実的な能力。

## 例

CRMのデモで顧客レコードを表示できても、重大な不足が隠れている場合があります。エクスポートAPIが添付ファイルを省略したり、Webhookが過去のイベントの再送に対応していなかったりします。添付ファイル付きの代表的なレコードをテストし、イベントの取りこぼしを模擬します。実際のAPIクォータと想定日次件数から、追い付きに必要な時間を見積もります。

## 判断と落とし穴

各不足点を、設定、アダプター開発、受け入れる制限、導入阻害要因に分類します。責任者を定め、アダプターの継続サポート費用を含めます。試用環境では異なる機能が利用できることがあるため、提案された契約プランと契約内容に照らして機能を再確認します。

面接では、証拠によって推奨がどう変わるかを示します。業務上重要な経路を誰もテストしていなければ、ベンダーのチェックリストがすべて「はい」でも根拠として弱いままです。

連携マップから始める

検証する領域

例

判断と落とし穴

関連する質問