Alternative Architecture DOJO

オルターブースのクラウドネイティブ特化型ブログです。

【週刊オルターブース】The Twelve-Factor Appで実践するSaaS開発 Vol.1 ~無視してはいけないフレームワークと開発フェーズとは?~

こんにちは!株式会社オルターブース代表取締役のこじまです。
最近はSaaS開発を始めたり、既にSaaS開発を行っている方も多いですよね。

一方で、「SaaS開発って何から始めたら良いの?」と悩みを抱えていらっしゃる方も多いと思うんです。 そこで今回は「The Twelve-Factor Appで実践するSaaS開発」をテーマに、数回に分けてお話をしていこうと思います。

自己紹介

まずは簡単に自己紹介をしますね。先ほども申し上げた通り、私は株式会社オルターブースで代表をやっている小島 淳と申します。
Microsoft Regional Directorに就任し、Microsoft Azureの啓蒙活動をしております。
会社としても3年連続、計4回にわたるマイクロソフト パートナー オブ ザ イヤー を受賞しており、Microsoft Azureを提供するマイクロソフトからもAzureのプロフェッショナルとして認められているのが弊社オルターブースであります。
これからクラウドのことについて色々と発信をしていくのでどうぞよろしくお願いします。

▼私の紹介記事もあります aadojo.alterbooth.com

フレームワークについて

では、本題に戻りましょう。
SaaS開発の内容に入る前に、まずはフレームワークに触れておきますね。

クラウドの導入やアプリ開発の設計には、フレームワークを活用することが重要になってきます。
フレームワークとは「枠組み」や「骨組み」「構造」といった意味を持つ言葉で、開発を行う際のプログラムに一定のルールや制限をつけてくれるものです。

現在クラウド導入やクラウドを活用した開発ではCloud Adoption Framework(CAF)Well-Architected Framework(WAF)といったフレームワークが活用されていますが、これらが一体に何に使われるのかについて、簡単に説明していきたいと思います。

Cloud Adoption Framework(CAF)について

Cloud Adoption Framework(CAF)は、主にエンジニアというよりはビジネスよりの方を対象としたフレームワークになっています。

戦略、計画、準備完了、移行があり、さらにガバナンス管理というそれぞれのフェーズがあります。 それぞれのフェーズごとにツールやテンプレも用意されているので、それを基に各フェーズの中の計画を作っていく。

これがCloud Adoption Frameworkです。

Well-Architected Framework(WAF)について

一方、Well-Architected Framework はエンジニアの方が設計するための材料になる5つの柱で成り立っています。

その柱というのは、コストの最適化、オペレーショナルエクセレンス、パフォーマンス効率、信頼性、セキュリティのことです。

Azure自体のベストプラクティスが入っているというわけなんですね。

CAFとWAFの違い

そしてこれらがどのようなところで使えるかというところについて、解説します。

下記画像はクラウド導入のプロセスなのですが、まずCAFについては最初の部分で活用します。
デジタル資産の評価から始まり、戦略を作ってどうやっていこうするのか、移行した後どうするのか、そういったことを考える場面で活用されます。

ここでは「WAF」を「W-A」と記載しています

ちなみに弊社では3rd Party、解決提案の部分は弊社サービス「KOSMISCH」を使用しています。

新しい環境を考えるときは、CAFの中から連動してWAFに入っていき、設計して合理化をしていく。 これが実際の流れといったところです。

CAFとWAFは同一の流れで語ると、少し混乱してしまうこともあるので、分けて考えたほうが良いと思っています。

無視してはいけないSaaS開発の重要フェーズ

さて、上記の前提を踏まえた上で、今回のテーマSaaS開発について触れていきますね。
冒頭でも申し上げた通り「SaaS開発をこれから始めたいけど何からやればいいの?」「本当の意味でのSaaS開発を知りたい」という方も多いと思うんです。 そこで今回はSaaS開発における技術、導入、設計についてお話していきます。

まず、開発の際には「誰と作るか」「何を作るか」「どうやって作るか」「どうやって売るか」という4つのフェーズがあると思うのですが、 その中でもSaaS開発では「どうやって作るか」「どうやって売るか」というのが非常に重要になってきます。

もちろんすべて大切ではあるのですが、SaaSのアプリケーション設計においてはこの2つが非常に重要になってくるんです。 ここで先ほどご紹介したフレームワークを活用し、埋めていきます。

この部分についてもう少しミニマムに考えていきましょう。
下記画像を見てみてください。

これらはデータベースが並んでいるだけですね。インフラ構成図です。
昔はよくこういうので作られることも多かったんです。もしかしたら今でもこのような構成図で説明されている方もいらっしゃるかもしれません。

ただ、はっきり言ってこの構成からはどのサービスがどのように影響を受けているのかが全く分かりませんよね。

このようにサーバーだけ並べても、モノリス構造なのでビジネスの変化にも合わせずらいんですね。

一方これはどうでしょうか?

何かのユースケースだと思いますが、ここから何のビジネスなのか想像できますか?

これは先ほどの構成図とはがらりと変わって、アプリケーションの中のユーザーの動きを模した図です。 実際これもよく見かけますよね。

「ユースケースがあるからアプリケーションの動き分かるでしょ?」ってパターン。
でも、これ、分かるわけないんですよね。

結局のところアプリケーションアーキテクチャーとしての図もビジネスとしてのユースケースの図もどちらも必要なんですよね。

両方の整合性を合わせ、設計して導入することがSaaS開発には重要です。

「どうやって作るのか」を無視したSaaSは必ず破綻します。

では、どのようにしてSaaSを作っていくのか。
ここで今回のテーマにもなっている「The Twelve-Factor App」の考え方を活用するというわけです。

~Vol.2に続く~

次回、「The Twelve-Factor App」について解説していきます。
来週もお楽しみに!

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
オルターブースではクラウド導入を検討している企業様のためのトレーニングを提供しています。

・自社でクラウド導入を検討されている方
・導入にあたり、どこから始めたらよいかを教えてほしい方
・既存のアプリケーションをAzureに移行したい方
・アプリケーションをAzureに移行したけど、もっとAzureを活用したい方

などの課題をお持ちの方はぜひ一度ご検討ください。

▼トレーニングの詳細はこちら
www.alterbooth.com
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

文:小島
絵、編集:吉嵜

www.alterbooth.com

cloudpointer.tech

www.alterbooth.com