🍣

IT事業は「サービス」と「ソフトウェア」に分類でき、その分類によってDDDを適用すべきかが決まるのでは、という考察

2020/11/28に公開

先日、こんなツイートを見かけました。

ツイートの中で、以下の発言が気になりました。

日本はサービスには投資するけど、ソフトウェアに投資する人は皆無

本当に投資が皆無かどうかはデータを見ないとわからないとして、私は、IT 事業を大きく「サービス」と「ソフトウェア」に分類したことに注目しました。

また、私は普段 Web 開発に関わるエンジニアなのですが、ドメイン駆動設計(以下、DDD)とどのように向き合うのがいいかをよく思案しています。

そこで、今回は、「事業がサービスとソフトウェアのどちらに分類されるか」と「DDD を適用すべきか」という問いの関わりについて考察していこうと思います。

主張としては、エンジニアがどのような技術を使って開発すべきかどうかは、「事業がどのような種別で、何を差別化としていきたいか」によって決まっていくのだろうという当たり前のことですが、そこに「サービスとソフトウェア」「DDD」という思考の軸を提供することで、考察が得られることを目的として論理展開していきます。

サービスとソフトウェアという分類

この分類は、ツイ主さんの思う分類とは違うかもしれませんが、持論を展開します。

私は、IT 事業において、 「そのプロダクトによって得られる現実世界の価値に対して対価を支払う」 事業が「サービス」であり、 「そのプロダクトを利用することそれ自身に価値があると感じて対価を支払う」 事業を「ソフトウェア」と分類します。

具体例でお話しましょう。

例えば、不動産情報サイト「LIFULL HOME'S」は 「サービス」 です。

なぜなら、HOME’S を使って不動産会社は物件を探すお客さんを集客しており、HOME’S を使っている事自体にお金を払っているわけではなく、それを使って現実世界で反響を得られるから対価として利用料を支払っているからです。もし反響が 1 件も無ければ利用を辞めるでしょう。*1

続いて、例えばドキュメントツールの「Notion」は 「ソフトウェア」 です。

なぜなら、Notion を使っていることそれ自体に価値があるからです。Notion を使っている人が、フリーランスエンジニアとすると、Notion を使ったから案件が取れるわけでも、お金が稼げるわけでもありません。ただただ Notion を使っているということに対してお金を払っているはずです。*2


※1 HOME’S の事業内にはもちろんそうではない機能や事業もあるでしょうが、あくまでメインとなる事業は上記のはずです
※2 あくまで直接的には、という話です。Notion というプロダクトによって生産性向上の効果が得られ、結果として売上に貢献することはありえます

他のサービスの例:各種 EC サイト、各種ポータルサイト、出会い系アプリ、メディア、Zenn
他のソフトウェアの例:Evernote、自動運転技術、AWS、Figma、Spotify

※Zenn や note 等のブログサービスや SNS 等の CGM は分類が難しいので考慮の対象外にします。「コミュニティサービス」みたいな第 3 の概念かもしれない

※SmartHR や freee などの SaaS は私の分類ではサービスに入ります。ソフトウェアのようですが、実際は SmartHR を使うことで労務コストの削減につながるからお金を払うわけで、あくまで現実世界での価値に直接影響することが重要なモデルだと考えます

サービスかつソフトウェア(サービスが主、ソフトウェアがサブ)、という分類

上記のように分類を提言しましたが、もちろん実際にはそんなに極端ではありません。HOME’S の中にも、ソフトウェア的な部分はたくさんあるはずですし、不動産会社向けに、毎月の利用料でマネタイズするツール系のプロダクトをリリースしていることも考えられます。

というように、メインの事業はサービス的であっても、マネタイズや事業展開の補完としてソフトウェア的なプロダクトも販売しているという例は散見されると思います。

私が開発に関わっている「オンライン家庭教師マナリンク」も、メインの事業は学生のお子さんを持つご家庭とオンライン家庭教師のマッチングであり、それによるマネタイズは「サービス」に分類されるものですが、オンライン指導専用のアプリをリリースしているなど、将来的にソフトウェア的なプロダクトを展開し、マネタイズしていく道を進んでいます。

ただし、これらのケースでは、あくまでメインの事業は特定の事業ドメインについて何らかの経済活動を発展させることで利潤を得るという形態なのは間違いなく、事業全体としてサービスである、という立場に変わりはないと思います。

ソフトウェアかつサービス(ソフトウェアが主、サービスがサブ)、という分類

ちなみに逆パターンも考えてみましょう。ソフトウェアをメイン事業としながらも、事業ドメインを限定してサービス的な展開をしている事業です。

私は「LINE」が該当すると思います。

LINE は、リアルタイムチャットがアプリでできること、および無料通話それ自体を価値として展開してきました。料金自体は広告費やスタンプによって初期は収益があったと思いますが、ソフトウェアに該当するのは間違いないです。

しかし、今となっては LINE のユーザー基盤を駆使して、決済系、バイト、医療等のドメインを限定したサービス的な展開をしています。これらのドメインを限定したプロダクトでは、そのドメインでの経済活動(バイトなら企業と働き手のマッチングじゃないかと推察されます)がメインスコープとなる、いかにもサービスらしい展開となります。


以上のように、IT 事業をサービスとソフトウェアに分類し、企業がそれぞれ何を軸にしながらどのように展開していくかをモデリングすることができると考えています。

それぞれの分類の特徴

サービス

プロダクトとして自社開発するアプリや Web は大変シンプルです。

これらの事業の場合、多くはクライアントとの契約などの複雑な手続きはすべて書面やノーコードサービス、外部ツールで行われるため、自社開発するプロダクトが持つべきロジックは大変薄いものとなります。

特定の事業ドメインに大変詳しい起業家による事業はこの方向性に進むことで、開発費よりビジネスサイドへの投資によって差別化を築く傾向にあります。マーケティング、広告、SEO などを集客の柱にすることが多いと思われます。

サービスかつソフトウェア

特定の事業ドメインに特化して事業展開し、その結果として、仲介手数料的なマネタイズ以外の手段を追い求めてこの形態に至ることが多いです。または、顧客接点が点になっており、線として関わりたいときにもこの方向性に進むことがあると考えられます。

当初サービスとして展開していたことで、ソフトウェアとして展開するプロダクトも、ある程度枯れている、Web やアプリ技術を用いたプロダクトになることが多いです。

理由としては、尖った技術で差別化するよりも、いかにドメイン知識をソフトウェアで体現し、顧客のコスト削減等に貢献するかが重要視されることと、その時点で採用している人材が比較的一般的な技術者になるからです。

例外的に、SmartHR 等の SaaS はこの分類に入りますが、当初から「サービスかつソフトウェア」な立ち位置を追い求めている点が異なります。労務や会計などの特定の事業ドメインに特化しつつ、仲介手数料ではなく利用料の形式でマネタイズすることが多いことが特徴です。

この分類に進むためにはマネタイズが安定していることが必須です。サービス分野で成功しキャッシュを得るか、初期から利用料によるマネタイズでグロースが見えている状態で投資等を受けるか、といった方針が選択肢としてあります。

ソフトウェア

事業ドメインに限定されません。多くの場合、技術畑出身の起業家による事業です。

事業ドメインというより、誰にでも使われるが職種やユースケースが限られるイメージです。

スマートフォンや AI、VR といったエッジの技術分野に大きく影響を受ける分、参入タイミングが非常に重要で、かつ、グローバルに通用する技術であることが重要なことが多いです。

Figma や Notion 等のツール系で立ち上がった場合は、英語を利用してグローバルに展開し、UI も文化によらず利用できるようなものを追求する必要があります。

Notion が出てきて Evernote が衰退したように、グローバルでの競争によりライバルが圧倒的な技術で逆転してくることが多いため、継続して勝ち続けることがとりわけ難しい市場と言えます。本当に Notion 規模の事業を目指すのであれば、必要となる初期投資の金額も果てしないでしょうから、投資が盛んな国で起業したり、大手企業と穏便なアライアンスを組んで共同研究、といった形式があると思います。

日本だと Pay.jp や STUDIO、microCMS 等が数少ないソフトウェアだと思います。

ソフトウェアかつサービス

この例が、私にはパッとは LINE しか浮かばなかったのですが、グローバル進出を狙いつつ、自国で確実な基盤を築くために展開するのかなと考えられます。

DDD との関連

続いて、これらの事業と、DDD の関連性について考察します。

DDD について

DDD について簡単に解説しますと、事業ドメインを正確に表現することに注力してプロダクトを開発する手法のことです。

これまでの Web アプリケーション開発で主流となってきていた MVC と呼ばれる開発手法(アーキテクチャ)は、あくまで Web アプリケーションをどう組むのかというお題だけに向き合ってきていました。それが、スマートフォンの登場や、関連技術の進歩によって年々 Web アプリケーションへの要件定義が複雑化していくにあたって無理が出てきていた背景があります。

不動産、医療、会計管理といった、もともと必要となる知識が多い事業ドメインでプロダクトを展開し、かつ、そのドメインでの手続を IT プロダクトに載せていこうとした場合、開発者自身もドメインを理解して実装することが求められます。 そのための手法として DDD が脚光を浴びてきました。個人的な見解としては、日本における SaaS ビジネスの流行と関係があるような気がしてなりません。

本当の意味で DDD をやろうとすると、エンジニア以外の職種のメンバーの協力が欠かせません。
開発者にドメインの知識を正しく伝える必要があるからです。

一方で、DDD を実現するために確立されたいくつかの実装手法だけを借りてきて、開発者がドメイン知識を持っていなくても実装を進められるようにする考え方もあり、そちらは軽量 DDDと俗に呼ばれています。

DDD で本当に解決したかった課題は軽量 DDD では解決できないものの、MVC アーキテクチャでは手に負えない、運用に耐えうる実装ができないケースにおいて、DDD が培ってきた実装手法だけを真似するというやり方は、多くの実装者に知見を与えていると思います。

DDD と事業の分類

サービス

サービスには DDD の導入は難しいと考えられます。

なぜなら、サービスの事業においては、複雑なドメイン知識はプロダクトの外側で契約書や運用体制といったやり方で表現されているからです。
不動産検索サイトを開発しているとき、全く不動産の知識が不要とは言いませんが、サイト上でやっていることは物件情報の表示だけであり、物件に関するドメイン知識が役立つ場面は多くはないでしょう。

しかし、当然ながら軽量 DDD のような、保守性を加味した実装や開発を心がける努力が必要なのは言うまでもありません。

サービスかつソフトウェア

この形態になってくると、場合によっては DDD が必要とされます。また、多くの場合において軽量 DDD のアプローチが有効になります。

サービスかつソフトウェアの場合は、エンドユーザーがそのプロダクトを使うことそれ自体に価値を感じてお金を払っています。そのため、特定ドメインにおけるなんらかの事務コストの削減等をメインミッションとしたプロダクトを構築しているはずです。そこでは、そのドメインの専門家の知識に劣るようなプロダクトの仕様では利用できたものではないので、専門知識をサービス上に乗せる必要があります。

そのため、場合によっては DDD が必要となると言えますし、その他の多くの場合においては、プロダクトが複雑化していくことが予想されるため、軽量 DDD 等の手法で運用に耐えうる設計を導入していく必要があるでしょう。

ソフトウェア

ソフトウェアの場合、技術で差別化を行っているため、DDD/軽量 DDD を導入すべき以前に、何をもって差別化していくか定義されている必要があります。そのため、軽量 DDD を導入すべきかどうかなどは一概には言えません。自動運転技術とか、CDN サービスが DDD を導入しているかどうかは大きな問題ではないと思いますし、そもそもドメインを限定する事業じゃないので、DDD を採用しようがないと思います。

ソフトウェアかつサービス

このケースは、憶測でしか無いですが、もともとソフトウェアを運用していた企業だけに、ドメイン知識が欠落していることが大きな問題になるのではないでしょうか。DDD に詳しいエキスパートを採用して、ビジネスサイドも巻き込んでみんなでドメイン知識を学び、実装やオペレーションに適用していくことが求められるかもしれません。

まとめ

IT 事業の分類と、それぞれに DDD がどう関わっているかについて持論を展開してみました。

この持論が活かされるのはエンジニアが転職したいときだと思います。

転職したい、かつ DDD を学びたい、実践したいと思っている人が、「サービス」だったり「ソフトウェア」の会社に行くのは恐らく悪手です。

本当は、「サービスかつソフトウェア」な会社または、その立ち位置を目指すことがロードマップに入っている会社に行くのが良いのではないかと思います。

採用する側は、どうしても「Laravel エンジニア募集中!」とか「React Native エンジニア募集中!」とか言ってしまうのですが、求職者側からすると、その企業がどういった区分の事業を運営していて、どういうことを差別化としてやっていくのかを聞いて、理解しておくと、自身のやりたいことやキャリアとの紐付けがより見えてくるのではないでしょうか。

告知

私が CTO を務めている「オンライン家庭教師マナリンク」では、エンジニアを募集しております。

2020/11/28 現在、Web エンジニア及び、React Native エンジニアを探しております。

「オンライン家庭教師マナリンク」では、本記事でいう「サービスかつソフトウェア」に分類される事業を運営しています。複雑な業務ドメインというよりは、オンライン家庭教師という新しい生き方のドメインを作っていく企業なので、DDD よりはひとまず軽量 DDD で保守性の高い設計をしつつ、事業状況によっては DDD に寄せていくのかなぁ、などと考えています。

興味あれば Twitter に DM 等でご連絡をください!


もし記事が参考になれば、Zenn でサポートいただければ嬉しいです。
技術書・カンファレンス等に当てさせていただきます!

Discussion