◯アーキテクチャー（作り方）とビジネスモデル（売り方）の重要性

こんにちは、オルターブースの小島です。

前回に引き続き、SaaS開発ガイダンスとしてのThe Twelve-Factorについてお話していきます。

前回話しましたCAF（クラウドアダプションフレームワーク）やW-A（ウェルアーキテクテッドフレームワーク）はベストプラクティスなので、参考にして頂ければと思います。

ところで、僕たちが開発するのはWebアプリケーションの中でもSaaSで、そこにビジネスを絞っていますが、サブスクリプション型の SaaS ビジネスだと、もう少しコンパクトに考え方を作って行った方が楽なのかなと思っているんです。

なので、SaaS 開発は初めてという方に対して、ここでは何が大事なのかという話をしていこうかなと思います。

僕が考えている Web アプリケーションの作り方なのですが、

誰と作るか（スクラムチーム）

何を作るか（アイデアボーディング）

どうやって作るか（アーキテクチャー）

どうやって売るか（ビジネスモデル）

この辺りが明確にされているかどうかは非常に大事なんですよね。

明確化するために様々なツールを使います。これこそフレームワークなのですが、これを使って一つの資料に落とし込んでいくんですよ。

その中でも、どうやって作るか、どうやって売るか、この2つについて話していきます。

実はこの2つの関係って、凄い重要だということを理解して頂きたいんですよね。

この2つは別々で動いているわけではないんです。

上に挙げた4要素は全て繋がっているんですが、特に「どうやって作るか（アーキテクチャー）と「どうやって売るか（ビジネスモデル）」はめちゃくちゃ密接な関係性を持っています。

例えばこんなアーキテクチャーの場合、どのようなビジネスモデルをを持っているか想像できますか？

並んでいるサーバーの目的はそれぞれあるかもしれないですが、一応ここにweb1 、web 2って書いてあります。

従来型のシステムは大体こんな形でネットワーク構成図から書かれていて、ここからビジネスが展開されていくという話になります。

この構成自体の問題点については今回は省きますが、これだけだとビジネスモデルを想像できるかどうかと言ったら、想像できないと思うんですよね。

ということはSaaS開発やる時に、こういったモデルを作っていくと、ビジネスモデルがあやふやになるわけです。

もっと明確にしなくちゃいけない。

そうするとIaaSではなくて、別のものに作り変えなくちゃいけないんですよね。

そういった考え方を持ってこの構成の問題点について見ていくと、一つキーワードが出てきます。

それが「モノリス構造であるためビジネスの変化に合わせづらい」です。

既にサーバーとして固まった箱でアーキテクチャーを作っているので、これを分解するっていうのはできないですよね。

非常に巨大なモノリス構造で作られているため、ビジネスの変化が間に合わない。もしくはビジネスの変化にシステムが間に合わない。

そういった問題点が必ず出てきます。

理想的なユースケースだけを書いているのも、スタートアップにありがちです。

僕はG’s Academy 福岡でメンターもやっていますので、様々なスタートアップのビジネスモデル触れる機会が多いんですが、理想的なビジネスモデルには理想的なユースケースってやっぱりあるんですよ。

でもそのユースケースだけを見てビジネスを想像できるかというと、実は結構難しい。

なぜかと言いますと、どこで課金して、どこでどういう情報を持って、どういう風にビジネスが展開されるかに関して、実は裏側のバックエンドが凄く大事だからです。

それが分からないとビジネス展開できないわけですよ。

どうやって作るのかを無視したSaaSは必ず破綻します。これはもう絶対そうです。

なので、破綻しないように必ずどこかで作り直しが発生してしまう。

いきなり作り直しが発生してしまうともったいないので、SaaSを作るために押さえておくべきガイダンスが必要になります。

◯The Twelve-Factor Appの意義

ここまで長くなってしまいましたが、The Twelve-Factor Appが出てくるわけです。

The Twelve-Factor AppはSaaS開発におけるベストプラクティスです。

このThe Twelve-Factor upはHerokuというクラウドの技術者が作りました。

HerokuはPaaSでもありますが、PaaSがゆえにビジネスを作りやすいんですよね。

アプリケーションを簡単に実装できるし、ビジネスがそこから展開しやすい。

となると、その展開しやすさが仇になって、凄いモノリシックな構造になりやすいんですよ。

それを回避するためにHerokuの中の人たちがガイダンスを作ったわけです。

ガイダンスの中身はおおよそこんな感じです。

セットアップ自動化のために宣言的フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化するとか、下層のOSの依存関係の明確化し、実行環境間での移植性を最大化するなど。

大事なのは、The Twelve-Factorの方法論は、どのようなプログラミング言語で書かれたアプリケーションでも適用できること、またどのようなバックエンド（サービス、データベース、メッセージキュー、メモリキャッシュなど）の組み合わせを使っていても、適用できる点です。

アーキテクチャーなので、かなり抽象的な言葉ではあります。実際は自分たちで考えなくちゃいけない所が非常に多い。

なので、自分で考えなくちゃいけない部分を簡単に解説しようかなと思います。

これはThe Twelve-Factor App on Azureの全体図です。

1から12までのファクターがあって、それを僕の方でカテゴリー化したものです。

Ⅰ. コートベース

Ⅱ. 依存関係

Ⅴ. ビルド、リリース、実行

これが準備の部分ですね。

あとⅢの設定はアプリケーションのコンフィグとかですね。

バックエンドサービスっていうのはアプリケーションの裏側にあるサービス全般のことです。

データベースであったり、メールであったり、もしくは外部のサービスだったり、色んなものがあります。

あとはプロセス、ポートバインディング、並行性、廃棄容易性、開発本番一致、ログ、管理プロセスがありますね。

様々な要素が12個のファクターとして設定されていて、それぞれにおいてこういう風にやった方がいいですよっていうガイダンスが用意されています。

そのガイダンスをベースに、クラウドではこういう風に実装しよう、アプリケーション開発はこういう風にやっていこう、こういう風に考えていけばSaaS開発がスムーズにいく、といった形で活用されていく。

これについて、次回は超スーパーざっくりな概要を話そうかなと思います。

本気出したら丸一日話せるくらいボリュームがあるんですが、それもそれで面白いので、いつかやりたいですね。（つづく）

☆本記事はオルターブースYouTubeチャンネルの配信動画をもとに再構成しています。

☆配信動画の本編をご覧になりたい方はこちらから！（小島）