IT ソリューションを「買うか作るか」のジレンマに対する新しい解決策 – 「仕立てる」

正直なところ、ソフトウェアを自ら作ること（building）と買うこと（buying）との差別化をするのは好きではありません。必要とする機能を有し、企業の望むような今後の開発ロードマップを持ち、すべてのセキュリティニーズを満たし、非常に安価で素晴らしいサポートのあるサードパーティー製品が何らかの形で存在するならば、自前で開発することには何の競争上の優位性もないのですから、もちろん作るのではなく買うべきです。言い換えれば、買うという選択する明確なケースは実際には存在しないのです。その他の場合、想定される「作るか買うか」の決定はより微妙なものになります。3 つ目選択肢として、既存のビルディングブロックを使って「組み立てる」という方法もあります。こういった様々なビルディングブロックはハイレベルのサービスとしてクラウド上で利用できます。他にも著名なオープンソースのフレームワークとツールもあります。このブログでは、Simon Carter が「仕立てる（tailoring）」というアプローチについて、それがしばしば最良の選択となる理由を説明してくれます。

– Mark Schwartz

以下 Simon Carter による寄稿です：

以前のブログ（Time to rethink Build vs Buy、 Buy vs. Build Revisited: 3 Traps to Avoid）では、「作るか買うか」の微妙な判断と、それがクラウド時代になってどのように変化したのかを見てきました。IT チームのスキル、組織の構造や俊敏性、市場の差別化要因、リスク許容度、承認メカニズムなどすべての要素が影響します。しかし、両方の利点のいいところ取りをする 3 つ目の選択肢が可能になりつつあり、それを真剣に検討するべきでしょう。その選択肢のことを我々は「テーラリング（仕立てる）」と呼んでいます。

構築と購入との間のトレードオフとは通常、市場投入までのスピードとコストに対するリスクとのバランスになります。理由はさまざまですが組織はどちらかを好むものです:

「買う」という判断

ソリューションの購入を選ぶ組織には、市販の（commercial off-the-shelf; COTS）ソリューションが固定価格かつ、ウォーターフォール型デリバリーであることから、それによりリスクを軽減しようとする傾向があります。内部のビジネスケースでは各プロジェクトの経済的根拠が提供され、通常パートナーがソリューションを提供します。ビジネスケースでは、ユーザーエクスペリエンスや使いやすさといった主観的な価値の定量化で苦労し、スケジュールとコストの変更影響が過小評価されがちです。価値を実現するには、数年とは言わないにしても、数か月かかることがあります。

「買う」型プロジェクトの典型的なライフサイクルとは、“評価、購入、統合、テスト、そしてデプロイ”です。

「作る」という判断

ソリューションの構築を選択する組織には、アジャイル型デリバリーと変動価格（最大値は必要）を好む傾向があります。ビジネスケースはより軽量で、主要な指標と、組織、顧客にとっての指標の改善の価値を対象とします。クロスファンクショナルなチームで、オープンソースやカスタム開発でソリューションを提供します。変更は想定されるものなので繰り返し行われます。適切なテクノロジーを選択しようとすることで、プロジェクトの計画段階が遅延する傾向があります。一気に多くを構築しようとすることで進行を遅延させる可能性もあります。バリューストリーム提供開始までには数か月かかることもありますが、ひとたび始まれば価値が継続的に提供されるようになります。

「作る」型プロジェクトの典型的なライフサイクルは、“計画、設計、開発、統合、テスト、デプロイ、保守、そしてスケール（拡張）”です。

その他の選択肢があるのでしょうか？

自分で作るプロダクトのように柔軟性を備えていて、かつ、プロダクトを買うように市場投入までのスピードを得ることができるとしたらどうでしょうか？

ソリューションを作るための技術的な不確実性は飛び越えられて、エンタープライズセキュリティ標準に準拠しつつコスト効率の高い、高可用性で安定したソリューションを確実に提供できるとしたら？

できるのです。そして、それは非常に単純なのです。

「テーラー（仕立てる）」という新しい選択

アマゾンウェブサービス（AWS）のソリューションアーキテクトやパートナーによって構築され、精査されたソリューションとリファレンスアーキテクチャは今や 350 を超えています。完全なドキュメントがあり、複雑なソリューションをジャンプスタートするためのベストプラクティスが提供されています。セキュアでコンプライアンスに準拠した金融サービス環境から、フライトクルー管理のリファレンスアーキテクチャにまで及びます。これらのソリューションは、セキュリティ、高可用性、コストといった AWS ベストプラクティスに準拠しており、数百の選択肢と手作業をわずか数ステップに削減します。

これらのソリューションは、数分で展開した後、組織固有のニーズに合わせたテーラリング（仕立て）を開始できます。

「テーラリング」型プロジェクトの典型的なライフサイクルは、“デプロイ、統合、テスト、（必要に応じて）拡張”です。

「テーラリング」はどう違う？

管理という観点から、「テーラリング」を「買う」や「作る」と比較してみましょう:

ハイレベルには、ソリューションのテーラリングは組織に大きな利点をもたらします。たとえば、アーキテクチャのオーバーヘッドを低減して、迅速かつ安全で、費用対効果が高く、将来要件への適応も高く、回復力があり、信頼性の高いソリューションを提供できます。

AWS のお客様が、すぐに使える、精査されたリファレンスアーキテクチャをご存知でないということがよくあります。これは、TOGAF や Zachman といったアーキテクチャフレームワークが、完成された既製品のアーキテクチャよりも、商用やオープンソース製品を検討する傾向があるためです。

組織にとってあるプロダクトを買うか、作るのか、テーラリングするかを選択する場合に考慮すべき要素は 5つあります:

コントロール: 市場での差別化において最も効いてくるポイントです。購入したソリューションのロードマップをコントロールすることはできないと言ってよく、また一定期間ロックインされる可能性があります。一方、ソリューションを作れば完全にコントロールすることができます – が、全責任を持たなくてはなりません！テーラリングであれば、適切に設計され、堅牢かつ安全で、費用対効果の高いベースラインから始めながらも、必要な場合の反復開発を完全にコントロールできます。AWSのようなクラウドは新しい機能やサービス、統合を繰り返しリリースしており、そのスピードをもってすればネイティブソリューションを将来要件に合わせて容易に拡張することができます。

コスト: ベンダーからソフトウェアを買うことで“規模の経済”のメリットを得られるかもしれませんが、多くの場合は、ランニングコストに加えて、提供する価値と知的財産（IP）の開発コストに基づいて値付けされています。自分でプロダクトを作るとなるとより高くつきます。プロダクトチームを管理し、IP を開発し、アーキテクチャを構築し、プロダクトを実行しサポートしなくてはなりません。テーラリングならば、ランニングコストとサポートコストを支払うだけで済みます。セキュリティ、パフォーマンス、コスト効率、信頼性、運用に関連するコストを最小限に抑えられます。

メンテナンス: 特に市販ソリューションに改修を加えている場合、アップグレードが複雑で費用がかかる可能性があります。プロダクトを作る場合には、OSバージョン、ソフトウェアスタック全体のライフサイクルとその依存関係、バグ修正を管理しなくてはなりません。テーラリングの場合、OS バージョンとソフトウェアライフサイクルは、パッチ管理（OS バージョン更新の自動化）か、バージョンとは無縁のサーバーレスソリューションのいずれかで管理されていることが一般的です。

機会費用(*): ソリューションを買う場合、機会費用は考慮外になります。利益を生み出すコアとなる活動に集中することはできますが、ソリューション構成と他システム統合以外の差別化能力は失われます。ソリューション作成では、対象分野の専門家（subject matter expert; SME）がビジネスの主要部分から長期間外れてしまいます。一方、テーラリングでは、インフラストラクチャーのコード化（Infrastructure as Code; IaC）により数分から数時間でソリューションをデプロイできます。

（*訳注: 機会費用とはある行為を選択することによって失われる、他の最も有利な選択肢から得られたであろう利益のこと）

価値実現までの時間: ソリューションを買うことで価値実現までの時間は大幅に短縮されます。投資すべき時間は、ソリューションを評価、決定、構成し、立ち上げる時間に削減されます。対照的に、適切に機能するユーザーフレンドリーなプラットフォームのバージョン 1.0 を自ら作ろうとすると数ヶ月かかる場合があります。AWS Amplify などの最新のフレームワークを使用してテーラリングできるソリューションでは、セキュリティサービス、スケーラビリティ、ベストプラクティスパターンを統合することができます。さらに、AWS Lambda などのサーバーレス機能を「のり」のように使うことで、リファレンスアーキテクチャとソリューションを重ね合わせ、ハイレベルなサービスをシームレスにつなぎ合わせて、価値実現までの時間を短縮できます。

なるほど、テーラリングはよさそうだ、ではどこから始める？

今日、非常に多くの出発点があります。以下のリンクが役立つでしょう。一つ以上のマルチサービスアーキテクチャパターンを選択して、well-architected な独自のアプリケーションを作成することで、時間を浪費せず、価値提供のための差別化を図っていきましょう。

作るか買うか、次に検討するときには、思考プロセスを「作る vs 買う vs テーラリング（仕立てる）」まで拡げてみてください。

– Simon Carter

PS. 以下に精査済みのソリューションライブラリをいくつかご紹介します:

AWS Quick Starts – AWS ソリューションアーキテクトやパートナーによって構築されたもので、セキュリティと高可用性に関する AWS のベストプラクティスに基づき AWS 上に一般的なテクノロジーをデプロイするお手伝いをします。これらのアクセラレータで、数百のマニュアルの手順をわずか数ステップに削減できるため、本番環境を迅速に構築し、すぐに使い始めることができます。
AWS Solutions Library – AWS によって検証済みの、数十の技術上、ビジネス上の課題に対するクラウドベースソリューションのコレクションを提供します。Well-architected な独自アプリケーションを構築したいのであれば、AWS Solutions Constructs のパターンを使用できます。AWS ソリューションのリファレンスアーキテクチャコレクションからプロジェクトのリファレンスを検索する、AWS ソリューション実装のポートフォリオで自分の AWS アカウント上に直接、自動デプロイ可能なアプリケーションを検索する、AWS ソリューションコンサルティングサービスから選択して、ソリューションのデプロイやインテグレーション、管理について AWS パートナーに支援してもらってください。
AWS Prescriptive Guidance − AWS および AWS パートナーネットワーク (APN) パートナーから、クラウド移行、モダナイゼーション、最適化のプロジェクトを加速するため実績のある戦略、ガイド、パターンが提供されています。これらのリソースは、お客様が AWS を使ってビジネス目標を実現する支援をしてきた長年の経験に基づいて AWSプロフェッショナルサービスチームのエキスパートによって開発されたものです。
AWS GitHub リポジトリーのサンプル: AWS Samples & AWS GitHub

著者について

Simon Carter

AWS エンタープライズソリューションアーキテクトであり、オーストラリアにおける最大かつ最も複雑な顧客を担当しています。AWS 以前は FinTech スタートアップ、HealthTech スタートアップの CIO、データ移行 ISV の CEO を努め、輸送・ロジスティクス、ユーティリティ、FinTech のコンサルティングを行っていました。Monashでコンピューターサイエンスとエンジニアリングの学士号を取得しています。

Mark Schwart

AWSエンタープライズストラテジストであり、The Art of Business Value and A Seat at the Table：IT Leadership in the Age of Agility の著者です。AWS 以前は米国市民権および移民局（国土安全保障省の一部）の CIO、Intrax の CIO、Auctiva の CEO を努めました。Wharton 大学で MBA、Yale 大学でコンピューターサイエンス理学士号を取得、Yale 大学で哲学修士号を取得しています。

翻訳は Solutions Architect 杉中が担当しました。原文はこちらです。

Amazon Web Services ブログ