「新しいサービスに検証が追い付かない」「PoCが終わらないまま要件が変わる」――。サービスの増加で選定が複雑化する課題に対し、AWSは「3Cフレームワーク」を提唱する。その中身は。
AWSのサービス数は、240以上ある。AWS Marketplaceには6000社以上の独立系ソフトウェアベンダーが2万5000の製品やサービスを展開している。AWSの仮想マシンサービス「Amazon Elastic Compute Cloud」（Amazon EC2）のインスタンスだけで900通り以上のバリエーションがある。
製品やサービスをキャッチアップしなければならない情報システム部門（情シス）が、膨大なラインアップの選定や導入を効率化するためにできることは何か。AWSが提唱するのが「3Cフレームワーク」だ。
AWSのソリューションアーキテクト、ムクンド・ラオ氏は、膨大な製品やサービスの選定でユーザーが混乱する実態を「ビジネスが技術の迷路に迷い込んでいる」と表現する。製品やサービスを選択するための判断軸を持たない中で、ユーザーは個人の意見が混在するユーザーフォーラムや断片的なブログ記事から情報をかき集めて場当たり的に設計の方針を決めようとしているという意味だ。
さらに、複数のベンダーを並行評価するために長期間の概念実証（PoC）を続け、結局どれも採用判断に至らないまま検証が終わらない企業もあるという。さらに深刻なのは「shiny-new-toy症候群」だ。新技術を追いかけるあまり、問題に無理やりソリューションを当てはめ、非効率なアーキテクチャを拡大し、リソースを浪費し、持続可能性もないという状態だ。
そこでラオ氏が紹介するのは「生き残るのは、最も強い種や最も賢い種ではない。変化に最も適応できるものだ」という言葉だ。この言葉を技術アーキテクチャにも直接適用できると同氏は説明する。
ラオ氏によると、AWSの利用で成功しているユーザーはモダナイゼーションを継続的に進め、段階的な変化を積み重ねている。逆に失敗するユーザーは「全書き換え」をしているという。つまり、古いシステムを一気にリプレースしようとする考え方だ。その結果、プロジェクトは長期化し、途中で要件が変わり、完成時には設計が陳腐化しているといった事例がある。
開発の速度を優先し不完全な実装を進める結果、将来的に改修コストや保守負担が増大するというテックデット（技術的負債）もポイントだ。テックデットも金融負債と同じく、計画的に増大するため、意識的に返済していく必要がある。しかし、経営層から「なぜシステムがこれほど維持コストを食うのか」と問われたとき、答えられるようにしておきたい。その問いへの答えを準備するのが、次に紹介するフレームワークの活用だ。
AWSのシニアソリューションアーキテクト、スシャンス・マンガロール氏が紹介するのが「3Cフレームワーク」だ。
「C」の1つ目は「Capabilities」（ケイパビリティ）だ。大きなシステムを「誰が何の目的で使うか」という単位に切り分ける作業だ。切り分けの方法は4つある。
1つ目が「このシステムの機能は、どの部門が責任を持つか」だ。例えばEC（電子商取引）システムの場合、「おすすめ商品の表示」はマーケティング部門が、「チャットbotでの問い合わせ対応」はカスタマーサポート部門が責任を持つ。部門ごとに予算、判断基準、スキルが異なるため、システムもその単位で分けると管理しやすくなる。注意すべきは「コンウェイの法則」だ。システムのアーキテクチャは組織の通信構造を反映してしまうため、組織の縦割りがそのままシステムの分断になるリスクがある。
2つ目が、「業務の文脈ごとに意味が変わる言葉」を境界にして切り分ける方法だ。例えば「顧客」という言葉は、販売部門では「購入者」、サポート部門では「問い合わせ者」、財務部門では「請求先」と意味が変わる。この意味の境界をシステムの境界として使う。
3つ目が、「関係の強いものは一緒に、関係の薄いものは切り離す」というアーキテクチャの基本原則の適用だ。注文処理に関係する機能はひとまとめにし（凝集）、注文処理と在庫管理は互いに直接依存しないように設計する（疎結合）。疎結合にしておくと、片方を変更しても他方に影響が出にくくなる。
4つ目が、「競争優位を生む機能」を独立した単位として切り出す方法だ。「最速でチェックアウトできる」というのがビジネスにおける差別化ポイントなら、その機能を他の部分から独立させ、性能投資を集中できるようにする。差別化に関係ない機能と同じ設計基準を適用する必要がなくなる。
「C」の2つ目は「Characteristics」（アーキテクチャ特性）だ。セキュリティ・可用性・性能など、機能ではなく「品質や動作特性」を意味する非機能要件（NFR）の中でも、トレードオフを受け入れてでも死守すべき要件を5つ以内に絞ったものだ。
例えば貿易関連の注文管理システムの場合、スケーラビリティ・信頼性・性能・規制準拠を優先すれば、コスト・シンプルさ・アジリティはトレードオフになる。逆に日報の作成機能なら、コスト、実装容易性、保守容易性を優先し、スケールと性能はトレードオフとする。このトレードオフを事前に合意しておくことが、後から「なぜこの設計にしたのか」と問われたときの説明責任を果たす根拠になる。
マンガロール氏はこれをサッカーに例えて説明する。走る、パス回し、基礎体力の構築はは全プレイヤーが実行する標準的な基礎練習だ。これを同氏は、「Well-Architected Framework」と呼ぶ。ゴールキーパーのセービングやフォワードのシュート練習といったポジション別トレーニングは、「アーキテクチャ特性」だという。
同一の基盤を使っていても、機能によって必要となる性能は異なる。だから、“ポジション別トレーニング”が必要だというのが同氏の主張だ。
「C」の3つ目は「Constraints」（制約）だ。予算、タイムライン、スキル、リスクなど、チームがコントロールできない要因を指す。ラオ氏はAmazon,comのCTO、ワーナー・ボゲルス氏が提唱する「frugal architect」（制約の中で最大価値を出す設計者）の概念を引用し、「制約はネガティブな要素ではなく創造性を促進するものだ」と述べる。一般的に人は「制約がなければ自由に設計できる」と考えがちだが実際は逆だという。
「Kubernetesは必須」「特定のデータベースしか使えない」といった企業独自のルールがあった場合は、3Cで設計した後に企業の独自ルールと照合し、必要に応じてルールを更新することが重要だ。
「全社で同じ技術を使う」「統一すれば管理しやすい」といった取り組みは一見成功しそうに見える。しかしマンガロール氏はこれを「失敗する」と指摘する。理由は簡単だ。「機能ごとに“求める特性”が違うから」である。ケイパビリティによって最適な特性は異なる、それにもかかわらず、全てに同じアーキテクチャ基準を適用すれば、過剰コストの発生や性能不足、技術負債の増大が発生する可能性がある。
「重要な機能には多く投資してよい」、逆に「全部平等に設計する必要はない」というのがマンガロール氏の主張だ。
開発や運用過程の判断を記録し蓄積するためのツールにアーキテクチャ決定記録（Architectural Decision Records：ADR）がある。記録する項目は、タイトル、ステータス、コンテキスト、決定内容、結果、代替案、ステークホルダー、アーキテクチャ特性や制約の9項目だ。同じ検討を繰り返さないために、「却下した案」も残すのが大切だ。さらに、「誰が決めたか」も残すことで、責任の所在が明確になる。ADRを使うことで、「障害時の判断の加速化」「経営への説明責任の向上」「ナレッジの蓄積」が可能となる。
Copyright © ITmedia, Inc. All Rights Reserved.
瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓
MFA（多要素認証）を入れたから安心という常識が崩れ去っている。フィッシング集団「Tycoon2FA」が摘発されたが、脅威が完全になくなったというわけではない。
「サイト内検索」＆「ライブチャット」売れ筋TOP5（2025年5月）
今週は、サイト内検索ツールとライブチャットの国内売れ筋TOP5をそれぞれ紹介します。
「ECプラットフォーム」売れ筋TOP10（2025年5月）
今週は、ECプラットフォーム製品（ECサイト構築ツール）の国内売れ筋TOP10を紹介します。
「パーソナライゼーション」＆「A／Bテスト」ツール売れ筋TOP5（2025年5月）
今週は、パーソナライゼーション製品と「A／Bテスト」ツールの国内売れ筋各TOP5を紹介し...
ITmediaはアイティメディア株式会社の登録商標です。
